View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002161 | Far Manager | Macro | public | 2012-10-01 08:54 | 2013-01-26 09:20 |
Reporter | vskirdin | Assigned To | shmuel | ||
Priority | urgent | Severity | block | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | 7 |
Product Version | 3.0 | ||||
Target Version | 3.0 | Fixed in Version | 3.0 | ||
Summary | 0002161: Не работают макросы, если отустствует необходимый набор dll луо | ||||
Description | При отсутствие набора dll, завязанного на луо, не работают макросы, но интерфейсная часть, связанная с макросами, юзеру все же показывается. Это вводит в заблуждение. Необходимо либо: 1. вообще на Ctrl-. (и прочие макросовые интерфейсы) не реагировать (что не есть правильно) 2. выводить сообщение, что в ядре отсутствуют необходимые компоненты (и тоже не реагировать) - тоже политически неверно. 3. вкомпилить ядро луо в ФАР, при этом если рядом есть необходимые dll - юзать их (это дает возможность обновлять ядро луо без перекомпиляции и юзать макросы, если необходимых dll нет). 4. не выкидывать старое ядро макродвижка, а сосуществовать с ним (в настройках выбирая нужную математику). | ||||
Steps To Reproduce | 1. стартуем FAR с параметром /p 2. макросы не работают (ожидаемо, т.к. luamacro не подгрузился) 3. пытаемся записать простое кнопкосочетание Esc = CtrlO: Ctrl-. Ctrl-O Ctrl-Shift-. выбираем из списка Esc жмем Enter. Появляется диалог, который кроме как по Esc или Cancel закрыть нельзя. | ||||
Tags | No tags attached. | ||||
Build | 2874 | ||||
|
Имхо, надо движок в ядро. |
|
В идеале, конечно, 4 лучше. Но, Боливар не вынесет двоих. Если уж перешли на LUA, надо чтобы он был всегда. Если не компилить в ядро, то хотя бы перенести из плагинов к фар и без него не стартовать. |
|
> В идеале, конечно, 4 лучше. И чем оно лучше? Даже если предположить, что будут возможны разные движки, и каждый пишет на своем любимом языке, это ж неудобно. Нужно единообразие, для единой документации, обмена макросами, и т.п. Много свободы, это не всегда хорошо. (Луа для макросов учится за одно утро на свежую голову. За день максимум. Даже легче, чем оригинальный макро язык.) Наконец-то свершилось и у Фара не самопальный, а профессиональный язык макросов. Но он все же должен быть для юзера "как родной", "как раньше", из коробки, а не сбоку в плагине, как сейчас. |
|
А PowerShell не родной для винды? ;-) |
|
> А PowerShell не родной для винды? Только начиная с 7-ки (или с Висты?). Для макроязыка он тяжеловат и прослойка типа FarNet опять же нужна, в Фар не встроишь. PowerShell не создавался для автоматизации нативных приложений. Lua изначально создавался именно с такой целью и преуспел во вмогих отношениях. Lua - более правильный интструмент для макродвижка Фара. Для более сложных задач есть другие инструменты, включая PowerShell. |
|
+1 за внесение lua в ядро. sqlite же не стали делать отдельной dll. |
|
вариант №1. ну на крайний случай №2 с галкой больше не показывать. но тогда нужно точно такое же сообщение при отсутствии арклайта. ибо у нас _F_ile and _A_rchive Manager. |
|
zg, то есть все же плагином оставлять? но тогда Far /p и макросы обрубает. Это регрессия как бы. |
|
это не регрессия. это изменение функциональности. |
|
но траблшутинг макросов в режиме без плагинов затрудняется, как минимум |
|
far /p%farhome%\plugins\luamacro |
|
ОК, хорошо, что можно выкрутиться. Но а польза-то какая, что движок в плагине? Интересно все-таки какие есть соображения по такой архитектуре. Хочется, чтобы как-то гладко было, без лишних нюансов. Нюансы есть, пусть и обходятся. |
|
Гипотетический пример, лучше подумать раньше. Не скажется ли когда-нибудь порядок загрузки плагинов -- плагин ожидает наличие макросов при загрузке, а движок-плагин еще не загрузился. |
|
Macro.LoadMacros() выполняется (и выполнялся ранее) последним, посему гипотетический пример невозможен :-) |
|
> Но а польза-то какая, что движок в плагине? польза лично для меня в модульности и некоторой изолированности (которая, надеюсь, будет расти) макросов от всего фара. > Не скажется ли когда-нибудь порядок загрузки плагинов он сказывался ещё до выноса макросов в плагин. как минимум один инцидент есть. но в целом проблемы это не составляет, найти плагин по гуиду и если он есть загрузить его первым технически можно уже сейчас. |
|
Варианты 1 и 2 - это затычка от регрессии (и называть это "изменением функционала" как то неправильно). Вариант 3 более разумный. В этом случае мы получаем профиты от того, что dll где-то потерялась по дороге. А если вышло луно-ядро поновее, чем "у нас", то ФАР именно его (из внешней dll) и возьмет (должен брать). |
|
> что dll где-то потерялась по дороге давайте lng тогда уж встроим в фар. а то потеряется где-то по дороге. |
|
2864. Выбран предложенный вариант #1. |
|
описать в хелпе забыл. |
|
В хелпе пока вообще ничего нет про Lua или плагин LuaMacro. Как это подавать и в каком объёме, пусть решают более опытные фартимовцы. Я, если надо, исполню. |
|
Как бы первый пункт без уведомления пользователя (разового в каждом сеансе + отметка в хелпе) - это зоопарк Инцов на мантисе и периодических постов на форуме. Вообще, подобные исправления мне напоминают вот такую историю: В IBM по Lotus Domino наша контора завела PMR (инцидент, по нашему) по одной проблеме (детали не важны, суть - периодическое падение сервера, может 2 раза в день упасть, а может через пару месяцев). Как водится, проблему передали в отдел разработки (индусам, в Индию). Через полгода они присылают письмо, мол "да, проблема есть и у нас она воспроизводится, но мы не может её отловить, давайте закроем PMR...". Может не будем "индусами", а? |
|
Такой вопрос. А почему ядро луа не интегрировано в плагин? Ведь в этом случае нужно будет помнить только про одну dll (плагин). |
|
Чтобы другие плагины тоже пользовали ядро луа, если им захочется, раз ядро все равно есть. |
|
> А почему ядро луа не интегрировано в плагин? Потому что им пользуется не только плагин, но и luafar3.dll, и внешние подключаемые модули. |
|
Хмм... тогда надо подымать вопрос о выводе SQLite из ядра во внешнюю DLL, ибо я знаю уже двух (как минимум) кандидатов на "непрочь поюзать" |
|
> Хмм... тогда надо подымать вопрос о выводе SQLite из ядра во внешнюю DLL Есть разница. Такого понятия, как стандартная SQLite DLL как бы нет, продукт только в сорсах существует. И ее не обязательно кто-то может ожидать. А случае с Луа иначе, есть и стандартная DLL, и продукты, ее ожидающие и использующие. Но вопрос о вынесе SQLite в DLL, конечно, может иметь смысл. Только к этой теме не очень относится. |
|
> Такого понятия, как стандартная SQLite DLL как бы нет, продукт только в сорсах существует. Это шутка такая с твоей стороны? http://www.sqlite.org/download.html -> http://www.sqlite.org/sqlite-dll-win32-x86-3071401.zip > Только к этой теме не очень относится. Реплика про lng (выше) тоже как то не сюда. |
|
Хорошо, не знал, что есть эта ДЛЛ в стандартном виде, спасибо за урок. Но все равно это никак не влияет на Lua, совместное использование этой Lua DLL предполагается с самого начала, потому она и отдельно. |
|
> Это шутка такая с твоей стороны? ну так вперёд. я лично только рад буду более быстрой сборке фара. |
|
а вот такого делать не надо. макры - это "сбоку бантик", в отличии от настроек. и ломать там ничего не надо. |
|
> ну так вперёд. я лично только рад буду более быстрой сборке фара. В отличии от я предпочитаю принимать подобные решения НЕ в одно лицо, а коллегиально. > макры - это "сбоку бантик", в отличии от настроек Это так же можно сказать про любую компоненту FAR`а - от копира до редактора. |
|
2874. Выбран предложенный вариант #2. |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-10-01 08:54 | vskirdin | New Issue | |
2012-10-01 10:16 | NightRoman | Note Added: 0009543 | |
2012-10-01 10:23 | 2useven10 | Note Added: 0009544 | |
2012-10-01 11:05 | NightRoman | Note Added: 0009545 | |
2012-10-01 11:08 | vskirdin | Note Added: 0009546 | |
2012-10-01 11:27 | NightRoman | Note Added: 0009548 | |
2012-10-01 12:09 | Denis | Note Added: 0009549 | |
2012-10-01 13:51 | zg | Note Added: 0009550 | |
2012-10-01 14:10 | NightRoman | Note Added: 0009551 | |
2012-10-01 14:26 | zg | Note Added: 0009552 | |
2012-10-01 14:30 | NightRoman | Note Added: 0009553 | |
2012-10-01 14:34 | zg | Note Added: 0009554 | |
2012-10-01 14:39 | NightRoman | Note Added: 0009555 | |
2012-10-01 14:51 | NightRoman | Note Added: 0009556 | |
2012-10-01 15:10 | vskirdin | Note Added: 0009557 | |
2012-10-01 15:26 | zg | Note Added: 0009558 | |
2012-10-01 15:32 | vskirdin | Note Added: 0009559 | |
2012-10-01 15:49 | zg | Note Added: 0009560 | |
2012-10-03 15:14 | shmuel | Assigned To | => shmuel |
2012-10-03 15:14 | shmuel | Status | new => assigned |
2012-10-03 15:15 | shmuel | Note Added: 0009572 | |
2012-10-03 15:15 | shmuel | Status | assigned => feedback |
2012-10-03 15:20 | samlyukov | Note Added: 0009573 | |
2012-10-03 15:32 | shmuel | Note Added: 0009575 | |
2012-10-04 10:16 | vskirdin | Note Added: 0009579 | |
2012-10-04 10:16 | vskirdin | Status | feedback => assigned |
2012-10-05 06:45 | vskirdin | Note Added: 0009591 | |
2012-10-05 06:49 | NightRoman | Note Added: 0009593 | |
2012-10-05 06:53 | shmuel | Note Added: 0009594 | |
2012-10-05 11:04 | vskirdin | Note Added: 0009601 | |
2012-10-05 11:32 | NightRoman | Note Added: 0009602 | |
2012-10-05 13:33 | vskirdin | Note Added: 0009604 | |
2012-10-05 13:34 | vskirdin | Note Edited: 0009604 | |
2012-10-05 13:53 | NightRoman | Note Added: 0009605 | |
2012-10-05 14:43 | zg | Note Added: 0009607 | |
2012-10-05 15:28 | samlyukov | Note Added: 0009610 | |
2012-10-05 18:18 | vskirdin | Note Added: 0009612 | |
2012-10-06 23:55 | shmuel | Note Added: 0009615 | |
2012-10-06 23:55 | shmuel | Status | assigned => feedback |
2013-01-26 09:20 | shmuel | Build | => 2874 |
2013-01-26 09:20 | shmuel | Status | feedback => closed |
2013-01-26 09:20 | shmuel | Resolution | open => fixed |
2013-01-26 09:20 | shmuel | Fixed in Version | => 3.0 |