View Issue Details

IDProjectCategoryView StatusLast Update
0000096Wishes.PluginsFARCmdspublic2013-02-03 00:37
Reportervskirdin Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionno change required 
Summary0000096: Обработка макрофайла
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-файл будет проблематично ручками править.
TagsNo tags attached.

Activities

Raistlin

2006-03-08 02:31

reporter   bugnote:0000089

Идея хорошая. Но, как я понял, предлагается для каждого макроса иметь отдельный файл? Это неудобно. Пусть в одном файле можно будет указывать несколько макросов:
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.
И ещё: хотелось бы иметь возможность указывать текст макроса в несколько строк. Концом текста будет считаться "}" - одна в строке, без ведущих пробелов.

samlyukov

2006-03-09 04:11

reporter   bugnote:0000090

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> А на мантис это занес?

samlyukov

2006-07-17 20:20

reporter   bugnote:0000244

И даже так:

Macro: Viewer
&: F9
#: DisableOutput, Selection
@: Use F9 to change current table in viewer and editor
{
  ShiftF8
  Down Enter
}

где:
& - Key
# - Options
@ - Description

vskirdin

2009-04-08 19:40

administrator   bugnote:0002925

> & - Key
> # - Options
> @ - Description
За за хрень, что тайнопись/клинопись?
Смысл в этих тайных знаках?

vskirdin

2009-04-10 12:17

administrator   bugnote:0002934

в служебных словах есть смысл - они читаемы, в отличии от @
плюс предложенный формат - это не один макрос на один файл...
по сути - это заменитель reg-файла, но не зависимый от юзера (предполагалось, что farcmds сам разрулит в какую ветку реестра пихать)

Kildor

2009-04-10 15:53

reporter   bugnote:0002939

Лично мне нравится то, как с макросами работает selmacro
Есть и комментарии, и многострочность, и даже --begin|--end, хотя это уже излишество, да.

JohnDoe

2009-04-13 15:17

updater   bugnote:0002943

Last edited: 2010-12-21 20:04

Предлагаю свои дополнения к предложенному формату макрофайла.
(Пытался продумать детали, пункты идут без какого-либо порядка)

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=

vskirdin

2009-04-13 15:41

administrator   bugnote:0002944

> ";;"
встречное предложение - "#" или как в cmd "::"

> фигурные скобки
удобно "прыгать" по блокам

> Типа /area="Viewer" /key="F9" /description="" /DisableOutput=1
в самом файле?
А смысл (кроме того, что ты указал - "в макрофайле лучше служебные слова писать в виде параметров ")?

> точнее отражают какую-то изощрённую логику
обоснуй "изощренность".

JohnDoe

2009-04-13 18:01

updater   bugnote:0002945

>встречное предложение - "#" или как в cmd "::"
Как бы есть стандарт де-факто, заданый плагином Selmacro...
Не только я им пользуюсь - на форуме многострочные макросы комментируются именно с помощью ;;

>удобно "прыгать" по блокам
Вопрос: есть ли техническая необходимость вводить именно в макрофайл {}?

Что касается удобства, то почему бы не ввести в макроязык {} вообще?
Тогда можно было бы лепить любые удобные блоки.

>А смысл (кроме того, что ты указал - "в макрофайле лучше служебные слова писать в виде параметров ")?
Ну идея в том что макрофайл - просто продолжение коммандной строки.
И можно "прозрачно" переносить параметры из коммандной строки в макрофайл и наоборот.

>обоснуй "изощренность".
Может я не ясно выразился, но речь была о том как эти параметры выглядят в реестре.
Разумеется можно не привязываться к реестру и ввести нормальные имена параметров.

HaRT

2009-04-13 18:07

reporter   bugnote:0002946

Last edited: 2009-04-13 18:12

> расширение макро файла (я использую .macro)
Очень уж это расширение перегруженное и затасканное.
Лично я предлагаю .FMM (от Far Manager Macro).

А в формате главное, чтобы не было всяческих неоднозначностей и лишних привязок к контексту.

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

Идея использовать символы перенаправления ‘<’ и ‘>’ представляется здравой, но лишь для тех операций, которые иначе работали бы с консолью.

