[HN Gopher] Comprehensive Keyboard Handling in Terminals
___________________________________________________________________
Comprehensive Keyboard Handling in Terminals
Author : g0xA52A2A
Score : 154 points
Date : 2023-04-01 07:16 UTC (1 days ago)
(HTM) web link (sw.kovidgoyal.net)
(TXT) w3m dump (sw.kovidgoyal.net)
| gpanders wrote:
| It is briefly mentioned in this post, but this work is based on a
| proposal by Paul Evans [1] (creator of libtickit and libvterm,
| among others).
|
| Kovid deserves credit for addressing some of the issues in the
| original proposal, and for documenting it well. But Evans
| deserves credit as well for formulating the original idea.
|
| Note also that this is not the only solution to this problem.
| Xterm has had its own solution for a long time called
| modifyOtherKeys [2] which has been supported by Vim and iTerm2
| for quite some time (I believe foot supports it as well, perhaps
| others). Of course people have different opinions on which
| approach is "better", though empirically it seems like the
| CSIu/"fixterms"/kitty approach has a lot more momentum at
| present.
|
| [1]: http://www.leonerd.org.uk/hacks/fixterms/
|
| [2]: https://invisible-island.net/xterm/modified-keys.html
| kps wrote:
| I know mlterm is one that supports modifyOtherKeys.
|
| Fragmentation is unfortunate, especially since there's no
| termcap/terminfo property that indicates which form(s) a
| terminal supports, and so many terminals already identify
| themselves as 'xterm' without being remotely close to xterm-
| compatible.
| ithrow wrote:
| Does kitty lets you remap modifiers like iterm2?
| https://i.stack.imgur.com/hd5Yi.png
| jwr wrote:
| If this were widely adopted, it would do wonders for Emacs. Right
| now Emacs is unusable in remote terminal connections for many of
| us, because there is no way to get key combinations like Super-
| Shift-G to work.
| donio wrote:
| I agree that Emacs would greatly benefit from this feature but
| "unusable" a overly dramatic. It's an inconvenience. I use
| Super on the desktop as much as anybody but I manage with
| remote tty sessions (including termux from phone) just fine. I
| just make sure that I also have a terminal-friendly binding for
| anything critical that I have on Super.
| denotational wrote:
| > "unusable" a overly dramatic
|
| Disagree. I used to use Emacs with evil-mode, but I gave up
| because of this issue.
|
| If I entered `ESC` then `k` (i.e. return to normal mode and
| move up a line) too quickly on an SSH connection, there was a
| good chance the `read` syscall on the PTTY file descriptor
| would return _two_ characters (determined via `strace`)
| instead of two subsequent calls returning a single character
| each.
|
| This makes it literally impossible for Emacs to distinguish
| it from `M-k` (i.e. `kill-line`), so I'd "randomly" see lines
| deleted before I figured out what was going on.
|
| The effect is a lot more pronounced over SSH where a spike in
| network latency can cause two subsequent TCP segments to
| reach the host essentially back-to-back (or even be
| retransmitted as a single segment), leading to this behaviour
| of `read` returning two characters.
| eviks wrote:
| It's very nice to see some progress in this moldy part of a
| technology junkyard
| galkk wrote:
| Kovid is one of those 10x engineers for me. I love kitty and use
| it every day, calibre does it job too.
|
| Great, that he tries to make progress in terminal area, that, as
| for me, is quite archaic as of now.
| nextlevelwizard wrote:
| I have never quite understood what the benefit of using kitty
| is. My default terminal emulator just isn't using that many
| resources and I don't get why I would even want GPU rendering
| for text.
|
| What problem does it solve for you?
| kzrdude wrote:
| Terminals have some infuriating limitations, like imagine not
| being able to tell the difference between Esc + A or Alt + A
| as an application. Or that tab and Ctrl + I produce identical
| input.
|
| Kitty has a new keyboard handling protocol, and Neovim
| supports it. So if you use kitty, you can use key mappings in
| neovim in a more predicatable and flexible way.
| kps wrote:
| But xterm and xterm-compatibles have been able to do this
| for over a decade (CSI > 4 ; 2 m).
| mftb wrote:
| Kitty renders more cases correctly, more stable, mainly I
| appreciate it's overall high quality. I don't use it's tmux-
| like features.
| seri4l wrote:
| You can configure a key combination to run a pager on the
| last command output, color and everything. You can also
| configure it so that it pipes the output of a command to a
| pager automatically whenever it is more than a screen long.
| ploum wrote:
| Also support displaying picture (try chafa with any jpg/png
| file inside kitty). That makes browsing with offpunk a
| completely different experience.
| nvarsj wrote:
| kitty is the most feature complete terminal emulator out
| there. It's the only one that properly supports ligatures and
| variable width characters for instance. If you want faithful
| terminal reproduction with built in native tmux like
| functionality (including non broken mouse support), kitty is
| about the only option.
| NotEvil wrote:
| Wezterm is feature parity with kitty. But can be configured
| in lua instead of a long custom text file with vim tag
| support
| tmtvl wrote:
| No it isn't, I have version 0.27.1 installed and it reports
| itself as a VT220 rather than VT420 (like xterm), or VT520
| (like Zutty). And even despite purporting to be a VT220 it
| still fails on LineFeed Mode, DSR, and SRM; which the
| developer of Zutty called out back in 2020:
| https://tomscii.sig7.se/2020/12/A-totally-biased-
| comparison-...
| AndyKluger wrote:
| Are you saying that because you've found something missing
| from wezterm, or because you're not considering wezterm at
| all?
| toastal wrote:
| Joining in questioning... kitty dev seems to hate tmux since
| kitty can perform many of it's behaviors. The thing that's
| most interesting to me is tmux for detaching and persisting a
| session on a remote host. Does kitty cover this functionality
| too? Is there like kittyd?
| kps wrote:
| If persisting sessions is the _only_ thing you use tmux or
| screen for (as it was for me), try `dtach`. Session
| management is all it does; terminal I /O is passed through
| just like a plain ssh session.
| gorgoiler wrote:
| In addition to what others have said, it is also freely
| licensed and open source, with ports to my daily drivers
| macOS and xorg/Linux. I wonder if a Windows port is in the
| works too?
| version_five wrote:
| Being able to display inline images in the terminal
| leephillips wrote:
| I've tried many terminal emulators, probably all available on
| Linux, and kitty is the best in my experience. Performance is
| excellent: keyboard latency, catting files. It's sometimes
| convenient to use some of its tricks, such as viewing an
| image right in the terminal through ssh.
| AndyKluger wrote:
| Have you tried wezterm as well?
| petepete wrote:
| It's _really_ responsive, whether you're in an editor or
| accidentally grepped a minified JavaScript file.
|
| I would be capable of working entirely in any modern terminal
| emulator, but Kitty makes it a pleasure.
| Version467 wrote:
| I didn't know he also made calibre. That's awesome.
| kickaha wrote:
| Calibre user. I was like, that's weird. There's another Kovid
| Goyal?
| ibiza wrote:
| There's an even richer protocol, `?9001h`, developed by the
| Microsoft Terminal team, designed to maintain the fidelity of
| INPUT_RECORD events. These are the events seen by console
| programs in Win32. It's quite nice.
|
| https://github.com/microsoft/terminal/blob/main/doc/specs/%2...
| eviks wrote:
| In what way is it richer? I've skimmed through the linked doc,
| saw the mention that it is richer, but didn't see an
| explanation of the extra functionality is available
| ibiza wrote:
| Events include key scan codes for one. The end of the doc
| contains a pros & cons section of the alternative approaches.
|
| https://github.com/microsoft/terminal/blob/main/doc/specs/%2.
| ..
| comfypotato wrote:
| Shoutout to Alacritty for having Windows support. Would have
| adopted kitty at the time for the reasons mentioned in the
| article (much more mature) but Alacritty does the trick. Not sure
| how it deals with modifiers etc. in the plumbing, but the
| configuration is plenty straightforward to access everything from
| terminal applications that can use lots of bindings.
| zokier wrote:
| At some point one might consider if it would be simpler and
| better to just have some way to pass wayland-compatible events
| instead of inventing yet another protocol. So much stuff has now
| been thrown into terminal layer in a way that is not particularly
| elegant and what we already have perfectly good protocols for.
| tyingq wrote:
| How would that traverse ssh, tmux, etc?
| hendersoon wrote:
| In a development that will surely confuse nobody, the terminal
| emulator linked in this thread (kitty) is completely separate
| from another terminal named KiTTY. I assume there's some drama
| behind this. Anyway, this one is for Linux/MacOS only while KiTTY
| is a PuTTY fork for Windows only.
| durazabu wrote:
| Glad to see this page featured again.
|
| Is there any advance on that front?
|
| Previous submission was 2 years ago.
|
| https://news.ycombinator.com/item?id=27193661
| aumerle2 wrote:
| The progress is that this protocol has been implemented in many
| widely used programs, such as vim, neovim, helix, kakoune as
| well as at least two more terminal emulators, wezterm and foot
| in addition to kitty.
| durazabu wrote:
| It seems like the protocol has not been implemented yet in
| neovim.
|
| https://github.com/neovim/neovim/issues/14400
| aumerle2 wrote:
| It has, just not fully. See the very first checkbox in the
| link you posted. Indeed this protocol is designed so
| applications can pick and choose what parts they want to
| use.
| gpanders wrote:
| It has been implemented to a degree that it is useful for
| most users. For instance, you can now map Control-I and Tab
| separately, as well as keys like Control-1, Control-2,
| Control-;, etc.
| durazabu wrote:
| Thank you for your work on neovim :)
|
| I noticed the difference by playing with kitty. It makes
| me consider switching to a compatible terminal emulator.
| gpanders wrote:
| It is also supported by iTerm2, Wezterm, and foot.
| Alacritty does not (yet) support dynamically modifying
| the key encoding per-application, but you can hardcode
| the encodings in your config file (there is an issue in
| the Alacritty repo that explains how to do this).
|
| You may not have to switch at all if you are already
| using one of these terminal emulators.
| 3np wrote:
| I'm not sure I agree that terminal applications should get access
| to the whole range of modifiers. It's nice having a certain key
| dedicated to the WM or macros and know there will be no
| conflicts.
| eviks wrote:
| Which certain key? It's different per user, so no way to have a
| common list to exclude.
|
| Anyway, there are other better mechanisms to resolve the
| conflict instead of crippling the app
| Findecanor wrote:
| On Mac, the "Super"/"Command" key controls the terminal app.
| On Linux, I sometimes wish I had a Command key instead of the
| Control key being used by both the terminal and programs _in_
| the terminal. On X11, "Super" is often mapped to the window
| manager/the desktop environment, likewise on MS-Windows where
| it is the Windows key.
|
| BTW. "Hyper" _is_ available also on Mac, by default mapped to
| Shift+Control+Alt+Command but it can be remapped to another
| key. That key combination is emitted by the "Office key" on
| some Microsoft keyboards, and is used in MS-Windows for
| launching a component in their Office pack, or the Emoji
| picker.
|
| So, there are lots of opportunities for configuration, and
| conflicts. IMHO, It would be a "nice thing to have" if users
| could configure their text-mode programs to use more
| modifiers, sure ... but as long as they are the only users of
| that config. I don't think a text-mode program should map
| Super or Hyper by default.
| kps wrote:
| > _On Linux, I sometimes wish I had a Command key instead
| of the Control key being used by both the terminal and
| programs in the terminal._
|
| This is precisely why I prefer KDE -- it's feasible to move
| GUI shortcuts off Control. (It could and should be easier,
| since there's a global setting deep in Qt somewhere, but
| it's only exposed on MacOS.)
| Version467 wrote:
| The command key being different from the control key in
| macOS is really one of its biggest out-of-the-box strengths
| fro people who use the terminal a lot. It's really quite
| helpful to have different modifier keys for different
| "system layers".
|
| In addition to the Hyper key, there's also the "Meh" key,
| which is Shift+Control+Command and basically not used by
| any application. I use it as my default macro hotkey.
| TacticalCoder wrote:
| > BTW. "Hyper" is available also on Mac, by default mapped
| to Shift+Control+Alt+Command but it can be remapped to
| another key.
|
| I dedicate "Super" to my WM and Hyper to quite a few things
| but... Hyper is a hack for the USB specs do not have the
| concept of the Hyper key. So Hyper support is always a
| kludge.
| [deleted]
___________________________________________________________________
(page generated 2023-04-02 23:02 UTC)