> ecb (layout left-analyse)Что это? Про ecb написано, что это "An interface to the Eclipse IDE". Я думаю, что если я поставлю eclipse, то я не буду костылить и впихивать в него emacs. Или оно не требует установки eclipse?
> company-mode (не помню бэкэнд, но с вспылающей менюшкой есть уже давно и как бы он сейчас не по умолчанию с ней шел)
Да, круто. Спасибо.
> Но вообще, с мыслью из #3 о костыльности отрисовки в граф.моде согласен -- во многих местах шурупы, которыми прикручивали "современные" (т.е. еще конца прошлого века) возможности гуя через ГТК, торчат наружу в самых неожиданных местах.
Во, круто что это кто-то понимает. Тут публика слишком догматична, чтобы оценить идею отрисовки при помощи html/css. Некоторые тут считают даже (я видел в комментах), что css замедляет работу сайтов.
Но вообще, если несколько абстрагироваться от html/css в том виде, в котором они описаны на w3c, взять основную идею блочной разметки текста, то... Я сейчас подумываю о том, чтобы запилить эмулятор терминала, с esc-последовательностями изоморфными html. Чтобы можно было бы сделать, что-нибудь в стиле:
printf("\eu<Глянь\e>, это \ei<курсив\e>, а это \eb<жирный\e>\n")
или
printf("\ediv{id: menu}<\e>");
printf("\estyle{#menu {width: 100%; position: fixed; left: 0px; top: 0px; background: grey;}}");
// и теперь menuitem
printf("\estyle{.menuitem {color: black; margin-left: 1em; margin-right: 1em;}}");
printf("\eadd_child($id, span{id: file; class: menuitem}<File>)");
printf("\eadd_cb($file, {onclick})");
А затем:
if scanf("\e$file.onclick(%d, %d)", &x, &y) == 2 {
printf("File clicked with mouse coords: (%d, %d)", x, y);
}
Ну или типа того. Я не продумал ещё в деталях весь этот протокол общения между терминалом и приложением. Но фишка в том, что его можно сделать недвусмысленным, дать возможность добавлять/изменять/удалять элементы. Выкидывать в помойку элементы уползающие за край терминала (или может выкидывать их не сразу, или не все, и иметь некое хранилище для созданных но неотображаемых элементов, типа видеопамяти, где можно хранить кучу всякой всячины, рисуя при этом лишь какой-то кусок её). Что-то с css тоже надо сделать, чтобы их можно было бы прочищать. Было бы прикольно привязать хранилище тегов и правил css к процессу, чтобы когда процесс помер, можно было бы зачистить выборочно "видеопамять". Можно ascii представление заменить на бинарное -- это может сэкономить ресурсов, но прибъёт читабельность глазами. Что может быть и не важно, потому что даже в таком виде оно не очень удобно, и по-любому поверх надо наворачивать API для ввода/вывода этих esc-последовательностей. Но тогда со скриптовыми языками начнутся проблемы -- не все скриптовые языки умеют работать с бинарными данными, и некоторым придётся писать модули на C, чтобы получить доступ к этим возможностям терминала.
ncurses не нужен при таком подходе. DOM может хранится на стороне терминала, и общение с ним обеспечивать посредством протокола -- это, правда, может замедлять в некоторых случаях, но если библиотечку для управления DOM терминала сделать именно библиотечкой, то ничто не помешает поверх неё написать client-side обёртку, чтобы проводить ввод/вывод через неё, и иметь идентичную копию DOM на стороне клиента. Костыль конечно, но альтернатива -- это shared memory, растущее количество связей между клиентом и сервером, проблемы синхронизации, и вообще увеличение сложности, от него просто напрашивается откупиться повышенным расходом оперативки.
Правда я тут подумал, что сложно будет отслеживать состояние DOM если есть несколько конкуретных процессов, которые параллельно выводят в терминал.
А если ещё дать возможность загружать в терминал модули на webassembly, для того, чтобы, например, выводить видео из ffmpeg буковками, но передавать кадры не as is, а в виде закодированного пожатого битового потока, и декодировать в буковки на стороне терминала... это вообще сделает ненужным Xorg, Wayland, gtk/qt/wxwidgets/... и всё остальное. И электрон в частности станет ненужным. И даже web станет ненужным, и даже небо, и даже Аллах.
Но применительно к emacs'у это просто фонтан, а не идея, потому что emacs может продолжать работать с графикой (с тем что он считает графикой) так, как он работал с ней исходно в 80-х годах через ncurses, только вместо ncurses будет тонкая прослойка API над printf. А при желании, можно загрузить в терминал vt100.wasm, и будет emacs работать с терминалом через ncurses.
