Ferramentas

Extensão do VS Code

Realce que respeita a caixa, trechos prontos e os erros do fc no painel de Problemas.

Uma extensão para editar .fxp, .fxm e .fxi no VS Code: realce, indentação, trechos prontos e leitura dos erros do compilador. Ela é só declarativa: nenhum JavaScript, nenhum npm, nenhum build.

Instalar#

terminal

code --install-extension "<pasta>\mycompiler-0.1.0.vsix" --force

Depois reinicie o VS Code. Para conferir: code --list-extensions tem de listar a extensão.

Um .vsix é só um ZIP com um layout fixo (o manifesto na raiz, o [Content_Types].xml e a extensão dentro de extension/): não precisa do vsce. Depois de mexer na gramática, nos trechos ou no package.json, o script empacota.ps1 da extensão regera o arquivo.

Compilar de dentro do editor#

Copie tasks-exemplo.json para .vscode\tasks.json do seu projeto. A partir daí:

Ctrl+Shift+B compila o arquivo aberto;
os erros caem no painel de Problemas (Ctrl+Shift+M), cada um clicável direto na linha e coluna.

Isso funciona porque o compilador já escreve arquivo(linha,coluna): Erro: texto. A extensão traz três leitores ($mycompiler-erro, $mycompiler-aviso e $mycompiler-dica), um por severidade, porque o VS Code casa severidade pelas palavras inglesas e as nossas mensagens estão em português. Com isso, os {$message hint 'x'} e {$message warning 'x'} espalhados pelo código aparecem no painel junto com os erros, cada um no seu nível.

O que o realce faz de diferente#

É case-sensitive, como a linguagem. Uma gramática Pascal comum acende BEGIN e Begin; aqui elas não são palavras reservadas, e acendê-las esconderia justamente o erro que você quer enxergar.
{$…} é diretiva, { … } é comentário, e a diretiva é reconhecida primeiro. Isso reproduz de propósito uma armadilha real do compilador: dentro de um comentário de chaves, um } que apareça no meio (por exemplo { veja o {$if} }) fecha o comentário ali, e o resto vira código. No editor você vai ver a cor voltar ao normal no meio da linha, que é o aviso de que aquilo não é mais comentário.
Os tipos levam a largura no nome (Int32, não Integer). Só os nomes válidos acendem como tipo: se você escrever Integer por hábito, ele fica sem cor, antes mesmo de compilar.
Também acendem os operadores do ? (??, ?., !), o corpo =>, e as diretivas reconhecidas por posição (static, inline, overload, virtual, pure, discardable, abi_win…), que são modificadores e não palavras reservadas.

Trechos (digite o prefixo e Tab)#

Prefixo	O que sai
`program`	esqueleto de projeto
`module`	módulo (sem `interface`/`implementation`)
`class` / `record`	com `end class;` / `end record;`
`precord`	`PNome^, TNome = record`: o ponteiro declarado junto
`helper`	`helper for`
`casevar`	parte variante, com o `end` do `case`
`forin`	`for-in`
`whilerot`	laço com rótulo, para o `break(nome)`
`sync`	região protegida com o `else` do prazo
`message`	`{$message}` com as quatro severidades
`tryf` / `trye`	`try..finally` / `try..except`

O que ainda não tem#

Não há servidor de linguagem: não existe ir-para-definição, completar por contexto (o que aparece é só o completar por palavras do arquivo), nem renomear. Isso exigiria expor o que o parser já sabe por um protocolo; o caminho natural seria um modo que devolva os símbolos em JSON, como o -rtti já faz com o grafo do gerador, e um processo pequeno traduzindo aquilo para LSP. É um projeto à parte. Também não há depuração passo a passo.

O RAD tem completar código por contexto (inclusive membros depois do ponto) e navegação entre declaração e implementação.