It's self discovering... once you figure out how to use its very eclectic by modern standards mechanisms for discovery. No sarcasm. Learning how to use it is a skill you have to actively acquire. This is more a criticism of emacs than of you.
That said, I've been using it for... uhh... about 30 years now, and I've honestly never picked this skill up myself very much. I can only use it minimally. Just googling is fine, and as others have commented today (although maybe in that other thread about emacs), AI makes it even easier because it can just straight up write the modifications for you if you need them.
Some years ago, Microsoft got the security religion internally. While it doesn't mean that they've been issue-free since then, it largely worked. They were dangerously close to acquiring a reputation as being too insecure to do real work on, and they resolved that enough for the market.
I wish someone would give them the performance religion. The saying that what Intel giveth, Microsoft taketh away is pretty old, but I will defend Microsoft in the past with the observation that, you know, 32MB of RAM to 64MB is a pretty small change in the modern sense. It doesn't take very many bitmaps or fonts or colors to burn through that sort of increase in power, even at the older resolutions of the past. There's a reason we don't all build our UIs to run on 386-class machines.
But it's gotten freaking absurd. I've got a 8-core monster that cranks up to near 5GHz at the drop of a hat, more RAM than I could have dreamed of in the 1990s, and a disk with numbers that I would have asked if you were accidentally talking about RAM back then (NVME SSDs still have ~500-1000x the latency, but the modern SSD wins handily on bandwidth). Modern code has more to do, more fonts, more graphics, more Unicode, but still it has gotten really absurd. 10 seconds on a modern computer is a lot of time. 12,000 frames of a AAA game ought to be enough computational power to check my email, not to have my email checker still choking and stuttering as it barely manages to start up.
I never liked the word "start" itself, but if you're going to have a GUI, a single central clean place to say "every interaction you may want to do can be found from here" is a good idea. In principle having search there is pretty useful.
In practice Microsoft has consistently from the beginning gone out of their way to make the search useless and slow, a policy that is now old enough to vote. How the start menu has now gone nearly two decades without you being able to type "note" and see Notepad just pop up as one of the choices instantly beats me on my ever-more-super super computers, but that's an implementation detail that Microsoft has consistently botched. And more and more over time, Microsoft has thought more about what they want in the menu than what the user wants.
Nevertheless, the general idea of that top-level "here's everything" is a good one. The open source desktop environments do a much better job with it, without marketing trying to figure out how to stuff this half-decade's marketing push on to the user or "monetize" it.
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)
Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
Besides the performance and what baokaola already mentioned some things that make Ghostel better than vterm especially when working with those cli agents are:
- proper handling of resizing windows
- progress reports (you get a spinner in the modeline when claude thinks)
- notifications (get an alert when your agent is done)
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
Of course. Emacs has been my stable editor over many years, handling many languages that came along, surviving many other IDEs that came and gone (the latest being the Cursor sold out).
There're always new enhancements in Emacs, from multiple-cursor editing years ago, to LSP and tree sitter in recent years. Currently I just got into the vertico/marginalia/consult/embark combo packages. Embark with its context based actions seriously is an amazing underrated package.
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.
Yup. I've aliased it to e and and it works just fine. Sort of "send file into Emacs". I've also added some elisp to say things like e something.c:43 so that it opens it up at line 43.
I used have a ep which I could pipe something into and it would put it in Emacs buffer but that stopped working somewhere I never got around to fixing it.
I used emacs for about 16 years, but never properly gotten into client-daemon setup. What’s your setup? Does the daemon preserve open buffers and stuff, so when you connect you have all your openned stuff? Or each emacs sessions have separate set of buffers and windows?
Yes to some extent. When you attach to it, the default screen will still be scratch, but all your buffers are still open. There are some settings you can set to fix that, if it's burdensome.
being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example
On my MacBook I map the right hand command key to “ctrl” and the right hand option key to “meta”. Since the command keys are right next to the space bar that puts the ctrl key on a thumb position most of the time, and for the times when that isn’t a good key for a given combo I still have caps lock bound to “ctrl” as well. Seems to work reasonably well and lets me keep the usual command and option keys on the left side for “super” modifiers and for typing accented and other characters.
For my desktops, I use an Ergodox EZ keyboard and mapped ctrl and meta into the thumb clusters there.
I don't use actual vim for much, most of my time is spent in JetBrains IDEs and sometimes Xcode. Both with vim emulation. Setting up Spacemacs would take hours of my time for questionable gain. If I was still a student I'd jump on it but alas
This works especially well on an IBM Model M because there's nothing in the vicinity of either the left or right ctrl, you just chop your palm down and can't go wrong. I could also pretty reliably M-x in one hit by flipping my left hand over, curling my pinkie finger, and hitting the keys with the knuckles. On more crowded keyboards I remap ctrl:nocaps and use thumb and forefinger for M-x. I actually deliberately got rid of my Model M to teach myself to do it this objectively worse way, because context switching between my docked workstation setup and laptop keyboard on the go was difficult. If only someone would make a laptop with a proper keyboard...
> for getting huge swathes of code on your screen at once
This is my major gripe at most IDEs. Every window, or view, or sub-view insists on shaving off a little bit of vertical and horizontal space for... I don't know, tabs or things? Or to tell me what program I'm running?
I just want a dark screen with text (I run Vim, so I'll concede I allow a tiny bit of vertical space for line numbers and a little bit of horizontal space for the command space)
I also have been using emacs for almost anything for the past 20 years. I had to switch to VSCode for coding over a remote ssh connection to cloud VMs. The client/server split of vscode felt superior over the ssh connection and the emacs alternatives was not up to the same level of performance two years ago. Do you know any progress on that front? I would love to go back to emacs as my daily driver but I am sensitive to lags when I type / execute commands. Have you worked with ai assistants over a remote connection?
I've been trying to use agent-shell with OpenCode but the abstraction that agent-shell puts on top of it is too much. I can't figure out how to change the model. The command to do it doesn't do anything; I see the correct model list and seem to be able to select it, but then it doesn't change. If I just run "opencode" in the same directory it comes up configured the way I want. The Claude integration works with that workflow too. Opencode comes up with some baby CPU-only model that I've never heard of, and basically, it outputs syntactically correct English sentences but doesn't seem to do much more than that.
Since I mostly use Claude I haven't fussed with agent-shell much yet.
agent-shell is awesome, but Anthropic banning subscription usage via ACP is a killer. I've liked claude-code-ide.el when I've used it, but its lack of concurrent sessions per project has prevented me from fully adopting it. I know, I should be using worktrees, but I still haven't figured out a nice way to get that to work with my docker-compose-based project (though I'm open to suggestions!)
In addition to the observations in the sibling comments, note that "one half of the camels should go to the eldest heir, one third of the camels should go to the second heir, and one ninth of the camels should go to the youngest heir." -> 1/2 + 1/3 + 1/9 = 9/18 + 6/18 + 2/18 = 17/18ths, not 18/18ths. The will "happens" to be incorrect and fails to allot the full inheritance in exactly the way it needs to be for this to work.
If we're going to play the "should" game, whatever originated the body "shouldn't" have because the spec says that's illegal.
Although we could also go with, a proxy shouldn't delete the body, it "should" reject the request outright as ill-formed.
The meta-point I'm making here, which I'm sure will be missed if I don't spell it out, is that if we're going to talk about what "should" be done when it is explicily out of the scope of a standard, there's no way around the fact that there are multiple completely sensible ways to extend the standard and there's every reason to expect that in the real world people aren't going to agree. Sometimes they manage to, but even then often quite imperfectly. Our human intuitions that standards are something that are "built" is perhaps not wrong, but you can also productively look at standards as taking the raw material of all possible things two systems could send to each other and removing possibilities. If you reach into a space that has been explicitly removed, you can't expect everyone else to do so in exactly the same way you will.
For a very long time, the spec did not say it's illegal. In fact, RFC 2616 (that has been defining the HTTP/1.1 for 15 years) says that
A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.
but if you go into the section that describes the semantics of a GET request, well — that section says nothing at all whether a GET request is allowed or not to have a message-body. So it's not prohibited, and the servers should simply ignore it when processing it (and proxies should forward it up).
I would also observe that it is a completely reasonable hypothesis that even if you can construct a problem in some higher complexity class that a quantum computer "should" be able to solve, it is possible that it would turn out that it couldn't because the complexity barrier turns out to be even more fundamental than quantum mechanics. If I understand it correctly, Scott Aaronson at least takes this possibility seriously, and points out that it is at least a possibility that this could end up being the legacy of quantum computing, along with the possibility that it could demonstrate some sort of currently-unknown fundamental limit on entanglement. And I'd add my own commentary that the experiment that shows QM breaks down and refuses to solve some problem that it "should" be able to solve would be on the instant shortlist for Nobel prizes for the experimenters, pending only extended confirmation, because it would be a big, big deal.
"I can also write lines of code for free. I have the same superpowers you do..."
Boy oh boy can I tell that people have still not internalized this. Yes, your HTTP proxy with a list of features as long as my arm would have been impressive 5 years ago, at least on some level. Today, I can prompt it into existence as easily as you did, and if I am prompting it into existence I can build a custom one with just the features I need, that integrates into my logging & metrics, etc., and perhaps most importantly, I can literally do that more quickly than I can evaluate your project. AI has eliminated the space of open source projects where evaluation of your project takes longer than prompting it into existence does for me.
The premise of this argument is that using AI takes no skill, and experience using AI doesn't matter, and that domain expertise in software development won't help you build better software with AI.
I think you'll find most of the people creating the HTTP proxy servers and brand new AI harnesses and git or ssh config managers and all of the other things that we already have way too many versions of are not our best software engineers anyhow. I like to analyze things in terms of how much of the real world they've encountered [1], and one of the reasons I would just put my own solutions together is a lot of these manifested major projects with huge lists of "features" have either one user, or in many cases, zero, which is to say even the author isn't actually using it, and I might as well put together my 1-user project myself.
Right after I posted, I realized this hole in what I was saying.
Reflecting a bit more, I agree with you, but only in cases where the author of the open source project doesn't aggressively shun the use of AI in their own work. Folks that refuse to engage with AI (even open source project maintainers) will find themselves lacking the skill with AI that others have. So I can imagine a future where those open-source maintainers will get pull requests written with AI that they themselves could never produce.
I'm not sure I believe my own argument here, but I think it follows from "using AI to produce something worthwhile is a skill".
What about the price to verify your newly borne vibe coded project. At least the person who published it has a chance to have used their project to valid/solve their own problem and then was nice enough to publish it back to be freely used vs costing $10 to prompt it into existence
Sexual arousal also tends to inhibit rational thought. I don't mean that in a snarky or sarcastic way, I mean that it is a biological process that has been well-studied and well-established [1]. This has obvious uses for scamming people and doing other things that their executive function might normally catch and prevent.
This is also why sexual imagery should generally be kept out of public spaces, not because of "puritanism" but because it just generally isn't a good idea to go around letting bad actors inhibiting people's executive function willy-nilly. That should generally be denied as a tool to bad actors like scammers.
>This is also why sexual imagery should generally be kept out of public spaces, not because of "puritanism" but because it just generally isn't a good idea to go around letting bad actors inhibiting people's executive function willy-nilly
Okay but presumeably humans adapt to the level of "sexuality" around them to some degree (like they do nearly every other stimulus), because otherwise you could show less prude cultures having lower ability to do "rational thought".
Nudity is normal all over the world and yet people seem to function just fine. What constitutes content that justifies sexual arousal is socially constructed!
Note the above commenter specifically used the language "sexual imagery" and not "nudity". As you point out, what can be considered "sexual imagery" can vary somewhat based on the cultural norms of the society.
Somewhat? The variance is off the charts. Without even going to the extremes of casual nudism vs burka, there are cultures where wearing hair down is seen as sexual, and there are cultures were twerking is child appropriate.
I cited my sources. You're welcome to seek out studies on the question of how it varies between societies, they probably exist somewhere. However as part of the "adaptation" you cite is precisely scammers getting better at scamming people, this isn't something we should treat casually.
It's not as if it's news or anything. "Sex sells" isn't a new phrase. But I think most people assume it's just because it's ambiently appealing, the fact that it also objectively lowers rational barriers to buying what is being sold is less well understood and changes the question from just a matter of appeal to one of psychological abusiveness.
That's how I've come to see it; that sexy chick (sexist language chosen advisedly) on the billboard isn't just a company nicely providing me a beautiful thing to look at for no reason at all, it's an attack on my executive function. It's an incredibly hostile thing to do and should be treated as such.
Why would seeing sexual imagery make you less rational? That doesn't make sense.
The study you mention say the people were already in an arousal state (that they had to induce themselves). It's very different from seeing images that you may simply ignore, evaluate differently, etc.
Also, there is the bias that if people are looking for such images (because they really want them), they are probably more willing to drop recommended practices, and hence make irrational moves. So irrationality doesn't come from seeing the images at the first place, but from their willingness to find / see such images.
I often use the rough approximation that Python is 40-50x slower than C. This is what you'll see in the benchmarks.
The truly rough thing about Python though is that that is the speed when the code is being written to a benchmark. It is really, really easy to write Python that is multiples slower than that when not writing to a benchmark and just trying to get work done without hyperoptimizing. I did some testing of Python [1] to back some other commentary I was making that compared the time it took to set an attribute repeatedly on a particular instance of an empty class to the time it took to setting it on a subclass of a subclass of a class that had a property setter that was wrapped by a decorator. The latter was about 4.6 time slower than the direct attribute setting, which was itself already ~100x slower than an attribute setting in a static language.
And it's not like a three-deep nested class with a property wrapped by a decorator is all that absurd in Python or anything. That's a completely normal case, not some absurd example I made up to skew the test.
In practice the 40-50x number is more lower bound than what you can count on. If you are actually using Python's features I think you can easily score another order of magnitude slower without anything jumping out at you as being an obviously bad idea.
> 40-50x number is more lower bound [...] easily score another order of magnitude slower
This is about what I observe. I had a utility based on `scapy`; there were no obviously bad ideas in the python source, but porting the work loop into a cpython extension module yielded a 500x speedup.
I feel like scapy is a bit of a special case though. It's unusually dynamic because it allows kind of arbitrarily crazy things. I feel like it's maily best for prototyping. I've had 1000x speedups (100s of milliseconds to dozens of microseconds) just by removing dynamism. In our case we used scapy to work out the packet shapes we cared about and then just implemented just that subset (still in Python!). But that dynamism really helped with the early stages along with wireshark
A while back I had claude implement something, I don't quite remember what it was, but it chose Python. It was going to take hours. I told it to rewrite it in Rust and it was > 300000x faster. This is without any optimization or prompting particularly about performance, a short one shot lift.
echo "Python sucks, use something else when you can" >> ~/CLAUDE.md
Python was cool in 2005 in academia IT, all the rage in startup 2012. These days...
That said, I've been using it for... uhh... about 30 years now, and I've honestly never picked this skill up myself very much. I can only use it minimally. Just googling is fine, and as others have commented today (although maybe in that other thread about emacs), AI makes it even easier because it can just straight up write the modifications for you if you need them.
reply