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:
- One click to destroy the window
- Click + drag to create a new window (the action is interpreted as dragging if the mouse cursor is moved at least one cell after pressing the button down)
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:
- Emoji
- For example, the sequence U+1F468 MAN, U+200D ZWJ, U+1F469 WOMAN, U+200D ZWJ, U+1F467 GIRL (👨👩👧) could be displayed as a single emoji depicting a family with a man, a woman, and a girl.
- CJK characters
- Orthographic and stylistic ligatures, e.g. fl, ft, ff, fi, ffi (ffi), and ffl (ffl)
- Conjuncts in segmental writing systems like Devanagari, in which consonant-vowel sequences and any dependent combining characters should never be split
- Mathematical operators and symbols
- Halves/cuts of all of the above
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:
- String, grapheme cluster: a set of code points forming the final character, in general, for simplicity, you can operate with a set of bytes encoded in UTF-8
- Width: number of occupied cells
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.
New feature
- Copying an arbitrary terminal area with the mouse, preserving all text attributes
Clipboard contains ANSI-art
[48;2;0;55;218m[38;2;97;214;214m [48;2;24;72;196m[38;2;242;242;242m [48;2;0;55;218m │-DIR│ 3 23:
[38;2;97;214;214m [48;2;16;70;209m[38;2;242;242;242m [48;2;0;55;218met │4096│ 9 23:
[38;2;255;255;255m�タ[38;2;97;214;214m ...I decided to go my own way, and decided not to use the classical state machine when parsing vt-sequences. And it works 😎
I am currently implementing basic VT functionality combined with horizontal scrolling.
I made a small application showing the output of a terminal application running in vtm. It helps me find defects.
I will upload the next release as I finish a couple of bugs. It will take about a week.
Probably the problem may be related to the following.
The ENABLE_VIRTUAL_TERMINAL_PROCESSING mode for handling VT-sequences is disabled by default in the classic Windows console (the features added in the Anniversary Update for Windows 10, link).
VTM (vtm.exe) forces this console mode on every startup:
void tty::ignite()
{
...
ok(GetConsoleMode(board, &omode), "GetConsoleMode error (omode)");
ok(GetConsoleMode(input, &imode), "GetConsoleMode error (imode)");
DWORD sources = 0
| ENABLE_EXTENDED_FLAGS
| ENABLE_PROCESSED_INPUT
| ENABLE_WINDOW_INPUT
| ENABLE_MOUSE_INPUT
;
ok(SetConsoleMode(input, sources), "SetConsoleMode error (input)");
DWORD mode = 0
| ENABLE_PROCESSED_OUTPUT
| ENABLE_VIRTUAL_TERMINAL_PROCESSING
| DISABLE_NEWLINE_AUTO_RETURN
;
ok(SetConsoleMode(board, mode), "SetConsoleMode error (board)");
...
}if for some reason the Windows console didn't enable this mode, then all VT-sequences are displayed as plain text:
The same goes for the SSH-client that comes with Windows, this SSH-client may not switch some modes, such as mouse tracking. With the latest version of the SSH-client this should work (WT issue comment), I haven't tested it yet. I didn't test this because the current version of Windows Terminal supports mouse tracking in WSL only.
In Windows Terminal, the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode is enabled by default, so there such problems don't appear.