View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000096 | Wishes.Plugins | FARCmds | public | 2006-03-07 12:50 | 2013-02-03 00:37 |
Reporter | vskirdin | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Summary | 0000096: Обработка макрофайла | ||||
Description | Для префикса "macro:" ключ "/f filename" (для команд... наверное всех). Параметр - имя файла специального формата, например так: Macro Viewer:F9 (DisableOutput) Description: Use F9 to change current table in viewer and editor { ShiftF8 Down Enter } Т.е. здесь "Macro" - константа "Viewer" - область действия "F9" - на что вешать "(...)" - в круглых скобках параметры макроса "Description: " - константа, задающая описание макроса "{" - начало тела макроса "}" - окончание тела макроса Между скобками - тело макроса в произвольной форматированной форме FARCmds в это случае: 1. "post" - парсит файл и передает макрос на исполнение FAR`у 2. "load" - парсит файл и передает макрос на "запоминание" FAR`у (как будто записали с клавиатуры). В этом случае действует правило "под текущим юзером". 3. "save" - сохраняет все или выбранный макрос (тогда синтаксис будет "macro: save [MacroKey] /f filename") 4. "check" - парсит файл и передает макрос на проверку FAR`у Так же для файла предусмотреть цветовую схему для Colorer`а. Возможно, что придется изменить формат хранения "Sequence", т.е. сделать его не REG_SZ, а REG_MULTI_SZ. Правда в таком виде REG-файл будет проблематично ручками править. | ||||
Tags | No tags attached. | ||||
|
Идея хорошая. Но, как я понял, предлагается для каждого макроса иметь отдельный файл? Это неудобно. Пусть в одном файле можно будет указывать несколько макросов: macro: /f filename [macro_id] Если macro_id не указан, действие выполняется с первым макросом, описанным в файле. Формат файла: Macro: Change_Table Viewer:F9 (DisableOutput) Description: Use F9 to change current table in viewer and editor { ShiftF8 Down Enter } После Macro: первый параметр - macro_id, далее всё так же, как предложил VS. И ещё: хотелось бы иметь возможность указывать текст макроса в несколько строк. Концом текста будет считаться "}" - одна в строке, без ведущих пробелов. |
|
AS>> вместо F9 я ведь могу написать ( AS>> да и опции могут отсутствовать... VS> Согласен. AS>> Правильнее и проще разбирать, на мой взгляд, скорее всего такое: AS>> Macro: Viewer AS>> Key: F9 AS>> Options: DisableOutput, Selection AS>> Description: Use F9 to change current table in viewer and editor AS>> { AS>> ShiftF8 AS>> Down Enter AS>> } VS> А на мантис это занес? |
|
И даже так: Macro: Viewer &: F9 #: DisableOutput, Selection @: Use F9 to change current table in viewer and editor { ShiftF8 Down Enter } где: & - Key # - Options @ - Description |
|
> & - Key > # - Options > @ - Description За за хрень, что тайнопись/клинопись? Смысл в этих тайных знаках? |
|
в служебных словах есть смысл - они читаемы, в отличии от @ плюс предложенный формат - это не один макрос на один файл... по сути - это заменитель reg-файла, но не зависимый от юзера (предполагалось, что farcmds сам разрулит в какую ветку реестра пихать) |
|
Лично мне нравится то, как с макросами работает selmacro Есть и комментарии, и многострочность, и даже --begin|--end, хотя это уже излишество, да. |
|
Предлагаю свои дополнения к предложенному формату макрофайла. (Пытался продумать детали, пункты идут без какого-либо порядка) 1) Необходимо определиться, и таким образом стандартизировать расширение макро файла (я использую .macro). Можно использовать 2 разных расширения - ведь файлы можно будет использовать как для импорта в реестр, так и для прямого исполнения. (Соответственно и в раскраске одна маска будет в группе исполняемых, а другая - в группе конфигурационных.) На эти расширения удобно также определить ассоциации. 2) Комментариями считать строки, начинающиеся с ";;" Перед ";;" могут быть только пробелы или табуляции (Комментарии при импорте в реестр хранить наравне с кодом.) 3) Служебные слова нужны не всегда - предлагаю сделать их опциональными. 4) Логично было бы "check" и "load" не только из файла, но прямо из командной строки (как "post"). В этом случае служебные слова указывались бы в виде параметров. Типа /area="Viewer" /key="F9" /description="" /DisableOutput=1 А чтобы не плодить сущности то и в макрофайле можно служебные слова писать в виде параметров (т.е. /area= /key= /description= /DisableOutput=) Также ключ /f можно заменить перенаправлением вывода "<" и ">" Кстати служебных слов ещё много - /RunAfterFARStart /NotEmptyCommandLine /NoEVSelection /NoPluginPanels /NoFolders /NoSelection /NoFilePPanels /NoPFiles /PSelection 4) Необходимость фигурных скобок для задания начала/конца макроса под сомнением Собственно блок параметров может служить разделителем макросов. 5) При использовании несколько макросов в одном файле нужен параметр /name= |
|
> ";;" встречное предложение - "#" или как в cmd "::" > фигурные скобки удобно "прыгать" по блокам > Типа /area="Viewer" /key="F9" /description="" /DisableOutput=1 в самом файле? А смысл (кроме того, что ты указал - "в макрофайле лучше служебные слова писать в виде параметров ")? > точнее отражают какую-то изощрённую логику обоснуй "изощренность". |
|
>встречное предложение - "#" или как в cmd "::" Как бы есть стандарт де-факто, заданый плагином Selmacro... Не только я им пользуюсь - на форуме многострочные макросы комментируются именно с помощью ;; >удобно "прыгать" по блокам Вопрос: есть ли техническая необходимость вводить именно в макрофайл {}? Что касается удобства, то почему бы не ввести в макроязык {} вообще? Тогда можно было бы лепить любые удобные блоки. >А смысл (кроме того, что ты указал - "в макрофайле лучше служебные слова писать в виде параметров ")? Ну идея в том что макрофайл - просто продолжение коммандной строки. И можно "прозрачно" переносить параметры из коммандной строки в макрофайл и наоборот. >обоснуй "изощренность". Может я не ясно выразился, но речь была о том как эти параметры выглядят в реестре. Разумеется можно не привязываться к реестру и ввести нормальные имена параметров. |
|
> расширение макро файла (я использую .macro) Очень уж это расширение перегруженное и затасканное. Лично я предлагаю .FMM (от Far Manager Macro). А в формате главное, чтобы не было всяческих неоднозначностей и лишних привязок к контексту. Я тоже за то, чтобы в одном файле могло быть несколько макросов и чтобы комментарии и форматирование сохранялись. Если это будет, то и править REG-файлы нужда отпадёт. Идея использовать символы перенаправления ‘<’ и ‘>’ представляется здравой, но лишь для тех операций, которые иначе работали бы с консолью. Кстати, учитывая то, что макросы развиваются, хорошо бы при автоматическом создании файла прописывать где-нибудь в его начале номер сборки, чтобы потом можно было его учесть. |
|
>Очень уж это расширение перегруженное и затасканное. Вопрос непринципиальный, хотя лично у меня на машине нету и никогда не было других файлов с .macro-расширением кроме фаровских. И кстати см. выше - речь о двух разных расширениях. >хорошо бы при автоматическом создании файла прописывать где-нибудь в его начале номер сборки В комментарии можно (хотя практической пользы не вижу) |
|
>Идея использовать символы перенаправления ‘<’ и ‘>’ представляется здравой, но лишь для тех операций, которые иначе работали бы с консолью. С консолью пока ничего не работает, и если Валентин не сделает - не будет работать. Поэтому предлагайте конкретнее. |
|
>>удобно "прыгать" по блокам >Вопрос: есть ли техническая необходимость вводить именно в макрофайл {}? у меня есть идея немного переделать синтаксис, убрав $end, а для этой цели фигурные скобки (как в Це, awk, perl, etc) будут играть роль "блока". > И можно "прозрачно" переносить параметры из коммандной строки в макрофайл и наоборот. FARCmds запрограммируешь? ;-) >Идея использовать символы перенаправления ‘<’ и ‘>’ нафига? у нас все таки не shellscript :-) |
|
Есть один принципиальный вопрос: поддерживаете ли вы идею импорта (как и остальных команд) прямо из коммандной строки? Ведь если да, то убъём 2-х зайцев - не надо будет никакого специального формата макрофайла. >>Идея использовать символы перенаправления ‘<’ и ‘>’ >нафига? у нас все таки не shellscript :-) Синтаксис многих команд FarCmds предусматривает использование < | >. Экспорт/импорт макроса вроде вписывается в "идеологию" перенаправления. А там как хотите - мне всё равно, пусть будет "/f filename" |
|
>> Выходит Mantis#96 откладывается на неопределённый срок? VS>почему? все зависит от вас :-) VS>Все дело в волшебных пузырьках. А именно: VS>1. FARCmds как бы официальный плагин, идущий в официальной поставке VS>2. некто selmacro (или как там его) - ХЗ, это т.с. стороняя разработка, VS>официально не поддерживаемая разработчиками. Собственно и не требуется никакой поддержки Selmacro, кроме пожелания комментарии обозначать с помощью ;; (не более чем пожелание) VS>3. как только устаканится формат для FARCmds - тогда можно... думать VS>дальше ;-) А что надо сделать чтобы он начал устаканиваться? VS>5. т.к. как бы стандарта нет, то ни кто не мешает узаконить (возможно с VS>некоторыми доделками) синтаксис selmacro (или еще чего-то). Нет никакого особого синтаксиса selmacro VS>6. возможно имеет смысл selmacro сделать официальным, предназначенным только VS>для макросов, при этом убрать из FARCmds код - здесь все зависит от автора VS>selmacro: согласится ли он на такой шаг. Selmacro ничего особого не делает - его основная функция - преобразование макроса таким образом, чтобы он выполнился на каждом выделенном в панели файле (т.е. добавляются команды позиционирования для каждого файла) Плагин давно не обновлялся и несколько устарел, в уникодном фаре не работает. Автор давно не появлялся и на форуме из чего можно предположить что он охладел к фару. Вынести макрофункции из FarCmds в отдельный плагин конечно можно, но с Selmacro это связывать нет необходимости. |
|
>Возможно, что придется изменить формат хранения "Sequence", т.е. сделать его не REG_SZ, а REG_MULTI_SZ. >Правда в таком виде REG-файл будет проблематично ручками править. Что если оставить REG_SZ? Переносы строк в виде "\r\n" (или просто "\n") никому помешать не должны |
|
Если мы говорим о файле, то какая разница как ФАР хранит секвенс? (кстати, он и так и так понимает - и REG_SZ и REG_MULTI_SZ). Для того и вводится понятие "макрофайл", что бы вообще абстрагироваться от реестра. |
|
Большой разницы конечно нет, но... (1)Проблема в том что абстрагируемся мы от реестра только частично, и всё равно никуда от него не денемся при сохранении всех настроек. И вот в FarSettings.reg было бы приятнее видеть хоть что-то. (2)Выше я предлагал чтобы операции с макросами были доступны прямо из коммандной строки (без всякого макрофайла) Если это предложение будет принято, то всё равно надо будет вводить какой-то разделитель строк. Так зачем плодить сущности, если \r\n и так есть? Вообще если окажется что всю кухню внутри фара проще организовать с помощью REG_MULTI_SZ, тогда конечно "овчинка не стоит выделки" Если же одинаково - пусть бы себе оставалось REG_SZ |
|
неактуально |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-03-07 12:50 | vskirdin | New Issue | |
2006-03-08 02:31 | Raistlin | Note Added: 0000089 | |
2006-03-09 04:11 | samlyukov | Note Added: 0000090 | |
2006-07-17 20:20 | samlyukov | Note Added: 0000244 | |
2009-04-08 19:40 | vskirdin | Note Added: 0002925 | |
2009-04-10 12:17 | vskirdin | Note Added: 0002934 | |
2009-04-10 15:53 | Kildor | Note Added: 0002939 | |
2009-04-13 15:17 | JohnDoe | Note Added: 0002943 | |
2009-04-13 15:41 | vskirdin | Note Added: 0002944 | |
2009-04-13 18:01 | JohnDoe | Note Added: 0002945 | |
2009-04-13 18:07 | HaRT | Note Added: 0002946 | |
2009-04-13 18:10 | HaRT | Note Edited: 0002946 | |
2009-04-13 18:12 | HaRT | Note Edited: 0002946 | |
2009-04-13 19:09 | JohnDoe | Note Added: 0002947 | |
2009-04-13 19:23 | JohnDoe | Note Added: 0002948 | |
2009-04-14 06:44 | vskirdin | Note Added: 0002949 | |
2009-04-14 09:22 | JohnDoe | Note Added: 0002950 | |
2009-04-14 12:40 | JohnDoe | Note Edited: 0002950 | |
2009-04-17 19:35 | JohnDoe | Note Added: 0002975 | |
2009-04-17 19:36 | JohnDoe | Note Edited: 0002975 | |
2009-04-17 19:36 | JohnDoe | Note Edited: 0002975 | |
2009-04-27 11:49 | JohnDoe | Note Added: 0003030 | |
2009-04-27 12:08 | vskirdin | Note Added: 0003031 | |
2009-04-27 14:24 | JohnDoe | Note Added: 0003032 | |
2009-04-27 18:57 | JohnDoe | Note Edited: 0003030 | |
2010-09-02 21:46 | JohnDoe | Note Edited: 0002943 | |
2010-12-21 20:04 | JohnDoe | Note Edited: 0002943 | |
2013-01-16 12:20 | vskirdin | Note Added: 0010017 | |
2013-01-16 12:20 | vskirdin | Status | new => closed |
2013-01-16 12:20 | vskirdin | Resolution | open => no change required |
2013-02-03 00:37 | alexy | Severity | minor => feature |