VIvilark·Sep 9, 2023Submission
Show HN: Story of using C# for a terminal app (macOS and Linux)
The backstory and implementation of a hobby project called ViLark[1]
I wrote it to make myself a faster and nicer looking file/buffer selector when I am using vim. But it's a stand alone executable -- when I launch it from a hotkey in vim, it takes over the terminal screen, and vim is suspended. It uses temp files to communicate the user selection back to vim, and it exits whenever a file is chosen or the escape key cancels it.
This honestly wouldn't be possible without C# AOT compilation. Startup time would be too slow. But now, it's finally at c/c++ level startup time, perceptually. Really, it's instant, and doesn't feel like a break in the flow.
It uses a few new .NET features like PosixSignalRegistration, so it gracefully handles CTRL-Z and CTRL-C -- setting the tty back to default settings, and going back to the 'main' terminal s
Read the rest
creen. Those are low-level details but are pretty important -- having your cursor not be visible when you type in a shell is not something you ever want.
It also uses the new Console.ReadKey() handling to decode keyboard sequences, like ctrl-shift-right_arrow, etc. That seems to be working ok. Previously, I hacked up my own parser which wasn't a lot of fun, and I was happy to remove that code.
Unicode support was definitely time consuming. For example, if you read in an emoji, that is 2 chars, which are surrogates. They also form a two-column wide glyph in the terminal. If you hit backspace in the searchbox, you don't want to cut off one of those chars, or you will throw an exception, because a partial surrogate pair isn't a valid string. So you need to use the Rune API wherever you are slicing strings. And I still don't know what to actually _do_ if I need to draw a vertical bar half way through an emoji.
The utf8 string literals are helpful, for low level optimizations in some of the screen drawing, and more UTF8 support would certainly be welcome in .NET. For example, testing on 300K files, vilark uses 60MB of RSS compared to 30MB for fzf, and I believe it's primarily due to UTF16 vs UTF8. That said, the search speed was comparable, so I don't know if it's a detriment there.
Since ViLark is a stand-alone process, it can exec another process (e.g. your $EDITOR) when you choose a file. This was a bit more challenging to do in current .NET 8 preview. After a lot of trial and error, including renting an EC2 Mac instance for a day, I settled on a solution of P/Invoke of `execve()` + a `sh -c` mini-wrapper that runs `stty sane; exec "$EDITOR" "$FILENAME"`. That resets the tty and launches the new process all in one shot, and seems pretty robust. It works identically on Mac and Linux/WSL.
Anyway, I hope to see continued AOT support from the .NET team, because it makes coding fun again.
And now that I have the low level plumbing out of the way, hopefully I can think about other features I'd like, such as a 'Projects' or 'Favorites' tab. I'd like to have something "Spatial" in my terminal, similar to a Desktop or Mission Control, that I can access quickly.
1. https://github.com/kjpgit/vilark