$ git log --oneline --reverse | head -n1
5f72575 Initial commit: January 2022
My importers take care of reconciling the common transactions, like train fares and groceries, which means my monthly session takes under an hour. The slow bits are exporting CSV statements from my banks, and reconciling transactions from amazon and the local pet supply store (is it useful in practice to track litter and treats separately? probably not).
I'm following this approach. One of the most interesting things so far has been observing just how separate recall and production are. There are kanji that I can recognise instantly, and recall meanings and pronunciations, but I can't visualise them at all.
I have this set up using kmonad[1], and the following config. Many punctation marks are obviously missing, but I'm sure they could be added with a little thought. The mirrored layout is toggled by holding the space key.
(defalias
lhs (tap-next-release spc (layer-toggle ytrewq)))
(deflayer ytrewq
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
bspc 0 9 8 7 6 _ _ _ _ _ _ _ _ _
_ p o i u y _ _ _ _ _ _ _ _
ret ; l k j h _ _ _ _ _ _ _ _ _
lsft / . , m n _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _)
The Strand programming book states that an early version of the Erlang runtime was implemented in Strand (see "13.1: History" http://www.call-with-current-continuation.org/files/strand-b...), which is an interesting tidbit that I haven't seen come up when the history of Erlang is discussed, like in the featured article.
I do this from time to time as well, although I tend to get hung up on error handling. I would say that it's a simple enough exercise if you don't care too much about reporting parse errors in a meaningful way, although I'd be happy for someone to point out an implementation of error handling that fits into one's head.
Here's the most basic error handling to implement, which I learned from studying FParsec:
1. Keep a collection of errors in the stream. It represents errors at the current position.
2. Clear all errors when input is consumed.
3. When a token-like parser fails without consuming input, push an "expected '<literal>'" error.
4. When a labeled parser fails without consuming input, restore the error set as it was before running it, and push an "expected <label>" error instead.
This will naturally accumulate errors from choice and repetition combinators, as long as you don't have needless backtracking before the choice points.
So this already gives you reasonable errors like "foo:17:4: expected one of expression, assignment or 'end'". And it's easy to extend to nested errors, backtracking information or recoverable nodes.
I like that Ploopy are designing and building open-source hardware. I have their Classic (1) trackball, which has been great. I recently got their new trackpad, which is better for me. Having multi-finger gestures (pinch to zoom, swipe back) is nice.
With Emacs 30 I've stopped compiling from the master branch, preferring the tagged releases.
GNU Emacs 30.0.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2024-12-03
It seems that most of the features I was eager to try from the master branch at various times (starting from native comp, then tree-sitter, use-package (although I've started using elpaca instead), modus themes, transient, etc.) have been merged. A lot of great features have been added to Emacs in recent years. Kudos to the maintainers!
Using your thread to ask: What recommendations do people have for a
build that's best for heavy org-mode use? Of all emacsen which is the
best drive for Org?
I don't have any specific build-time recommendations for org-mode, but I can wholeheartedly recommend the built-in 'leuven' theme for org-mode work. I normally don't go in for light themes, but this one has so many nice little touches to spruce up org-mode elements I find myself switching to it from my usual dark doom or modus themes when working on org-mode projects.
Can anyone shed light on the difference/overlap between Fleng and Strand, for someone who's reading about concurrent logic programming for the first time?
dape ( https://github.com/svaante/dape# ) is a great option for languages with debuggers implementing the Debug Adapter Protocol. Combined with debugpy it's killed M-x pdb for me, and has a very similar UI to M-x gdb.
