Відобразити список слів у нижній частині кадру?


20

Я хотів би відобразити 3 списки слів на окремих рядках по горизонталі вздовж нижньої частини (хоча верхня частина також буде працювати) кожного відкритого в мене кадру Emacs. Я продумав 6 способів зробити це, і всі вони мають проблеми:

  1. Першою моєю думкою було додати рядок до мого режиму, але AFAICT ви не можете використовувати символ нового рядка в рядку режиму, він просто перетворюється на "^ J".

  2. Друга моя думка полягала в тому, щоб розташовувати рядок у верхній частині екрана та використовувати рядок заголовка, але він також не підтримує символ нового рядка.

  3. Я міг би відобразити накладку протягом останніх 3 рядків вікна, але зробити це надійним здається важко - прокручування потрібно буде запускати, коли точка доходить до накладання, а не до реального кінця вікна, і мені доведеться постійно перестановляти накладання, оскільки накладки знаходяться в текстовому просторі, а не у вікні.

  4. Я міг би спробувати зробити виділені вікна в нижній частині кадру. Я спробував це кодувати, але він не дуже надійний, він, здається, не працює, коли кадр вже містить розділені вікна, і мені довелося відновлювати Cx, 1 на користувальницьку версію delete-other-windows, яка ігнорує мої спеціальні вікна, і я впевнений, що є інші кутові шафи. Також, коли відкриється вікно довідки, воно відкривається вертикально, тому що він вважає, що горизонтальний розкол вже є (який технічно є, але це лише для відображення вікна з одним рядком).

  5. Я міг би мати виділений кадр для цього, але тоді моя конфігурація не працюватиме в термінальному режимі, і мені доведеться скриптувати свій віконний менеджер, щоб утримувати його в нижній частині екрана, роблячи його невибірним, не впливаючи на макет, тощо.

  6. Я міг би вставити текст для 3-х рядків безпосередньо в мінібуфер. У мене це частково працює, я можу виростити мінібуфер для розміщення трьох ліній, і я можу їх відобразити. Однак кожного разу, коли будь-яке повідомлення лунає, рядки зникають, поки я не видаю іншу команду, в який момент вони знову з’являться. В ідеалі 3 лінії та зона ехо не перетинатимуться, тому я міг бачити і те, і інше. Це було б менш набридливо, якби я міг надійно відфільтрувати, які повідомлення надходять у зону ехо - я знайшов рішення на EmacsWiki, але це, здається, не працює для повідомлень, що походять із джерела emacs C (конкретно я хотів би отримати позбутися повідомлень про збереження файлів, оскільки я автоматично зберігаю на таймері).

У контексті, моя мета - постійно відображати слова, які найчастіше використовуються в поточному буфері, слова, найближчі точки в поточному буфері, та слова, які останнім часом використовуються в поточному буфері. Я маю намір мати можливість вставити їх у буфер за допомогою голосових команд. Тож я міг би сказати "найближчий 2" і запропонувати йому вибрати другий пункт із списку слів найближчого пункту та вставити його. Мене хвилює лише те, щоб списки слів були видимі для будь-якого буфера, який я зараз редагую. Я не хочу використовувати спливаючі вікна, які використовуються в різних режимах заповнення коду, тому що мені потрібні списки, які завжди відображаються.


Добре питання, і добре поставлене. Сподіваюся, ви отримаєте кілька корисних пропозицій.
Дрю

Цікаво про інші частини №5, окрім необхідності термінального режиму (що є головним). Ви можете використовувати виділений кадр, розміщений внизу (без проблем). Що ви маєте на увазі під невибірливим , і навіщо це вам потрібно? Якщо ви маєте на увазі лише читання, то це теж не проблема. Що ви маєте на увазі, не впливаючи на макет ? Підсумовуючи, №5 для мене не надто зрозумілий.
Дрю

