Rendered at 16:12:38 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
tzs 10 hours ago [-]
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? :-)
bigiain 10 hours ago [-]
I was hoping for this to end with "I wrote emacs, and Karl wrote vi."
tzs 6 minutes ago [-]
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).
LtWorf 10 hours ago [-]
If Rob Pike is in the story, it happened like yesterday.
NooneAtAll3 4 hours ago [-]
and everyone clapped?
socksy 7 hours ago [-]
It's amazing just how many stories of Rob Pike seem to show him being both a dick and wrong
ithkuil 5 hours ago [-]
There is a correlation between having strong opinions and sounding like a dick. But also between having strong opinions and having impact.
Luckily there are also people who manage to have impact while giving out a different vibe
IAmBroom 2 hours ago [-]
There is also a correlation between having strong opinions and just being a dick.
Imagining yourself the next Richard Dawkins is a fulltime occupation for a lot of smart kids.
ithkuil 27 minutes ago [-]
Sounding and being are not the same thing. I don't want to insult Mr. Pike and claim he is a dick just because how some of his quotes sound.
ferguess_k 3 hours ago [-]
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.
dist-epoch 7 hours ago [-]
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.
andsoitis 3 hours ago [-]
> 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
chillpenguin 55 minutes ago [-]
When he said the average programmer is too stupid to program in a brilliant language, I don't think he was referring to C++. I think he was referring to non-mainstream languages that require totally different ways of thinking (there are many, and I don't know which ones he had in mind, so I won't list any examples). So he designed Go to be very familiar to average programmers, instead of embracing more powerful ideas (which average programmers would have a hard time with).
That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language.
For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
eloisant 3 hours ago [-]
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.
sherburt3 3 hours ago [-]
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.
mjr00 1 hours ago [-]
> 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!
ryandrake 31 minutes ago [-]
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.
transdev12 53 minutes ago [-]
[dead]
ferguess_k 4 hours ago [-]
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"?
cmrdporcupine 3 hours ago [-]
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.
mike_hearn 1 hours ago [-]
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.
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.
cmrdporcupine 46 minutes ago [-]
C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite well.
Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...)
But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world.
As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d).
And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems).
The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool.
I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial.
Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
atherton94027 6 hours ago [-]
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
speed_spread 4 hours ago [-]
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.
pjmlp 4 hours ago [-]
He also doesn't like C++, that was the main reason, note that Plan 9 and Inferno contrary to UNIX, also don't do C++.
And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?
tripledry 4 hours ago [-]
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."
I have used both editors quite a bit and did like both of them.
NetMageSCW 2 hours ago [-]
Those were both amazing but so very niche.
kqp 2 hours ago [-]
Seems to me that in the short term everybody screams “DO NOT OPTIMIZE THAT CODE”, in the medium term everybody shrugs “buy a new computer”, and in the long term everybody gradually migrates to the solutions that optimized that code.
I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever.
The idea that optimization matters less over time is short-term thinking.
It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
akersten 10 hours ago [-]
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.
notarobot123 9 hours ago [-]
The browser-standards-or-bust moment has past, hasn't it?
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
snoopen 6 hours ago [-]
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?
pmkary 11 hours ago [-]
Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.
alansaber 10 hours ago [-]
The implementation is usually pretty ugly, actually
bensyverson 3 hours ago [-]
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.
NetMageSCW 2 hours ago [-]
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.
bensyverson 1 hours ago [-]
It probably depends on what you're trying to do; I needed Markdown styling and Markdown-aware behaviors (e.g. when you hit return after a list item, indent the same amount and add a new list marker), context-aware nesting (hit Command-[/] to indent/outdent), hotkeys for heading levels, and so on. Between keeping the attributed text styles correct, properly grabbing the right text ranges to operate on, and doing it all in undoable transactions, it became a handful.
pmkary 3 hours ago [-]
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.
bensyverson 3 hours ago [-]
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.
pmkary 41 minutes ago [-]
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
bitwize 9 hours ago [-]
Yes, but...
On one otherwise tranquil morning Master Foo's meditations were disturbed by cries of distress.
Finding that they came from one of the novices, he inquired "What is the difficulty here?"
The novice replied, "I am frustrated by my tools. Every day I must use many different editors because neither Emacs nor vi nor any of these other random editors has all the features I require."
Master Foo nodded. "How," he asked, "would a master of the Great Way resolve this difficulty?"
The student thought for a few moments, then replied. "Well, it's obvious. I will write the best editor ever. It will do everything I need. It will do everything everyone needs. And the world will be a better place because..."
The novice's speech halted as Master Foo rapped him sharply across the back of the head with his staff.
"Um. Master?" the student asked, rubbing the back of his head gingerly. "In what way have I erred?"
"Fool!" said Master Foo. "Do you think I want to learn yet another editor?"
Upon hearing this, the novice attained enlightenment.
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.
pmkary 11 hours ago [-]
[flagged]
xyzelement 4 hours ago [-]
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.
3 hours ago [-]
ameminator 11 hours ago [-]
Sometimes people down vote for no reason. Unfortunately, when one complains about it, they look like a whiner.
wolletd 10 hours ago [-]
That's because they are whining about worthless internet points.
rootlocus 7 hours ago [-]
They're asking about a reaction. "What did I say wrong?" is a valid question IMO, even if wrong is subjective, it's part of the question.
pmkary 3 hours ago [-]
Yes thank you! Wouldn't you be confused to see someone getting offended or angry that you have said text editors are beautiful things?
andsoitis 3 hours ago [-]
> Wouldn't you be confused to see someone getting offended or angry that you have said text editors are beautiful things?
Yes perhaps, but that doesn't mean I need to care why or that I can demand someone explain themselves.
Let it go and you'll feel better!
ycislost 4 hours ago [-]
Downvotes and flags are used for narrative control
dspillett 5 hours ago [-]
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).
noduerme 5 hours ago [-]
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 ;)
bluGill 3 hours ago [-]
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)
roarcher 11 hours ago [-]
A word of unsolicited advice: HNers are a prickly lot and will downvote without explanation because you stepped on some unknowable pet peeve of theirs that probably nobody else in the world shares. This happens all the time but you likely only notice when you happen to get downvoted before any upvotes and end up at 0 or -1. If your comment is reasonable, it will usually come back up.
But complaining about downvotes will certainly earn more of them.
criddell 4 hours ago [-]
I always blame it on the HN UI, especially on a touch device. The up/down vote arrow is a pretty small target and once you hit it, the arrows go away with no visual indication of which way you voted.
bluGill 3 hours ago [-]
If you look close there is either a unvote or undown added to the line. However that is easy to miss. I've learned to always check that line on a touch device because there is no way to consistently hit the tiny arrow correctly (at least not for my body)
rezonant 6 hours ago [-]
Don't forget the post score is a balance of up votes and down votes. This mean 2 down votes and 0 up votes registers the same (-1) as 10 down votes and 8 up votes (-1).
So there's no sense treating it like the community has forsaken you.
tomxor 4 hours ago [-]
Thats a good point to highlight.
If the purpose of down votes is to guide discussion away from uninteresting or counterproductive paths, then it also scoops up divisive comments.
I suppose divisive comments are potentially disruptive if they are particularly flamey. But it seems like they deserve to be distinguished from more objectively negative comments. If the raw up/downs were exposed it would be interesting to experiment with this in the front end.
graemep 8 hours ago [-]
I quite often upvote comments I disagree with that have been downvoted for no apparent reason. Sometimes I vouch for flagged comments for the same reason too. That said, the last one I vouched for was flagged again and so were all the commentor's other comments.
jasonkester 10 hours ago [-]
Don’t forget the old “downvote the other comments so mine goes to the top “ trick.
All your best stuff will get downvoted by at least somebody eventually. For some reason, that somebody always gets in early enough that you notice.
card_zero 10 hours ago [-]
I don't think that's certain at all. What affects votes is:
1. Being near the top of the page
2. Having a downvote already
You can curtail the bandwagon effect by complaining.
roarcher 7 hours ago [-]
> You can curtail the bandwagon effect by complaining.
I've observed the opposite--complaints are often more heavily downvoted than the original downvoted comment. The one I originally replied to is an example, at least at the moment.
pmkary 11 hours ago [-]
Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
DonHopkins 9 hours ago [-]
On text editor related topics, you should have thrown down the gauntlet and been explicitly clear that emacs rules, vi sucks, spaces are supreme, tabs are terrible, and mixing them is miscegenation. That way you only offend evil people, so their downvotes are delightful. Revel in them instead of whining!
Since you enjoy beautiful machinery, here are some classic clockworks:
Seriously. What is so beautiful about text editors? (I am not the downvoter btw).
pmkary 3 hours ago [-]
There is just an insane amount of engineering and work you have to do. Measuring text and shaping fonts is a nightmare, computing chart atlases, having infinite scroll with virtual lines coming to and out of the screen, all the strange data structures to preserve optimized decoration rendering, ropes and ropes (hard data structures), navigating with the keyboard, computing which character interaction is closer to the I-beam when jumping up and down, also caching your previous movements to go back where you actually were. CRDT and atomic editing strategies... There are hundreds and thousands of articles and papers and stuff covering these things. It’s just something we take for granted with so much beauty in the background.
qsera 3 hours ago [-]
I think you are over estimating it. Sure unicode support is a hell hole. But if you stick to ascii, it is not very hard, that is including syntax highlighting. virtual lines ....I don't know about CRDT or atomic editing though...
CamperBob2 10 hours ago [-]
It's unfortunately all too easy to hit the downvote arrow when you're aiming for the other one, especially for people using touchscreens.
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
fsckboy 10 hours ago [-]
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.
Isofarro 5 hours ago [-]
The author travels the same path that ended up eventually with VS Code.
Haverbeke went on to create CodeMirror and ProseMirror.
holgerschurig 6 hours ago [-]
Fine, I do this since several decades.
I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more.
IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
shuvrojit 2 hours ago [-]
The only thing I miss in emacs is concurrency/multi-threading. Apart from that, it's a complete software for me. Anyone can build it to anyone's liking.
lbriner 4 hours ago [-]
A text editor is very personal to your use-case and experience, which is why not everyone likes any particular editor.
Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it.
But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
stillpointlab 10 hours ago [-]
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.
brailsafe 10 hours ago [-]
> 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.
stillpointlab 10 hours ago [-]
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.
TonyStr 9 hours ago [-]
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?
stillpointlab 9 hours ago [-]
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.
dwedge 8 hours ago [-]
> Very few features on purpose
Not a criticism just an interesting sign of the times that this is ambiguous and before vibe coding it would have been obvious from the context which you mean (deliberately minimal) but now it could just as easily mean that Fable implemented features without asking you
zahlman 7 hours ago [-]
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.
shoobiedoo 7 hours ago [-]
> We live in wild times. I hope everyone is taking advantage while they can.
To do what exactly? Everyone can churn out their own "kinda different but mostly the same" app thing?
hk__2 7 hours ago [-]
> "kinda different but mostly the same"
Isn’t that the description of our whole lives?
lelanthran 8 hours ago [-]
> 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.
shjssusuus 8 hours ago [-]
[dead]
rd07 6 hours ago [-]
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.
inatreecrown2 10 hours ago [-]
do you want to share your text editor?
stillpointlab 10 hours ago [-]
I was planning to. It is 100% vibe coded, the first project I did that way. I'm one of those who've been reading all the code in my major projects. But when I got frustrated with editors and off-handed mentioned to Fable something like "I like Kate, but it has way too many option I will never use" it told me that the core part could be wrapped pretty easily (like 50 lines of C++).
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
andsoitis 3 hours ago [-]
Love this approach, for what it's worth! Thanks for sharing.
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
rfgplk 8 hours ago [-]
Actually looks really good
boxed 7 hours ago [-]
Heh thanks. It started as a joke idea, but now it's my daily driver. Especially the review mode is useful now that so much work goes through LLMs.
wolletd 9 hours ago [-]
It's important to share all vibe coded software to poison future LLM trainings!
brettermeier 3 hours ago [-]
Why you burned all the tokens and energy for something that is out there like 1000 times? I don't think this is the future, would be a stupid future.
I used sublime text over so many years. Still find it to be a marvel when it comes to large text files, and how well it still handles them
cwnyth 10 hours ago [-]
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.
Cthulhu_ 8 hours ago [-]
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.
a1o 6 hours ago [-]
I still use Sublime Text, is it going to be the new Firefox now?
mangecoeur 8 hours ago [-]
I mean… they still make sublime text. Works great.
jsymolon 4 hours ago [-]
I have a few minor quibbles about sublime, but I still use it for the bulk of stuff.
mikewarot 2 hours ago [-]
I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS.
I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.
I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]
It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.
When I saw the title, I thought this is about a native editor. A noble pursuit.
As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
criddell 4 hours ago [-]
The beauty of the word performant is that any thing is performant if your expectations are low enough.
rf15 5 hours ago [-]
> Fine, I'll build my own text editor
> “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk.
My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor.
But then
> I’m good at building garbage!
I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
wmwragg 3 hours ago [-]
For the very basic of basic browser based text editors just use this as the URL:
data:text/html, <html contenteditable>
nottorp 11 hours ago [-]
There really is a fps counter on there.
Is the experiment seriously rendering continuously in a loop?
10 hours ago [-]
owenbrown 1 hours ago [-]
Check out Quick Memory.
It’s a stripped-down, faster Obsidian. All rust, not html.
It’s small (zip < 7MB) and fast (launches in 300 ms, opens Moby Dick in < 300 ms).
Ping me if you use and something is missing.
It’s my daily note-taking app.
emursebrian 3 hours ago [-]
In my mind, my computer is pretty beefy: 2.8 GHZ I7 with 16GB of ram. Yet, vendors like Adobe figure out ways to consume all available resources and make performance complete trash.
Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do.
Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
pmarreck 4 hours ago [-]
The highlit line and cursor are 1 down from the line it thinks it is editing.
I see off-by-one errors are still a common bug class, lol
EDIT: It's only in the earlier examples.
I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!
philippta 6 hours ago [-]
I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch.
How is it possible that Notepad++ still has no Markdown support? Only a few imperfect plugins exist for it and those of us without admin rights on a corporate computer can't install those. Even though Markdown has become an extremely dominant filetype due to AI.
marssaxman 39 minutes ago [-]
"Fine, I'll build my own text editor" is certainly a familiar sentence, one I've uttered several times, but it would never in a thousand years occur to me to take the next step in a web browser. Interesting to see such a different approach to the world: thank you for sharing.
krzyzanowskim 6 hours ago [-]
the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.
utopiah 4 hours ago [-]
Could use a WASM environment to run tests or a companion app that run wrap in a (Podman) container, to be safe, e.g :
> [...] is promising but I’ve noticed strange [...]
In a nutshell, the perpetual experience of writing your own (web) text editor.
alwaysmrno 8 hours ago [-]
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
mr_mitm 8 hours ago [-]
Let's see Paul Allen's text editor
__patchbit__ 8 hours ago [-]
The Moon Landing Project text editors may not have survived
Cthulhu_ 8 hours ago [-]
Frameworks / forums / CMSes to PHP developers
vintermann 10 hours ago [-]
I still miss NEdit.
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
jillesvangurp 5 hours ago [-]
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.
badsectoracula 7 hours ago [-]
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.
dwedge 8 hours ago [-]
This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
It's all personal preference
gtr 7 hours ago [-]
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.
wazoox 37 minutes ago [-]
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 :)
qbane 10 hours ago [-]
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.
gushogg-blake 7 hours ago [-]
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).
qbane 1 hours ago [-]
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)
I never stopped using Sublime Text so I suppose I am cool again.
dkersten 9 hours ago [-]
Interestingly, for me on iOS, all of the examples worked except the textarea one, which didn’t allow me to interact at all.
joefreeman 9 hours ago [-]
> I’m good at building garbage!
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.
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.)
swiftcoder 8 hours ago [-]
For some reason on all the canvas based demos, the text cursor is displayed on the line below where actual text insertion happens (at least on Safari). Canvas-based text editor is definitely hard-mode
neogodless 3 hours ago [-]
Same in Firefox (on Windows).
kris-memoket 4 hours ago [-]
You are truly a very dedicated developer! Thank you so much for your artifacts!
Driftbench 8 hours ago [-]
Been there, done that. It's a rabbit hole, but you learn so much about rendering and input. Good luck!
dvh 8 hours ago [-]
I've been using my own text editor for over decade. Written in Lazarus using SynEdit component. It's trivial.
Sweepline 9 hours ago [-]
All I wanted was proper multi-cursor editing and Emacs keybindings. Gave up and just started a new `src` folder.
samus 11 hours ago [-]
Every time someone has that idea they discover that text editing is hard! Kudos to the author that they considered accessibility as well.
anon291 12 hours ago [-]
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.
xedrac 11 hours ago [-]
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.
cosmic_cheese 10 hours ago [-]
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.
Mashimo 7 hours ago [-]
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)
iso1631 6 hours ago [-]
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)
kodoman 7 hours ago [-]
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)
kstenerud 10 hours ago [-]
Because very few people actually care about the things that emacs has to offer.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
__patchbit__ 7 hours ago [-]
Emacs and AI go hand in glove.
kodoman 6 hours ago [-]
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.
nxc18 11 hours ago [-]
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.
kodoman 7 hours ago [-]
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.
jotato 11 hours ago [-]
I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.
I do miss the configurablity though
nxc18 7 hours ago [-]
What counts as large? There can be some perf issues if you don’t exclude node_modules and build outputs from search, but I’ve never seen it crash.
jotato 3 hours ago [-]
It was a mono repo with 30+ projects Most were react apps. I’m going to guess at least 5000 files in the repo.
And yes, node_modules was excluded.
bigstrat2003 10 hours ago [-]
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.
golf1052 8 hours ago [-]
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).
muppetman 11 hours ago [-]
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.
zelphirkalt 10 hours ago [-]
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.
Mashimo 7 hours ago [-]
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.
NetMageSCW 1 hours ago [-]
Counterpoint: when you go to a coworker’s desk you shouldn’t be touching the keyboard or the mouse otherwise they are just watching you do their work. You should have them come to your desk if you want to be the one running the show. Everyone can have their own environment and they translate what you say to their own methods and it helps them learn.
This isn’t an episode of NCIS.
Mashimo 26 minutes ago [-]
If they ask me for help, why should I not give a quick example?
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.
01100011 10 hours ago [-]
90% of software is just new people not learning from the past and making/using some new thing.
Get off my lawn.
not-so-darkstar 6 hours ago [-]
>Text editing is a solved problem.
I have this sentence so much.
Ken Thompson wrote UNIX using a line-editor (QED), judging by his work does it mean text editing was already solved in the 60s?
eviks 9 hours ago [-]
> just a configuration of vim or emacs.
So which one?
1718627440 8 hours ago [-]
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.
NetMageSCW 1 hours ago [-]
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.
rfgplk 8 hours ago [-]
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.
tmtvl 5 hours ago [-]
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).
gushogg-blake 7 hours ago [-]
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.
5 hours ago [-]
throwawayffffas 7 hours ago [-]
Ooof you were not lying about the garbage. Hidden div for scrolling on canvas...
Not really judging I make a lot garbage too.
If you are going to do custom drawing why bother with the web platform, go native.
pizzabearman 9 hours ago [-]
Vim bindings joke was great
EdZitron2 6 hours ago [-]
He used AI but his site says “No AI”
serchinastico 6 hours ago [-]
Where do you get he used AI?
erichocean 10 hours ago [-]
If you want to do this in Clojure, Clobber[0] is a great base to start from.
It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely.
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.
alansaber 10 hours ago [-]
This is just not true at all.
globalnode 7 hours ago [-]
Which part is untrue? That theyre simple applications or that syntax highlighting and code completion are difficult?
bigstrat2003 10 hours ago [-]
You don't actually need either of those things for coding. Many, many programmers did just fine without them.
syngrog66 7 hours ago [-]
A mini-vi/vim I might be willing to reinvent for myself, if I ever felt it was needed or a net win. but would (obviously) prefer not. free time & energy are precious
threethirtytwo 4 hours ago [-]
I love this but, Text editors and IDEs are becoming obsolete. This is not a joke.
tech_army 3 hours ago [-]
In what way ? Can you elaborate ?
I use it all the time in Linux to edit config files.
jdw64 10 hours ago [-]
There used to be a joke that said, 'A great programmer should try building a text editor.'
__patchbit__ 7 hours ago [-]
Is Emacs the planaria species of text editors?
jdw64 6 hours ago [-]
Probably. And that makes Vim the cockroach.
self_awareness 11 hours ago [-]
Text editing is a solved problem.
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.
rfgplk 8 hours ago [-]
> Text editing is a solved problem.
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)
A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.
tmtvl 5 hours ago [-]
I use Emacs and the edits I do seem imperceptible to me. Do you know of any test I should try to see whether the lag is notable and intrusive?
Emacs does start fairly slowly, though, takes about 0.6 seconds.
self_awareness 5 hours ago [-]
I would love to see your config!
tmtvl 1 hours ago [-]
I'll try to remember to put it on Codeberg, though it's a little bloated and idiosyncratic (that means 'made by an idiot', right?).
Mashimo 7 hours ago [-]
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!
boxed 10 hours ago [-]
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
self_awareness 9 hours ago [-]
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. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. 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.
boxed 7 hours ago [-]
Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
artyomsv 4 hours ago [-]
[dead]
lynx97 8 hours ago [-]
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?
somat 7 hours ago [-]
Static-site generators.
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.
lynx97 6 hours ago [-]
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...
krapp 5 hours ago [-]
If you hang out here, you've probably tried to write a HN clone or client.
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).
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.
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.
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
That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language.
For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
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.
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!
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.
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-...
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 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]."
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.
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 have used both editors quite a bit and did like both of them.
I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever.
The idea that optimization matters less over time is short-term thinking.
It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
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.
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
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.
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.
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!
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).
But complaining about downvotes will certainly earn more of them.
So there's no sense treating it like the community has forsaken you.
If the purpose of down votes is to guide discussion away from uninteresting or counterproductive paths, then it also scoops up divisive comments.
I suppose divisive comments are potentially disruptive if they are particularly flamey. But it seems like they deserve to be distinguished from more objectively negative comments. If the raw up/downs were exposed it would be interesting to experiment with this in the front end.
All your best stuff will get downvoted by at least somebody eventually. For some reason, that somebody always gets in early enough that you notice.
1. Being near the top of the page
2. Having a downvote already
You can curtail the bandwagon effect by complaining.
I've observed the opposite--complaints are often more heavily downvoted than the original downvoted comment. The one I originally replied to is an example, at least at the moment.
Since you enjoy beautiful machinery, here are some classic clockworks:
https://news.ycombinator.com/item?id=44633225
https://donhopkins.com/home/documents/EmacsRedisplayAlgorith...
https://donhopkins.com/home/archive/emacs/skull-and-crossbon...
https://donhopkins.com/home/archive/emacs/mw/display.c
https://donhopkins.com/home/code/emacs.ps.txt
https://donhopkins.com/home/archive/NeWS/news-tape/utilities...
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
i 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.
Reminds me strongly of Marjin Haverbeke's talk at Full Frontal conf in 2011: https://ffconf.org/talks/respectable-code-editing-in-the-bro... - Using Canvas, then contenteditable, and then DOM.
Haverbeke went on to create CodeMirror and ProseMirror.
I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more.
IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it.
But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
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.
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 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.
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
They 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.
I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.
I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]
It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.
[1] https://github.com/mikewarot/teco
As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
> “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk.
My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor.
But then
> I’m good at building garbage!
I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
Is the experiment seriously rendering continuously in a loop?
https://qm.venka.com
It’s small (zip < 7MB) and fast (launches in 300 ms, opens Moby Dick in < 300 ms).
Ping me if you use and something is missing.
It’s my daily note-taking app.
Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do.
Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
I see off-by-one errors are still a common bug class, lol
EDIT: It's only in the earlier examples.
I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!
https://pkg.odin-lang.org/core/text/edit/
In a nutshell, the perpetual experience of writing your own (web) text editor.
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.
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.
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
For several years I've even hosted the nedit.org website :)
[0]: https://codemirror.net/docs/guide/
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
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)
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)
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)
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
It 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.
I do miss the configurablity though
And yes, node_modules was excluded.
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.
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.
Get off my lawn.
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?
So which one?
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).
Not really judging I make a lot garbage too.
If you are going to do custom drawing why bother with the web platform, go native.
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
I use it all the time in Linux to edit config files.
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.
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)
A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.
Emacs does start fairly slowly, though, takes about 0.6 seconds.
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!
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. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. 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.
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.