Я хотел бы отобразить 3 списка слов в отдельных строках по горизонтали вдоль нижней части (хотя верх будет также работать) каждого открытого кадра Emacs. Я подумал о 6 способах сделать это, и у всех них есть проблемы:
Моей первой мыслью было добавить строку в мою строку режима, но УЖАСНО, вы не можете использовать символ новой строки в строке режима, он просто конвертируется в «^ J».
Моей второй мыслью было провести строку в верхней части экрана и использовать строку заголовка, но она также не поддерживает символ перевода строки.
Я мог бы отобразить наложение на последние 3 строки окна, но сделать это устойчивым кажется трудным - прокрутка должна была бы быть вызвана, когда точка достигла наложения, а не реального конца окна, и мне пришлось бы постоянно перемещать наложение, так как наложения находятся в текстовом пространстве, а не в окне.
Я мог бы попытаться сделать выделенные окна внизу рамы. Я попытался написать код, но он не очень надежен, он не работает должным образом, когда фрейм уже содержит разделенные окна, и мне пришлось повторно привязать Cx, 1 к пользовательской версии delete-other-windows, которая игнорирует мои специальные окна, и я уверен, что есть другие угловые случаи. Также, когда окно справки открывается, оно открывается вертикально, потому что думает, что горизонтальное разделение уже есть (что технически есть, но это только для отображения окна в одну строку).
У меня мог бы быть специальный фрейм для этого, но тогда моя конфигурация не будет работать в терминальном режиме, и мне нужно было бы написать скрипт моего оконного менеджера, чтобы он удерживал его вдоль нижней части экрана, делая его невыбираемым, не влияя на макет, и т. д.
Я мог бы вставить текст для 3 строк прямо в минибуфер. Я получил это частично работающим, я могу вырастить минибуфер для размещения 3 строк, и я могу отобразить их. Тем не менее, всякий раз, когда любое сообщение отображается, строки исчезают, пока я не выполню другую команду, и в этот момент они появятся снова. В идеале 3 линии и область эха не должны пересекаться, чтобы я мог видеть обе. Это было бы менее раздражающим, если бы я мог надежно отфильтровать, какие сообщения отправляются в область эха - я нашел решение на EmacsWiki, но, похоже, оно не работает для сообщений, которые исходят из источника emacs C (в частности, я хотел бы получить избавиться от файла сохранения сообщений, потому что я часто сохраняю по таймеру).
Для контекста, моя цель состоит в том, чтобы постоянно отображать наиболее часто используемые слова в текущем буфере, слова, ближайшие к точке в текущем буфере, и слова, которые в последний раз использовались в текущем буфере. Я намерен иметь возможность вставлять их в буфер с помощью голосовых команд. Таким образом, я мог бы сказать «ближайшие 2» и заставить его выбрать второй пункт из списка слов ближайшей точки и вставить его. Я забочусь только о том, чтобы списки слов были видны для любого буфера, который я сейчас редактирую. Я не хочу использовать всплывающие окна, используемые различными режимами завершения кода, потому что мне нужно, чтобы списки всегда были видны.
Ответы:
Проведя много хакерских экспериментов, я смог получить № 6 (используя текст минибуфера) в «достаточно хорошем» рабочем состоянии. Вот скриншот:
Есть несколько ключевых частей, чтобы сделать эту работу:
Вот ссылка на мою реализацию с примером пояса, отображающего список убийств. В конце концов это будет частью правильного проекта: https://gist.github.com/jgarvin/ce37d08654978fd7e4c9
Я впервые пишу значительное количество elisp, поэтому качество, вероятно, не на должном уровне, но это работает.
источник
К сожалению, ни строка режима, ни строка заголовка не могут состоять из нескольких строк. Я спрашивал об этом раньше, и есть (по крайней мере, не было) какой-либо скрытой возможности сделать эту работу. Итак, 1 и 2 отсутствуют. Я также чувствую, что 3 и 6 - хаки, которые не сделают вас счастливыми в долгосрочной перспективе. 3 и 4 кажутся хорошими подходами, но заставить их работать надежно, будет достаточно инвестиций.
Поэтому я бы порекомендовал вам сначала рассказать об этом на emacs-devel . По моему опыту, в конце концов, все будет реализовано, если вы попытаетесь тщательно объяснить, чего вы хотите, и почему это хорошо. Это может занять некоторое время, по крайней мере, до следующего выпуска, но если вы прекрасно подождете немного или воспользуетесь версией для разработчиков, вы можете получить именно то, что вам нужно, с гораздо меньшими усилиями.
источник