I wanted to show, just this once for this project, the *compilation* buffer in a bottom split. I also wanted the split to be dedicated, so no other buffers would occupy it by accident, and not be deleted (aka closed) when using delete-other-windows. That should be reserved for code buffers.
Some days I forget to run Denote to create a new journal file for the day, and then the appropriately named note file is missing when I want to write down things later. That’s not how you use a daily journal, I know, but I use Emacs and denote.el to write down things like exercise logs or when I get sick, and these are information I can backfill easily the day after.
Giles Turnbull shared a link today to a site I didn’t know:
It’s a directory of 950+ menu bar apps for macOS. I browsed it a bit, and while each page is a bit short (5 items per page), it’s great to discover new tools – and also check out UI design trends in menu bar apps.
For example, I’m surprised that there are still so many NSPopover style windows with the speech-bubble pointy thing (because almost all apps I use don’t use popovers anymore). At the same time, there are many apps with what looks like custom NSMenus to embed more complex views as menu items.
When you type in a text editor, you always type out of some range. When your insertion point or cursor is blinking at the end of a word you just typed, you expect to still be “in touch” with the word, and that the next key you press will for example add a character to that word. This is a useful deception for us human users. It’s not actually part of the technological underpinnings.
Documentation-writing is not a goal in itself. Code, tests, documentation – all of these are tools to communicate in writing with other programmers. That includes your future selves as it includes teammates and project collaborators. Kent Beck, “The Documentation Tradeoff”:
KOMA-Script is Omakase. If you trust the package, you’re in good hands to get consistent output from compiling LaTeX documents. I’ve been using Markus Kohm’s KOMA-Script for most of my life with LaTeX in some way or another because the package’s document classes really nail typical German typesetting requirements, e.g. requirements of DIN letter formats (yes, there is a standard for layout and typesetting of letters!). And the scrbook document class ships with tasteful defaults for book typesetting.
With the power of outline-minor-mode in Emacs, you can turn any text buffer into an outline – with the killer feature of “cycling”, i.e. folding and unfolding outline elements. This includes rg.el-managed buffers, search results powered by ripgrep.
I figured out a way to consistently change a NSRange, e.g. of a selection of text or the insertion point in a text view, to select surrounding words in DeclarativeTextKit. But first off: Dear heavens! This wasn’t easy. I’m still not happy with the solution. While there are three to four hundred test cases (the vast majority is generated) that helped me narrow things down, I can tell you up front that I’m not proud of the resulting 160 lines of code.
Marco (@esamecar@social.lol) posted a list of alternatives. From that list, I filtered out MAS-only and Chinese-subtitled apps: I’m running Ice at the moment. You can organize menu bar icons into “always hidden” and just “hidden”. The latter will reveal itself when you e.g. click on the menu bar, the former won’t by default. You can bind shortcuts to show either or both of these groups.
I’ve now finished adding an example adapter to get a structural representation of a Markdown code block to my app. It bridges the abstract syntax tree (or “token tree”) of libMultiMarkdown to NSTextStorage-compatible UTF-16 substring ranges – which DeclarativeTextKit works with, reducing code size and potential for errors even further:
I started working on DeclarativeTextKit mostly out of desperation, because the naive approach wouldn’t do the trick any longer. I complained about this on Mastodon in the beginning, but until now, I haven’t actually shown the code that made me want to change things.