#visual-studio-code #lua #vscode-extensions
#visual-studio-код #lua #vscode-расширения
Вопрос:
Я пытаюсь узнать, как реализовать некоторые вспомогательные поставщики: автозаполнение, помощь по подписи и наведение курсора.
Я делаю это для фреймворка, который, насколько мне известно, не может быть выполнен вне его основного приложения, поэтому я подумал, что один из способов сделать это (получить типы объектов, методы и документы) — это проанализировать его документацию.
Например, поставщик наведения курсора; как только курсор наведен на слово, я могу найти его в документации и отобразить результат:
class HSHoverProvider implements vscode.HoverProvider { public provideSignatureHelp( document: vscode.TextDocument, position: vscode.Position, token: vscode.CancellationToken ): vscode.SignatureHelp { // get current word/line under the cursor and find a match inside the docs ... return new vscode.Hover(data); } } ... context.subscriptions.push( vscode.languages.registerHoverProvider("lua", new HSHoverProvider()) ); Это прекрасно работает, когда действие выполняется непосредственно в начальной декларации. Я могу проанализировать непосредственно строку и найти то, что мне нужно, с помощью регулярного выражения.
-- hovering over `application`, I check the context with a regex. local app = hs.application('Code') Однако у меня возникают трудности, когда дело доходит до «ссылки». Поиск в документе объявления app с использованием подхода регулярных выражений приводит ко многим крайним случаям, главным образом из — за области объявления:
Пример:
-- declaration target local app = hs.application('Code') local function foo() local app = hs.pasteboard() end local function bar() if 'foo' then local app = hs.alert() end do local app = hs.window.focusedWindow() end -- a regex will have a hard time to understand which declaration is correct print(app:title()) end Это наводит меня на мысль, что регулярное выражение не является подходящим решением. Я также думал, что внедрение vscode.DefinitionProvider даст мне некоторое представление, но этого не произошло.
Я попытался посмотреть на другие расширения, которые уже делают то же самое (в основном Lua Language Server от sumneko), но я не могу понять, как они пошли на это (кроме того, они используют подход языкового сервера).
Как бы я пошел на что-то подобное? Нужно ли мне дерево AST и проверять его оттуда? Будет ли использование языкового сервера лучшим выбором? Мне не хватает общей картины или мне просто нужен более надежный анализатор документов?
Любое понимание ценится. Заранее спасибо
Комментарии:
1. Регулярные выражения (примеры, такие как механизм подсветки синтаксиса по умолчанию VSCode) имеют существенные ограничения на то, на какой уровень языковых конструкций могут полагаться другие функции и какой уровень точности может быть достигнут. Вот почему в конечном счете отличные языковые расширения обращаются к языковым серверам за кулисами. В вашем случае, я не думаю, что вы можете избежать этого пути.
Ответ №1:
Обычный подход в таких случаях заключается в создании таблицы символов. Вы начинаете с анализа кода, для которого хотите предоставить инструменты. Из дерева синтаксического анализа (или синтаксического дерева, в зависимости от используемого инструмента синтаксического анализа) вы создаете таблицу символов, в которой содержится необходимая вам информация, включая вложенность блоков и символов, тип символов (например, имя объекта или ссылка на объект) и область, для которой допустим символ.
Комментарии:
1. Хотя я еще не реализовал этот метод, я приму ответ, поскольку он указывает в правильном направлении. Спасибо