May be splitting hairs, but I don't think it's the terminal-native part that's relevant, so much as that both LLMs and emacs/vim are text oriented in ways which e.g. VSCode isn't. (Or perhaps just the text-oriented nature is a result from initial constraint from being terminal-native).
As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different tasks together. -- This ought to be a natural parallel to what the agentic tools are trying to do (use MCPs and skills etc. to bring different functionality to the LLM execution environment).
That LLMs can help users extend emacs ought to lower the difficulty curve.
Still. It's silly to wish that Emacs could be the LLM's best friend, rather than demonstrating how it is.
RE: "what if in the future all coding skills are irrelevant". My experience has been that good results from LLMs come from putting good thought into its usage. They're quite far from a magic "push the button and get the result you want" where the skill doesn't matter.
Not totally related to your point BUT I’d like to tack on that lisps and generally repl-friendly languages are in an interesting spot in the LLM-enabled world.
The calva-backseat-driver vscode extension runs an MCP that lets LLMs manipulate and eval clojure expressions in a REPL. It provides a tighter feedback loop and lets LLMs do much more complicated stuff with much more confidence. They can test functions as they go, read docs, check query outputs, write and eval tests. It’s actually crazy what Claude opus can do with REPL access.
It might be insanity to let an LLM modify your emacs on the fly, but I’m sure people will have some crazy and interesting ideas in that vein!
I don't let it execute emacs lisp itself, but elisp generated in org mode babel blocks which is instantly executable is a fine way to have gptel improve itself.
This is super exciting. Emacs already treats UI as just more Elisp to eval. The AI could sculpt the entire editor to whatever you need in the moment. No plugin to install, no config to maintain. Just describe what you need and the editor becomes it.
With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.
For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.
Or magit makes it easy to stage/unstage line by line.
The core of it is described by the post you're replying to as "I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality to make Emacs work exactly how you want."
Emacs is highly customisable. There's not really a hard difference between "configuration" and "extension". Whereas with e.g. VSCode, very few people would write their own extensions. -- So it's a good point that with LLMs, the barrier to customise Emacs to exactly how you want it is even lower.
I'd also argue that since practically everything in Emacs is text (as opposed to a rich GUI interface), Emacs itself ought to make for a nice interface to LLM functionality.
While this is a problem for the default user experience, I think if you're an enthusiast there's less of a problem because you can get an external keyboard you like.
Laptop keyboards will always be disliked by someone: the standard keyboard layout is awful, and dealing with this either involves trying to stick to the conventional design (wherein different people will dislike different changes); whereas a good keyboard design is going to be so far from the standard keyboard that laptops aren't going to do that.
(People will quibble about where to put the arrow keys or however many modifier keys there are or that caps lock is badly placed.. but the most glaring issue is that the spacebar doesn't need to be over 6x the size of other keys).
It's a problem if the OS is inconsistent/unclear about what scan codes are required to do things.
> the OS is inconsistent/unclear about what scan codes are required to do things.
Both that, and there's an internal list that allows only Apple's (plus a few makers' like Logitech and Keychron) keyboard to _send_ the modifier keycode. Others are simply ignored. Sorry enthusiasts, Apple don't want to favor you.
My Mac has no keyboard, it's just a metal box that sits on your desk - so an external keyboard is the only option. Nobody told me I had to get any specific type in particular!
It looks like you can still use hidutil to remap some other key. This invocation seems to remap the Application key to the fn key:
On my keyboard, metakeywise, I then have 2 x Shift, 2 x Ctrl, 2 x Option (marked Alt), 2 x Command (marked Start), 1 x undetectable-to-macOS (marked Fn), and 1 x Fn (got that little Windows context menu logo on it).
Yep, this is what I have in my Bash config, for the external Microsoft Natural Keyboard attached to my Mac:
# note: works for e.g. Fn-F (fullscreen), but not Fn-F{1..12} (brightness etc.)
alias app2fn+=$'hidutil property --set \'{"UserKeyMapping":[{"HIDKeyboardModifierMappingSrc":0x700000065,"HIDKeyboardModifierMappingDst":0xFF00000003}]}\''
alias app2fn-=$'hidutil property --set \'{"UserKeyMapping":[]}\''
alias app2fn?=$'hidutil property --get "UserKeyMapping"'
I have an external keyboard and I keep accidentally hitting the fn key when I mean to hit backspace. And that toggles the keyboard layout if you have more than one.
I've used CH32X035 (which is practically CH32V00x plus USB and some other things) at the hobbyist level (no-frills keyboard PCB designs).
The impression I get of WCH and their CH32 line is it ... draws heavy inspiration from STM32.
WCH provide English translated datasheets and reference manuals. They're fine.
Their own recommended toolchain is a fork of GCC. But as far as I can tell, they haven't shared their changes anywhere. The specifics of the changes they've made are a bit beyond my understanding, though.
With the open source distributions of GCC toolchains work just fine. I've built Rust crates as firmware libraries for them.
That the CH32X035 is very simple to design for (& low cost) means I'd rather make use of it for hobbyist keyboard PCB designs compared to the RP2040.
While "I don't have to think, I just get the LLM to do the task" is a bit careless (or a "hype" way of putting it)... I'd reckon it's always been true that you want to think about the stuff that matters and the other stuff to be done for minimal effort.
e.g. By using a cryptography library / algorithm someone else has written, I don't need to think about it (although someone has done the thinking, I hope!). Or by using a high level language, I don't need to think about how to write assembly / machine code.
Or with a tool like a spell-checker: since it checks the document, you don't have to worry about spelling mistakes.
What upsets is the imbalance between "tasks which previously required some thought/effort can now be done effortlessly". -- Stuff like "write out a document" used to signal effort had been put into it.
Helix is a really nice editor. I use it as my go-to for when I'm in the terminal environment.
For sufficiently complex manipulations, I find the "selection-action" ("motion-action") to be more intuitive than "action-motion". Even with vim, I'd often like making use of visual mode.
I think the main limitation to this that I believe is it's probably a bit slower for quick + frequent edits compared to vim.
Hadn't heard of this. So I looked at the docs for Ki.
I see the "Why Ki?", and then it has this:
> Being first-class means that it is not an extra or even sidekick; it is the protagonist.
Eh.
I find it quite off putting.
I guess my expectation is that someone enthusiastic enough to write a text editor with a value proposition of "it's got good tree-sitter-based navigation" would want to discuss why they thing syntactic selection is neat.
Seeing cliche LLMisms doesn't signal the same level of care to me.
Having been in the community for some time, it is just how the authors are, very enthusiastic about the wording. They like to come up with some wild terms explaining different behaviors and reasoning behind those behaviors, like "positional coherence" or "behavioral asymmetry", and the term "kimmunity" to reference to ki editor community. On a surface level, sure, it looks LLM generated, but I would be very surprised if they used LLM to generate that sentence. I choose to look at the actual meaning of the content and what they are trying to do differently
To some extend that is true for any opinionated piece of software. But that is a beauty of opensource don't use it if it doesn't match your idea of how that software should look like
It's not generated by LLM, it was actually my idea, but grammar-corrected by LLM, but you are not wrong either, the docs are really subpar in a lot of ways, and not clearly explaining why is one of them, and of course, the potentially cringey sentences too, someone complained the docs read like a Vogue magazine before lol
I sincerely respect your humility, it's refreshing. I doubt I'll have time to try out Ki any time soon, but it's been bumped up the infinite TODO list :)
> Thing is, pretty much all of this missile defence technology is about to become obsolete once hypersonic missiles become more widespread, which is going to happen pretty soon.
I think you'll have to be more specific.
Or I guess to compare with your other observation: """Even with all this protection, Iran [sent] enough ballistic missiles to overwhelm the defences""" -- It's not a binary of "have missile defense or not => every missile will be shot down". An amount of missile defense will make it harder for missiles to successfully hit a target.
Similarly with hypersonic missiles, it's not the binary of "I have a missile that's difficult to defend against, I win".
Having a sword which can defeat a shield isn't in itself sufficient to obsolete the shield. (Infantry can be killed with bullets, yet infantry remain an important part of fighting despite that).
To my understanding, the main difference between "curl directly to bash" and "curl to a temp file, then execute the temp file" is "the attacker could inject additional malicious commands when curl'd directly to bash".
If you're not going to then also read all the source code from the download script (& the source code used to produce the binaries), this suggests the attitude of "I mistrust anything I can't read; but will trust anything I could read (without having to read it)".
It seems more likely that malicious code would be in a precompiled binary, compared to malicious commands injected into "curl to bash". -- Though, if there have ever been any observed cases of a server injecting commands from "curl ... | tee foo | bash", I'd be curious to know about these.
> the attacker could inject additional malicious commands when curl'd directly to bash
There's another issue actually. You're streaming, so ask yourself what happens if the stream gets cut prematurely. I'll give you an example, consider how this like could be cut prematurely to create major issues
rm -rf /home/theuser/.config/theprogram/build_dir
A malicious attacker doesn't need to inject code, they can just detect the stream and use a line like the above to destroy your filesystem. Sure, you might preserve root but `rm -rf /home` is for all practical purposes destroying the computer's data for most people
Or it doesn't have to be malicious. It can just happen. The best protection is writing functions since those have to be created and so can't execute until fully streamed. But so much bash is poorly written that well... just check out Anthropic's install script...
> If you're not going to then also read all the source code
Saving the source code still has a benefit. If something does go wrong you can go read it. Probably a good place to start tbh. In fact, if you're streaming and something goes wrong you'll see exactly what the early termination error did.
Is it good security practice? Absolutely not. Is it a hundred times better than curl-pipe-bash? Absolutely.
> To my understanding, the main difference between "curl directly to bash" and "curl to a temp file, then execute the temp file"...
It's not a temp file in the sense of a regular file. `<()` is also a pipe, hence equivalent. `curl` and `bash` run concurrently.
Running one after the other wouldn't be all that much of an improvement anyway if it's done automatically. One really should manually review the script before running it.
As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different tasks together. -- This ought to be a natural parallel to what the agentic tools are trying to do (use MCPs and skills etc. to bring different functionality to the LLM execution environment).
That LLMs can help users extend emacs ought to lower the difficulty curve.
Still. It's silly to wish that Emacs could be the LLM's best friend, rather than demonstrating how it is.
RE: "what if in the future all coding skills are irrelevant". My experience has been that good results from LLMs come from putting good thought into its usage. They're quite far from a magic "push the button and get the result you want" where the skill doesn't matter.
reply