this is my concern as well, i think vim wins for a lot of folks because of latency and that an emacs successor should prioritize performance and low ux-interruptions in it's values and culture. fwiw, i'm much more comfortable optimizing atop guile's bytecode than elisp.
I've got a lot of Lisp experience, and love Emacs' values and ecosystem. I still use neovim regularly because of a tangle security, a sound sure-footedness of action, derived from consistency and latency. It takes a combination of confident action on the users part and confident response from the machine to perpetuate the user's experience of both speed and intrusive confidence. (IMO) Emacs fails to deliver this experience plainly in latency due to the main thread blocking (even with more the 8MB of RAM). It fails partly due to the greater variety of modes and (as an evil user) lack of "core" support for Vim bindings, creating a higher sense of care and vigilance, but I really that could be over-come if one's config is kept small and the ecosystem tuned more towards robustness and optimization in visible UI, tactile UI, and multi-threading.
In favor of what, I don't know. Something that explicitly aspires to feature-parity with a modern-emacs stack (vertico/corfu/marginalia/transient/tramp), but which sacrifices some aspect of the platform's flexibility (eg. make plugins use transient and allow consistent global user prefs) to prioritize consistency, latency, and robustness for the sake of UX.
love seeing this resurface, am working on something similar myself -- it'll be like running Taipo on the Fulcrum, with influence from Ikcelaks "Word Builder" serial-steno system (in case anyone wants terms to research :p)
i'll try to polish a write-up when i finish, but really need to focus on finishing first >u<
Love it! Have you seen the signals proposal? Just learned no-build-step preact, but between signal and these examples, I might not bother for my next project.
I've been writing (and reading) a lot of Lisp lately, and have seen some projects adopt indentation idioms which offset blocks from the regular tab-stop intervals. A standard tab-stop might be +4, but then arguments might be lined up with each-other at +6 (+1.5 stops):
(list 'a
'b
'c)
Any of those arguments could be forms, which might return to the standard tap-stop of +4 but off by 2 (let's call that `+4(+2)`):
(list 'a
(with-foo quz
(bar quz))
'c)
Lists written with the `quote` syntax might do the same thing, but produce an offset of only 1:
'(a
(b
(c)))
The end result is that changing a code's indentation level (like when raising an anonymous function into a top-level definition) means adjusting the spaces (which were supposed to only be for alignment) if any preceding forms had introduced an offset. The alignment doesn't change, but it's relation to regular tab-stops does. Sometimes, this is an adjustment of zero, but you still need to think about it. In an all-spaces environment you could use vim's visual mode to select the block as a rectangle and paste it into the top level, but with "indent/align" semantics this same situation regularly requires maintenance (by inserting or removing spaces, in addition to manipulating indentation via tabs) to preserve both proper alignment and the integrity of the semantic distinction[1].
I think that elastic tab-stops fix this by correctly modeling indentation is it should be conceptualized, platonically divorced from the characters encoding it. I think that spaces are better than tabs when white-space isn't significant (and personal style might disregard tab-stops), but recognize that tabs are more accessible and worth using when tab-stops are enforced as a byproduct of significant white-space. I repeat that elastic tab-stops are awesome.
1: Someone correct me if vim can actually just do that with tabs just fine, i dont really know, it late~
In my mind, the "Right Thing to Do" would be to follow the precident established by OpenPGP's `.well-known` email-hashing in Web Key Directory (not the prefix of course, and barring technical arguments justifying deviation, which may be considered on merit).
> SHA-1 hashed and z-Base-32 encoded [to distinguish it from a fingerprint]
> The local part is always lower-cased before the encoding. [...] A common example for case-insensitivity are visiting cards which capitalize the canonical lowercase mail address for easier reading.
Thanks for writing! Love the composition of your site pages btw. I've got the same "|"-seperated nav bar on my WIP branch. Cleaner then my current branch, but I'm trying to compromise between sparse-ness and something with more "vibes". If only I was in the habit of actually writing anything-- congats!
It's only legal for each `now` to be consumed by at-most one `at` form, so at that point you'd just be re-implementing the "timeline" and "instant" system from mariposa. The need to wrap the program in a form and the management of `now` "values" has me pondering the implications of IanTheHenry's macaroni[1] system, which (like the CSS :has operator) allow macros to climb up into manipulations of their parent forms-- the `now` macro could effectively wrap every remaining form in the program with a new context that augments eg. the closure of `at`. But indeed, perhaps a problem to not become too invested in :p
uh, case in point, that hypothetical closure would have some difficulty crossing module boundries (and that's assuming it gets away with re-writing top-level define forms), but still nothing technically incomputable, just supremely ill-advised and still closer to a reimplimentation of mariposa's semantics than a truely native concept emerging out of the continuations system