@Drew: Я маю на увазі, що я керую WM за допомогою клавіатури, і навряд чи я хотів би коли-небудь приділити цьому кадру цілеспрямованість, тому я хотів би, щоб мої прив'язки до наступного вікна / попереднього вікна пропускали через нього. Так само я хотів би, щоб макети вікон діяли так, ніби цей кадр був лише частиною панелі / панелі завдань. Редагувати: скрізь у цьому коментарі я сказав "вікно", я маю на увазі "X вікно", а не "emacs window"; p
Джозеф Гарвін

Ще одна можливість, запропонована мені, - це просто використання minibuffer. Я не маю уявлення, чи можна пасивно відображати текст там, не втручаючись у все інше, намагаючись його використовувати, хоча ...
Джозеф Гарвін

Додано примітку про спробу використання мінібуфера.
Джозеф Гарвін

Відповіді:


8

Маючи багато експериментальних експериментів, я зміг довести №6 (використовуючи текст мінібуфера) до робочого стану, достатньо хорошого. Ось скріншот:

Знімок екрана в дії

Для цієї роботи є кілька ключових частин:

  • Вставлення тексту в мінібуфер несподівано майже не виходить із вікна. Текст, вставлений туди, дійсно з’явиться.
  • Зробивши текст текстом "післязарядний наклад" замість звичайного тексту, ви робите його не виділеним і не потрібно турбуватися про те, що курсор випадково потрапить у нього.
  • Щоб команди спонукань мінібуфера працювали правильно, вам потрібно заборонити вставляти текст / накладення, коли вікно мінібуфера активоване.
  • Якщо ви спробуєте змінити розмір мінібуфера за допомогою звичайних функцій зміни розміру вікон, ви отримаєте помилки з приводу занадто малих вікон, якщо ви використовуєте недокументовану функцію md-resize-minibuf, то ви можете змінити розмір до потрібної кількості ліній, поки ви хочете встановили міні-вікна resize-мінімум, щоб спершу нульові.
  • Щоб вирішити, що списки зникають, коли є повідомлення, вам потрібно порадити функцію повідомлення перехоплювати повідомлення. Потім ви вставляєте їх у мінібуфер самостійно. Ви також повинні переглянути змінну поточного повідомлення, яка зберігає все, що останнім часом з’явилося в області ехо (дивно, що область ехо та мінібуфер технічно відрізняються, а деякі функції вихідного коду C друкуються безпосередньо в область ехо, не переходячи через повідомлення функція). Код, який я надаю нижче для цього, є недосконалим, повідомлення зберігаються довше, ніж зазвичай, що мені все-таки потрібно вивчити (перевірка останнього запису в * Повідомленнях * може бути простішим та надійнішим), але це "досить добре" на даний момент.

Ось посилання на мою реалізацію з прикладом пояса із зображенням кільця вбивства. Згодом це стане частиною належного проекту: https://gist.github.com/jgarvin/ce37d08654978fd7e4c9

Це вперше я пишу будь-яку значну кількість елісп, тому якість, ймовірно, є підрозділом, але це працює.


1

На жаль, ані рядки режиму, ані заголовок не можуть бути декількома рядками. Я вже про це запитував і раніше (принаймні не було) жодного прихованого варіанту, щоб зробити цю роботу. Отже 1 і 2 виходять. Я також відчуваю, що 3 та 6 - це хаки, які не зроблять тебе щасливим у довгостроковій перспективі. 3 і 4 здаються прекрасними підходами, але змусити їх працювати надійно буде цілком інвестицією.

Тому я б рекомендував спочатку викласти це на emacs-devel . З мого досвіду, з часом все реалізовується, якщо ви намагаєтесь ретельно пояснити, чого ви хочете, і чому це добре. Це може зайняти деякий час, принаймні до наступного випуску, але якщо ви добре почекаєте трохи або використовуєте версію для розробки, то, можливо, ви зможете отримати саме те, що хочете, зі значно меншими зусиллями.


Дякуємо за пропозицію зв’язатися з emacs-devel. Незважаючи на те, що я придумав рішення, воно було досить хакітним, і було б непогано мати справжній API для прямого малювання на екранах координат, тому, коли у мене буде час, я, мабуть, зніму електронний лист їх шляхом.
Джозеф Гарвін
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.