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 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.
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.
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.
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)
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.
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).
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.
> 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?
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.
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.
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.
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 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.
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 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 it 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? I do remain optimistic though, the number of people willing to try Vim and Emacs, instead of succumbing to the status quo, is steadily increasing each year.
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.
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.
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).
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, 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".
Text editors are like mechanical watches or fountain pens. There is so so much beauty in the machinery that makes them. For me, there are hardly any other module that is this satisfying 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.
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.
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.
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)
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 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.
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.
You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod
By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken.
It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP.
For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc)
And then there is me, working on large java codebase with IDEA through remote desktop on wifi, on a 7 year old windows laptop that is slowed down by corporate crap.
It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
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.
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?
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.
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.
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.
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).
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.
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.
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 decisions as a result. The error handling in particular is awful.
> 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.
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 strongly 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.
> 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.
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.
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.
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)
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.
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.
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.
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.
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.
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 :)
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've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard.
Oh God
Not another text editor.
I swear that text editors are to computer engineers what trains are to mechanical engineers.
Or Satisfactory to Systems Engineers
Oddly enough, I've recently started doing a text editor myself. (I'm using Tkinter, and I am implementing a Vim-like editing system with key commands and modes and such, but substantially different from actual Vim.)
So apparently every half-serious coder will write at least one chess engine and a text editor. Any other program type which gets implemented over-and-over again?
I wasn't trying to imply there is anything wrong with these practice projects. I have written at least two chess engines maybe. And I am seriouly considering to write an editor, so, there you have it. I kind of got sidetracked by implementing my own rope...
The single most disappointing fact about (more or less) all text editors on the market today is how god awful their performance is. For most text editors, and when I say most I really do mean _most_, you can very easily start seeing noticeable lag and stuttering when making modifications, or even outright INPUT LAG when entering text. For very tiny buffers <1kB it's a rare occurrence (although bad editors lag there too), but once you start crossing the 10kB size it's dead obvious. For editing buffers >1MB, 99% of them are unusable due to a) writes taking SECONDS (how?) b) scrolling/using the buffer physically lagging out the editor itself. Which is really basic functionality that editors should be able to handle since it's rather trivial to come across a multiMB json/config file. Try a simple benchmark
cd /tmp && dd if=/dev/random of=big_file bs=4096 count=10000
[editor of choice big_file]
This should really be _trivial_ for any modern CPU.
Having written a canvas-based editor with some non-trivial features like Tree-sitter based multi-language syntax highlighting, performance is actually what impresses me the most about VS Code. Maybe my standards are different but I don't think I've ever noticed it lag even on large files.
Large files lagging editors is usually because the entire file needs to be parsed for the editor to know how the syntax highlighting and error reporting should work.
Making that random big_file and opening it and editing it should be trivial under any editor (works perfectly fine under Emacs because it gets opened in fundamental mode, even opening it in hexl (hex editor) mode is fine), opening a 40M JSON file is a different can of worms (because it's a larger file Emacs will offer to open it in fundamental mode anyway, which means sacrificing QOL features for performance).
238 comments
[ 2.1 ms ] story [ 18.8 ms ] threadThey don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)
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.
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.
Same with no screenshots on github projects (For GUI projects)
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)
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)
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.
What's Sublime's excuse for needing 300MB to open a text file?
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?
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.
Get off my lawn.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability.
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.
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.
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 it 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? I do remain optimistic though, the number of people willing to try Vim and Emacs, instead of succumbing to the status quo, is steadily increasing each year.
This isn’t an episode of NCIS.
On some hard tasks we sometimes switch so codes.
Must be a cultural thing, I never heard about not touching a coworkers keyboard when working together.
So which one?
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?
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).
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, 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".
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!
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 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.
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).
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.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.
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)
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.
a) the world doesn’t need another editor
b) if you build an editor, it should have an intended audience of one: yourself.
It's not about the style of cursor, or if rope is used or not. We already have answers to that.
It's about remote editing, LSP support.
It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP.
For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc)
It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
Emacs does start fairly slowly, though, takes about 0.6 seconds.
Is the experiment seriously rendering continuously in a loop?
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.
I was saying if the goal is "text editor," the web platform is the wrong foundation entirely
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.
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.
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.
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
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.
¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
² https://github.com/agzam/wiktionary-bro.el
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.
To do what exactly? Everyone can churn out their own "kinda different but mostly the same" app thing?
Isn’t that the description of our whole lives?
I would have no qualms recommending either.
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
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? :-)
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 have used both editors quite a bit and did like both of them.
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.
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.
And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?
"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 personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate decisions as a result. The error handling in particular is awful.
You might like https://arxiv.org/abs/2504.01841v4
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.
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.
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.
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 strongly 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]."
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)
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-...
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
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 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.
Funny, Ironwood (https://github.com/ironwood-lang/ironwood) explores exactly this space: familiar Java programming without JVM startup, warmup, or GC.
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!
I do agree our profession grapples with complexity in bad ways though.
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.
> 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...
Luckily there are also people who manage to have impact while giving out a different vibe
Imagining yourself the next Richard Dawkins is a fulltime occupation for a lot of smart kids.
I'm familiar with his stated opinions regarding both generics, and syntax highlighting. They check both the "sounding" and "being" boxes quite nicely.
I'm sorry, what does this mean? He can't have bad opinions because he worked on good projects? What's the logical syllogism here?
> I don’t get this obsession with tone policing,
Saying someone is wrong about something is tone policing? Do you know what this means or are you just throwing around insulting terms?
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.
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.
[0]: https://codemirror.net/docs/guide/
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.
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
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.
For several years I've even hosted the nedit.org website :)
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've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard.
https://github.com/joefreeman/aether
Nothing wrong with that, I like to think there are some apps you should probably make yourself, like the blacksmith apprentice making their own tools.
Making that random big_file and opening it and editing it should be trivial under any editor (works perfectly fine under Emacs because it gets opened in fundamental mode, even opening it in hexl (hex editor) mode is fine), opening a 40M JSON file is a different can of worms (because it's a larger file Emacs will offer to open it in fundamental mode anyway, which means sacrificing QOL features for performance).