i think "self-hosted", "home" or "company"/"office" should be the term we use, instead of "local", since
1. every LLM is _local_ in relation to the location the storage and/or the computers hosting/using it
2. the LLM running in your home is only _local_, until u step out of the door, but if you have some tailscale or zerotier VPN setup, u can still access it _remote_ly...
even on a native 2K monitor, having a virtual 5K frame buffer downscaled to 2K yields perfectly enjoyable results, compared to how macOS' native 2K image would look like; it causes eye-bleed :)
pretty amazing so far.
put together a SpaceFn layout, with partial home row keys, in no time, with their web usb based, online configurator.
i tried and/or assembled keyboard.io model 01, (falba.tech bamboo) minidox, troy fletcher signum 3.0, egodox ez, leopold, glove80 before, but this device is a pretty amazing compromise among many dimensions, like portability, price, familiarity, split-ness, extra layers, thumb keys, connectivity, portability.
what's clearly not great is its serviceablilty and only time will tell how durable is it.
if the battery dies in it and puffs up, it's most likely have to be thrown away, so it's not really an end-game keyboard, in that sense.
a good reason for getting used to the M-n/p/r binding is that they work in the minibuffer too, even in `emacs -Q` (though without live feedback, but i think that's a fine compromise)
for the past half year i'm using emacs without any extra competition packages and it's surprisingly usable as-is.
i haven't even customized the completion styles and it's fine!
i got used to typing `M-x -forward<TAB>` if i want to find a command which contains the word "forward" and not just starts with it.
i do have karabiner elements remapping my keys under macOS and i use a tweaked version of @jeebak 's SpaceFn layout, where i've mapped Opt on holding the semicolon key, which still acts as semicolon, when tapped.
that way M-r is pretty convenient to type. M-p is less so though, because i switch to the regular opt key for that... i should really have to get used to my glove80 keyboard to avoid such quirks...
there are some quirks with it though, given it has a couple of input modes.
i think everyone should read its fantastic documentation 1st to avoid frustration, instead of just falling back to the local minima of trying to use their pimped up shell inside eat as is.
e.g. i had a 2 line starship prompt enabled in my macOS zsh and inside eat it made the screen scroll back and forth by half a page randomly as i was just typing regular characters at the prompt.
M-<left>/<right> moves the Emacs point in semi-char mode, but the underlying shell is not aware of it, so the next character input will happen at an incorrect position. M-f/b works though.
There is an auto-line-mode, which might be a good compromise, but i haven't tried it yet.
otherwise, as others have mentioned it, remap the keys!
also, you can talk to some LLM about it, if you feel it would be tedious to come up with better bindings.
feed in the key bindings from `C-h m` of eshell, enumerate which bindings you want to carry over from traditional shells and instruct it to recommend you binding swapping pairs.
i was able to get great results on such niche operations already from anthropic's opus 4.5 models but even grok or deepseek was pretty helpful already last summer.
steve yegge's efrit takes this to a whole new level, by letting the LLM interrogate your running Emacs process live for documentation or function source code:
no.
as others have stated too, the following should be mentioned
- what's the 2 meaning in BMP
- it's designed as a monospaced (or proportional?) bitmap font
- designed in a single 16x16 size only (or also 8x16? it's a bit unclear)
- provided as an OTF/TTF font format, which can be scaled by most font rendering engines to other sizes, but u need antialiasing to make it look smooth (this is mentioned, but under the download section only)
- use as a "last resort" default font, according to wikipedia at least
In earlier versions of Apple OSes, you could edit the menus yourself, with the officially supplied resource file editor app and there was nothing really special about it.
There are `ibtool` and `plutil` CLI commands built-in to macOS these days too, but to get some graphical editor, u would need to download 3GB of Xcode and u would invalidate the code signatures, etc...
Plus there is a huge churn in the application versions, so any customizations would need to be applied repeatedly to newer app versions.
> I feel like my Forth-like compiler and VM capture enough of the spirit of Forth!
Being interactive is core to the spirit of Forth, so I think your feeling is off.
The fact that editing, compilation and execution is folded into single, comprehensive workflow, makes it possible for a Forth system to be situated in very resource constrained environments and evolve while it's running, potentially without any dependence on some other, beefier computer somewhere else.
There are tons of problems avoided with bundling all these capabilities together. There is no question of "which version of the compiler to use?", since it's part of your program, because it's so small (few hundred bytes probably), it can be part of it.
It also has the D-lang, Rust or Zig style `comptime` feature via the immediate mode words.
I wonder, how rigidly has the JSON format been baked into the protocol.
It feels like a shortsighted choice, just because it's prevalent in recent decades.
It took years to implement performant parsers for it and it has a lot of quirks, missing features and the tons of double quotes and mandatory commas significantly harm its human readability...
Not sure what would I recommend instead, but personally I would prefer using EDN instead, as a Clojure programmer
It's finally as snappy as recompiling the "Borland Pascal version of Turbo Vision for DOS" was on an Intel 486 in 1995, when I graduated from high school...
They C version of Turbo Vision was 5-10x slower to compile at that time too.
Turbo Vision is a TUI windowing framework, which was used for developing the Borland Pascal and C++ IDEs. Kinda like a character mode JetBrains IDE in 10 MB instead of 1000 MB...
While I agree with what we don't need, something is still off with the UI. I can't really put my finger on any specific problem, though. It's just a gut feeling.
The names are bold faced, so my attention is drawn to them, but since i don't recognize any of them, i don't even know where to start reading.
i'm not from the US, but i did work on forms related to government workflows.
it bugged me for a long time why a person can't store facts about themselves and let some software figure out which of those facts are needed for filling out any form, which needs the usual personal facts.
then one can review the required facts and decide which ones are they willing to share.
in fact governments could even standardize the kind of info they are dealing with usually and when a citizen wants the government to do something, instead of filling out forms, they could provide their own, self-hosted fact db, run the govt's query and provide the results (after review)
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
1. every LLM is _local_ in relation to the location the storage and/or the computers hosting/using it
2. the LLM running in your home is only _local_, until u step out of the door, but if you have some tailscale or zerotier VPN setup, u can still access it _remote_ly...