Rendered at 10:12:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
tzs 4 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? :-)
socksy 41 minutes ago [-]
It's amazing just how many stories of Rob Pike seem to show him being both a dick and wrong
dist-epoch 36 minutes 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.
bigiain 4 hours ago [-]
I was hoping for this to end with "I wrote emacs, and Karl wrote vi."
LtWorf 4 hours ago [-]
If Rob Pike is in the story, it happened like yesterday.
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 3 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.
pmkary 5 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 4 hours ago [-]
The implementation is usually pretty ugly, actually
pmkary 5 hours ago [-]
Just what part of this comment deserved to get a -1 point leaves a whole universe of imagination to me and no answer :/
ameminator 5 hours ago [-]
Sometimes people down vote for no reason. Unfortunately, when one complains about it, they look like a whiner.
wolletd 4 hours ago [-]
That's because they are whining about worthless internet points.
rootlocus 56 minutes 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 5 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 3 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).
roarcher 5 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.
rezonant 2 minutes 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.
graemep 2 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 4 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 4 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 58 minutes 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.
CamperBob2 4 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 4 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.
bitwize 3 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.
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 4 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_ 2 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.
mangecoeur 2 hours ago [-]
I mean… they still make sublime text. Works great.
nottorp 5 hours ago [-]
There really is a fps counter on there.
Is the experiment seriously rendering continuously in a loop?
4 hours ago [-]
stillpointlab 4 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 4 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 4 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.
zahlman 1 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.
TonyStr 3 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 3 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 2 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
lelanthran 2 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 2 hours ago [-]
[dead]
shoobiedoo 1 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 45 minutes ago [-]
> "kinda different but mostly the same"
Isn’t that the description of our whole lives?
inatreecrown2 4 hours ago [-]
do you want to share your text editor?
stillpointlab 4 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)
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 2 hours ago [-]
Actually looks really good
boxed 57 minutes 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 3 hours ago [-]
It's important to share all vibe coded software to poison future LLM trainings!
Jean-Philipe 1 hours ago [-]
OT but I really like the design of this website. It's fresh, it's fun, but still easy to read. Love the AI policy page as well.
zahlman 2 hours ago [-]
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 2 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
rfgplk 2 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.
gushogg-blake 45 minutes 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.
vintermann 4 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.
badsectoracula 38 minutes 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.
gtr 1 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.
dwedge 2 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
joefreeman 3 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.
Been there, done that. It's a rabbit hole, but you learn so much about rendering and input. Good luck!
alwaysmrno 2 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 2 hours ago [-]
Let's see Paul Allen's text editor
__patchbit__ 2 hours ago [-]
The Moon Landing Project text editors may not have survived
Cthulhu_ 2 hours ago [-]
Frameworks / forums / CMSes to PHP developers
dvh 2 hours ago [-]
I've been using my own text editor for over decade. Written in Lazarus using SynEdit component. It's trivial.
Sweepline 3 hours ago [-]
All I wanted was proper multi-cursor editing and Emacs keybindings. Gave up and just started a new `src` folder.
throwawayffffas 35 minutes 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.
qbane 4 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 39 minutes 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).
dkersten 3 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.
anon291 6 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 5 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 4 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 1 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)
kodoman 40 minutes 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)
iso1631 24 minutes 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)
not-so-darkstar 27 minutes 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?
nxc18 5 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 33 minutes 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 5 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 57 minutes 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.
bigstrat2003 4 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 2 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 5 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.
kstenerud 4 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__ 1 hours ago [-]
Emacs and AI go hand in glove.
kodoman 28 minutes 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.
zelphirkalt 4 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 1 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.
1718627440 2 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.
eviks 3 hours ago [-]
> just a configuration of vim or emacs.
So which one?
01100011 4 hours ago [-]
90% of software is just new people not learning from the past and making/using some new thing.
Get off my lawn.
samus 5 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.
syngrog66 1 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
lynx97 2 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 34 minutes 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 12 minutes 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...
pizzabearman 3 hours ago [-]
Vim bindings joke was great
erichocean 4 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.
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 2 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.
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!
Mashimo 1 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.
boxed 4 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 3 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 33 minutes ago [-]
Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
jdw64 4 hours ago [-]
There used to be a joke that said, 'A great programmer should try building a text editor.'
__patchbit__ 1 hours ago [-]
Is Emacs the planaria species of text editors?
jdw64 7 minutes ago [-]
Probably. And that makes Vim the cockroach.
globalnode 4 hours ago [-]
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 4 hours ago [-]
This is just not true at all.
globalnode 1 hours ago [-]
Which part is untrue? That theyre simple applications or that syntax highlighting and code completion are difficult?
bigstrat2003 4 hours ago [-]
You don't actually need either of those things for coding. Many, many programmers did just fine without them.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
I'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.
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...
But complaining about downvotes will certainly earn more of them.
So there's no sense treating it like the community has forsaken you.
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.
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.
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.
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.
Is the experiment seriously rendering continuously in a loop?
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.
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.
It is worth noting that KTextEditor is a fully-featured library. Like, line numbers+gutter (for eventual git status icons), undo/redo, save, warn on exit for unsaved changes, syntax highlighting, color theming. It does 95% of what we'd all call "editing". But it doesn't do things like tab interface, project explorer, terminal pane, output windows, etc.
What the library didn't have were LSP features, of which I only implemented a few (error squiggles under things that fail the type check, go to definition). Notable absent are completions and hover features for things like help. I also only added (and tested) LSP servers for typescript, Rust and Go.
My plan has been: do as little as possible until I need something, then ask Fable to add it.
edit: I guess one thing I added I didn't see everywhere else was a built-in Markdown preview. But many editors have that (VSCode definitely does) so it isn't special.
Not a criticism just an interesting sign of the times that this is ambiguous and before vibe coding it would have been obvious from the context which you mean (deliberately minimal) but now it could just as easily mean that Fable implemented features without asking you
I dunno, hey. I'm not about to yolo my way for all things that are important. For things that are unimportant I will just use the existing stuff.
The goldilocks zone (things that an irritation, but not important), sure, I'll vibe a little Python/shell whatever, but pre-LLMs, I was already reducing my friction with little scripts anyway.
For example, in a recent comment of mine I posted a little wish script that I created in 2002, to have a simple GUI mp3 player, which I have been using daily since 2002.
To do what exactly? Everyone can churn out their own "kinda different but mostly the same" app thing?
Isn’t that the description of our whole lives?
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.
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
It's all personal preference
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
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.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
Same with no screenshots on github projects (For GUI projects)
Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug.
I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
Until about 2022 this was fine, then they introduced things like shifting the scrolling window, breaking mouse support, I think changing search to highlight text etc.
That's fine, but that means everytime I run it on any machine I have to now deploy a vimrc to fix it.
(I think I noticed the regressions starting in vim 8)
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?
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
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.
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.
So which one?
Get off my lawn.
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.
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
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.
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.