понятно, сурцы будут или полностью закрыто? я не идеолог, просто интересно понимать
Исходники VTM будут довольно скоро, но там будет видна лишь логика встроенного терминала. Основной пласт работы находится в "Desktopio TUI Engine" (Desktopio) на базе которого строится VTM. Туда входит практически всё - формы, события, рендеринг, мышь/клавиатура, пользовательские сеансы и т.д. Его исходники будут в отдельном проекте после того, как Desktopio заматереет. Под "заматереет" я имею ввиду момент, когда на его базе будет сделано несколько приложений: первым стал VTM (со встроенным терминалом), затем примитивный текстовый редактор, электронные таблицы, пасьянс типа косынки. Возможно, будет достаточно одного VTM с его встроенным терминалом.
В долгосрочных планах - построить TUI экосистему внутри VTM, сделать удобным Windows Server Core (VTM хорошо себя чувствует в cmd.exe, вдобавок подходе Windows Terminal), сделать возможным совместную работу любого количества людей в терминале (сейчас VTM позволяет одновременно подключиться любому количеству человек и как-то там взаимодействовать). Когда исходники Desktopio будут доступны всем, я думаю народ много чего напридумывает на его базе. Не открываю исходники сейчас, потому что боюсь, что придумают что-то серьезное раньше, чем он будет доведен до ума, и тогда придется поддерживать обратную совместимость, которая не даст нормально сформироваться архитектуре.
middle mouse button seems to work ok in kitty.
Thank you, I updated the issue [Demo] List of tested terminals #37
More support for more terminals?
I meant that on these holidays I am redesigning the internal structure of the terminal built into the VTM.
At the moment, the structure of the internal buffer prevents many terminal applications such as less/bat/etc from working as expected.
Designing the internal buffer of my terminal is complicated by the support of clusters of non-standard-size grapheme clusters (stretched over several cells) and their individual fragments (halves/quarters).
Grapheme clusters should be able to be more than one cell in height/width, as well as it should be possible to process their individual fragments.
Support for such graphemes by modern terminal emulators is a matter of time.
sometimes the middle click closes the window and sometimes the middle click duplicates the window
The middle button has two functions:
Perhaps the mouse cursor moves outside the current cell during the time between pressing and releasing the button, and this action is interpreted as dragging to create a new window.
I wouldn't be so optimistic about support for such things in other terminal emulators.
Indeed, at first glance, this doesn't seem to be in demand. Moreover, it seems inappropriate in a terminal environment, as many terminal developers have spoken about repeatedly.
I have several reasons to be optimistic about such things.
This came up when people requested support for DECDWL/DECDHL.
The answer was that the cost of implementing it was not justified given lack of use in existing software and libraries (ncurses principally).
Naturally, software isn't going to use something that isn't widely supported.
This feature request was definitively closed as wont-fix by libvte (the Gnome terminal emulator library used by most cookie-cutter interface-focused terminal emulators).
The GPU-accelerated ones like alacritty say they won't implement because of libvte.
Support for DECDWL/DECDHL is a special case of some big puzzle. You're right, DECDWL/DECDHL support only solves one specific problem, and it requires a lot of work to design and implement. Most likely for this reason it didn't fire.
Reasons to be optimistic.
Basically, we are interested in supporting the following text abstractions:
All modern terminals intend to display these objects. Nobody is going to give it up. For example, a ticket about support for Devanagari in VTE has not been closed for ten years, everyone hopes for some kind of solution.
In fact, all these objects are a class of objects that can occupy any number of cells in the terminal. In this context, it seems strange to me that terminal developers are trying to solve the problem of displaying these primitives individually for each such object, without trying to generalize the problem.
If we abstract from the clever names of these objects, then we see what they are in the general case:
We can use the Unicode database to get the widths of characters and the rules for their clustering, but for a full-fledged correct display in terminals, this is not enough. The Unicode standard offers nothing about Emoji that are three or four cells wide. Also, the standard gives nothing about the width of conjuncts in segmental writing systems, and nothing about custom ligatures.
Custom ligature sizing information can only be retrieved from the font used. Despite the fact that the size of common ligatures depends on the current locale, this does not help much.
The size of the conjuncts in a segmental writing system depends solely on the font. It can range from one cell to five wide.
About halves. Terminals have a well-known problem of partial displaying of wide characters, and all developers have unanimously decided that in order not to split wide characters, it must either be wrapped on a new line or not displayed at all. It is not clear what to do with Emoji/ligatures/conjuncts with a width of three or more cells.
To solve the problems of displaying all the above text objects, terminals must at least be able to display clusters of graphemes and their fragments in an arbitrary set of cells, and be able to do this both from the terminal side and at the request of the terminal application.
As an automatic bonus after solving the problem in the general case, a number of new opportunities appear both for the terminal and for applications, including support for DECDWL/DECDHL. For example, you can "construct" characters that are more than one cell high, and so on. I've outlined new features and use cases here.