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.
Having written a Forth-like native-code compiler (https://github.com/kragen/stoneknifeforth) and also a game in Gforth, I can't claim to be a Forth expert, but I agree. A lot of the weaknesses of the language (such as no compile-time checking of even the number of arguments to a subroutine, much less their types, and its terseness) are shored up by the interactivity of the environment. Some of the short words in Forth like ? only make sense in that context. And some things that might otherwise be weaknesses, like variables being static, become strengths in that context. (If you store into x in a word you're testing, you can see what got stored there with x ?.)
More generally, Forth, considered as a programming language, is not very good compared to other languages of a similar level, such as C or assembly. Its strength is as an interactive environment. (And none of what I've said here implies that you have to use a block editor.)
This is all fairly abstract, but it's not the first time I've talked about it, so I did an ASCIIcast last year demonstrating me writing a square root subroutine: https://asciinema.org/a/621404 I screwed it up in the middle and had to debug it, which is where Forth's interactivity shines. You may want to watch it on double speed, though. You can also get the pleasure of watching me learn that Gforth has readline-like command-line history!
That said, I think you're exaggerating a bit. I haven't seen a Forth compiler that's only a few hundred bytes, and I don't think the blocking PIO in Chuck's IDE driver is a good way to access an IDE disk, although it's adequate for initial bootstrapping.
I think it's ok to edit forth code in a modern text editor. Following your definition, many modern forth engines wouldn't qualify as a forth. You don't need an antique screen-based editor to get immediate words.
Another thing of the Forth spirit is that the system is supposed to be fully bootstraped (like most Lisps as well), having a very small of words written in Assembly, and then everything else fully bootstraped in Forth and available for customisation.
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
We're all sending JSON around all the time, it's not really that big a performance hit, especially in context of the formats transiting networks today (it's the same, lots and lots of JSON)
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...
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...
reply