Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
Hah. Those were some of the screen editors we complained about. Emacs was popularly said to stand for "(e)ight (m)egabytes (a)nd (c)constantly (s)wapping". (8 MB is small by today's standards, but back then it was big. I believe CITHEP's VAX 11/780 was either 4 MB or 8 MB). I don't remember what we didn't like about vi.
At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix.
If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor".
This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee.
Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).
I kinda think this is the story of "Oh someone wrote a screen editor -- that's the 10th time I heard from other people".
Like, if you write a text editor nowadays, my thoughts would probably NOT be too different, except that 1) I wouldn't speak out, and 2) I'd congratulate you, for real, because this world doesn't give ordinary people good time.
Yeah, my thought when seeing the title of this post was "everyone should build their own text editor". You can start with a couple of hundred lines of code. Not everyone will be happy using their own editor for very long, but it's surprising how little code you can get away with when it's your own and the (many) bugs left in it at any point are the ones that don't annoy you enough for you to spend time on.
My own is absolutely full of bugs and missing features, and probably a real pain to everyone else (to my knowledge only one other person has actually tried to seriously use it - I mostly discourage other users), but that's okay: It has the features I care about, some of which are entirely useless to everyone else. It started because I realised my Emacs config was big enough that I could write an editor in fewer lines.
Yeah, I think it's good to dogfood one's own program. It's just...we are so short of time. We are not the lucky few who could actually pull it off, lol.
Dude has worked on UTF-8, Plan 9, and a very popular language despite its flaws.
I am not accomplished enough to judge him. Nor have I had the pleasure to meet him in person to pass any judgement.
I don’t get this obsession with tone policing, probably borne of corporate tendency towards blandness and inoffensiveness. The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
That's weird, considering I was saying he was wrong about something. That's not tone policing? The breathless hero worship in your comment is ironically a much more insidious form of tone policing.
> The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
When you grow up, you'll (hopefully) learn that "being loudly and confidently wrong a lot" and "being unpleasant to work with" are not in fact correlated with any particular metrics of technical success, nor are they part of being an "interesting person". Quite the opposite in fact! (Although TBF it does correlate pretty well with certain measures of "success" and longevity in business and large organizations.)
I don't actually know very much about Rob Pike, but the two issues I've heard his opinions on, they were both wrong and poorly argued. I appreciate you don't think I should be able to say this, but I don't think your tone policing is appropriate for this web site.
He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.
> He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.
It is more nuanced than that. Created Go because:
a) C++ deemed excessively and unnecessarily complex, overloaded with features, increasingly difficult to manage
b) Very slow compilation times
c) Wanted a language with built-in concurrency (neither C++ nor Java qualified)
d) Enable fresh-out-of-university team mates to be effective
To be fair Java was created in a world where you'd run hundreds on services on a single server, run them in application server with a persistent JVM running.
Now with containers, running Java apps in containers isn't great because of that JVM layer. Memory management, JVM boot time, etc.
There are many things I dislike in Go as a langage but create a high level language that compiles to native makes sense in the cloud hosting/containers world.
I mean, I don't think there's nothing intrinsic to the JVM design on paper that requires this memory model. Just to the specific extant JVM implementations out there.
I haven't kept in touch with what has been happening in the Java world since I stopped working in it (uh, probbly 15 years ago) but you'd think someone would have come along at this point and created a lighter weight JVM solution that starts faster and manages memory in a more container-friendly way.
Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things.
> Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things.
s/software engineering/running a business.
I'd much prefer that the people building the bridges and planes I use, or the staff at the hospital I visit, have procedures in place to prevent them from "making a whoopsie" than the space to be creative or interesting. Even if they enjoy their job less.
The good news with software engineering is that unlike building a plane or running a hospital, nobody is stopping you from making your own projects and being creative and interesting as you want!
Yea, it's too bad that "making whoopsies" has become such a common occurrence, treated so casually, in what is made out to be a serious engineering discipline.
I mean, all engineering disciplines seemingly build in for margin of error / tolerances. e.g. Bridge, etc. are often overbuilt in case of faults in materials or expected circumstances.
I do agree our profession grapples with complexity in bad ways though.
When he said the average programmer is too stupid to program in a brilliant language, I don't think he was referring to C++. I think he was referring to non-mainstream languages that require totally different ways of thinking (there are many, and I don't know which ones he had in mind, so I won't list any examples). So he designed Go to be very familiar to average programmers, instead of embracing more powerful ideas (which average programmers would have a hard time with).
That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language.
For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
I'm not sure what he meant by "brilliant language", but he was working in C++ and was frustrated with it when he decided to create Go.
> Back around September 2007, I was doing some minor but central work on an enormous Google C++ program
> I actually tried and failed to find a way to bring the ideas to C++
> Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
Honestly could you blame him for not liking Java in 2007? Between the many layers of abstractions the frameworks used, the exceptions and the sluggishness to compile it was not a compelling stack
Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point.
Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds.
The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago.
My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.
Java and the JVM does show its age specifically in one era, and that is its OO-dogmatism which it inherited from the 1990s OO wave (i-was-there-gandalf.gif). Even the opcode set in the VM reflects this everything-an-object mentality.
While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.
When the Java people showed up to Python, they brought a bunch of that FrameworkFactoryItis with them, it was looking pretty bleak for a couple years. The culture that springs up around a language is as important as the language itself, even more so. It spreads to the libraries, and in turn the applications.
If average Google programmers are too stupid to program in C++, what kind of qualities are needed to get good at programming in C++? Like 140+ IQ? Or one needs to really sit down, think through, slow down, which is against the "velocity"?
He's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent.
Source: worked there.
That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact was barely used at Google when I was there)
I don't even know what actual production systems Pike ever worked on, before being given carte blanche to go off and make a new programming language to supposedly fit that niche?
In any case, Go is an insulting language to work in, which is not surprising since its origin story seems to involve insults.
Thanks for sharing. Do you mind to share a bit more about your observation and experience with C++ in Google? I'm just curious what kind of guidelines and practices produce better C++ code, because I have used C++ in my side projects, but I found it difficult to command -- it was always like handling a lot of dishes without breaking any -- that's why I talked about IQ.
And when you said "before being given carte blanche to go off and make a new programming language to supposedly fit that niche?", did you mean that (https://go.dev/talks/2012/splash.article#TOC_4) is not justified? I'm just curious.
C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite well.
Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...)
But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world.
As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d).
And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems).
The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool.
I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial.
Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.
FWIW that is exactly what happened, to some degree.
And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.
The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)
I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point.
It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.
They are probably referring to what Rob said in a presentation.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.
Rust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think).
I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another.
I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go.
Closest to this out there might be OCaml, I dunno. Maybe Swift.
> Rust development was already in the air a bit at the time that Go made its debut.
Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
Using explicitly checked errors instead of exceptions was a considered design choice and is well explained in the Go literature. It may not be to everyone's taste, but there are reasons for it. One of those reasons is how often very normal flow control is shoehorned into exceptions when they are available.
Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text.
I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.
The browser-standards-or-bust moment has past, hasn't it?
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
So we take a web browser and trim it down to only ever show a single <textarea> element you say? That's what I'm taking away from this. All the hard work for accessibility is already done then right?
Seems to me that in the short term everybody screams “DO NOT OPTIMIZE THAT CODE”, in the medium term everybody shrugs “buy a new computer”, and in the long term everybody gradually migrates to the solutions that optimized that code.
I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever.
The idea that optimization matters less over time is short-term thinking.
It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
> The idea that optimization matters less over time is short-term thinking.
The more you think about things and the deeper you investigate, the closer you get to realizing that most aphorisms, advice, and even "facts" are a combination of best-effort philosophy and selection biases from the lowest common denominator. Add in the Barnum effect and you end up with an ocean of inconsequential platitudes being parroted by every Tom, Dick, and Harry.
It's very difficult, requires active effort, and goes against human nature to act rationally. Most people don't even want to do it.
Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.
On one otherwise tranquil morning Master Foo's meditations were disturbed by cries of distress.
Finding that they came from one of the novices, he inquired "What is the difficulty here?"
The novice replied, "I am frustrated by my tools. Every day I must use many different editors because neither Emacs nor vi nor any of these other random editors has all the features I require."
Master Foo nodded. "How," he asked, "would a master of the Great Way resolve this difficulty?"
The student thought for a few moments, then replied. "Well, it's obvious. I will write the best editor ever. It will do everything I need. It will do everything everyone needs. And the world will be a better place because..."
The novice's speech halted as Master Foo rapped him sharply across the back of the head with his staff.
"Um. Master?" the student asked, rubbing the back of his head gingerly. "In what way have I erred?"
"Fool!" said Master Foo. "Do you think I want to learn yet another editor?"
Upon hearing this, the novice attained enlightenment.
Sometimes there are genuine reasons to build a text editor. It's really hard to build a full WYSIWYG graphics editor without modelling text layout yourself, especially for more advanced work like properly curving the text.
I implemented a pretty simple iOS/macOS text editor using TextKit 2, and it was astonishing how many hacks, workarounds and manual implementations were needed to support even the most basic features.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.
That is exactly it. You know what an engineer you are making a system as complex as that? I don't know your codebase but I'm quite aware of TextKit and I can see what a hard and consuming job you must have done. I wish I could see your editor too.
Thanks—I might return to it and open source it soon… It was a pre-Claude Code project, and it was hard to feel any momentum. It's basically a note-taking tool for capturing quick one-off notes in Markdown, but it stores a lot of surrounding metadata (location, any current calendar events, device type, etc) in the YAML front matter. It feels like it would be even more relevant in this era, but there's a lot of work to do on the UI.
I actually built a fully featured text editor with Codex last month for a GUI toolkit I was building from the scratch. It worked quite well. You should give it a try. Perhaps you can offload much of the refinements to the llms now
I am surprised- I reimplemented Notepad for Windows CE and it was pretty much a wrapper around a standard Windows control. It was just a couple of pages of MFC code I believe.
It probably depends on what you're trying to do; I needed Markdown styling and Markdown-aware behaviors (e.g. when you hit return after a list item, indent the same amount and add a new list marker), context-aware nesting (hit Command-[/] to indent/outdent), hotkeys for heading levels, and so on. Between keeping the attributed text styles correct, properly grabbing the right text ranges to operate on, and doing it all in undoable transactions, it became a handful.
Don't stress about it. The other day there was a thread about public bathroom descriptions and someone said "wow this has a countdown timer before the doors automatically open, how stress inducing" and I wrote "shit or get off the pot".
Now overall it's a well up voted comment but occasionally can see someone taking it down a point. What a psychological mystery. A normal person sees a humorous quip and either chuckles or ignores.
So a down vote is what.. someone offended by mild profanity? Someone who perceives me (correctly I guess) as not being empathetic to bathroom anxiety.
Point being - who cares. Make a post you think would be valuable for some reason (funny, informative) and move on. Someone is going to take issue with everything and that's just the beauty of the diversity of life.
I just assume that downvotes without explanation just mean that I am right and that has somehow made someone unhappy.
Unless I've been deliberately bait-y, which does sometimes happen, of course.
Sometimes I reread later I realise that I've come across in an unpleasant manner that I did not intend, or I misunderstood and my comment is irrelevant, necessary, or occasionally just plain wrong.
The real fun comes when you divide the audience: a few of my fairly negative comments around AI have bounced between -1 and 1-or-2 for days after posting, as some hate it and down vote then others see that as unfair and upvote, almost all without leaving any comment about why they agree or disagree (with either the content or my style).
Hah. Yes. The one-dimensional up/down mechanism leaves a lot to be desired. Your response could be so wildly engaging that literally everyone on HN has voted on it; so controversial that the masses and the bots are evenly split between loving and hating it; and so immaculately well-written that no one can think of anything to add or to counter it with which wouldn't embarrass themselves. That's usually what I tell myself after I get a single downvote and no reply ;)
I think eventually HN should see something getting a lot of votes and count everything as an upvote. (presumably if it is bad long before then a mod should have noted and removed the bad post)
A word of unsolicited advice: HNers are a prickly lot and will downvote without explanation because you stepped on some unknowable pet peeve of theirs that probably nobody else in the world shares. This happens all the time but you likely only notice when you happen to get downvoted before any upvotes and end up at 0 or -1. If your comment is reasonable, it will usually come back up.
But complaining about downvotes will certainly earn more of them.
I always blame it on the HN UI, especially on a touch device. The up/down vote arrow is a pretty small target and once you hit it, the arrows go away with no visual indication of which way you voted.
If you look close there is either a unvote or undown added to the line. However that is easy to miss. I've learned to always check that line on a touch device because there is no way to consistently hit the tiny arrow correctly (at least not for my body)
Don't forget the post score is a balance of up votes and down votes. This mean 2 down votes and 0 up votes registers the same (-1) as 10 down votes and 8 up votes (-1).
So there's no sense treating it like the community has forsaken you.
If the purpose of down votes is to guide discussion away from uninteresting or counterproductive paths, then it also scoops up divisive comments.
I suppose divisive comments are potentially disruptive if they are particularly flamey. But it seems like they deserve to be distinguished from more objectively negative comments. If the raw up/downs were exposed it would be interesting to experiment with this in the front end.
I'm pretty sure that downvotes from some users, perhaps those at a given karma threshold, count twice. I've seen quite a few posts that aren't otherwise attracting a lot of attention go straight from 1 to -1 more-or-less instantly, or from 3 back to 1.
It's also possible that they have experimented with fuzzing votes like Reddit does.
Either way, they don't seem inclined to disclose how it works behind the scenes. The Kremlinology of Hacker News is half the fun.
I quite often upvote comments I disagree with that have been downvoted for no apparent reason. Sometimes I vouch for flagged comments for the same reason too. That said, the last one I vouched for was flagged again and so were all the commentor's other comments.
> You can curtail the bandwagon effect by complaining.
I've observed the opposite--complaints are often more heavily downvoted than the original downvoted comment. The one I originally replied to is an example, at least at the moment.
Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
On text editor related topics, you should have thrown down the gauntlet and been explicitly clear that emacs rules, vi sucks, spaces are supreme, tabs are terrible, and mixing them is miscegenation. That way you only offend evil people, so their downvotes are delightful. Revel in them instead of whining!
Since you enjoy beautiful machinery, here are some classic clockworks:
There is just an insane amount of engineering and work you have to do. Measuring text and shaping fonts is a nightmare, computing chart atlases, having infinite scroll with virtual lines coming to and out of the screen, all the strange data structures to preserve optimized decoration rendering, ropes and ropes (hard data structures), navigating with the keyboard, computing which character interaction is closer to the I-beam when jumping up and down, also caching your previous movements to go back where you actually were. CRDT and atomic editing strategies... There are hundreds and thousands of articles and papers and stuff covering these things. It’s just something we take for granted with so much beauty in the background.
I think you are over estimating it. Sure unicode support is a hell hole. But if you stick to ascii, it is not very hard, that is including syntax highlighting. virtual lines ....I don't know about CRDT or atomic editing though...
It's unfortunately all too easy to hit the downvote arrow when you're aiming for the other one, especially for people using touchscreens.
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
i didn't downvote it but I thought it was pretty empty. "how do i love thee, let me count the ways" has been done before, and his love was more interesting than that you like text editors generically, and you don't mention anything you like. I'm not in favor of more poesy in tech circles.
i like text editors but I feel they contain "everything but the kitchen sink" (if you know you know) and that makes them somewhat impenetrable and difficult to modify and bend to new purposes even though they contain so much capability and potential, and the people who do understand them think it's a good idea to drag and drop an URL and have that do a web transaction and download a buttload of text, when what I wanted was just the text... of the url. I'm sure there's some way to turn it off, but instead there should be some way to turn it on. Oh yeah, worse when it's a jpg url, guess what they do with that.
in another direction, the point of markdown was to be editable and readable in source form, not to be a replacement for rendered HTML, but the same people who ruined HTML by overloading it are now fully engaged in ruining markdown by overloading it and making it unreadable in source form.
I literally just got Fable to write me a text editor. Well, I'll be honest, I got it to wrap the KDE KTextEditor library which is like 90% of a text editor.
I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on.
So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration.
Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes.
We live in wild times. I hope everyone is taking advantage while they can.
> We live in wild times. I hope everyone is taking advantage while they can.
Yep, I'm taking advantage of the times by using the exact same tools I have been for years, and if those fail me, I'll pay for one of the multitude of other high quality editors offered by companies who's business it is to make them, so I get back to writing things in them instead of paying even more to companies trying to persuade me to believe that those products are obselete.
No shade on keeping using what is working. I was moving from Windows to Linux Fedora so I was in the market for a new editor. VSCode just wasn't working for me any more.
I considered a bunch of options, including vim or neovim or lazyvim, emacs, newer projects like zed. LLM gave a few more I can't recall including helix and Kate. There are so many good options these days, we're all spoiled for choice.
But the main thing is, and YMMV, I am not writing a lot of code anymore. I'm mostly reading/searching/navigating. So all of the powerful editing features are lost on me. No editors really match my current workflow, they all have too much.
So this was an opportunity to try something out, to experiment. See if I could do the real-deal vibe coding thing and judge the result. I just said "I want it to do ..." and then a few minutes later it did. I repeated this until it did enough to use as my primary editor.
I don't recommend it for anyone else, nor do I expect people to agree. Just describing my thought process.
What features did you end up implementing? I assume tree-sitter based highlighting, lsp, and maybe fuzzy search? Did you implement anything different that you didn't get out of existing editors that you tried?
Very few features on purpose. Every editor I tested had all the features I added and more.
It is worth noting that KTextEditor is a fully-featured library. Like, line numbers+gutter (for eventual git status icons), undo/redo, save, warn on exit for unsaved changes, syntax highlighting, color theming. It does 95% of what we'd all call "editing". But it doesn't do things like tab interface, project explorer, terminal pane, output windows, etc.
What the library didn't have were LSP features, of which I only implemented a few (error squiggles under things that fail the type check, go to definition). Notable absent are completions and hover features for things like help. I also only added (and tested) LSP servers for typescript, Rust and Go.
My plan has been: do as little as possible until I need something, then ask Fable to add it.
edit: I guess one thing I added I didn't see everywhere else was a built-in Markdown preview. But many editors have that (VSCode definitely does) so it isn't special.
Not a criticism just an interesting sign of the times that this is ambiguous and before vibe coding it would have been obvious from the context which you mean (deliberately minimal) but now it could just as easily mean that Fable implemented features without asking you
I don't understand why you'd want to get an LLM to wrap up a text-editing library in what sounds like a pretty straightforward way, when there are already text editors using that library.
The reason I'm making one is because I have a whole separate idea about the design and an at-least-somewhat-distinct one about the editing paradigm.
I think you need someone sufficiently experienced to give you the tour of what's possible in Emacs. Search is what sold it to me and I have never seen anything close to that in any type of software I ever used, and I've been programming for a long time - decades.
When someone showed me just a few ways of performing different kinds of search tasks in Emacs, it blew my mind. Wait a minute. You can search by grouping categorically, with regexp, with sparse-trees, sorted - by recency, alphanumerically, contextually; narrowed, expanded, in a grid-view, in a list, incrementally as you type; forward, backward, wrapped; fuzzy; by out-of-order separator tokens; by scope; by structure; by history; by class; by tree-sitter node shapes; in your browser history, in Google, Wikipedia, GitHub, YouTube, etc. etc.?
And because Emacs is insanely text-oriented it fits amazingly to use with LLMs. Just look at the number of different packages people keep building in it¹. You can query a model anytime, anywhere, I'd be typing some text (like this very comment for example) and then I can start chatting with an agent right there, in the same buffer - e.g. for fact-checking my assumptions. Then I can collapse the irrelevant points and focus on the substance, I can peek into the collapsed sessions individually, or I can open them in an indirect-buffer and start chatting on some specific point there.
In my coding assistant buffer, while typing a prompt, I can use a different model, with different parameters, within the same or different context to adjust the prompt itself. Then I can compare the rewrite changes on the spot - using different methods - line-based or three-way-merge diff, etc.
Or even wilder scenario - I'd be reading some article in a foreign language, I get automatic translation popup for every word, paragraph or selected region - all "smart", all based on where the cursor position is. Then, if I'm confused about a word, I can bring wiktionary² or definition lookup buffer. Guess what? I can start chatting with an agent in that same buffer asking it I dunno, if there's an Arabic influence on the word or whatever.
Because the agents have introspective capabilities, they can easily reach to other buffers, multiple agents working in parallel can empirically analyze the state of things, you basically get orchestration pretty much for free - it's just a matter of building proper skills.
I don't know what and how you evaluated things, but no other harness tool I've seen in the wild has reached the point of flexibility and malleability level of it. Emacs remains uncontested king of all sorts of text manipulation. It's not an editor, it's entirely something else.
> We live in wild times. I hope everyone is taking advantage while they can.
I dunno, hey. I'm not about to yolo my way for all things that are important. For things that are unimportant I will just use the existing stuff.
The goldilocks zone (things that an irritation, but not important), sure, I'll vibe a little Python/shell whatever, but pre-LLMs, I was already reducing my friction with little scripts anyway.
For example, in a recent comment of mine I posted a little wish script that I created in 2002, to have a simple GUI mp3 player, which I have been using daily since 2002.
You being able / willing to maintain the same routine for over twenty years is not something I want to condemn or anything, but it is IMO a good indication that our lives are very different.
My whole life swifts gears every five years or so. I can’t imagine living in a world where I’d be needing a “script” to handle my “MP3 playing”. Besides vast changes in hardware and OS realities I regularly go from not listening to music for months to listening every day and besides getting those “MP3”s will get tiring because I won’t listen to the same music for years, I want variety, stuff I don’t know. Spotify is the only real option these days. In five years it will be different I’m sure.
If your life’s substrate is so stable and unchanging it supports decade long unaltered daily habits.. Let’s just say it’s not universal.
If we simplify everyone’s life to “just do X unaltered for twenty years” much if not all of modern life’s complexities would fall away. I can see how you can be dismissive of AI; it doesn’t change your underlying reality at all in fact it only introduces noise into your perfectly stable bubble.
Kate is a good editor and it needs more publicity and more extensions. But, in my experience, as far as speed goes, it is slower than Sublime Text in my machine though still tolerable.
I was planning to. It is 100% vibe coded, the first project I did that way. I'm one of those who've been reading all the code in my major projects. But when I got frustrated with editors and off-handed mentioned to Fable something like "I like Kate, but it has way too many option I will never use" it told me that the core part could be wrapped pretty easily (like 50 lines of C++).
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more.
IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
The only thing I miss in emacs is concurrency/multi-threading. Apart from that, it's a complete software for me. Anyone can build it to anyone's liking.
Emacs has primitive concurrency (see Chapter 40, Threads in the Elisp manual), and because it's a Lisp, having nice concurrency is just a matter of programming.
I still don't see a point in switching from Sublime to VS Code. If I need to SSH in to my server, I have options there. But Sublime does everything I need it to do and it does it faster and cleaner and just better than the alternatives.
At this point the main advantage VS Code has is its ecosystem. I tried to switch back to VS Code a while ago but most of its plugins are outdated / haven't been updated in five years. It's not the whole story of course, but it just feels like it's no longer able to keep up.
In hindsight, part of me wishes I stuck with it for longer. I enjoyed working in it in a way that later editors didn't capture. That said, counterpoint, that was when I wrote a lot of JS in the early NodeJS days, when things like typing or even cmd+clicking on references didn't reliably work because there was no standard module system. Memorizing filenames and the like was still important then.
When I saw the title, I thought this is about a native editor. A noble pursuit.
As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
A text editor is very personal to your use-case and experience, which is why not everyone likes any particular editor.
Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it.
But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
> “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk.
My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor.
But then
> I’m good at building garbage!
I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.
Text manipulation isn't just about creating content - it's also about how you consume and interact with it. Just because text appears in a different app, with a different format, or different fonts and colors doesn't mean your editor shouldn't be easily grab it.
While typing text in my editor, I can:
- Read the list of urls on a webpage in my browser
- Check if any links lead to HN discussions
- Search for text on a page, switch tabs, or list urls of open tabs
- Search across all open tabs for a pattern
- Control YT vids - rewind, change speed, pause, mute, transcript, etc. - handy when watching and taking notes.
I can capture any area of my screen and have the text OCR'd directly into a buffer. Even grabbing a code snippet from a Slack thread only takes a single keystroke. None of these apps have "compatibility layer" or RPCs or designed to talk-to-one-another. The only shared property they have is text.
Vendors are designed to keep your text a hostage, that's why whatever text-editing system you choose, it should have means for reaching out and extracting text from anything you want. And that is not a "solved problem", not for everyone.
I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
In general, I find that good defaults are rather undervalued and downplayed in the FOSS world.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
Defaults really shouldn't change. Each time I upgrade my OS, I get a new version of vim, and have to add more
Until about 2022 this was fine, then they introduced things like shifting the scrolling window, breaking mouse support, I think changing search to highlight text etc.
That's fine, but that means everytime I run it on any machine I have to now deploy a vimrc to fix it.
(I think I noticed the regressions starting in vim 8)
You speak from my heart. How many years did it take Debian to activate syntax highlighting for nano? Is the bash history still very short? So many low hanging fruits.
Same with no screenshots on github projects (For GUI projects)
The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them.
Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug.
I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
Exactly, this my point. If you want to make a great editor, the proper thing to do is start from a good base. Start from emacs and make something like doom emacs or spacemacs, etc. Or start from vim or whatever. Text editing at speed is a solved problem. It's just 'not-invented-here' syndrome. I admit that base emacs may not be everyone's cup of tea... that's fine. Just download one of the many pre-configurations.
Because very few people actually care about the things that emacs has to offer.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.
Because Emacs is not a text editor, it's rather a text orchestrator. And Emacs Lisp is specifically text-oriented, unlike most other Lisps that are data-oriented. It fits incredibly well for LLM-flows. I'm surprised how it remains enormously flexible even though my workflows change every day. The way how I used LLMs last year vastly differs from a few months ago and totally unlike of today, yet bending Emacs never hits the ceiling.
If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.
work amazingly well, almost perfect. I have not see anything come close to what you can do with emacs and the easy to which ai can be integrated and slotted into emacs.
> Because very few people actually care about the things that emacs has to offer.
Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine.
> everyone's environment and tooling ends up becoming incompatible with each other.
It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts.
> Tools like VS Code do the job
Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it.
You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem.
Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.
They jump to such tools, because they are not that invested in making and having the optimal tool for their job, and don't want to spend time setting things up. Especially, not in their own time, if they even do any projects in their own time at all. Lots and lots of people in IT are not that dedicated or passionate about the work.
Also another reason for having a single tool for a whole team: I can go to my coworkers desk for pair programming and have the same setup. I know the shortcuts, everyone has the same "run configurations" (start app, remote debug etc.), starting gradle tasks from UI, git comment style.
Counterpoint: when you go to a coworker’s desk you shouldn’t be touching the keyboard or the mouse otherwise they are just watching you do their work. You should have them come to your desk if you want to be the one running the show. Everyone can have their own environment and they translate what you say to their own methods and it helps them learn.
If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it.
It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).
People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.
> But I don’t think it is meaningfully slower in practice
It's all relative and perceptional, no? It really irks me that when you grab a freshly installed VSCode and install just a single extension for vim-support, there comes a palpable typing latency. Just like that. I currently use about 300 packages in Emacs. I can't ever imagine even attempting half of this number of extensions in VSCode. Would it even start?
using a js engine is anything other then a selling point IMO. I don't hate javascript but sure hate the ecosystem and the tendencies of js or ts developers today. I would not want that approach in my editor at all. elisp and js actually share some things in common and their is no reason a developer would struggle to learn elisp and once they do they will probably like it and the very light weight emacs rendering system, everything is text is a fantastic paradigm for a text editor or an IDE. web technologies like Html/js are actually too complex and can do things you don't actually want your editor to do when rendering bits of interface. I want text and nothing else and I want to hook into text renders easily and without having to worry about timings asyncs and other features of the modern web interface. It's that emacs is simpler and understands that one does not want everything a modern browser can do.
VSCode's problem isn't that it's slow, it's that it's bloated. It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.
I just tried opening a 730 MB file in both and VSCode's usage was just around 2 GB while Sublime's usage (fresh install) was over 3 GB. This is even with my normal VSCode extensions enabled (91 currently).
I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.
The monorepo I work in has 2-5x as large (depending on how you count) and I don’t see crashes or major performance issues. Even when bloated with plugins (testing, GitHub PRs, formatters, copilot, vim emulation, codelens turned on, etc). And I have an older presumably slower Mac.
That’s easy. Because if they accept that emacs is good enough, they have to then accept that probably whatever thing they’re building is almost certainly worthless.
26 different browsers all based on Chromium, 127 different “observability platforms” etc.
So so much redundant rehashed stuff. We can’t accept that though, THIS TIME it’s going to be great and amazing and we’ll get a huge investment and sold to a huge company for millions.
I’m not suggesting that it hasn’t been a huge leap in computing and software in the last 40 years.
But we need to have faith in new being better to keep going. That’s why the new hotness is always so popular.
The interface of text editors has not substantially changed since the time of interactive editors like VIM and emacs. Line editing is an entirely different paradigm. If you are actually going to change the paradigm with which we edit text away from the grid of characters and cursor approach, then by all means, go ahead and write your own. But if you're just making yet another text input pane, then vim and emacs have that problem solved.
You are talking about vim AND emacs but they have completely different approaches, I wouldn't call that solved?
If instead of general text editing we talk about specialized editors (for example emacs for lisp or powerful IDES) they're gonna beat vim or emacs any day (vim is never going to be better than emacs at writing lisp).
Whichever you want. There's a million text editors today because people have different approaches. I'm not criticizing having different approaches. I'm criticizing people who start writing their own text editor instead of just building off of established platforms.
You're just avoding the same question - why not build off the established platforM - which one, though? Why not VSCode, which is also an established platform?
I always wanted to learn emacs, but I never do, because while I don't know it using it doesn't pay off. I did the tutorial at some point (I mean great that it exists) and now I can move around and close the editor, but that's the same I can do in nano, so I keep using nano.
That’s how you start with emacs but as you need to do more complex actions emacs will be able to support you so your skills will grow if you keep using it.
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
Ah ah I'm also a NEdit fan. Still using XNEdit at times (the version that supports UTF-8, https://github.com/unixwork/xnedit ), because I've written so many small tools in its weird built-in language.
For several years I've even hosted the nedit.org website :)
I still use nedit pretty much daily whenever i want to note something down - basically kinda like Notepad (though obviously nedit is much more featureful... not that i use the extra features though). Win+R (my Window Maker shortcut for showing the Run dialog) -> nedit is something that i do pretty much automatically when i want to take a quick note.
This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
Can't say I miss nedit. But it was alright for the mid nineties when I used it on university workstations (a mix of Sun, HP, and SGI hardware). I also got into Jedit for a while. Nice editor and the plugin system it had was pretty advanced for the time. This before we had the option of using something like javascript to do the same kinds of things (like vs code and other editors now do). Java had the ability to dynamically load jar files for plugins at run time.
These days I use VS Code which is more than fine for my needs and it of course has a very rich plugin ecosystem. I never really got into vi, Emacs, or other terminal editors. I can use vi in a pinch (on remote servers when there's nothing else). For most programming I prefer full IDEs. (intellij for the last few years). Or at least I used to; these days it's mostly agentic coding tools doing the editing for me.
Hey, greetings from another former nedit user. It was my refuge from emacs on my 1997 redhat setup as I was stumbling around learning the ropes (I had to keep referring To my "Linux in a nutshell" book to remind myself how to open, save & quit in emacs)
Nedit was a godsend, until I decided to look into that other weird editor (vim) that I kept hearing about (circa 1999 or so) ...
I loved nedit back in the day. I wrote my entire PhD thesis in LaTeX using it. I think the only reason I picked it over emacs (which I was using for coding) was that the text line wrapping was sane out of the box.
In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt:
* <textarea> - plain text editor working with single text node.
* <htmlarea> - WYSIWYG editor working with a DOM tree.
* <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1].
<plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>.
All editors support ::highlight - to style fragments of text without the need to change underlying DOM.
<plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler:
I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch.
I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS.
I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.
I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]
It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.
The problem with writing an editor if you intend to use it for coding, is not the text editor itself, that's rather simple. The problem is code completion and syntax highlighting. Then whatever system you try to implement becomes just as bloated as the bloatware you're trying to replace.
In my mind, my computer is pretty beefy: 2.8 GHZ I7 with 16GB of ram. Yet, vendors like Adobe figure out ways to consume all available resources and make performance complete trash.
Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do.
Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.
It's an amazing project but I always found the docs lacking. Maybe you'd have to sit down with the code for a while or ask AI to explain it, but there were concepts, like "facets", that seemed crucial but were never really explained. I also found the way the docs sites were structured to be really frustrating and confusing - it always felt like there were pages missing and I was never sure if I was on the right page for the thing I was trying to read about (or even on the right site, as it's split into multiple projects).
It takes a bit of time to get used to the abstractions, but I think it is worthwhile. To make a minimal working text editor you will only need a little surface of API (covered in the system guide [0]), but to do this by yourself you need to know a lot about browsers' internal working and their undocumented quirks, which is much more overwhelming. (you can glance over `@codemirror/view`'s commit history to see what I mean)
the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.
Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
I was hoping for this to end with "I wrote emacs, and Karl wrote vi."
Hah. Those were some of the screen editors we complained about. Emacs was popularly said to stand for "(e)ight (m)egabytes (a)nd (c)constantly (s)wapping". (8 MB is small by today's standards, but back then it was big. I believe CITHEP's VAX 11/780 was either 4 MB or 8 MB). I don't remember what we didn't like about vi.
At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix.
If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor".
This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee.
Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).
If Rob Pike is in the story, it happened like yesterday.
[flagged]
It's amazing just how many stories of Rob Pike seem to show him being both a dick and wrong
I kinda think this is the story of "Oh someone wrote a screen editor -- that's the 10th time I heard from other people".
Like, if you write a text editor nowadays, my thoughts would probably NOT be too different, except that 1) I wouldn't speak out, and 2) I'd congratulate you, for real, because this world doesn't give ordinary people good time.
Yeah, my thought when seeing the title of this post was "everyone should build their own text editor". You can start with a couple of hundred lines of code. Not everyone will be happy using their own editor for very long, but it's surprising how little code you can get away with when it's your own and the (many) bugs left in it at any point are the ones that don't annoy you enough for you to spend time on.
My own is absolutely full of bugs and missing features, and probably a real pain to everyone else (to my knowledge only one other person has actually tried to seriously use it - I mostly discourage other users), but that's okay: It has the features I care about, some of which are entirely useless to everyone else. It started because I realised my Emacs config was big enough that I could write an editor in fewer lines.
Yeah, I think it's good to dogfood one's own program. It's just...we are so short of time. We are not the lucky few who could actually pull it off, lol.
There is a correlation between having strong opinions and sounding like a dick. But also between having strong opinions and having impact.
Luckily there are also people who manage to have impact while giving out a different vibe
There is also a correlation between having strong opinions and just being a dick.
Imagining yourself the next Richard Dawkins is a fulltime occupation for a lot of smart kids.
Sounding and being are not the same thing. I don't want to insult Mr. Pike and claim he is a dick just because how some of his quotes sound.
> Sounding and being are not the same thing.
I'm familiar with his stated opinions regarding both generics, and syntax highlighting. They check both the "sounding" and "being" boxes quite nicely.
Dude has worked on UTF-8, Plan 9, and a very popular language despite its flaws.
I am not accomplished enough to judge him. Nor have I had the pleasure to meet him in person to pass any judgement.
I don’t get this obsession with tone policing, probably borne of corporate tendency towards blandness and inoffensiveness. The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
> I don’t get this obsession with tone policing,
That's weird, considering I was saying he was wrong about something. That's not tone policing? The breathless hero worship in your comment is ironically a much more insidious form of tone policing.
> The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
When you grow up, you'll (hopefully) learn that "being loudly and confidently wrong a lot" and "being unpleasant to work with" are not in fact correlated with any particular metrics of technical success, nor are they part of being an "interesting person". Quite the opposite in fact! (Although TBF it does correlate pretty well with certain measures of "success" and longevity in business and large organizations.)
I don't actually know very much about Rob Pike, but the two issues I've heard his opinions on, they were both wrong and poorly argued. I appreciate you don't think I should be able to say this, but I don't think your tone policing is appropriate for this web site.
He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.
> He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.
It is more nuanced than that. Created Go because:
a) C++ deemed excessively and unnecessarily complex, overloaded with features, increasingly difficult to manage
b) Very slow compilation times
c) Wanted a language with built-in concurrency (neither C++ nor Java qualified)
d) Enable fresh-out-of-university team mates to be effective
e) provided a Plan 9 like cross compiler using the Inferno tooling to target any supported platform, out of the box.
its too bad they basically gave up the core of the idea and added generics. in a terrible way none the less
To be fair Java was created in a world where you'd run hundreds on services on a single server, run them in application server with a persistent JVM running.
Now with containers, running Java apps in containers isn't great because of that JVM layer. Memory management, JVM boot time, etc.
There are many things I dislike in Go as a langage but create a high level language that compiles to native makes sense in the cloud hosting/containers world.
I mean, I don't think there's nothing intrinsic to the JVM design on paper that requires this memory model. Just to the specific extant JVM implementations out there.
I haven't kept in touch with what has been happening in the Java world since I stopped working in it (uh, probbly 15 years ago) but you'd think someone would have come along at this point and created a lighter weight JVM solution that starts faster and manages memory in a more container-friendly way.
Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things.
> Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things.
s/software engineering/running a business.
I'd much prefer that the people building the bridges and planes I use, or the staff at the hospital I visit, have procedures in place to prevent them from "making a whoopsie" than the space to be creative or interesting. Even if they enjoy their job less.
The good news with software engineering is that unlike building a plane or running a hospital, nobody is stopping you from making your own projects and being creative and interesting as you want!
Yea, it's too bad that "making whoopsies" has become such a common occurrence, treated so casually, in what is made out to be a serious engineering discipline.
I mean, all engineering disciplines seemingly build in for margin of error / tolerances. e.g. Bridge, etc. are often overbuilt in case of faults in materials or expected circumstances.
I do agree our profession grapples with complexity in bad ways though.
[dead]
When he said the average programmer is too stupid to program in a brilliant language, I don't think he was referring to C++. I think he was referring to non-mainstream languages that require totally different ways of thinking (there are many, and I don't know which ones he had in mind, so I won't list any examples). So he designed Go to be very familiar to average programmers, instead of embracing more powerful ideas (which average programmers would have a hard time with).
That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language.
For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
I'm not sure what he meant by "brilliant language", but he was working in C++ and was frustrated with it when he decided to create Go.
> Back around September 2007, I was doing some minor but central work on an enormous Google C++ program
> I actually tried and failed to find a way to bring the ideas to C++
> Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Honestly could you blame him for not liking Java in 2007? Between the many layers of abstractions the frameworks used, the exceptions and the sluggishness to compile it was not a compelling stack
Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point.
Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds.
The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago.
My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.
Java and the JVM does show its age specifically in one era, and that is its OO-dogmatism which it inherited from the 1990s OO wave (i-was-there-gandalf.gif). Even the opcode set in the VM reflects this everything-an-object mentality.
While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.
When the Java people showed up to Python, they brought a bunch of that FrameworkFactoryItis with them, it was looking pretty bleak for a couple years. The culture that springs up around a language is as important as the language itself, even more so. It spreads to the libraries, and in turn the applications.
If average Google programmers are too stupid to program in C++, what kind of qualities are needed to get good at programming in C++? Like 140+ IQ? Or one needs to really sit down, think through, slow down, which is against the "velocity"?
He's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent.
Source: worked there.
That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact was barely used at Google when I was there)
I don't even know what actual production systems Pike ever worked on, before being given carte blanche to go off and make a new programming language to supposedly fit that niche?
In any case, Go is an insulting language to work in, which is not surprising since its origin story seems to involve insults.
Thanks for sharing. Do you mind to share a bit more about your observation and experience with C++ in Google? I'm just curious what kind of guidelines and practices produce better C++ code, because I have used C++ in my side projects, but I found it difficult to command -- it was always like handling a lot of dishes without breaking any -- that's why I talked about IQ.
And when you said "before being given carte blanche to go off and make a new programming language to supposedly fit that niche?", did you mean that (https://go.dev/talks/2012/splash.article#TOC_4) is not justified? I'm just curious.
C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite well.
Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...)
But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world.
As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d).
And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems).
The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool.
I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial.
Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.
FWIW that is exactly what happened, to some degree.
And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.
The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)
I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point.
It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.
https://github.com/anthonyu/Sizzle/blob/master/docs/sawzall-...
Ah, ok, I worked a bit with Sawzall. It was fine.
He also doesn't like C++, that was the main reason, note that Plan 9 and Inferno contrary to UNIX, also don't do C++.
Bullshit. He describes the actual reasons here: https://go.dev/talks/2012/splash.article#TOC_4.
And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?
They are probably referring to what Rob said in a presentation.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.
Rust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think).
I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another.
I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go.
Closest to this out there might be OCaml, I dunno. Maybe Swift.
> Rust development was already in the air a bit at the time that Go made its debut.
Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
Using explicitly checked errors instead of exceptions was a considered design choice and is well explained in the Go literature. It may not be to everyone's taste, but there are reasons for it. One of those reasons is how often very normal flow control is shoehorned into exceptions when they are available.
Rust with a GC would give you this.
You might like https://arxiv.org/abs/2504.01841v4
Ah, well, I take it back then. Sorry dist-epoch!
Here's Rob's editor (or at least one of them): https://en.wikipedia.org/wiki/Acme_(text_editor)
Here is another one: https://en.wikipedia.org/wiki/Sam_(text_editor)
I have used both editors quite a bit and did like both of them.
Those were both amazing but so very niche.
Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text.
I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.
The browser-standards-or-bust moment has past, hasn't it?
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
So we take a web browser and trim it down to only ever show a single <textarea> element you say? That's what I'm taking away from this. All the hard work for accessibility is already done then right?
> So we take a web browser and trim it down to only ever show a single <textarea> element you say?
I was saying if the goal is "text editor," the web platform is the wrong foundation entirely
[dead]
Seems to me that in the short term everybody screams “DO NOT OPTIMIZE THAT CODE”, in the medium term everybody shrugs “buy a new computer”, and in the long term everybody gradually migrates to the solutions that optimized that code.
I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever.
The idea that optimization matters less over time is short-term thinking.
It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
In the longer term we regress and start running an entire web browser to run a text editor in javascript
Casey Muratori has an interesting talk about how that narrative (“premature optimization is the root of all evil”) came to the mainstream narrative
https://youtu.be/hpj6r6CjJf8
> The idea that optimization matters less over time is short-term thinking.
The more you think about things and the deeper you investigate, the closer you get to realizing that most aphorisms, advice, and even "facts" are a combination of best-effort philosophy and selection biases from the lowest common denominator. Add in the Barnum effect and you end up with an ocean of inconsequential platitudes being parroted by every Tom, Dick, and Harry.
It's very difficult, requires active effort, and goes against human nature to act rationally. Most people don't even want to do it.
Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.
Yes, but...
On one otherwise tranquil morning Master Foo's meditations were disturbed by cries of distress.
Finding that they came from one of the novices, he inquired "What is the difficulty here?"
The novice replied, "I am frustrated by my tools. Every day I must use many different editors because neither Emacs nor vi nor any of these other random editors has all the features I require."
Master Foo nodded. "How," he asked, "would a master of the Great Way resolve this difficulty?"
The student thought for a few moments, then replied. "Well, it's obvious. I will write the best editor ever. It will do everything I need. It will do everything everyone needs. And the world will be a better place because..."
The novice's speech halted as Master Foo rapped him sharply across the back of the head with his staff.
"Um. Master?" the student asked, rubbing the back of his head gingerly. "In what way have I erred?"
"Fool!" said Master Foo. "Do you think I want to learn yet another editor?"
Upon hearing this, the novice attained enlightenment.
—from The Rootless Root (https://www.catb.org/~esr/writings/unix-koans/index.html)
Yes, but ...
Sometimes there are genuine reasons to build a text editor. It's really hard to build a full WYSIWYG graphics editor without modelling text layout yourself, especially for more advanced work like properly curving the text.
Every coder/developer/programmer/software engineer should write a text editor at least once.
There are two possibly conflicting lessons from this koan:
a) the world doesn’t need another editor
b) if you build an editor, it should have an intended audience of one: yourself.
The implementation is usually pretty ugly, actually
I implemented a pretty simple iOS/macOS text editor using TextKit 2, and it was astonishing how many hacks, workarounds and manual implementations were needed to support even the most basic features.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.
That is exactly it. You know what an engineer you are making a system as complex as that? I don't know your codebase but I'm quite aware of TextKit and I can see what a hard and consuming job you must have done. I wish I could see your editor too.
Thanks—I might return to it and open source it soon… It was a pre-Claude Code project, and it was hard to feel any momentum. It's basically a note-taking tool for capturing quick one-off notes in Markdown, but it stores a lot of surrounding metadata (location, any current calendar events, device type, etc) in the YAML front matter. It feels like it would be even more relevant in this era, but there's a lot of work to do on the UI.
I actually built a fully featured text editor with Codex last month for a GUI toolkit I was building from the scratch. It worked quite well. You should give it a try. Perhaps you can offload much of the refinements to the llms now
I am surprised- I reimplemented Notepad for Windows CE and it was pretty much a wrapper around a standard Windows control. It was just a couple of pages of MFC code I believe.
It probably depends on what you're trying to do; I needed Markdown styling and Markdown-aware behaviors (e.g. when you hit return after a list item, indent the same amount and add a new list marker), context-aware nesting (hit Command-[/] to indent/outdent), hotkeys for heading levels, and so on. Between keeping the attributed text styles correct, properly grabbing the right text ranges to operate on, and doing it all in undoable transactions, it became a handful.
[flagged]
Don't stress about it. The other day there was a thread about public bathroom descriptions and someone said "wow this has a countdown timer before the doors automatically open, how stress inducing" and I wrote "shit or get off the pot".
Now overall it's a well up voted comment but occasionally can see someone taking it down a point. What a psychological mystery. A normal person sees a humorous quip and either chuckles or ignores.
So a down vote is what.. someone offended by mild profanity? Someone who perceives me (correctly I guess) as not being empathetic to bathroom anxiety.
Point being - who cares. Make a post you think would be valuable for some reason (funny, informative) and move on. Someone is going to take issue with everything and that's just the beauty of the diversity of life.
Sometimes people down vote for no reason. Unfortunately, when one complains about it, they look like a whiner.
That's because they are whining about worthless internet points.
They're asking about a reaction. "What did I say wrong?" is a valid question IMO, even if wrong is subjective, it's part of the question.
Yes thank you! Wouldn't you be confused to see someone getting offended or angry that you have said text editors are beautiful things?
> Wouldn't you be confused to see someone getting offended or angry that you have said text editors are beautiful things?
Yes perhaps, but that doesn't mean I need to care why or that I can demand someone explain themselves.
Let it go and you'll feel better!
Downvotes and flags are used for narrative control
I just assume that downvotes without explanation just mean that I am right and that has somehow made someone unhappy.
Unless I've been deliberately bait-y, which does sometimes happen, of course.
Sometimes I reread later I realise that I've come across in an unpleasant manner that I did not intend, or I misunderstood and my comment is irrelevant, necessary, or occasionally just plain wrong.
The real fun comes when you divide the audience: a few of my fairly negative comments around AI have bounced between -1 and 1-or-2 for days after posting, as some hate it and down vote then others see that as unfair and upvote, almost all without leaving any comment about why they agree or disagree (with either the content or my style).
Hah. Yes. The one-dimensional up/down mechanism leaves a lot to be desired. Your response could be so wildly engaging that literally everyone on HN has voted on it; so controversial that the masses and the bots are evenly split between loving and hating it; and so immaculately well-written that no one can think of anything to add or to counter it with which wouldn't embarrass themselves. That's usually what I tell myself after I get a single downvote and no reply ;)
I think eventually HN should see something getting a lot of votes and count everything as an upvote. (presumably if it is bad long before then a mod should have noted and removed the bad post)
A word of unsolicited advice: HNers are a prickly lot and will downvote without explanation because you stepped on some unknowable pet peeve of theirs that probably nobody else in the world shares. This happens all the time but you likely only notice when you happen to get downvoted before any upvotes and end up at 0 or -1. If your comment is reasonable, it will usually come back up.
But complaining about downvotes will certainly earn more of them.
I always blame it on the HN UI, especially on a touch device. The up/down vote arrow is a pretty small target and once you hit it, the arrows go away with no visual indication of which way you voted.
If you look close there is either a unvote or undown added to the line. However that is easy to miss. I've learned to always check that line on a touch device because there is no way to consistently hit the tiny arrow correctly (at least not for my body)
Don't forget the post score is a balance of up votes and down votes. This mean 2 down votes and 0 up votes registers the same (-1) as 10 down votes and 8 up votes (-1).
So there's no sense treating it like the community has forsaken you.
Thats a good point to highlight.
If the purpose of down votes is to guide discussion away from uninteresting or counterproductive paths, then it also scoops up divisive comments.
I suppose divisive comments are potentially disruptive if they are particularly flamey. But it seems like they deserve to be distinguished from more objectively negative comments. If the raw up/downs were exposed it would be interesting to experiment with this in the front end.
I'm pretty sure that downvotes from some users, perhaps those at a given karma threshold, count twice. I've seen quite a few posts that aren't otherwise attracting a lot of attention go straight from 1 to -1 more-or-less instantly, or from 3 back to 1.
It's also possible that they have experimented with fuzzing votes like Reddit does.
Either way, they don't seem inclined to disclose how it works behind the scenes. The Kremlinology of Hacker News is half the fun.
Indeed, I'm basing my statement on observation, I don't think they've ever disclosed exactly how the math works.
Don’t forget the old “downvote the other comments so mine goes to the top “ trick.
All your best stuff will get downvoted by at least somebody eventually. For some reason, that somebody always gets in early enough that you notice.
I quite often upvote comments I disagree with that have been downvoted for no apparent reason. Sometimes I vouch for flagged comments for the same reason too. That said, the last one I vouched for was flagged again and so were all the commentor's other comments.
I don't think that's certain at all. What affects votes is:
1. Being near the top of the page
2. Having a downvote already
You can curtail the bandwagon effect by complaining.
> You can curtail the bandwagon effect by complaining.
I've observed the opposite--complaints are often more heavily downvoted than the original downvoted comment. The one I originally replied to is an example, at least at the moment.
Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
On text editor related topics, you should have thrown down the gauntlet and been explicitly clear that emacs rules, vi sucks, spaces are supreme, tabs are terrible, and mixing them is miscegenation. That way you only offend evil people, so their downvotes are delightful. Revel in them instead of whining!
Since you enjoy beautiful machinery, here are some classic clockworks:
https://news.ycombinator.com/item?id=44633225
https://donhopkins.com/home/documents/EmacsRedisplayAlgorith...
https://donhopkins.com/home/archive/emacs/skull-and-crossbon...
https://donhopkins.com/home/archive/emacs/mw/display.c
https://donhopkins.com/home/code/emacs.ps.txt
https://donhopkins.com/home/archive/NeWS/news-tape/utilities...
Very good life lesson. I'm forever thankful.
Seriously. What is so beautiful about text editors? (I am not the downvoter btw).
There is just an insane amount of engineering and work you have to do. Measuring text and shaping fonts is a nightmare, computing chart atlases, having infinite scroll with virtual lines coming to and out of the screen, all the strange data structures to preserve optimized decoration rendering, ropes and ropes (hard data structures), navigating with the keyboard, computing which character interaction is closer to the I-beam when jumping up and down, also caching your previous movements to go back where you actually were. CRDT and atomic editing strategies... There are hundreds and thousands of articles and papers and stuff covering these things. It’s just something we take for granted with so much beauty in the background.
I think you are over estimating it. Sure unicode support is a hell hole. But if you stick to ascii, it is not very hard, that is including syntax highlighting. virtual lines ....I don't know about CRDT or atomic editing though...
It's unfortunately all too easy to hit the downvote arrow when you're aiming for the other one, especially for people using touchscreens.
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
i didn't downvote it but I thought it was pretty empty. "how do i love thee, let me count the ways" has been done before, and his love was more interesting than that you like text editors generically, and you don't mention anything you like. I'm not in favor of more poesy in tech circles.
i like text editors but I feel they contain "everything but the kitchen sink" (if you know you know) and that makes them somewhat impenetrable and difficult to modify and bend to new purposes even though they contain so much capability and potential, and the people who do understand them think it's a good idea to drag and drop an URL and have that do a web transaction and download a buttload of text, when what I wanted was just the text... of the url. I'm sure there's some way to turn it off, but instead there should be some way to turn it on. Oh yeah, worse when it's a jpg url, guess what they do with that.
in another direction, the point of markdown was to be editable and readable in source form, not to be a replacement for rendered HTML, but the same people who ruined HTML by overloading it are now fully engaged in ruining markdown by overloading it and making it unreadable in source form.
I literally just got Fable to write me a text editor. Well, I'll be honest, I got it to wrap the KDE KTextEditor library which is like 90% of a text editor.
I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on.
So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration.
Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes.
We live in wild times. I hope everyone is taking advantage while they can.
> We live in wild times. I hope everyone is taking advantage while they can.
Yep, I'm taking advantage of the times by using the exact same tools I have been for years, and if those fail me, I'll pay for one of the multitude of other high quality editors offered by companies who's business it is to make them, so I get back to writing things in them instead of paying even more to companies trying to persuade me to believe that those products are obselete.
No shade on keeping using what is working. I was moving from Windows to Linux Fedora so I was in the market for a new editor. VSCode just wasn't working for me any more.
I considered a bunch of options, including vim or neovim or lazyvim, emacs, newer projects like zed. LLM gave a few more I can't recall including helix and Kate. There are so many good options these days, we're all spoiled for choice.
But the main thing is, and YMMV, I am not writing a lot of code anymore. I'm mostly reading/searching/navigating. So all of the powerful editing features are lost on me. No editors really match my current workflow, they all have too much.
So this was an opportunity to try something out, to experiment. See if I could do the real-deal vibe coding thing and judge the result. I just said "I want it to do ..." and then a few minutes later it did. I repeated this until it did enough to use as my primary editor.
I don't recommend it for anyone else, nor do I expect people to agree. Just describing my thought process.
What features did you end up implementing? I assume tree-sitter based highlighting, lsp, and maybe fuzzy search? Did you implement anything different that you didn't get out of existing editors that you tried?
Very few features on purpose. Every editor I tested had all the features I added and more.
It is worth noting that KTextEditor is a fully-featured library. Like, line numbers+gutter (for eventual git status icons), undo/redo, save, warn on exit for unsaved changes, syntax highlighting, color theming. It does 95% of what we'd all call "editing". But it doesn't do things like tab interface, project explorer, terminal pane, output windows, etc.
What the library didn't have were LSP features, of which I only implemented a few (error squiggles under things that fail the type check, go to definition). Notable absent are completions and hover features for things like help. I also only added (and tested) LSP servers for typescript, Rust and Go.
My plan has been: do as little as possible until I need something, then ask Fable to add it.
edit: I guess one thing I added I didn't see everywhere else was a built-in Markdown preview. But many editors have that (VSCode definitely does) so it isn't special.
> Very few features on purpose
Not a criticism just an interesting sign of the times that this is ambiguous and before vibe coding it would have been obvious from the context which you mean (deliberately minimal) but now it could just as easily mean that Fable implemented features without asking you
I don't understand why you'd want to get an LLM to wrap up a text-editing library in what sounds like a pretty straightforward way, when there are already text editors using that library.
The reason I'm making one is because I have a whole separate idea about the design and an at-least-somewhat-distinct one about the editing paradigm.
> I'm mostly reading/searching/navigating
I think you need someone sufficiently experienced to give you the tour of what's possible in Emacs. Search is what sold it to me and I have never seen anything close to that in any type of software I ever used, and I've been programming for a long time - decades.
When someone showed me just a few ways of performing different kinds of search tasks in Emacs, it blew my mind. Wait a minute. You can search by grouping categorically, with regexp, with sparse-trees, sorted - by recency, alphanumerically, contextually; narrowed, expanded, in a grid-view, in a list, incrementally as you type; forward, backward, wrapped; fuzzy; by out-of-order separator tokens; by scope; by structure; by history; by class; by tree-sitter node shapes; in your browser history, in Google, Wikipedia, GitHub, YouTube, etc. etc.?
And because Emacs is insanely text-oriented it fits amazingly to use with LLMs. Just look at the number of different packages people keep building in it¹. You can query a model anytime, anywhere, I'd be typing some text (like this very comment for example) and then I can start chatting with an agent right there, in the same buffer - e.g. for fact-checking my assumptions. Then I can collapse the irrelevant points and focus on the substance, I can peek into the collapsed sessions individually, or I can open them in an indirect-buffer and start chatting on some specific point there.
In my coding assistant buffer, while typing a prompt, I can use a different model, with different parameters, within the same or different context to adjust the prompt itself. Then I can compare the rewrite changes on the spot - using different methods - line-based or three-way-merge diff, etc.
Or even wilder scenario - I'd be reading some article in a foreign language, I get automatic translation popup for every word, paragraph or selected region - all "smart", all based on where the cursor position is. Then, if I'm confused about a word, I can bring wiktionary² or definition lookup buffer. Guess what? I can start chatting with an agent in that same buffer asking it I dunno, if there's an Arabic influence on the word or whatever.
Because the agents have introspective capabilities, they can easily reach to other buffers, multiple agents working in parallel can empirically analyze the state of things, you basically get orchestration pretty much for free - it's just a matter of building proper skills.
I don't know what and how you evaluated things, but no other harness tool I've seen in the wild has reached the point of flexibility and malleability level of it. Emacs remains uncontested king of all sorts of text manipulation. It's not an editor, it's entirely something else.
¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
² https://github.com/agzam/wiktionary-bro.el
> We live in wild times. I hope everyone is taking advantage while they can.
To do what exactly? Everyone can churn out their own "kinda different but mostly the same" app thing?
> "kinda different but mostly the same"
Isn’t that the description of our whole lives?
To experiment. Given the availability of new tools there is opportunity to try new things.
Yes, so what? Personalized tools are great.
> We live in wild times. I hope everyone is taking advantage while they can.
I dunno, hey. I'm not about to yolo my way for all things that are important. For things that are unimportant I will just use the existing stuff.
The goldilocks zone (things that an irritation, but not important), sure, I'll vibe a little Python/shell whatever, but pre-LLMs, I was already reducing my friction with little scripts anyway.
For example, in a recent comment of mine I posted a little wish script that I created in 2002, to have a simple GUI mp3 player, which I have been using daily since 2002.
You being able / willing to maintain the same routine for over twenty years is not something I want to condemn or anything, but it is IMO a good indication that our lives are very different.
My whole life swifts gears every five years or so. I can’t imagine living in a world where I’d be needing a “script” to handle my “MP3 playing”. Besides vast changes in hardware and OS realities I regularly go from not listening to music for months to listening every day and besides getting those “MP3”s will get tiring because I won’t listen to the same music for years, I want variety, stuff I don’t know. Spotify is the only real option these days. In five years it will be different I’m sure.
If your life’s substrate is so stable and unchanging it supports decade long unaltered daily habits.. Let’s just say it’s not universal.
If we simplify everyone’s life to “just do X unaltered for twenty years” much if not all of modern life’s complexities would fall away. I can see how you can be dismissive of AI; it doesn’t change your underlying reality at all in fact it only introduces noise into your perfectly stable bubble.
Kate is a good editor and it needs more publicity and more extensions. But, in my experience, as far as speed goes, it is slower than Sublime Text in my machine though still tolerable.
I didn't try Sublime on the same machine so I can't compare. Kate is less polished but genuinely a good choice if someone wants FOSS.
I would have no qualms recommending either.
Why you burned all the tokens and energy for something that is out there like 1000 times? I don't think this is the future, would be a stupid future.
do you want to share your text editor?
I was planning to. It is 100% vibe coded, the first project I did that way. I'm one of those who've been reading all the code in my major projects. But when I got frustrated with editors and off-handed mentioned to Fable something like "I like Kate, but it has way too many option I will never use" it told me that the core part could be wrapped pretty easily (like 50 lines of C++).
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
Love this approach, for what it's worth! Thanks for sharing.
I also had Claude write me an IDE: https://github.com/boxed/TurboKod
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
Actually looks really good
Heh thanks. It started as a joke idea, but now it's my daily driver. Especially the review mode is useful now that so much work goes through LLMs.
It's important to share all vibe coded software to poison future LLM trainings!
The author travels the same path that ended up eventually with VS Code.
Reminds me strongly of Marjin Haverbeke's talk at Full Frontal conf in 2011: https://ffconf.org/talks/respectable-code-editing-in-the-bro... - Using Canvas, then contenteditable, and then DOM.
Haverbeke went on to create CodeMirror and ProseMirror.
Fine, I do this since several decades.
I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more.
IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
The only thing I miss in emacs is concurrency/multi-threading. Apart from that, it's a complete software for me. Anyone can build it to anyone's liking.
Emacs has primitive concurrency (see Chapter 40, Threads in the Elisp manual), and because it's a Lisp, having nice concurrency is just a matter of programming.
Recent and related:
They don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)
I used sublime text over so many years. Still find it to be a marvel when it comes to large text files, and how well it still handles them
I still don't see a point in switching from Sublime to VS Code. If I need to SSH in to my server, I have options there. But Sublime does everything I need it to do and it does it faster and cleaner and just better than the alternatives.
At this point the main advantage VS Code has is its ecosystem. I tried to switch back to VS Code a while ago but most of its plugins are outdated / haven't been updated in five years. It's not the whole story of course, but it just feels like it's no longer able to keep up.
In hindsight, part of me wishes I stuck with it for longer. I enjoyed working in it in a way that later editors didn't capture. That said, counterpoint, that was when I wrote a lot of JS in the early NodeJS days, when things like typing or even cmd+clicking on references didn't reliably work because there was no standard module system. Memorizing filenames and the like was still important then.
I still use Sublime Text, is it going to be the new Firefox now?
I mean… they still make sublime text. Works great.
I have a few minor quibbles about sublime, but I still use it for the bulk of stuff.
There really is a fps counter on there.
Is the experiment seriously rendering continuously in a loop?
When I saw the title, I thought this is about a native editor. A noble pursuit.
As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
The beauty of the word performant is that any thing is performant if your expectations are low enough.
A text editor is very personal to your use-case and experience, which is why not everyone likes any particular editor.
Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it.
But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
> Fine, I'll build my own text editor
> “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk.
My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor.
But then
> I’m good at building garbage!
I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.
> Text editing is a solved problem
Text manipulation isn't just about creating content - it's also about how you consume and interact with it. Just because text appears in a different app, with a different format, or different fonts and colors doesn't mean your editor shouldn't be easily grab it.
While typing text in my editor, I can:
- Read the list of urls on a webpage in my browser
- Check if any links lead to HN discussions
- Search for text on a page, switch tabs, or list urls of open tabs
- Search across all open tabs for a pattern
- Control YT vids - rewind, change speed, pause, mute, transcript, etc. - handy when watching and taking notes.
I can capture any area of my screen and have the text OCR'd directly into a buffer. Even grabbing a code snippet from a Slack thread only takes a single keystroke. None of these apps have "compatibility layer" or RPCs or designed to talk-to-one-another. The only shared property they have is text.
Vendors are designed to keep your text a hostage, that's why whatever text-editing system you choose, it should have means for reaching out and extracting text from anything you want. And that is not a "solved problem", not for everyone.
I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
In general, I find that good defaults are rather undervalued and downplayed in the FOSS world.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
Defaults really shouldn't change. Each time I upgrade my OS, I get a new version of vim, and have to add more
Until about 2022 this was fine, then they introduced things like shifting the scrolling window, breaking mouse support, I think changing search to highlight text etc.
That's fine, but that means everytime I run it on any machine I have to now deploy a vimrc to fix it.
(I think I noticed the regressions starting in vim 8)
You speak from my heart. How many years did it take Debian to activate syntax highlighting for nano? Is the bash history still very short? So many low hanging fruits.
Same with no screenshots on github projects (For GUI projects)
The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them.
Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug.
I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
Exactly, this my point. If you want to make a great editor, the proper thing to do is start from a good base. Start from emacs and make something like doom emacs or spacemacs, etc. Or start from vim or whatever. Text editing at speed is a solved problem. It's just 'not-invented-here' syndrome. I admit that base emacs may not be everyone's cup of tea... that's fine. Just download one of the many pre-configurations.
Because very few people actually care about the things that emacs has to offer.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.
Emacs and AI go hand in glove.
Because Emacs is not a text editor, it's rather a text orchestrator. And Emacs Lisp is specifically text-oriented, unlike most other Lisps that are data-oriented. It fits incredibly well for LLM-flows. I'm surprised how it remains enormously flexible even though my workflows change every day. The way how I used LLMs last year vastly differs from a few months ago and totally unlike of today, yet bending Emacs never hits the ceiling.
If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.
work amazingly well, almost perfect. I have not see anything come close to what you can do with emacs and the easy to which ai can be integrated and slotted into emacs.
> Because very few people actually care about the things that emacs has to offer.
Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine.
> everyone's environment and tooling ends up becoming incompatible with each other.
It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts.
> Tools like VS Code do the job
Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it.
You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem.
Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.
They jump to such tools, because they are not that invested in making and having the optimal tool for their job, and don't want to spend time setting things up. Especially, not in their own time, if they even do any projects in their own time at all. Lots and lots of people in IT are not that dedicated or passionate about the work.
Also another reason for having a single tool for a whole team: I can go to my coworkers desk for pair programming and have the same setup. I know the shortcuts, everyone has the same "run configurations" (start app, remote debug etc.), starting gradle tasks from UI, git comment style.
Counterpoint: when you go to a coworker’s desk you shouldn’t be touching the keyboard or the mouse otherwise they are just watching you do their work. You should have them come to your desk if you want to be the one running the show. Everyone can have their own environment and they translate what you say to their own methods and it helps them learn.
This isn’t an episode of NCIS.
If they ask me for help, why should I not give a quick example?
On some hard tasks we sometimes switch to codes.
Must be a cultural thing, I never heard about not touching a coworkers keyboard when working together.
If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it.
It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).
People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.
> But I don’t think it is meaningfully slower in practice
It's all relative and perceptional, no? It really irks me that when you grab a freshly installed VSCode and install just a single extension for vim-support, there comes a palpable typing latency. Just like that. I currently use about 300 packages in Emacs. I can't ever imagine even attempting half of this number of extensions in VSCode. Would it even start?
using a js engine is anything other then a selling point IMO. I don't hate javascript but sure hate the ecosystem and the tendencies of js or ts developers today. I would not want that approach in my editor at all. elisp and js actually share some things in common and their is no reason a developer would struggle to learn elisp and once they do they will probably like it and the very light weight emacs rendering system, everything is text is a fantastic paradigm for a text editor or an IDE. web technologies like Html/js are actually too complex and can do things you don't actually want your editor to do when rendering bits of interface. I want text and nothing else and I want to hook into text renders easily and without having to worry about timings asyncs and other features of the modern web interface. It's that emacs is simpler and understands that one does not want everything a modern browser can do.
VSCode's problem isn't that it's slow, it's that it's bloated. It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.
I just tried opening a 730 MB file in both and VSCode's usage was just around 2 GB while Sublime's usage (fresh install) was over 3 GB. This is even with my normal VSCode extensions enabled (91 currently).
VSCode at least has the excuse of being a full web browser, explaining (but not justifying!) its bloat.
What's Sublime's excuse for needing 300MB to open a text file?
I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.
I do miss the configurablity though
What counts as large? There can be some perf issues if you don’t exclude node_modules and build outputs from search, but I’ve never seen it crash.
It was a mono repo with 30+ projects Most were react apps. I’m going to guess at least 5000 files in the repo.
And yes, node_modules was excluded.
I’m sorry you had a bad experience.
The monorepo I work in has 2-5x as large (depending on how you count) and I don’t see crashes or major performance issues. Even when bloated with plugins (testing, GitHub PRs, formatters, copilot, vim emulation, codelens turned on, etc). And I have an older presumably slower Mac.
I wonder what the difference is.
That’s easy. Because if they accept that emacs is good enough, they have to then accept that probably whatever thing they’re building is almost certainly worthless.
26 different browsers all based on Chromium, 127 different “observability platforms” etc.
So so much redundant rehashed stuff. We can’t accept that though, THIS TIME it’s going to be great and amazing and we’ll get a huge investment and sold to a huge company for millions.
I’m not suggesting that it hasn’t been a huge leap in computing and software in the last 40 years.
But we need to have faith in new being better to keep going. That’s why the new hotness is always so popular.
90% of software is just new people not learning from the past and making/using some new thing.
Get off my lawn.
>Text editing is a solved problem.
I have this sentence so much.
Ken Thompson wrote UNIX using a line-editor (QED), judging by his work does it mean text editing was already solved in the 60s?
The interface of text editors has not substantially changed since the time of interactive editors like VIM and emacs. Line editing is an entirely different paradigm. If you are actually going to change the paradigm with which we edit text away from the grid of characters and cursor approach, then by all means, go ahead and write your own. But if you're just making yet another text input pane, then vim and emacs have that problem solved.
You are talking about vim AND emacs but they have completely different approaches, I wouldn't call that solved?
If instead of general text editing we talk about specialized editors (for example emacs for lisp or powerful IDES) they're gonna beat vim or emacs any day (vim is never going to be better than emacs at writing lisp).
> just a configuration of vim or emacs.
So which one?
Whichever you want. There's a million text editors today because people have different approaches. I'm not criticizing having different approaches. I'm criticizing people who start writing their own text editor instead of just building off of established platforms.
You're just avoding the same question - why not build off the established platforM - which one, though? Why not VSCode, which is also an established platform?
I always wanted to learn emacs, but I never do, because while I don't know it using it doesn't pay off. I did the tutorial at some point (I mean great that it exists) and now I can move around and close the editor, but that's the same I can do in nano, so I keep using nano.
That’s how you start with emacs but as you need to do more complex actions emacs will be able to support you so your skills will grow if you keep using it.
Yeah, but before I am proficient in the more elaborate stuff, there is no reason to use emacs, so I never do it. And there is no tutorial for this.
For the very basic of basic browser based text editors just use this as the URL:
Nice! That's a new one for me.
I still miss NEdit.
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
Ah ah I'm also a NEdit fan. Still using XNEdit at times (the version that supports UTF-8, https://github.com/unixwork/xnedit ), because I've written so many small tools in its weird built-in language.
For several years I've even hosted the nedit.org website :)
I still use nedit pretty much daily whenever i want to note something down - basically kinda like Notepad (though obviously nedit is much more featureful... not that i use the extra features though). Win+R (my Window Maker shortcut for showing the Run dialog) -> nedit is something that i do pretty much automatically when i want to take a quick note.
This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
It's all personal preference
Can't say I miss nedit. But it was alright for the mid nineties when I used it on university workstations (a mix of Sun, HP, and SGI hardware). I also got into Jedit for a while. Nice editor and the plugin system it had was pretty advanced for the time. This before we had the option of using something like javascript to do the same kinds of things (like vs code and other editors now do). Java had the ability to dynamically load jar files for plugins at run time.
These days I use VS Code which is more than fine for my needs and it of course has a very rich plugin ecosystem. I never really got into vi, Emacs, or other terminal editors. I can use vi in a pinch (on remote servers when there's nothing else). For most programming I prefer full IDEs. (intellij for the last few years). Or at least I used to; these days it's mostly agentic coding tools doing the editing for me.
Hey, greetings from another former nedit user. It was my refuge from emacs on my 1997 redhat setup as I was stumbling around learning the ropes (I had to keep referring To my "Linux in a nutshell" book to remind myself how to open, save & quit in emacs)
Nedit was a godsend, until I decided to look into that other weird editor (vim) that I kept hearing about (circa 1999 or so) ...
I loved nedit back in the day. I wrote my entire PhD thesis in LaTeX using it. I think the only reason I picked it over emacs (which I was using for coding) was that the text line wrapping was sane out of the box.
Just in case...
In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt:
* <textarea> - plain text editor working with single text node.
* <htmlarea> - WYSIWYG editor working with a DOM tree.
* <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1].
<plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>.
All editors support ::highlight - to style fragments of text without the need to change underlying DOM.
<plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler:
See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colo...
<htmlarea> and <plaintext> also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation.
[1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext
OT but I really like the design of this website. It's fresh, it's fun, but still easy to read. Love the AI policy page as well.
I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch.
https://pkg.odin-lang.org/core/text/edit/
I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS.
I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.
I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]
It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.
[1] https://github.com/mikewarot/teco
If you want to do this in Clojure, Clobber[0] is a great base to start from.
It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely.
[0] https://github.com/phronmophobic/clobber
The problem with writing an editor if you intend to use it for coding, is not the text editor itself, that's rather simple. The problem is code completion and syntax highlighting. Then whatever system you try to implement becomes just as bloated as the bloatware you're trying to replace.
You don't actually need either of those things for coding. Many, many programmers did just fine without them.
This is just not true at all.
Which part is untrue? That theyre simple applications or that syntax highlighting and code completion are difficult?
In my mind, my computer is pretty beefy: 2.8 GHZ I7 with 16GB of ram. Yet, vendors like Adobe figure out ways to consume all available resources and make performance complete trash.
Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do.
Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
The highlit line and cursor are 1 down from the line it thinks it is editing.
I see off-by-one errors are still a common bug class, lol
EDIT: It's only in the earlier examples.
I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!
Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.
It's an amazing project but I always found the docs lacking. Maybe you'd have to sit down with the code for a while or ask AI to explain it, but there were concepts, like "facets", that seemed crucial but were never really explained. I also found the way the docs sites were structured to be really frustrating and confusing - it always felt like there were pages missing and I was never sure if I was on the right page for the thing I was trying to read about (or even on the right site, as it's split into multiple projects).
It takes a bit of time to get used to the abstractions, but I think it is worthwhile. To make a minimal working text editor you will only need a little surface of API (covered in the system guide [0]), but to do this by yourself you need to know a lot about browsers' internal working and their undocumented quirks, which is much more overwhelming. (you can glance over `@codemirror/view`'s commit history to see what I mean)
[0]: https://codemirror.net/docs/guide/
the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.
Could use a WASM environment to run tests or a companion app that run wrap in a (Podman) container, to be safe, e.g :
I'm not saying it's perfect but took me a minute.