Кстати, учитывая то, что макросы развиваются, хорошо бы при автоматическом создании файла прописывать где-нибудь в его начале номер сборки, чтобы потом можно было его учесть.

JohnDoe

2009-04-13 19:09

updater   bugnote:0002947

>Очень уж это расширение перегруженное и затасканное.
Вопрос непринципиальный, хотя лично у меня на машине нету и никогда не было других файлов с .macro-расширением кроме фаровских.
И кстати см. выше - речь о двух разных расширениях.

>хорошо бы при автоматическом создании файла прописывать где-нибудь в его начале номер сборки
В комментарии можно (хотя практической пользы не вижу)

JohnDoe

2009-04-13 19:23

updater   bugnote:0002948

>Идея использовать символы перенаправления ‘<’ и ‘>’ представляется здравой, но лишь для тех операций, которые иначе работали бы с консолью.
С консолью пока ничего не работает, и если Валентин не сделает - не будет работать. Поэтому предлагайте конкретнее.

vskirdin

2009-04-14 06:44

administrator   bugnote:0002949

>>удобно "прыгать" по блокам
>Вопрос: есть ли техническая необходимость вводить именно в макрофайл {}?
у меня есть идея немного переделать синтаксис, убрав $end, а для этой цели фигурные скобки (как в Це, awk, perl, etc) будут играть роль "блока".

> И можно "прозрачно" переносить параметры из коммандной строки в макрофайл и наоборот.
FARCmds запрограммируешь? ;-)

>Идея использовать символы перенаправления ‘<’ и ‘>’
нафига? у нас все таки не shellscript :-)

JohnDoe

2009-04-14 09:22

updater   bugnote:0002950

Last edited: 2009-04-14 12:40

Есть один принципиальный вопрос: поддерживаете ли вы идею импорта (как и остальных команд) прямо из коммандной строки?
Ведь если да, то убъём 2-х зайцев - не надо будет никакого специального формата макрофайла.

>>Идея использовать символы перенаправления ‘<’ и ‘>’
>нафига? у нас все таки не shellscript :-)

Синтаксис многих команд FarCmds предусматривает использование < | >.
Экспорт/импорт макроса вроде вписывается в "идеологию" перенаправления.
А там как хотите - мне всё равно, пусть будет "/f filename"

JohnDoe

2009-04-17 19:35

updater   bugnote:0002975

Last edited: 2009-04-17 19:36

>> Выходит 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 это связывать нет необходимости.

JohnDoe

2009-04-27 11:49

updater   bugnote:0003030

Last edited: 2009-04-27 18:57

>Возможно, что придется изменить формат хранения "Sequence", т.е. сделать его не REG_SZ, а REG_MULTI_SZ.
>Правда в таком виде REG-файл будет проблематично ручками править.

Что если оставить REG_SZ? Переносы строк в виде "\r\n" (или просто "\n") никому помешать не должны

vskirdin

2009-04-27 12:08

administrator   bugnote:0003031

Если мы говорим о файле, то какая разница как ФАР хранит секвенс? (кстати, он и так и так понимает - и REG_SZ и REG_MULTI_SZ).
Для того и вводится понятие "макрофайл", что бы вообще абстрагироваться от реестра.

JohnDoe

2009-04-27 14:24

updater   bugnote:0003032

Большой разницы конечно нет, но...

(1)Проблема в том что абстрагируемся мы от реестра только частично, и всё равно никуда от него не денемся при сохранении всех настроек.

И вот в FarSettings.reg было бы приятнее видеть хоть что-то.

(2)Выше я предлагал чтобы операции с макросами были доступны прямо из коммандной строки (без всякого макрофайла)
Если это предложение будет принято, то всё равно надо будет вводить какой-то разделитель строк. Так зачем плодить сущности, если \r\n и так есть?

Вообще если окажется что всю кухню внутри фара проще организовать с помощью REG_MULTI_SZ, тогда конечно "овчинка не стоит выделки"
Если же одинаково - пусть бы себе оставалось REG_SZ

vskirdin

2013-01-16 12:20

administrator   bugnote:0010017

неактуально

Issue History

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