Paul Evans writes about terminal tooling and maintains C libraries such as libvterm, libtickit and libtermkey.
Commenters cite libvterm for terminal emulation, Tickit for reading modifier keys, and his fixterms proposal for keystrokes like Ctrl-Enter.
> I wish there were, in C, some equivalent of "struct" but where you could specify
I don't think there's a need for a struct-equivalent, I think there's a need for a struct loader with these capabilities, it would only be in charge of packing and unpacking but would shove everything in a struct.
Basically, Erlang's bit syntax for C (thought the bit syntax unpack to locals, not structs):
<< Foo:16/little, Bar:12/signed, Baz:4 >> = Bin.
(default type specifications are integer, unsigned and big-endian, between the : and / is the size of the data in "units", where Unit defaults to 8 bits for the binary type and 1 bit for integers, floats and strings).
Doesn't natively do alignment though, the developer has to pad on his own.
Python's `struct` module is similar[0]: http://docs.python.org/library/struct.html although the format string is basically unreadable and I believe it's absolutely terrible at decoding non-standard sizes (e.g. an int stored on 3 bits)
[0] libpack[1] for C, Perl also has this[2] which was probably the inspiration for Python
[1] http://www.leonerd.org.uk/code/libpack/intro.html
[2] http://perldoc.perl.org/functions/unpack.html
I did look at nix, but was less than enthusiastic about how complex[1] the software is. If I could, I would probably prefer gnu guix - but AFAIK it is unlikely to ever support running on macos - and is similarly complex (build daemon needed to run in background).
I'm also sad that pkgsrc seems to be abandoned wrt binary builds for macos - I could at least not find correct gpg keys for verifying the archives listed at: https://pkgsrc.joyent.com/install-on-macos/
Perhaps it's workable as a build-from-source package manager.
For now, it seems that macports have most of what I need - with less complexity than nix, and a better handling of upgrades than brew.
Does appear that brew moves faster, eg: https://trac.macports.org/ticket/65922 (i briefly tried a local build, but ran into dependency problems with libvterm that I didn't manage to resolve - there's a 0.3 [2] tarball, but the build system for neovim wasn't happy and kept finding 0.1.4 after it was uninstalled in favour of 0.3).
[1] https://nixos.org/manual/nix/stable/installation/installing-binary.html#macos-installation
[2] https://www.leonerd.org.uk/code/libvterm/
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
Every time I see this I'm hoping that it has taken off, because it feels like such an obvious improvement. Instead of that we have some support for it in FreeBSD, and a homegrown solution in some packages like util-linux. Yeah, there are some concerns but the concept seems sound and the implementation can be iterated upon.
For instance, years later and it still isn't packaged in Debian. If nothing out of the tens of thousands of Debian packages has a dependency on it there presumably must be a good reason.
It strikes me as one of those libtermkey¹/libvterm things where Leonerd pushed it for years before anybody really used it, despite it being a seemingly obvious improvement over the status quo.
¹ https://www.leonerd.org.uk/code/libtermkey/
Yeah, C is really missing a way to serialize/deserialize data from raw memory/sockets into structs usable by your code. The least insane way, libpack [1] requires replicating the data format definition three times:
* define the struct with all elements
* define a string for the binary representation
* call fpack/funpack with the string and all the struct elements as parameters...
Unfortunately, fixing this either requires some kind of black X-macro [2] magic or another template language used to write the specification and to generate the three above-mentioned representations from it...
[1] http://www.leonerd.org.uk/code/libpack/intro.html
[2] http://drdobbs.com/184401387
> In principle, your terminal could also turn Ctrl-Shift-I into some special escape sequence which an application could parse. Such a sequence just doesn't exist in the terminal protocol you are using, that is all.
A specification that allows all key combinations to be recognized by terminal applications does indeed exist: http://www.leonerd.org.uk/hacks/fixterms/
Sadly, very few apps use it. Vim for example doesn't, but maybe there is hope that NeoVim will: https://github.com/neovim/neovim/issues/176