Por padrão, os símbolos são classificados de acordo com sua ocorrência no documento, mas você pode alterar a classificação para ordem alfabética. Para isso, clique com o botão direito do mouse na janela de ferramentas e marque "Classificar alfabeticamente".

A visualização de ferramentas mostra os símbolos no modo de árvore por padrão, porém você pode alterá-la para uma lista usando o menu de contexto.

Para ir para qualquer símbolo em seu projeto, você pode abrir a caixa de diálogo do símbolo "Ir para" usando Ctrl+Alt+p. A caixa de diálogo está vazia quando é aberta, mas assim que você digita algo, ela começará a mostrar os símbolos correspondentes. A qualidade das correspondências, bem como os recursos de filtragem, dependem do servidor que você usa. Por exemplo, o clangd oferece suporte à filtragem aproximada, mas alguns outros servidores podem não oferecer.

Cada servidor LSP específico possui sua própria forma de personalização e pode usar meios específicos de linguagem/ferramenta para configuração, por exemplo tox.ini (entre outros, para Python) ou .clang-format para formato no estilo C++. Essa configuração também pode ser usada por outras ferramentas (não LSP), como tox ou clang-format. Além disso, alguns servidores LSP também carregam configurações de arquivos personalizados (por exemplo .ccls). Ademais, a configuração personalizada do servidor também pode ser passada pelo LSP (protocolo), conforme mencionado nas entradas "initializationOptions" e "settings" na configuração do servidor.

Como são aplicados vários níveis de sobrescrita/fusão, o exemplo a seguir de configuração de cliente especificada pelo usuário ajusta algumas configurações do servidor de linguagem Python.

{
    "servers": {
        "python": {
            "settings": {
                "pyls": {
                    "plugins": {
                        "pylint": {
                            "enable": true
                        }
                    }
                }
            }
        }
    }
}

Infelizmente, a configuração/personalização do servidor LSP muitas vezes não é tão bem documentada, de forma que apenas a análise do código-fonte revela as abordagens de configuração e o conjunto de opções disponíveis. Em particular, o servidor do exemplo acima suporta muito mais opções em "configurações". Consulte a documentação de outro cliente LSP para vários outros exemplos de servidores de linguagem e configurações correspondentes, que podem ser facilmente transformadas na configuração JSON usada aqui e descrita acima.

Você pode ativar a opção "formatar ao salvar" nas configurações do LSP, na janela de configuração.

Pode acontecer de serem relatados diagnósticos que não sejam muito úteis. Isso pode ser bastante trabalhoso, especialmente se houver muitos (frequentemente do mesmo tipo). Em alguns casos, isso pode ser ajustado por meios específicos da linguagem (servidor). Por exemplo, o mecanismo de configuração do clangd permite o ajuste de alguns aspectos dos diagnósticos. Em geral, no entanto, pode nem sempre ser evidente como fazer isso, ou pode até não ser possível da maneira desejada devido a limitações ou bugs do servidor.

Assim, o plugin suporta a supressão de diagnósticos semelhante, por exemplo, às supressões do Valgrind. A configuração mais detalhada pode ser fornecida em uma chave "suppressions" na configuração JSON (mesclada).

{
    "servers": {
        "c": {
            "suppressions": {
                "rulename": ["filename", "foo"],
                "clang_pointer": ["", "clang-tidy", "clear_pointer"],
            }
        }
    }
}

Cada regra (válida) tem um nome arbitrário e é definida por uma matriz de comprimento 2 ou 3 que fornece uma expressão regular para corresponder ao nome do arquivo (completo), uma expressão regular para corresponder ao diagnóstico (texto) e uma expressão regular opcional que corresponde ao intervalo do código-fonte do texto ao qual o diagnóstico se aplica.

Além da configuração detalhada acima, o menu de contexto na aba de diagnósticos também permite adicionar/remover supressões que correspondam exatamente a um diagnóstico específico (texto), seja globalmente (qualquer arquivo) ou localmente (o arquivo específico em questão). Essas supressões são armazenadas e carregadas da configuração da sessão.

