По умолчанию все идентификаторы упорядочены по порядку в документе, но также возможно выполнить сортировку по алфавиту. Для этого следует щёлкнуть по панели правой кнопкой мыши и выбрать пункт «Сортировать по алфавиту».

По умолчанию панель отображает идентификаторы в виде дерева, но с помощью контекстного меню также возможно представить их в виде списка.

Чтобы перейти к любому идентификатору в проекте, следует открыть диалог перехода с помощью комбинации клавиш Ctrl+Alt+p. При открытии диалог пуст, но по мере набора текста пользователем будут появляться соответствующие идентификаторы. Качество совпадений, а также возможности фильтрации зависят от используемого сервера. Например, clangd поддерживает неточную фильтрацию, а какой-либо другой сервер может не поддерживать эту возможность.

Каждый сервер LSP имеет свой собственный способ настройки; для конфигурации могут использоваться средства, специфичные для языка или инструмента, например, tox.ini (в том числе для python), .clang-format для форматирования в стиле C++. Такая конфигурация затем может также использоваться другими (отличными от LSP) инструментами (такими как tox или clang-format). Кроме того, некоторые серверы LSP загружают конфигурацию из пользовательских файлов (например, .ccls). Более того, настраиваемая конфигурация сервера также может быть передана с помощью LSP (протокол): смотрите вышеупомянутые записи «initializationOptions» и «settings» в конфигурации сервера.

Поскольку применяются различные уровни переопределения и слияния, в приведённом далее примере определённые пользователем параметры конфигурации клиента корректируют некоторые из параметров конфигурации python-language-server.

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

К сожалению, конфигурация сервера LSP зачастую не очень хорошо документирована, поэтому только изучение исходного кода позволяет найти способы настройки и набор доступных параметров конфигурации. В частности, сервер из приведённого выше примера поддерживает намного больше параметров в «settings». Ознакомьтесь с документацией другого клиента LSP, содержащей примеры серверов других языков и соответствующие параметры настройки, которые возможно легко и просто преобразовать в конфигурацию JSON, которая описана в этом руководстве.

Можно включить «форматирование при сохранении» в диалоге настройки параметров LSP.

Иногда диагностические данные могут оказаться не слишком полезны. Диагностика может быть лишней, особенно если диагностических сообщений слишком много (часто однотипных). В некоторых случаях поток сообщений можно скорректировать по языку программирования (на сервере). Например, механизм настройки clangd позволяет корректировать некоторые аспекты диагностики. Тем не менее, способ корректировки не всегда очевиден, а также желаемая корректировка может быть невозможна из-за ограничений сервера или внутренней ошибки.

Поэтому в модуле предусмотрена поддержка подавления диагностических сообщений (она похожа, например, на подавление valgrind). Самую тонкую настройку возможно выполнить с помощью ключа «suppressions» в (объединённой) конфигурации JSON.

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

Каждое (корректное) правило имеет произвольное имя и определяется массивом длины 2 или 3, в котором указано регулярное выражение для установления соответствия (полного) имени файла, регулярное выражение для установления соответствия диагностического текста и необязательное регулярное выражение для установления соответствия (диапазона исходного кода) текста, к которому применяется диагностика.

Помимо вышеупомянутой тонкой настройки, в контекстном меню на вкладке диагностики также предусмотрено добавление и удаление подавлений, которые точно соответствуют определённому диагностическому тексту (либо глобально (любой файл), либо локально (конкретный рассматриваемый файл)). Эти подавления хранятся и загружаются из конфигурации сеанса.

Одно дело описать настройку (нестандартного) сервера LSP для какого-либо языка программирования, другое же — сделать так, чтобы сервер работал без каких-либо проблем. К счастью, обычно сервер работает именно так. Впрочем, иногда могут возникать сложности из-за случайно допущенных неточностей в параметрах настройки или более серьёзных проблем с самим сервером. Второй вариант может проявлять себя в виде сообщения о неудачных попытках запустить сервер, которое появляется на вкладке вывода данных Kate. Следует учитывать, что такие сообщения представляют собой лишь сообщения верхнего уровня или хода обработки, а не подробные диагностические сообщения, а также могут не содержать данных о том, что фактически является другим процессом (сервер LSP).

Обычный способ диагностики заключается в том, чтобы добавить к команде запуска (языкового сервера) один или несколько флагов; это включает (дополнительное) журналирование (в какой-либо файл или стандартный поток ошибок), если оно не выполняется по умолчанию. Если затем запустить Kate из командной строки, возможно, получится узнать о проблеме больше.

Информацию также можно получить, изучив обмен данными между клиентом LSP Kate и сервером LSP. Опять же, на последнем обычно есть средства трассировки. Клиент LSP также предоставляет дополнительную трассировку отладки (в stderr) при вызове Kate с должным образом экспортированной переменной среды LSPCLIENT_DEBUG=1.

Приведённый выше пример виртуальной среды python — лишь один из вариантов «среды выполнения», работающей отличным и отдельным от обычной среды основной системы образом. Этого можно достичь с помощью различных параметров переменных (например, virtualenv) или настройки (s)chroot (переключения на другой каталог в качестве нового корня), контейнера (например, podman, docker) или ssh-сеанса к другой основной системе. В каждом из этих случаев «другая среда» определяется «префиксом выполнения». Это означает, что в этой другой среде программу можно вызвать/запустить с помощью «префикса» (программа и аргументы), добавленного к предполагаемому вызову. Например, podman exec -i containername или ssh user@host.

