Total Commander

Loopback
А, ну ОК, тогда я спокоен.

Версия 2.2.3 beta

+ добавлены сообщения об ошибках синтаксиса в циклах
- исправлено сообщение, когда отсутствует Then в условнии
+ Tab может использоваться аналогично пробелу в выражениях
+ дополнительная проверка ошибок синтаксиса в выражениях
+ добавлена директива LegacyExpressions
+ добавлено сообщение при попытке добавить функцию с дублирующимся именем
- при разбиении строк пробел перед _ не будет удаляться
- исправлена передача параметра по ссылке
- исправлена проблема с остановкой парсера на неподдерживаемых символах
- исправлен парсинг задания переменных без начального значения
- исправлен запрет на присвоение значений макросам и константам
- исправлена ошибка парсера с ключевыми словами or, and, not в условиях
- Tweaks: исправлена работа с модификаторами (снова, и снова, и снова)

Крупных изменений нет, в основном фиксы и оптимизации. Обсуждаемая ранее директива реализована и действует. Страница бета-функционала дополнена.

По поводу ControlSetMouseAction - менять что-то нет смысла, в ФЗ она и будет записываться, как в этом посте, за исключением того, что в "новом" режиме имя команды ShellExec также должно быть в кавычках (т.к. это обычная строка, один из параметров ControlSetMouseAction).

Но с этой командой без исключений никак, есть один момент: трюк, когда при запуске команды выполняется вычисляемая строка в ее параметрах, в функциональной записи невозможен (и неважно в каком режиме). Т.е. если в командной записи
при каждом запуске CommandExec выполняется вычисляемая строка с IniRead, то в функциональном режиме она выполнится только один раз при запуске ControlSetMouseAction. Но вообще-то такое поведение в командной записи ControlSetMouseAction и не предполагалось, по сути это баг

Нужного эффекта можно достигнуть через пользовательскую функцию-прослойку, но по-моему, если нужен именно этот результат, проще записать команду в командном виде.

Loopback писал(а):если нужен именно этот результат, проще записать команду в командном виде.

Виде? Без смены режима? Это как?

У LegacyExpressions свитч-то есть? Ты же обещал 2 прагмы. Иначе смысл?

Flasher писал(а):Виде?

Ну записи. В общем, как в приведенном примере.

Flasher писал(а):У LegacyExpressions свитч-то есть? Ты же обещал 2 прагмы. Иначе смысл?

Две-то зачем? Нет прагмы - новый режим, есть - старый.

Loopback писал(а):В общем, как в приведенном примере.

Так без LegacyExpressions он не работает.

Loopback писал(а):Две-то зачем?

Как это зачем? Сперва пишу в LegacyExpressions, а потом отключаю и пишу в умолчательном, что избежать проблем старого режима. В этом и суть.

Flasher писал(а):Так без LegacyExpressions он не работает.

Естественно, Configuration и LanguageIni без кавычек. Если включить LegacyExpressions - будет работать.

Flasher писал(а):Как это зачем? Сперва пишу в LegacyExpressions, а потом отключаю и пишу в умолчательном, что избежать проблем старого режима. В этом и суть.

Ничего не понял Зачем что-то писать в режиме LegacyExpressions, если всё что у тебя есть - и так в нём написано?

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

Loopback писал(а):Естественно

Я спросил "Без смены режима?", ты ответил "Ну записи.".

Loopback писал(а):Ничего не понял Зачем что-то писать в режиме LegacyExpressions, если всё что у тебя есть - и так в нём написано?

Я тем более. Как это зачем? Если всё в нём написано, то логично в нём и писать. А если после надо какую-то часть написать в ФЗ (например, для указания переменных без %), то логично переключиться обратно.

Flasher писал(а):А если после надо какую-то часть написать в ФЗ

Ты вроде тут писал, что стало понятно.

ФЗ - она при любой прагме ФЗ. Я же в обновленной справке в разделе "Синтаксис" разжевал всё подробно: прагма управляет интерпретацией ФЗ. По умолчанию включена правильная, которая исключает неоднозначности и обеспечивает корректную обработку ошибок, но можно переключиться на старую, если сложно/лень/нет времени вносить изменения в свой имеющийся код.

Loopback писал(а):Ты вроде тут писал, что стало понятно.

Что и как будет работать в каждом из режимов — да, стало понятно. Но я не хотел и не предполагал, что один из режимов будет выбит наглухо...

Тем более, что сам пишешь, что есть не только функциональная разница, но и отладочная. И тут дело не в лени вовсе.

У меня возникает стойкое ощущение, что иногда мы мыслим в противофазе. Полное отсутствие взаимопонимания.

В общем своё понимание я подробно документировал. Что куда и почему "выбито", откуда вообще взялось ожидание каких-то двух прагм и для чего они две нужны - мне так и осталось непонятным. Лучше я объяснить уже не смогу, так что я - пас.

