PT153, напоминаю, что этот компилятор рассчитан на работу с кодом в VSCode, а WE остается только GUI и все что с кодом не связано. Поэтому, например, не имеет смысла что-то чудить с пробелами перед синтакс чеком т.к. синтакс чек из WE просто не будет вызываться в 99% случаев.
Что касается синтаксиса макросов - я не случайно пошел путем аннотаций к переменным вместо кода в комментах - в моем варианте с этим более-менее прилично работает обычный синтакс-чекер для Lua и мне не нужно писать кастомный.
За счет этого, например, наведя мышку на константу я могу увидеть её значение.
А в результирующем коде от скрина выше останется только print("CONST_VAL")
Аналогично с макросом RAW - он принимает только значения в одинарных кавычках и имена констант чтобы проходить стандартный синтакс-чек. Более того, используется еще и объявление глобальной переменной RAW=FourCC, чтобы если что-то пошло не так с макросом, был шанс на срабатывание стандартного конвертера, ну и строгий синтакс-чек без этого не пройти.
--#INLINE для маркировки функций подлежащих инлайну в пределах текущего файла
--#INLINE GLOBAL для маркировки функций и переменных подлежащих инлайну во всех файлах
--#IF для начала блока условной компиляции, предварительно без серьезных вычислений, только на основе сравнения констант
--#ELSE для начала блока else при условной компиляции
--#END для завершения блоков у любых блочных макросов
Что-то похожее я и хотел иметь, но с другим синтаксисом.
<name> - идентификатор.
<expression> - значение или выражение.
регулярное выражение
описание
примеры
*-- *const +<name> *= *<expression>
Заменяет все вхождения <name> на <expression> во всех файлах. <expression> может являться <name> другой const. Другая константа может быть определена ниже, главное, чтобы не было рекурсий.
-- const INVUL = raw(Ainv)
-- const UserPlayers = 10
-- const AIPlayers = 2
-- const AllPlayers = UserPlayers + AIPlayers
*-- *localconst +<name> *= *<expression>
Заменяет все вхождения <name> на <expression> в файле, где определена localconst. <expression> может являться <name> другой const или localconst. Другая константа может быть определена ниже, главное, чтобы не было рекурсий.
-- localconst invul_here = INVUL
*-- *bool +<name> *= *<expression>
*-- *localbool +<name> *= *<expression>
Тоже самое, что и const, но значения могут быть только true, false, другая bool или даже выражение из операнд bool и localbool и операторов or, and и not. <expression> для bool не может содержать операнды типа localbool.
-- bool debug = true
-- localbool debug_here = debug
-- localbool no_debug_here = not debug_here
*-- *#if +<expression>( +then)?
*-- *#elseif +<expression>( +then)?
*-- *#else
*-- *#endif
Условная компиляция. <expression> состоит из операнд bool и localbool и операторов or, and и not. #endif можно заменить на #fi или #end.
Для укорочения можно изменить вид операнд и операторов.
false -> 0
true -> 1
and -> *
or -> +
not -> -
*<bool or localbool var> +<some lua expression>
Условная компиляция в линию. Для этого я и ввёл отдельно тип bool.
debug print(GetUnitName(u))
(RAW|raw)\( *('<rawcode>'|"<rawcode>"|<rawcode>) *\)
конвертирует равкод в число. Может принимать как в кавычках, так и без. С кавычками следует быть аккуратнее, так как сами кавычки могут быть частью равкода.
Так же я бы хотел опцию по удалению лишних пробелов для уменьшения веса кода ПЕРЕД вызовом syntax check.
Ещё бы я хотел, чтобы выражения в константах считались препроцессором.
prog, там достаточно все просто происходит, если несколько языковых серверов возвращают информацию на один и тот же контекст, то vscode это просто совмещает вместе. В целом работает там все очень просто. Не обязательно писать автокомплит через языковой сервер, можно внутри плагина просто подписаться на событие и обрабатывать его синхронно. Языковой сервер - это так, для асинхронной обработки и более удобной работы при интегрировании в другие редакторы. При этом код из синхронного в асинхронный переделывается методом копипасты :)
Самая сложная задача в автокомплите - это определение контекста где находится курсор, плюс внешнее окружение. Но тут на помощь приходят стейт машины, если интересно можешь посмотреть исходники нашего плагина и поспрашивать. Могу рассказать как там все работает
alexprey, пока в коде плагина слишком много остатков от стороннего плагина warcraft-vscode чтобы лить в маркетплейс, поэтому первая бета будет все-же на ручной установке, когда до этого дойдет дело, а потом таки сяду причешу код и начну разбираться с маркетплейсом.
Автокомплит по API вара - через сторонний плагин sumneko-lua, это и ланг сервер и эмми-луа аннотации и другие полезные фичи. Для него в комплекте будут идти конфиги и дефинишны API, чтобы достаточно было поставить и можно было пользоваться, но сам sumneko-lua используется оригинальный.
Автокомплит по API компилятора - мне очень хотелось бы, но я понятия не имею как он будет работать параллельно с ланг-сервером, да и не факт что я найду время его запилить - все-же запил плагинов к вскоду это немного далековато от моего базового набора скилов.
Автокомплит по равкодам - интересная мысль, можно попробовать, но те-же проблемы, что и в предыдущем пункте.
Автокомплит планируется? Например я начинаю писать равкод, а он мне достает инфу из карты, и пишет, что этот равкод принадлежит тому то и т.д.?
Автокомплит по API будет?
честно сворованный из warcraft-vscode упаковщик карты
запиленый на основе warcraft-vscode плагин к VSCode, вызывающий компилятор и упаковщик, а также запускающий игру и редактор
План на ближайшее будущее - предварительный релиз с ручной установкой и подготовка к релизу полноценному, через маркетплейс плагинов к вскоду.
В связи с тем что редактор показал возможность подхватывать abilitydata.slk из карты-папки, в список запланированных на ближайшее время фич добавляется игнор-лист для упаковщика карты, чтобы можно было указать ему "это файлы только для редактора, не надо совать их в запакованую карту". А в запланированные на будущее фичи - инжект плагином пофикшеного abilitydata.slk в карту для отображения скрытых способностей.
NazarPunk, если код передается через гитхаб - значит у всех кто работает с кодом настроена среда разработки. Зачем тогда полностью синхронизировать код с редактором пофайлово, если его можно весь в один блок кастом-скрипта вынести и не париться, а в редакторе триггеров оставить отдельными вкладками только всякие настройки, которые только через редактор и будут редактироваться?
Т.е. это еще и парсер нужен который будет парсить wct и wtg на предмет изменений...
Код передаётся через гитхаб и посему парсить ничего не нужно. Но над картой ещё работают люди, которым код какраз не нужен, а нужно чтоб просто карта работала.
Если нужно открытие карты редактором из-за совместной работы, а плюшки не нужны, то привязка будет в самый раз.
Совместная работа предполагает передачу карты в обе стороны. Т.е. это еще и парсер нужен который будет парсить wct и wtg на предмет изменений... Т.е. принял ты карту от того с кем работаеш и у кого только редактор и каждый раз надо прогнать карту через парсер чтобы подтянуть изменения в коде, чтобы они попали во внешние файлы которые редактируются в IDE. И нужно не забыть это сделать раньше первой пересборки карты из IDE иначе изменения потеряются. Как я уже говорил, крайне корявый workflow.
ИМХО, эффективнее просто заставить всех участников поставить и настроить среду разработки и передавать не только карту, но и весь проект. А время которое потратилось бы на разработку этого парсера и синхронизации папок потратить, например, на линуксовую версию тулсета.
ИМХО, единственная ценность сборки карты в режиме синхронизации папок - пилить что-то для выкладывания на сайте, не ожидая получить отредактированную карту обратно.
Добавил сборку с триггерами и поддержку линукса в рассматриваемые фичи. Правда не факт что я до них дойду.
BLOG-PROG
Комментарии проекта Эксперименты в Пустоте
Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Ред. prog
Ред. PT153
Самая сложная задача в автокомплите - это определение контекста где находится курсор, плюс внешнее окружение. Но тут на помощь приходят стейт машины, если интересно можешь посмотреть исходники нашего плагина и поспрашивать. Могу рассказать как там все работает
Ред. prog
Автокомплит по API компилятора - мне очень хотелось бы, но я понятия не имею как он будет работать параллельно с ланг-сервером, да и не факт что я найду время его запилить - все-же запил плагинов к вскоду это немного далековато от моего базового набора скилов.
Автокомплит по равкодам - интересная мысль, можно попробовать, но те-же проблемы, что и в предыдущем пункте.
Автокомплит по API будет?
Ред. prog