feat: comentários de documentação no hover e engine 1.4.0 - #79
Merged
Conversation
A engine 1.4.0 traz a interpretação dos comentários de documentação e a depreciação por `#pragma deprecated`. Também: `@types/node` 26.4.0, `esbuild` 0.28.2 e `vscode-languageclient` 10.1.1. `@types/vscode` volta para 1.106.0, fixo. O bump para 1.134.0 conflitava com `engines.vscode` (`^1.106.0`) e o vsce recusava empacotar; tipar contra uma API mais nova do que o `engines` permite deixaria passar uso de API inexistente no alvo. Fixo, e não em faixa, porque com `^` o npm reintroduz a 1.134 na próxima instalação e o conflito volta.
`github/codeql-action` 4.37.8 → 4.37.9 (`init` e `analyze` no mesmo SHA), `softprops/action-gh-release` 3.0.2 → 3.0.3 e `pymdown-extensions` 11.0.1 → 11.0.2, com os hashes verificados no PyPI. O workflow do CodeQL passa a aceitar `workflow_dispatch`, como o do Scorecard e o do repositório da engine.
Nova seção em `features.md` com exemplos dos dois formatos reconhecidos, e a seção de depreciação reescrita para a diretiva do compilador — o marcador `@DEPRECATED` deixou de ser reconhecido pela engine. Remove também uma linha duplicada de "Semantic Tokens".
|
Olá! 👋 Muito obrigado pelo seu primeiro pull request neste repositório. 🎉 Enquanto isso, confira se:
Agradecemos demais sua contribuição. 🙌 |
github-actions
Bot
added
deps
O PawnPro Debugger 0.2.0 amplia bastante o conjunto DAP: call stack multi-frame navegável, data breakpoints (inclusive em elementos de array), breakpoints de função, mais três classes de erro de runtime, arrays expansíveis e strings na inspeção, expressões no watch e no hover, edição por expressão e leitura de memória. Checksums repinados a partir da release e conferidos contra o `checksums.sha256` dela. A extensão não precisou de ajuste: o marcador do plugin passou a `PAWNPRO_DEBUG_MARKER:0.2.0`, mas `isOfficialDebugPlugin` casa só o prefixo. Atualiza a documentação de depuração, que ainda listava "call stack mostra só o frame atual" como limitação.
This was referenced Sep 1, 2026
A página de Ajuda dizia que a 3.10.11 era "a única existente e a testada". A 3.10.10 também funciona, incluindo a depuração — no Windows, a depuração ainda não foi verificada. A 3.10.11 segue sendo a recomendada. A chave dos bundles `l10n/` é a própria string em português, então o texto foi atualizado nos cinco idiomas.
github-actions
Bot
added
i18n
….json O tipo do servidor era decidido por `existsSync(config.json)`, e isso errava nos dois sentidos: - um open.mp recém-baixado ainda **não tem** `config.json` (é gerado na primeira execução) e passava por SA-MP; - um SA-MP com um `config.json` de outra ferramenta na mesma pasta passava por open.mp. O tipo decide o arquivo de log acompanhado, a leitura de RCON e o preflight do depurador — que então checava a pasta e a forma de registro erradas. `detectServerType` centraliza a decisão e olha, do sinal mais forte ao mais fraco: o executável (inequívoco), a pasta `components/` (exclusiva do open.mp), um `config.json` que tenha as chaves do open.mp — e não qualquer JSON homônimo — e por fim o `server.cfg`. `server.type` explícito na configuração continua tendo precedência.
O botão "Enviar" vira ícone. A fonte de codicons não chega à WebView (o CSP
é `default-src 'none'`, sem `font-src`, e CDN é bloqueado), então o traço vai
inline no HTML, com `currentColor` para seguir o tema — o mesmo ícone
substitui o "Enviar" das linhas da lista.
Favoritos e Últimos comandos deixam de ser duas listas empilhadas e passam a
dividir o mesmo espaço em abas, com a contagem em cada uma. O botão "Limpar"
segue a aba visível, para não haver dois com o mesmo rótulo e alvos
diferentes.
Esta era a única WebView com as strings fixas no código — daí os acentos que
faltavam ("historico", "Ultimos"). Passa a usar `createWebviewMsg` como as
outras, com as dez chaves nos cinco bundles, e é re-renderizada quando
`ui.locale` muda.
Também adiciona os badges de estrelas (nos dois repositórios) e de downloads
totais do repositório na extensão.
Ajustes sobre a revisão anterior, a partir do uso:
- **Textos.** O placeholder ("Digite um comando do servidor e pressione
Enter...") e a dica sobre setas/estrela ocupavam mais espaço do que
informavam. Viram "Digite um comando" e uma linha que responde a dúvida
real de quem usa o painel: escreve-se **sem barra** (`gmx`, `kick 0`) — o
prefixo `rcon` já é removido em `sendLine`.
- **"Últimos comandos" → "Recentes".** Mais direto, e cabe no painel
estreito sem truncar.
- **Ícones proporcionais ao botão.** O traço tinha tamanho fixo, então nas
linhas da lista ficava maior que o próprio botão.
- **Estrela dos favoritos.** O emoji `⭐`/`☆` ignora o tema e o contorno some
no fundo do painel. Vira SVG em dois estados: contornada quando não é
favorito, cheia e em amarelo do tema quando é.
- **Responsividade.** O painel lateral chega a ~170px: rótulos, ícones e a
dica passam a reduzir por `clamp`, com `min-width: 0` para o input encolher
e a contagem saindo abaixo de 220px, em vez de o layout quebrar.
O `clamp` usava `vw`, que mede a janela inteira. Com a janela estreita — mesmo com o painel tendo espaço — as fontes caíam para o mínimo: rótulos das abas e a dica ficavam em 10px sem necessidade. O `body` passa a declarar `container-type: inline-size` e as consultas viram `@container`, medindo o painel de fato. Com isso os textos voltam ao tamanho normal (12px nas abas, 11px na dica) e só cedem quando o painel realmente aperta: primeiro o respiro lateral (230px), depois a contagem de itens (190px), que é o menos essencial. O rótulo mantém o tamanho — é ele que identifica a aba.
A dica flutuava entre o input e as abas, sem vínculo com nenhum dos dois, e as crases do texto apareciam literais — era texto puro, não Markdown. - A dica cola no input e alinha ao texto dele, lida como legenda do campo; os trechos entre crases viram `<code>` (escapando antes de marcar, para que só a tag gerada aqui chegue ao HTML). - Os espaçamentos, que eram avulsos (6, 10, 4...), passam por uma escala de três degraus, dando ritmo vertical constante. - A régua das abas se estende até as bordas do bloco, para a aba ativa sentar sobre uma linha que atravessa o painel em vez de um traço curto. - Input e botão de enviar ganham a mesma altura, alinhando a primeira linha.
Revisão do commit anterior. Três pontas soltas: - **CSS órfão.** `.section-header` ficou definido sem uso desde que as seções viraram abas. - **Valores fora da escala.** Criei a escala e deixei `9px`, `28px`, `6px` e `10px` soltos pelo arquivo — exatamente o que ela deveria eliminar. Agora os espaçamentos vêm todos dela, e a altura e o recuo dos controles da primeira linha têm variáveis próprias (a legenda alinha pela mesma). - **Acoplamento silencioso.** A sangria das abas cancelava o recuo do bloco repetindo `--gap-sm` nos dois lugares: mudar um desalinharia a régua sem aviso. O recuo passa a viver em `--section-pad`, usada pelos dois.
- **A dica sai.** O texto sobre a barra não se acomodou em nenhum lugar do
painel; a orientação passa a viver na documentação, com um link direto na
página de Ajuda ("Guia do servidor: comandos, favoritos e log").
- **"Limpar" vira lixeira**, como "Enviar" virou seta. O rótulo continua no
title e no aria-label.
- **Contagem com teto.** O histórico guarda até 200 comandos, então a aba
podia exibir "(200)" e empurrar o rótulo. Acima de 99 vira "99+".
- **Busca e paginação.** As listas carregam 20 itens por vez, com "Mostrar
mais", e um campo filtra conforme se digita — só aparece quando há o que
buscar. Trocar de aba reinicia ambos: a página não faz sentido sobre outro
conjunto. A lista vazia distingue "não há nada" de "a busca não achou".
- **Rolagem.** A barra padrão do navegador é larga e clara, destoando do
painel: passa a usar as cores do tema, e a altura máxima recorta em linhas
inteiras para não cortar um item ao meio.
O renderizador de Markdown da página não conhecia cercas de crases. As linhas caíam na regra final e viravam parágrafos: a cerca aparecia literal, o código perdia a formatação, e trechos dele ganhavam destaque por acaso ao passarem pela marcação inline. Passam a virar `<pre><code>`, com o conteúdo escapado e sem marcação inline — dentro de um bloco, `-` inicia uma linha de código, não uma lista. A indentação da cerca é descontada, para um bloco aninhado numa lista não carregar o recuo dela para dentro do código, e uma cerca não fechada no fim ainda renderiza o que veio antes.
A lista tinha altura fixa em seis linhas, sem relação com o espaço real do painel: quando ele era menor que isso, a lista rolava por dentro enquanto o painel rolava por fora — dois scrolls no mesmo gesto, e alargar o painel não fazia nenhum dos dois sumir. O painel passa a ser uma coluna que ocupa a altura disponível: campo, abas e busca mantêm o tamanho, e a lista consome o que sobra. Só ela rola, e dar mais espaço ao painel faz a barra desaparecer sozinha, que era o comportamento esperado. O botão de limpar acumulava as classes mini (recuo próprio) e icon-btn (medida fixa) ao mesmo tempo, e as duas se contradiziam — daí o aspecto estranho. Ganha uma classe própria, com medida única e discreta como as abas, destacando-se ao passar o mouse.
- **Estado vazio.** Era uma linha em itálico encostada no canto, ocupando mal
o espaço que é a primeira coisa vista num painel novo. Passa a ser centrado,
com ícone e uma segunda linha dizendo como preencher a lista ("marque um
comando com a estrela..."). O caso de busca sem resultado tem ícone e texto
próprios — a saída para ele é outra.
- **Comando longo.** O `min-width: 0` autoriza o texto a encolher com
reticências; sem ele o flex mantinha a largura do conteúdo e empurrava os
botões para fora da linha. O comando inteiro segue no title.
- **Lixeira maior** (16px), que a 13px ficava difícil de reconhecer.
- **X da busca.** O botão nativo herda o azul de acento do sistema, alheio ao
tema; redesenhado como um X na cor de erro, que é o que a ação significa.
Na página "O que há de novo", a continuação de um item — o parágrafo depois do bloco de código — saía com a cor de descrição, mais apagada que o item acima. Não era a cor: era a estrutura. O parser fechava a lista em dois pontos indevidos, e o texto virava um parágrafo solto do card. - Uma linha em branco fechava a lista. Em Markdown ela não encerra nada; só o conteúdo seguinte decide, quando volta à margem. - A cerca de código também fechava. Um bloco indentado pertence ao item acima. Com a lista preservada, o conteúdo passaria a cair dentro do `<ul>` e fora de qualquer `<li>` — inválido. O item agora fica aberto enquanto puder receber continuação, e o bloco e o parágrafo ficam dentro dele, herdando a cor e o tamanho do item.
O X do campo de busca sumiu: a máscara apontava para uma variável declarada em :root, mas o pseudo-elemento vive no shadow DOM do input, onde ela não chega — sem máscara, restava um quadrado da cor de fundo. O desenho passa a ir direto no pseudo-elemento, com a cor dentro do próprio SVG. No estado vazio, a dica somava a cor de descrição com opacidade por cima e quase sumia. O título passa a usar a cor normal do texto — é a resposta a "o que há aqui?" e precisa ser lido primeiro — e a dica fica só com a cor secundária, sem a opacidade extra.
Comparei a saída do parser com a do GitHub (a mesma que renderiza este changelog) e havia duas divergências reais: - **Sub-lista fora do item pai.** O `</li>` era fechado antes do `<ul>` aninhado, deixando os sub-itens como irmãos do pai em vez de filhos. O item agora permanece aberto e só fecha depois do `</ul>` que estava dentro dele. - **Recuo dobrado.** O bloco de código e a continuação já herdam o recuo do `<li>`; o `margin-left` que eu havia somado os afastava além do que o Markdown pede. Sobre a posição: o recuo do bloco e do parágrafo é o comportamento correto — o GitHub também os coloca dentro do `<li>`. O que estava errado era o espaçamento extra, não o alinhamento.
…otão
Duas correções na raiz, no lugar dos contornos anteriores.
**Listas.** O parser tinha um único `liOpen` para toda a estrutura, mas há um
item aberto por nível de lista. Daí os defeitos irem trocando de lugar a cada
ajuste: consertar a continuação depois de uma sub-lista quebrava a
continuação depois de um bloco de código, e vice-versa — e a flag `manterLi`
que eu havia acrescentado ao `closeLists` era o sintoma disso, uma exceção
para contornar um estado que não representava a estrutura.
A pilha passa a guardar `{ indent, liOpen }` por nível, e `closeLists` volta
a ter uma responsabilidade só: fecha as listas mais internas, deixando aberto
o item do nível de destino — que é, por definição, o dono do que vem a
seguir. Comparado com o renderizador do GitHub em quatro casos (bloco dentro
de item, sub-lista, continuação depois de sub-lista, continuação dentro de
sub-item): saída idêntica nos quatro.
**Busca.** O X do `type="search"` vive no shadow DOM do input: a cor do tema
não chega até lá, e a máscara declarada no documento também não — ficava azul
do sistema ou invisível. Vira um botão próprio ao lado do campo, que aparece
quando há texto.
O ícone do estado vazio recebe o tipo como classe ('empty-icon ' + tipo).
Quando a busca não acha nada o tipo é 'search', então o div ficava
class="empty-icon search" e casava com o seletor .search, que estiliza o
campo de texto: herdava width:100%, height:24px, borda e background do
input, aparecendo como uma barra cinza acima da lupa.
O seletor passa a ser ancorado no elemento (input.search). Os outros dois
tipos, hist e fav, não colidem com nenhum seletor.
Cada categoria ganha um campo onde o usuário escreve o próprio padrão, como /^g_[a-z][a-zA-Z0-9]*$/, ao lado das cinco etiquetas. Os dois convivem: a engine aceita o nome que casar com qualquer critério da categoria. O campo mostra o efeito da regra enquanto se digita — os nomes de exemplo da categoria são testados contra o padrão e marcados com ✓ ou ×, e avisa quando nenhum passa. Um padrão inválido não é gravado: a engine o descartaria em silêncio e restaria uma regra que não existe. A validação da webview replica a da engine: mesma convenção de barras, mesma âncora ^(?:...)$ e mesmo tratamento do padrão inválido. O preview principal ignora o padrão próprio, porque de um regex arbitrário não se gera um nome de exemplo — seu efeito aparece no campo dele.
Dois defeitos no retorno visual, ambos meus: - O exemplo com prefixo era fixo em g_, então quem escrevesse /^q_.../ via g_carregarLixeiras na lista — um nome que o padrão dele rejeita, e que nenhum outro exemplo substituía. O prefixo passa a sair do próprio padrão, quando ele começa por um literal. - Enquanto se digita, o texto passa por estados incompletos (a barra final é o último caractere) e cada tecla acusava erro. Agora a reclamação só aparece ao confirmar; durante a digitação o campo apenas deixa de mostrar exemplos, em vez de manter os do padrão anterior. O invariante que faltava: os exemplos exibidos correspondem sempre ao texto que está no campo, nunca a um padrão anterior.
Os exemplos estavam dentro da coluna do rótulo, estreita, como texto corrido separado por espaços. Enchiam a coluna, quebravam no meio das palavras e empurravam a página. Passam a ocupar uma linha própria sob o campo, como etiquetas que não se partem (white-space: nowrap) numa grade que quebra entre elas. Os aceitos vêm primeiro, para caberem na primeira linha quando a lista quebra.
O motor de regex do JS faz backtracking: /^(a|b|ab)+X$/ contra uma entrada de 52 caracteres leva 1,7s, e o custo dobra a cada caractere. Como a pré-visualização roda a cada tecla, um padrão desses congelaria a página. A defesa que funciona é limitar a ENTRADA, não medir o tempo: uma vez iniciado, re.test roda até o fim — JS é single-threaded e não há como interrompê-lo. Um orçamento verificado entre testes deixava passar 17s num teste único. Agora o nome testado tem teto de 40 caracteres, o prefixo derivado do padrão tem teto de 12, e o padrão em si de 200; o orçamento fica só para não somar muitos testes caros. A engine não precisa disso: a crate regex do Rust tem tempo linear garantido. O limite é da pré-visualização, e por isso o aviso diz que a análise continua funcionando.
As sete etiquetas com ✓ e × davam o mesmo peso visual ao nome aceito e aos seis rejeitados, num vocabulário (bordas, pílulas coloridas) que não existe em nenhum outro lugar da página. O usuário tinha de decodificar item a item para responder à única pergunta que importa: o que este padrão aceita? Passa a mostrar UM nome aceito no mesmo trecho de código Pawn que as etiquetas de estilo já usam logo acima, na mesma coluna e com a mesma aparência (.naming-preview). Avisos voltam à fonte da interface, para não serem lidos como nome de exemplo. O campo de padrão ganha largura fluida com clamp(), como o recuo da página: num painel estreito ele cede em vez de espremer o rótulo.
A borda inferior da linha do padrão caía entre ele e a categoria seguinte, sugerindo que o campo pertencia à categoria de baixo — quando é da de cima. A separação estava dividindo o que é uma configuração só: as etiquetas e o padrão são a mesma lista de critérios aceitos. Passa a haver uma linha por categoria. O campo fecha a grade de etiquetas numa quarta linha própria (a grade preenche por coluna, então a posição é explícita para ele não virar uma sexta etiqueta), e seu exemplo fica sob o exemplo dos estilos, na mesma coluna e com a mesma aparência. A borda volta a delimitar a categoria inteira. Sem rótulo visível, o campo leva o nome em aria-label — daí data-i18n-aria, já que data-i18n só alcança textContent. Os min-width fixos dos controles da página passam a clamp(): em painel largo mantêm a medida atual, e em painel estreito cedem em vez de espremer o rótulo ao lado. Os dois campos numéricos de 90px seguem fixos, onde um clamp teria piso igual ao teto.
O overflow-x: auto que eu havia posto no exemplo do padrão criava um contexto de formatação próprio, e a caixa encolhia até o conteúdo: o fundo do <code> ficava mais curto que o da linha logo acima, que é display:block e ocupa a coluna inteira. Os dois mostram a mesma coisa e passam a ter a mesma caixa. O scroll não faz falta: os exemplos cabem na coluna, e em painel muito estreito o comportamento agora é o mesmo do preview dos estilos, que sempre foi assim.
O display que o user-agent aplica a [hidden] tem especificidade mínima e perde de qualquer classe que declare display. Como .naming-preview é display:block, o elemento continuava visível mesmo com o atributo posto — e a caixa aparecia na página sem conteúdo, com largura diferente da linha de cima. A página não tinha a regra; a do painel do servidor já tem, pelo mesmo motivo. Vale para todo elemento da página que venha a combinar hidden com uma classe que declare display.
Como bloco de largura total, o fundo do <code> ia até a borda da coluna independentemente do texto. Com dois exemplos empilhados — o dos estilos e o do padrão próprio — a diferença de comprimento entre eles virava duas caixas de tamanhos distintos, uma sob a outra. width: fit-content mantém cada exemplo em sua linha e faz o fundo acompanhar o texto; max-width: 100% evita transbordar a coluna num exemplo longo.
Havia dois <code> irmãos renderizando a mesma coisa, e toda a diferença visual entre eles vinha daí: caixas de larguras distintas, e o nó de texto entre as duas tags virando uma linha anônima de ~18px no container, que lia como espaçamento extra na primeira. Tratar isso pelo CSS ou colando as tags no markup seria remendar o sintoma. updateNamingPreview já juntava vários exemplos com quebra de linha num único elemento; o padrão próprio passa a ser mais uma linha dessa lista. Some o segundo elemento, seu CSS e a função que só existia para alimentá-lo. Para os embutidos o nome vem do estilo; para o regex, do primeiro exemplo que o padrão aceita. Um padrão inválido ou que nada aceita não contribui linha — a reclamação fica no campo, que é onde se escreve.
O padding lateral de 3rem era fixo: num painel de 320px consumia 30% da largura disponível, apertando o texto. Com clamp o conteúdo ganha 64px ali, e em tela larga o recuo é o mesmo de antes. Mesma solução que a página de configurações já usa em --pad-x.
Um traço de 16x16 por seção, no mesmo padrão do painel do servidor: SVG inline com fill currentColor, então o ícone acompanha os estados de hover e ativo sem regra própria para cada um. O rótulo passa a viver num <span> dentro do link: data-i18n escreve textContent e apagaria o <svg> irmão se ambos fossem filhos diretos do <a>. O recuo esquerdo perde os 2px que a borda do item ativo ocupa, para o ícone não deslizar ao ganhar a borda. O rótulo trunca com reticências se apertar, e o ícone permanece — os nove cabem em 180px com folga, com margem para idiomas de palavras mais longas.
O rótulo passou a viver num <span> com overflow oculto para poder truncar, e o texto ficou visivelmente menor que o original. Sobe de 0.93em para 0.98em, e o ícone de 15px para 16px para acompanhar. Os nove rótulos seguem cabendo em 180px com 46px de folga; os mais longos em russo e espanhol também.
Seis cores mais o padrão Automático, que herda do tema do editor como sempre foi — quem não escolher nada não vê diferença. A paleta é fechada porque o valor entra direto em CSS: cada tom foi verificado com o texto que vai por cima e passa o mínimo AA de 4.5:1. O hover escurece em vez de clarear; clarear reduzia o contraste e três das seis cores reprovavam. O controle é central: webviewTheme.ts é o único lugar que lê a configuração, e as páginas recebem só uma string de CSS. Uma cor nova ou uma variável a mais se resolve ali e vale para todas as cinco. A troca vale de imediato — a página de configurações regera o HTML quando a cor muda (só quando muda: o <style> não se atualiza por mensagem), e o painel do servidor já se re-renderiza a cada mudança de config. Não toca no realce de sintaxe, que tem esquema próprio.
Era o caractere ▸ num ::before: o desenho vinha da fonte do sistema, então o peso e a forma destoavam dos ícones da página, que são traços SVG. Vira um chevron SVG de 14px com fill currentColor, seguindo o mesmo padrão do resto — e girando 90° ao abrir, como antes. O summary passa a ser uma grade de duas colunas: o chevron ocupa a primeira, título e descrição a segunda. Some o padding-left: 18px que alinhava a descrição no chute — ele só acertaria se o glifo medisse exatamente 12px, e a largura dependia da fonte. Tamanho, peso e opacidade do texto seguem os mesmos.
O chevron que pus antes era um traço de ~1.5 unidades a 60% de opacidade: fino e apagado, pior que o glifo que substituiu. Vira um triângulo preenchido — a forma convencional de disclosure, e que não depende de espessura de traço para ser vista. Quase o dobro de massa visível, opacidade de 0.6 para 0.85, e 12px em vez de 14px porque uma forma cheia precisa de menos área que um contorno.
A implementação redefinia --vscode-button-background e afins num :root. O editor injeta essas variáveis no atributo style do <html>, e declaração inline vence qualquer seletor na cascata — a regra nunca se aplicava. Por isso nada mudava em página alguma. Passa a haver variáveis próprias (--pp-accent, -hover, -fg) que caem nas do editor quando não há cor escolhida, preservando o modo automático. Os 23 pontos que usavam o azul do editor nas cinco páginas e na animação da marca passam a consumi-las. A seta do grupo de nomenclatura vai a 16px com opacidade cheia e um triângulo que ocupa 15% do quadro — era 5% num traço a 60%.
Os badges da Ajuda e do O que há de novo usavam --vscode-badge-background, nome que a conversão anterior não alcançou, e seguiam azuis com outra cor escolhida. O texto do badge passa a sair de --pp-accent-fg junto com o fundo, para o contraste acompanhar a cor. A loja fica como está, a pedido.
Cria a página do servidor, que a página de Ajuda já linkava e não existia: iniciar e parar, envio de comandos por RCON, abas de recentes e favoritos, o que não é guardado no histórico e o acompanhamento do log. Marcadores de imagem deixados para inserção posterior. Atualiza o que ficou para trás: - Changelog — o padrão próprio de nomenclatura, a cor de destaque e os ícones da navegação; as entradas de engine e depurador passam a citar só a versão, com link para o detalhamento de cada projeto. - features.md — padrão próprio, cor de destaque, PP0019 na tabela, e a descrição do painel do servidor, que ainda falava de botões que viraram abas. - naming-assistant.md — o exemplo mostrava os estilos como string e citava uma categoria 'enums' que não existe; são listas, e as categorias são constants e macros. - configuration.md — a chave ui.accent. - Contagem de diagnósticos: 19 códigos, não 18 (o PP0019 entrou na 1.4.0). Corrigida no README, no index e no CLAUDE.md, que ainda dizia PP0013.
Auditoria dos 50 commits desde a última release: 31 têm efeito para quem usa a extensão, e 12 não estavam registrados. - Seção **Segurança** própria, como manda o Keep a Changelog que o arquivo declara seguir: os três itens estavam diluídos em Corrigido. O item do RCON ganha o quinto ponto da auditoria, que faltava — um login digitado sem o prefixo rcon tinha a senha gravada no log e no histórico. - **Adicionado** — o controle do histórico na página de configurações: as duas chaves existiam mas só à mão no config.json. - **Alterado** — refinamentos visuais do painel do servidor e os textos mais diretos. - **Corrigido** — textos que encolhiam por medir a janela em vez do painel, os dois scrolls concorrentes, a grade irregular dos estilos de nomenclatura, a hierarquia de listas do renderizador de Markdown e o X de limpar a busca, que ficava invisível. - **Documentação** — a página nova do servidor e a atualização das demais. Os 19 commits restantes são iteração sobre código que não chegou a ser publicado: não descrevem mudança para quem instala a versão.
- Página de configurações em painéis estreitos: as larguras fixas dos controles espremiam o rótulo ao lado e passam a ceder proporcionalmente, mantendo a medida atual em tela larga. Absorve o item do recuo lateral das páginas de Ajuda e O que há de novo, que dizia o mesmo em Corrigido. - Seta do grupo de estilos de nomenclatura, que era um caractere desenhado pela fonte do sistema. - No padrão próprio, onde cada validação acontece: a análise é da engine, cujo motor de expressões regulares tem tempo linear garantido, e a pré-visualização da página tem limites próprios por rodar no editor.
Era uma lista de especificações: dizia o que a extensão tem, nunca para quem serve nem que problema resolve. Quem chega pela busca — pessoa ou máquina — não conseguia inferir o valor, e o texto não mencionava sequer que é uma IDE completa e não um realce de sintaxe. Passa a abrir pelo ciclo que o desenvolvedor Pawn conhece (salvar, trocar de janela, compilar, ler um erro sem contexto) e pelo que a extensão faz com ele. Os recursos ficam agrupados por momento de uso — enquanto escreve, na hora de compilar, para o projeto não virar bagunça — em vez de listados por categoria técnica. Acrescenta instalação, primeiros passos e um índice da documentação, que não existiam. Os números foram conferidos no código: 19 diagnósticos, 11 deles com correção automática.
São 13; o README dizia apenas 'vários'.
server.history.enabled e server.history.sensitiveCommands podem ser editadas pelo usuário e não estavam na tabela nem no exemplo, embora já tivessem controle na página de configurações.
Os package.nls desses três idiomas traziam os valores ingleses como marcador — havia até um _comment pedindo a tradução. Na prática, quem usa o editor em espanhol via 'PawnPro: Compile current file' na paleta. As 22 chaves realmente referenciadas no package.json passam a estar traduzidas nos cinco idiomas. Remove também 36 chaves órfãs: descrições de config.* da época em que as opções viviam no settings.json do editor. Hoje a configuração está em .pawnpro/config.json e na página própria, e contributes.configuration não expõe nenhuma delas — traduzi-las não teria efeito.
Os cinco artefatos da release v1.4.0, conferidos contra o checksums.sha256 publicado junto dela.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O que muda
Fecha a 3.5.0. Sobe a engine para 1.4.0 e o depurador para 0.2.0, e traz o painel do servidor revisto, o padrão próprio de nomenclatura, a cor de destaque escolhível e uma rodada de segurança no envio por RCON.
O detalhamento de cada item está no CHANGELOG — 50 entradas, divididas em Adicionado, Alterado, Segurança, Corrigido e Documentação.
Destaques
#pragma deprecated,PP0019, quick fixes, padrão de nomenclatura por regex — detalhesQuem usava
// @DEPRECATEDprecisa trocar por#pragma deprecated, a diretiva do próprio compilador — o marcador antigo deixou de ser reconhecido:O autocomplete do
@, que existia só para inserir o marcador, passou a oferecer as tags de documentação.Nota sobre
@types/vscodeVolta para 1.106.0, fixo. O bump para 1.134.0 (#74) conflitava com
engines.vscode(^1.106.0) e ovscerecusava empacotar. Elevar oenginesexcluiria usuários de editores anteriores à 1.134, então o alinhamento foi pelo outro lado. Fixo, e não em faixa, porque com^o npm reintroduz a 1.134 e o conflito volta.Verificação
tsclimpo e CI verde. VSIX empacotado com o binário oficial da release da engine — o hash dentro do pacote confere com o publicado — e testado no editor contra os includes do open.mp e do SA-MP.