Page 5 of 10

Реализация Condensed View

Posted: Mon 27 Jul, 2015 23:06
by DrKnS

Latest post of the previous page:


Реализация Condensed View

Posted: Thu 26 May, 2016 02:06
by buniak_a_h
Окончательно сделал реализацию Condenced View макросом. Последнее изменение: запоминание-восстановление закладок. Сделано тупо (через переход и посылку клавиатурной комбинации RAlt<n>. Если кто знает, как сделать занесение закладок более корректно - напишите, пожалуйста!

Реализация Condensed View

Posted: Sun 05 Jun, 2016 12:19
by John Doe
buniak_a_h wrote: Если кто знает, как сделать занесение закладок более корректно - напишите, пожалуйста!
Не трогать закладки.
Вообще не менять содержимое редактора, а для работы открывать новый редактор.

По коду.
buniak_a_h wrote: создадим глобальную таблицу для хранения информации по концам строк
Здесь не нужна глобальная таблица.

Ну и то что раньше писал: хранение ei и EID между вызовами абсолютно различных функций непросто отследить, и вообще крайне сомнительная практика.
Навскидку, посмотрим что у вас в ProcessEditorEvent.
Насколько мне известно ProcessEditorEvent может приходить не только для текущего редактора.
Вы же полагаетесь на то что редактор всегда текущий, и используете в обработчике (когда-то) закешированные значения ei и EID.

Реализация Condensed View

Posted: Sun 05 Jun, 2016 14:26
by buniak_a_h
John Doe
Спасибо за анализ. Поясню некоторые моменты, которые я просто не знаю, как сделать по-другому, т.к. (а) это мой первый опыт написания процедуры на lua и (б) не смог найти детального описания областей видимости и времени жизни переменных.
John Doe wrote: Не трогать закладки.
Не трогаю. Обошёл по кривой. Запоминаю позиции закладок, при восстановлении перехожу на позицию закладки и посылаю Keys('RCtrl[0-9]")
John Doe wrote: Здесь не нужна глобальная таблица.
Мне нужно, чтобы информация оставалась между вызовами функций. Т.к. я не знаю, какое время жизни переменных, единственный способ обеспечить доступность информации между разными вызовами функций, который я смог придумать, это - заведение таблицы в _G, внутри неё - для каждого редактора по его ID-у таблицы для хранения данных. Придумал опять же не сам, а сделал по примеру макроса, расставляющего переносы по тексту (EditWrap.lua). Если подскажете, как это делают умные люди - буду благодарен.
John Doe wrote: Ну и то что раньше писал: хранение ei и EID между вызовами абсолютно различных функций непросто отследить, и вообще крайне сомнительная практика.
<...> и используете в обработчике (когда-то) закешированные значения ei и EID
Эти переменные присваиваются в функциях condition. Неужели между condition и action может произойти переключение на другой редактор?
John Doe wrote: Навскидку, посмотрим что у вас в ProcessEditorEvent.
Насколько мне известно ProcessEditorEvent может приходить не только для текущего редактора.
Я же проверяю, находится ли редактор, соответствующий переданному в обработчик события id-у, в condenced-режиме. Если да - всё, контроль за ним полностью обеспечивается макросом. Если нет - я ничего не делаю. Я не знаю, должна ли функция ProcessEditorEvent возвращать результат типа "обработан / не обработан". Было бы логично, чтоб не вызывать остальные обработчики. Не нашёл, где такое может быть описано.
John Doe wrote: не менять содержимое редактора, а для работы открывать новый редактор
Да, это было бы хорошо. Но не представляю себе, как можно открыть новый редактор, а старый "спрятать" (чтоб на него нельзя было переключиться). Если этого не сделать, то исходный текст возможно будет править, что приведёт к рассинхронизации сжатого и несжатого текстов. Ну и вообще куча проблем.

Реализация Condensed View

Posted: Sun 05 Jun, 2016 15:00
by John Doe
buniak_a_h wrote: Т.к. я не знаю, какое время жизни переменных
macroapi_manual.ru.chm
buniak_a_h wrote: Эти переменные присваиваются в функциях condition.
Возможно, но в самом определении макроса этого не видно, а присваивания эти не находятся в одном месте, а встречаются неоднократно и в разных функциях.
И используются присвоенные значения тоже повсеместно, а не только в функциях action.
buniak_a_h wrote: Не нашёл, где такое может быть описано.
А это тут при чём вообще.
Я описываю ситуацию, когда событие ProcessEditorEvent может придти для фонового редактора.
buniak_a_h wrote: Но не представляю себе, как можно открыть новый редактор, а старый "спрятать" (чтоб на него нельзя было переключиться).
Открыть модальный редактор.
buniak_a_h wrote: Если этого не сделать, то исходный текст возможно будет править,
Или просто запретить модификацию.

Реализация Condensed View

Posted: Sun 05 Jun, 2016 16:15
by buniak_a_h
John Doe wrote: buniak_a_h писал(а):
Источник цитаты Т.к. я не знаю, какое время жизни переменных
macroapi_manual.ru.chm
А если несколько экземпляров FAR - переменные общие, или нет? А editor.info.id - уникальный? Или всё в пределах одного экземпляра? Что как-то они между собой взаимодействуют - я понял. Во всяком случае, пока ВСЕ экземпляры не закроются, значение, занесённое в _G, остаётся доступным. Впрочем, начерно, _G.EditorsCondView можно заменить на local EditorsCondView - попробую.
John Doe wrote: А это тут при чём вообще.
Тут это - ни при чём. Просто нужно же иметь механизм прерывания цепочки обработчиков события (типа done). Просто чтоб другой обработчик не вмешался в работу макроса.
John Doe wrote: Я описываю ситуацию, когда событие ProcessEditorEvent может придти для фонового редактора.
1. Не знаю, что такое "фоновый редактор".
2. Если фоновый редактор в состоянии condenced, то обрабатывать надо независимо от того, фоновый он или нет. В начале функции ProcessEditorEvent я же проверяю if not _G.EditorsCondView[id] then return end - т.е. включен ли сжатый режим. И что тут не так?
John Doe wrote: Открыть модальный редактор
И потерять возможность переключаться в другие окна??? Ну ничего себе! Нужно запретиь переход только на исходный редактор, а не вообще на любой!
John Doe wrote: Или просто запретить модификацию.
Опять же не представляю, как запретить модификацию без перехвата нажатий клавиш. Собственно, я запретил модификацию в сжатом режиме.

Реализация Condensed View

Posted: Sun 05 Jun, 2016 23:10
by buniak_a_h
John Doe
Может, поможете с таким вопросом:
Я в документации (macroapi_manual.ru.chm, раздел "Обработчики событий") нашёл такую фразу:
Функции condition и action обработчика вызываются с теми же параметрами, с которыми вызывается соответствующая экспортируемая функция (см. мануал LuaFAR).
Что такое "соответствующая экспортируемая функция"? Поиск по condition ничего не дал, в разделе export.ProcessEditorEvent параметры абсолютно не соответствующие тем, что получают функции (первый параметр я получаю таблицу, а описан EditorID: integer.
Я использовал то, что подсмотрел в других макросах (в частности, LuaSpell.lua, EditWrap.lua). И почему-то работает. Чего-то я не понимаю... :(

Реализация Condensed View

Posted: Mon 06 Jun, 2016 00:47
by buniak_a_h
О! Как-то мимо моего внимания Ваш пост проскочил...
John Doe wrote: Я тут критикую избыточную область действия переменных ei, EID, объявленных в самом начале скрипта.
Утверждаю, что общие переменные необходимы только в макросах, для передачи значений из condition в action (поскольку других механизмов для этого не предусмотрено).
Так у меня именно так и делается (и именно для этого и используются)! В функции IsEditorActive эти переменные присваиваются, а используются в функциях action. Т.е. в точности то, что Вы написали...

Реализация Condensed View

Posted: Mon 06 Jun, 2016 06:30
by Shmuel
buniak_a_h wrote:в разделе export.ProcessEditorEvent параметры абсолютно не соответствующие тем, что получают функции (первый параметр я получаю таблицу, а описан EditorID: integer.
Довольно серьёзное заявление. Можете доказать на примере, чтобы не было голословно?

Реализация Condensed View

Posted: Mon 06 Jun, 2016 11:14
by John Doe
buniak_a_h wrote: А если несколько экземпляров FAR - переменные общие, или нет?
Разные экземпляры никак между собой не взаимодействуют.
buniak_a_h wrote: Тут это - ни при чём.
Значит и нечего мешать всё в кучу. Если что-то в Энциклипедии не ясно, значит надо спросить, но в соответствующей теме.
buniak_a_h wrote: В начале функции ProcessEditorEvent я же проверяю if not _G.EditorsCondView[id] then return end - т.е. включен ли сжатый режим. И что тут не так?
А то, что id может оказаться не равным EID, если редактор фоновый (т.е. не является активным окном).
buniak_a_h wrote: Нужно запретить переход только на исходный редактор, а не вообще на любой!
И так можно, всё в ваших руках.
buniak_a_h wrote: Собственно, я запретил модификацию в сжатом режиме.
Оказывается умеете.
buniak_a_h wrote: не представляю, как запретить модификацию без перехвата нажатий клавиш.
И перехватить можно, да.
buniak_a_h wrote: Может, поможете с таким вопросом:
Разумеется. В соответствующей теме.

Реализация Condensed View

Posted: Mon 06 Jun, 2016 11:27
by John Doe
buniak_a_h wrote: Т.е. в точности то, что Вы написали...
Нет же.
Пример:
Здесь область действия переменной ограничена двумя функциями, и это видно невооружённым глазом, соответственно откуда пришло значение очевидно, и также можно не беспокоиться о том, что переменная будет модифицирована где-то в другом месте.

А у вас:
1. Переменные общие для нескольких макросов (нормально, но уже надо быть внимательнее)
2. Визуально проконтроллировать сложно, поскольку используются переменные не в теле action/condition, а в ранее определённых функциях, которые откуда только не вызываются (не только из макросов).
3. Таких функций много, одна вызывается из другой и т.п. (ну можно же передавать значения параметрами, почему не пользуетесь)
4. Эти же переменные используется в обработчиках событий, и в этом случае мне уже совсем неясно, где предполагается их инициализация.

Я даже готов поверить, что вы свой код видите насквозь, и всё там предусмотрено.
Я только утверждаю, что практика эта плохая. Такой код сложно понимать, и модифицировать.

Реализация Condensed View

Posted: Mon 06 Jun, 2016 13:05
by buniak_a_h
John Doe
Т.е. если я вместо вызова функций в каждом condition буду делать одно и то же (получение Editor.ID-а), то это будет хорошая практика, а объединение одинакового кода в функцию - для LUA считается плохой? Ну, перенести кусок текста - дело секундное. Видимо, я неправильно понимаю стиль и критерии эффективности LUA и FAR

Реализация Condensed View

Posted: Mon 06 Jun, 2016 13:11
by HaRT
buniak_a_h wrote: объединение одинакового кода в функцию - для LUA считается плохой?
Ну зачем Вы передёргиваете? Ничего такого тут никто не утверждал. Впрочем, предлагаю придерживаться конструктивного русла.

Реализация Condensed View

Posted: Mon 06 Jun, 2016 13:35
by John Doe
buniak_a_h wrote: то это будет хорошая практика
Хорошая вот:

Я не утверждаю что надо вот прям только так, но надо стремиться к ясности

Реализация Condensed View

Posted: Mon 06 Jun, 2016 13:44
by HaRT
John Doe wrote: Хорошая вот
Заранее прошу прощения за нубский вопрос: а что мешает нам поместить переменную a прямо в „таблицу“ (?) Macro?
Где бы почитать, что эти Macro собой представляют с точки зрения виртуальной машины Lua?

Реализация Condensed View

Posted: Mon 06 Jun, 2016 13:47
by buniak_a_h
John Doe wrote: Хорошая вот:
1. Насколько я понимаю, код в принципе нерабочий. condition должна возвращать или boolean, или число-приоритет. а a в Вашем примере - это (в моём контексте) пара (ei, EID).
2. Да я, вроде, практически так и написал. Замените f1 на IsEditorActive, f2 на CondViewOff (или CondViewOn) - получится тот же код