Uma coisa é descrever como configurar um servidor LSP (personalizado) para qualquer linguagem específica, outra é conseguir que o servidor funcione sem problemas. Normalmente, felizmente, este último é o caso mais comum. Às vezes, porém, podem surgir problemas devido a alguma configuração incorreta "boba" ou a um problema mais fundamental com o próprio servidor. Este último pode se manifestar tipicamente como algumas tentativas de iniciar o servidor, conforme relatado na aba Saída. Esta última, no entanto, destina-se apenas a transmitir mensagens ou progresso de alto nível, e não a fornecer diagnósticos detalhados, e muito menos para o que é, na verdade, outro processo (o servidor LSP).

A maneira usual de diagnosticar isso é adicionar alguma(s) flag(s) ao comando de inicialização (do servidor de linguagem) que habilite(m) o registro (adicional) em algum arquivo ou no erro padrão, caso isso não ocorra por padrão. Se o Kate for iniciado na linha de comando, então poderemos obter mais informações sobre o que pode estar dando errado.

Também pode ser informativo examinar a troca de mensagens do protocolo entre o cliente LSP do Kate e o servidor LSP. Novamente, este último geralmente possui maneiras de rastrear isso. O cliente LSP também fornece rastreamento de depuração adicional (para stderr) quando o Kate é invocado com a seguinte opção LSPCLIENT_DEBUG=1 e devidamente exportado.

O exemplo de virtualenv em Python acima é apenas um exemplo de um "ambiente de execução" que opera de forma distinta e separada do ambiente usual do host. Isso pode ser alcançado por meio de diferentes configurações de variáveis ​​(por exemplo, virtualenv), ou uma configuração (s)chroot (alternando para outro diretório como novo root), um contêiner (por exemplo, podman, docker) ou uma sessão ssh para outro host. Em cada caso, o "outro ambiente" é definido por um "prefixo de execução". Ou seja, algum programa pode ser invocado/executado no outro ambiente por meio de um "prefixo" (um programa e argumentos) anexado à invocação pretendida. Por exemplo, podman exec -i nome_do_contêiner ou ssh usuário@host.

Em particular, como no exemplo anterior do virtualenv, pode-se optar/precisar executar um servidor LSP em um ambiente separado (por exemplo, um contêiner com todas as dependências necessárias para algum projeto). A abordagem "manual" descrita acima tem a desvantagem de substituir a linha de comando padrão do LSP, que precisa ser especificada e duplicada novamente no script wrapper. Além disso, em alguns dos outros exemplos mencionados acima, o "path namespace" do host (como visto pelo editor) pode ser diferente do do ambiente. Para lidar com essas questões de forma mais sistemática (do que uma abordagem "personalizada"), algumas configurações adicionais podem ser especificadas.

Por exemplo, o seguinte pode ser especificado em uma configuração .kateproject. Obviamente, os comentários "falsos" não devem ser incluídos.

{
    // isto pode ser uma array de objetos
    "exec": {
        "hostname": "foobar"
        // o comando também pode ser uma array de string
        "prefix": "podman exec -i foobarcontainer",
        "mapRemoteRoot": true,
        "pathMappings": [
            // todas as formas a seguir são possíveis
            // um alternativa mais automágica existe também, veja a seguir/abaixo
            [ "/dir/on/host", "/mounted/in/container" ]
            { "localRoot": "/local/dir", "remoteRoot": "/remote/dir" }
        ]
    },
    "lspclient": {
        "servers": {
            "python": {
                // isto irá corresponder/juntar com o objeto acima
                "exec": { "hostname": "foobar" },
                // confina este servidor a sua raiz de projeto,
                // então ele não é usado para outros projetos que podem ser abertos
                // (outros servidores podem já empregar raízes específicas, mas o python generalmente não pode)
                "root": "."
            },
            "c": {
                // as above
                "exec": { "hostname": "foobar" },
                "root": "."
            }
        }
    }
}

