Hexnut @ambihelical@qoto.org

Playing around with #typst it's like a dream come true so far. I edit in #emacs, changes show up in the generated pdf very quickly with the command line tool in watch mode. No fussing around with ponderous toolchains. Next up converting a medium size doc with a lot of equations from #asciidoc.

Bored this evening and thinking about #emacs defaults due to posts by @kickingvegas and @summeremacs

I wonder if adopting something like Rust's edition scheme would be the narrow path that would satisfy everyone. So a variable e.g. emacs-edition would control what defaults you get. If it's not set, it defaults to the legacy defaults, which are whatever they are before the 1st edition. If it is set to a a particular revision, you get the defaults which were active in that revision. If it's set to 'build you get the defaults of the build you are using. If set to e.g. 29, you never get any 30 defaults, but you could get 29.1, 29.2, 29.3, etc.

No clue how practical this is, and it's just a thought, and not a very deep one. Assuming someone implemented it, the hard part would be what color to paint the next edition's bike shed, I'm sure.

Continuing my exploration of #meow keybindings for #emacs, I'm finding that just the process of getting ready to use meow is causing quite a few changes to my configuration, independent of meow, for the better:

1. I am very habituated to having a bunch of vim-like keybindings for window (in the emacs sense) management which are under C-w in vim and evil. This won't fly for meow, so I finally started using super bindings, adding s-w as the first super binding, and avoiding evil functions for these. I've been avoiding super for a long time since I use the windows key as super under linux. In ms-windows that key by default brings up the windows menu, and I decided not to rock that boat. With the pressure on to have at least a few comfortable vim-like bindings, I found a way to allow the window key to be used for super under windows, without much restriction (win-l and win-g being the exceptions).

2. I use the capslock for my i3 modifier key, and didn't have an equivalent for windows. Mapping this key to the old windows-key functionality turned out to be super easy with powertoys, and it's kind of analogous to the i3 modifier, if you squint a little. The linux key mapping is to hyper, while windows hyper has been appropriated by MS to be something completely useless and difficult--maybe impossible--to bind to a key. So this seems like a good use of an available key, and I don't want to keep the original caps-lock functionality as it's really rather useless and can be a foot gun when typing in passwords.

3. I had been binding M-w for other-window, that usage was already provided by a subbinding of C-w and now s-w. This allows some workarounds I had for magit to be removed, and allows using the binding when evil is not active.

4. I've for a long time bound the function keys as sort of a keyboard driven menu system organized around errr... functional groups of frequently used commands. As I will need to use emacs macros if I stick with meow, I needed to provide something equivalent to f3 and f4. So I moved the kmacro original definitions to C-f3 and C-f4 respectively. I am hoping this works out with meow.

I'm not sure I'll continue with meow (I still haven't finished the tutorial because of all these yaks to be shaved), but the changes its been driving are quite useful and will be helpful if I ever drop evil.

My third session trying out #meow....

My strategy with trying meow is the same as #emacs when I switched from #vim in 2015. I'm noodling around with it on a branch of my dotfiles repo. Basically I give myself low pressure editting tasks to see if I'm really ready to roll with the new setup. When I'm comfortable with that, I'll try it for work tasks. My current task is editing my init.el file (using meow bindings) to convert it to #meow. I was able to remove all the evil config successfully but it is incredibly awkward atm. Other than not really getting meow bindings, the other stumbling points are kind of surprising since so much of this is very automatic after many decades:

1. Window (in the emacs sense) management. I relied on C-w commands provided by evil. I've been able to replace these with various other commands under the C-w binding, mostly leveraging the built-in winmove.

2. Undo and redo. Although meow has an undo, there's no redo binding. I don't like the emacs bindings, so I decided to go more mainstream on this one and use C-z and S-C-z for undo and redo respectively. I've never used C-z to suspend emacs, so it doesn't seem like a huge loss.

3. Saving files. I used evil commands for these. The emacs bindings are ok, so I'm training myself to use C-x C-s. I'm already used to C-x C-c so this seems consistent.

4. Searching and replacing in current buffer. I really liked / and the :s///gc vim commands. C-s is a poor substitute so far. Still working on this.

Surprisingly, other than text editing, things are going well. I'm able to use 90% of emacs without issue. I still don't grok meow bindings yet, so next is getting up to speed on actually editing.

My second session trying out #meow did not go well. However I found out something important.

Unlike #evil meow uses the built-in #emacs keybindings in its implementation (instead of binding to commands). So if I rebind C-b and C-f, then h and l don't work as expected but now move up and down by a page.

There's actually a note about it in the sources, and there's apparently a reason, but now I have to find new keybindings for anything that collides with emacs built-in keybindings. So that includes a number of #vim bindings that I'd rather have than the built-in bindings.

Oh well, I guess I'll have to adapt more than expected to use meow.

After having used vi-like keybindings for over 30 years, I've decided to try something new and give #emacs #meow a try. The fact that ijkl are there in the default qwerty bindings is a huge plus, and means I can hobble around initially and not completely loose all of my muscle memory (I still use vim occasionally). I am looking forward to jettisoning a ton of evil specific configuration if I can adapt to meow.

The first road-bump I encountered was that the cheat-sheet came up all wonky, so had to spend the first hour or so figuring that out. Turns out I was using whitespace-mode for text files, and that turns on font-lock-mode which messes up the formatting. I think I did that to lazily get whitespace-mode for some text-mode derived modes, so easy fix.

Now that I can cheat, the next road bump are the window management keystrokes under ^W, some of which I've grown accustomed to. Haven't tackled that one yet, and so any ideas are appreciated.

I really like how #emacs has been over the last few years sprouting packages that integrate well with existing emacs functionality. This is in contrast with older do-it-all packages like helm, ivy/counsel which in my usage have been replaced with vertico/consult/etc and projectile which has been replaced by project.el.

Case in point, someone I follow recently extolled the use of helm-apropos, but in #vertico, the emacs command describe-symbol is enhanced with vertico's narrowing framework without having to bind to any new functions. It may be not 100% the same as the helm function (I don't know I've not used it), but it does the job well enough in a nice and neatly engineered way.

I really appreciate this burgeoning attention to engineering, orthogonality and separation of concerns. As a software developer myself, I strongly believe this is the way to go.

Drinking the after-mentioned beverage tonight, I sometimes wonder if I am the only one at the center of the venn diagram of #rust #emacs, #progressive, #bebop and #lagavulin, if not let me know. We can probably be friends.