При чём тут взаимопонимание? Я твой ликбез в целом прекрасно понял. Да и ты мой нужник наверняка тоже. А вот отсутствие желания с твоей стороны и только, это уже совсем другой разговор.

Почему "выбито" толком объяснено не было. Была только констатация текущего положения. Любая прагма работает с места, а не по всему коду, если не задана первой строкой. То есть имеем потенциал разделения на две части. С остальными прагмами понятно, там переключатель бессмысленен. А почему тут нет доступа к переключателю для возврата к синтаксису, который как минимум "имеет корректную обработку ошибок", так однозначного (хотя бы что-то типа "это очень трудоёмко, по такой-то причине надо много переписывать", "замедлится скорость" и т. п.) пояснения и не было.

Flasher писал(а): Да и ты мой нужник наверняка тоже.

И нафига бы это мне? Слишком много лишнего времени, что захотелось поразвлекаться перепиской на несколько страниц?

Flasher писал(а):Любая прагма работает с места, а не по всему коду

Ну наконец хоть что-то стало проясняться. Вот это была большая ошибка так думать. До сих пор единственная прагма, работающая в конкретном месте - это была FinalizeSection. Теперь добавилась Include, вставляющая по этому месту содержимое файла. Всё. Остальные прагмы - глобальные, и размещать их можно не в первых строках, а где угодно.

Резюме: это на самом деле трудоемко. Потому что прагмы читаются на этапе препроцессинга. И если с Include проблем нет (всё что нужно реализуется на этапе препроцессинга), то даже под FinalizeSection пришлось городить специальную обработку (если бы не совместимость, сейчас я бы лучше сделал специальную функцию "OnExit"). В парсер выражений сейчас передается единственный глобальный флаг. А чтобы реализовать включение/выключение по месту, придется сначала как-то сохранить с препроцессинга и проставить флаги в каждый узел дерева скрипта, учитывая вложенности, потом их проверять при выполнении.

Не то чтобы это было невозможно, но есть вопрос целесообразности. Были бы скрипты длиной в тысячи строк, об этом еще можно было бы говорить. А так в среднестатистическом скрипте всё исправить - дело от силы десятка-другого минут. И это не говоря о том, что само наличие каких-то сегментов, в которых один и тот же код выполняется по-разному, явно всё только усложнит. И ладно бы каждый из этих режимов давал какой-то уникальный профит, а так один раз перешел и забыл.

Loopback писал(а):И нафига бы это мне? Слишком много лишнего времени, что захотелось поразвлекаться перепиской на несколько страниц?

Мы после выкладки беты даже до второй не дошли, а ты уже несколько насчитал. Нафига тебе понимать мою нужду? Хороший вопрос, но не ко мне он, не телепат я. )

Loopback писал(а):Вот это была большая ошибка так думать. До сих пор единственная прагма, работающая в конкретном месте - это была FinalizeSection.

У тебя очень интересно в описании:

Директивы выполняются на этапе предварительной обработки скрипта, результат их обработки действует на протяжении всего времени выполнения скрипта.

И тут же следующей строкой:

Часть скрипта после этой директивы обрабатывается при завершении Total Commander.

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

Loopback писал(а):если бы не совместимость, сейчас я бы лучше сделал специальную функцию "OnExit"

Совместимость уже поломалась в синтаксисе, поэтому можно делать не глядя.

По остальному ясно-понятно, вопросов больше не имею...

Flasher писал(а): Нафига тебе понимать мою нужду? Хороший вопрос, но не ко мне он, не телепат я. )

Мда, двусмысленно вышло. Надо было полностью цитировать.

Flasher писал(а):Такие противоречия заставляют задуматься, что там да как на самом деле.

Доработаю. Но как раз это и должно было наводить на мысль, что не всё однозначно.

Flasher писал(а):Совместимость уже поломалась в синтаксисе, поэтому можно делать не глядя.

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

Функцию теперь нет смысла делать, раз уж секция осталась.

Здравствуйте!
Возник вопрос следующего характера:
В Wind'е есть переменная среды вида "ProgramFiles(x86)". Ясно, что она неоднозначна для разных битностей ОС и самого ТС, ну, т.е. она может быть (в Win_х64), а может и не быть (в Win_x32).
Вопрос - возможно ли реализовать в плагине создание переменной с именем, содержащим скобки "()"?
З.Ы.: я знаю, что такое можно реализовать через .cmd(.bat), знаю, что есть и другие переменные, вопрос именно реализации через плагин Autorun.
З.Ы.2.: да, добавлю, что речь идёт про переменную среды в рамках процесса ТС. Т.е. добавление в реестр (утилита setx.exe и иже с ней) пользователя не задуман.