Então, o que acontece como resultado do exposto acima? Como mencionado, a parte lspclient acima é mesclada à configuração global, portanto, uma seção exec é encontrada (para as linguagens especificadas). Uma busca é realizada por outro objeto (que especifica hostname correspondente) na seção exec ou lspclient, e um objeto correspondente serve como base para uma mesclagem. Como resultado, um servidor LSP (para C e Python) terá sua linha de comando anexada ao prefixo especificado (variável substituída) e, portanto, será iniciado dentro do contêiner fornecido. Obviamente, o contêiner deve ter sido criado, estar em um estado iniciado corretamente e equipado com servidores LSP apropriados. Poderia ter havido a tentação de usar a seção global (dentro de lspclient). Isso também poderia funcionar, mas então todos os servidores LSP seriam iniciados com esse prefixo, incluindo aqueles para, por exemplo, Markdown, script Bash ou JSON. É mais provável que o host usual ainda forneça esses (se estiverem em uso). Portanto, como sempre, depende da sua configuração específica.

No entanto, o servidor LSP agora pode observar caminhos (remotos) diferentes dos caminhos (locais) que são vistos e usados ​​pelo editor. Os pathMappings especificados são usados ​​para traduzir de um lado para o outro na comunicação com o servidor LSP. Isso é, obviamente, o máximo possível. Claramente, nem todos os caminhos locais têm uma representação remota, mas os ausentes também não são vistos (pelo servidor) e não representam um problema. Por outro lado, o servidor (remoto) agora pode ver e fornecer referências na "raiz remota" que não são evidentemente/facilmente representadas no sistema local. O mapRemoteRoot habilitado mapeia implicitamente a raiz remota para uma "URL local" exec://foobar, que é então tratada por um protocolo KIO simples. Este último utiliza essencialmente (por exemplo) podman exec -i foobarcontainer cat somefile para copiar de um arquivo remoto para um local (e outras variações semelhantes usando ferramentas do pacote coreutils). Basta dizer que não se destina ao uso geral e não promete qualquer desempenho, mas é suficiente para carregar um arquivo referenciado no editor de forma rápida e fácil.

Agora é fácil perceber que uma versão simplificada da configuração acima (sem hostname ou pathMappings) poderia ser usada para lidar com o ambiente virtual sem precisar duplicar a linha de comando do servidor (no script wrapper).

O que se segue pode não ser tão facilmente visível, por isso é mencionado aqui explicitamente.

Por último, mas não menos importante, e se a abordagem "KIO de fallback" não for considerada adequada? Na prática, muitas vezes é possível "montar" a raiz remota no sistema de arquivos local e, em seguida, especificar este último em um pathMappings. Para começar, o conhecido sistema de arquivos sshfs (fuse) pode montar um sistema (realmente) remoto no local. Para um contêiner (podman/docker), a maioria das configurações (de driver de sistema de arquivos) suporta o seguinte truque;

$ rootdir=/proc/`podman inspect --format '{{.State.Pid}}' containername`/root
# alguns links simbólicos podem causar problemas, veja também a alternativa abaixo
$ sudo mount --bind $rootdir /somewhere/containername

Se isso falhar, pode-se recorrer ao sshfs, ou, na verdade, a um subconjunto dele para montar a raiz remota/do contêiner;

# consulte as respectivas páginas de manual; sftp-server é suficiente para o protocolo de operações de arquivo real (não criptografado)
$ socat 'exec:podman exec -i containername /usr/lib/openssh/sftp-server'
   'exec:sshfs -o transform_symlinks -o passive \:/ /somewhere/containername'
# ...
$ fusermount -u /somewhere/containername

Observe que essa montagem da raiz remota no sistema de arquivos do host provavelmente será especificada manualmente e explicitamente em uma seção pathMappings (exceto em um inicializador de prefixo muito inteligente que organiza tudo isso automaticamente).