Author of the terminal emulator foot, and other Wayland open source projects.
Professional software developer, working mostly in C.
| IRC | [email protected] |
| Forge | https://codeberg.org/dnkl |
| GitHub | https://github.com/dnkl |
| GitHub Sponsors | https://github.com/sponsors/dnkl |
I've been working on OT-SVG support in #fcft the whole day, and is finally starting to get somewhere...
Because support has recently been added to FreeType2 for the OpenType SVG specification, it would be a a nice addition to support this capability. This includes the color SVG support for glyphs. I am not sure how large of a lift this would be, but would be a nice addition for supporting SVG icon fonts in `yambar` See: https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/122 https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/68
"highlight all matches" in #foot scrollback search mode:
Before this patch, only the currently “selected” match was highlighted (by having the “selected” attribute, and by *not* dimming it, like the rest of the grid during a scrollback search). With this ~~(POC-like)~~ patch, we now highlight matches within the viewport. ~~This is somewhat hackish at the moment:~~ The actual searching is done in the viewport, when rendering a frame. This way, we don’t have to search the entire scrollback whenever the search criteria is updated (but instead we do have to search the entire viewport for *every* frame). Searching and rendering is done with a search iterator. It starts at the upper left corner of the viewport, and continues untill we’ve reached the bottom of the viewport. ~~The primary (currently “selected”) match is *not* included by the iterator.~~ The iterator’s text matching logic is *very* similar to what we do when the search criteria has been updated, and we re-search the scrollback. ~~It should be possible to refactor this, and share code.~~ This has now been refactored.  ~~Again, the visual appearance of the secondary matches are likely to change.~~ Depends on #1025
I'm back on #solarized again, but with a twist.
I replaced the 8 bright colors in my terminal color scheme (which in solarized aren't really "bright" colors) with brightened variants of the 8 base colors.
I find this makes unsolarized applications look better.
Editors etc use 24-bit color schemes anyway, meaning I get the full solarized experience even with a butchered terminal color scheme.
Window title in CSDs! This has been missing in #foot long enough...
(we _do_ support antialiasing, but I like my bitmap fonts)
Next release of #foot (1.8.1) will most likely have support for improved width calculation of grapheme clusters.
This will break almost all applications (cursor getting out of sync), but the idea is to give application developers a playground.
There will of course be a foot.ini option to switch between the current and the new width calculation.
Highly controversial perhaps... * All emoji graphemes are double-width. * Foot doesn’t support e.g. Right-to-Left scripts, or any script that requires text shaping. Ergo, limiting the grapheme width to two cells should result in the _Right Thing_, even though we’re not doing it the _Right Way_. Note that we’re now breaking cursor synchronization with nearly all applications, since we're no longer doing the equivalent of `wcswidth()` on the grapheme. But the way I see it, the applications need to be updated. This is a move towards better handling of complex graphemes in the terminal. Hopefully, there will be better APIs for grapheme width calculation in the future (as in, _standard_ APIs). But until then, I'm hoping this is good enough to function as a test ground for applications. Seeing that complex graphemes are more or less broken **without** this patch (but in a different way), we're not really breaking, or regressing, anything with this patch. There's a tweak option, `tweak.grapheme-width-method=wcswidth|at-most-2` that can be used to switch between the old behavior, and this PR. With `wcswidth`:  With `at-most-2`: 