В частности, как было сделано в приведённом ранее примере virtualenv, можно запустить сервер LSP в такой отдельной среде (например, контейнер со всеми необходимыми проекту зависимостями). «Ручной» подход, описание которого приведено выше, имеет следующий недостаток: выполняется замена стандартной командной строки LSP, её потом необходимо указать и продублировать ещё раз в сценарии-обёртке. Кроме того, в некоторых других вышеупомянутых примерах «путь к пространству имён» основной системы (как он виден редактору) может отличаться от соответствующего для среды. Чтобы решить эти вопросы более системно (а не просто с помощью «индивидуального» подхода), можно дополнить конфигурацию.

Например, в конфигурации .kateproject можно указать следующее. Очевидно, что «фиктивные» комментарии включать не следует.

{
    // это также может быть массив объектов
    "exec": {
        "hostname": "foobar"
        // команда также может быть массивом строк
        "prefix": "podman exec -i foobarcontainer",
        "mapRemoteRoot": true,
        "pathMappings": [
            // возможна любая из следующих форм
            // также существует более автоматизированная альтернатива, подробнее о ней далее/ниже
            [ "/dir/on/host", "/mounted/in/container" ]
            { "localRoot": "/local/dir", "remoteRoot": "/remote/dir" }
        ]
    },
    "lspclient": {
        "servers": {
            "python": {
                // это устанавливает соответствие или выполняет объединение для объекта выше
                "exec": { "hostname": "foobar" },
                // ограничивает этот сервер корневым каталогом этого проекта,
                // чтобы он не использовался для других проектов, которые могут быть открыты
                // (для других серверов уже могут использоваться определённые корневые каталоги, но для python это обычно не так)
                "root": "."
            },
            "c": {
                // как выше
                "exec": { "hostname": "foobar" },
                "root": "."
            }
        }
    }
}

Как работает приведённый выше код? Как уже говорилось, часть с lspclient из этого кода добавляется в глобальную конфигурацию, поэтому будет найден раздел exec (для указанных языков). Поиск другого объекта (который указывает соответствующий hostname) выполняется либо в разделе exec, либо в разделе lspclient, и соответствующий объект служит основой для объединения. В результате командная строка сервера LSP (для C и python) будет добавлена к указанному (с подстановкой переменных) префиксу и, следовательно, он будет запускаться в указанном контейнере. Конечно, контейнер уже должен быть создан, корректно запущен и снабжён надлежащими серверами LSP. Может возникнуть соблазн использовать раздел global (внутри lspclient.) Это также может сработать, но тогда все серверы LSP будут запускаться с этим префиксом, включая серверы для, например, Markdown, Bash-сценариев или JSON. Более вероятно, что в основной системе всё это есть (если используется). Поэтому, как всегда, всё зависит от конкретных параметров настройки.

Тем не менее, сервер LSP теперь может отслеживать другие (сетевые) пути, которые отличаются от локальных путей, отображаемых и используемых редактором. Указанные pathMappings используются для преобразования туда-обратно в рамках обмена данными с сервером LSP. Конечно, это делается по возможности. Очевидно, что не у всех локальных путей есть сетевые аналоги, но отсутствующие пути не будут видимы (серверу) и не создадут проблем. Тем не менее, верно и обратное: (сетевой) сервер теперь может видеть и делать ссылки в «сетевом корневом каталоге», которые не представлены в локальной системе простым/явным образом. При включении mapRemoteRoot сетевой корневой каталог неявно привязывается к «локальному URL-адресу» exec://foobar/, который затем обрабатывается простым и понятным протоколом KIO (протокол системы ввода-вывода среды KDE). Последний, по сути, использует (например) podman exec -i foobarcontainer cat somefile" для копирования с сетевого компьютера на локальный (и другие подобные варианты с использованием утилит из набора coreutils). Достаточно сказать, что это решение не предназначается для использования в качестве основного и не претендует на производительность, но позволяет быстро получить файл по ссылке и с лёгкостью загрузить его в редактор.

Теперь очевидно, что упрощённый вариант приведённой выше конфигурации (без hostname или pathMappings) можно использовать для обработки virtualenv без дублирования командной строки сервера (в сценарии-обёртке).

Следующее может быть не слишком очевидно, поэтому здесь приводится прямое описание.

И последнее по порядку, но не по значимости: что, если подход с «резервным KIO» не считается подходящим? На практике зачастую можно «подключить» сетевой корневой каталог к локальной файловой системе и затем указать последнюю в pathMappings. Для начала, широко известная файловая система sshfs (fuse) может подключить (действительно) сетевую систему к локальной. Если используется контейнер (podman/docker), большинство конфигураций (драйвера файловой системы) поддерживают следующий трюк;

$ rootdir=/proc/`podman inspect --format '{{.State.Pid}}' containername`/root
# некоторые символьные ссылки могут приводить к проблемам, ниже приводится альтернатива
$ sudo mount --bind $rootdir /somewhere/containername

Если это не сработает, можно воспользоваться sshfs или его вариантом для подключения корневого каталога сетевого ресурса или контейнера;

# смотрите соответствующие man-страницы; для обычного (незашифрованного) протокола обработки файлов достаточно sftp-server
$ socat 'exec:podman exec -i containername /usr/lib/openssh/sftp-server'
   'exec:sshfs -o transform_symlinks -o passive \:/ /somewhere/containername'
# ...
$ fusermount -u /somewhere/containername

Обратите внимание, что такое подключение сетевого корневого каталога к основной файловой системе, скорее всего, потребуется указывать вручную и в явном виде в разделе pathMappings (за исключением случаев, когда используется интеллектуальное средство запуска с префиксом, которое организовывает всё это автоматически).