[corecoder]

I've been a long time Emacs user since ~1997 until ~2011, when I started developing mostly with ruby on rails on a mac, discovered TextMate and falled in love with it, with its slick UI, freshness (at the time) of ideas, ease of use, despite its obsession with mac based stuff, like the use of Finder for project navigation.

After a few years I discovered Sublime Text, with its tons of extensions and exceptional speed, bought a subscription and learned as much of it as possible, ditching TextMate.

Then I switched to Atom, mostly for the discoverability and the speed (back then) of development (and, frankly, for the hype). The only problem with Sublime Text, at least at the time, was the slow development process: new builds were few and far between.

I tried VS Code too soon, and wasn't impressed by how the navigation between buffers used to work (it has changed since then, I think).

A few years ago I did a serious attempt at learning Vim for good, but in the end I gave up, and I've come back to Emacs, this time to stay, unless something radically new is introduced.

The good thing is that I can usually tell my coworkers about features of the editors they use that they don't know, because I've used them a lot.

The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.

The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.

[gen220]

I might be in the minority here, but I don’t particularly enjoy how IDEs at the level of abstraction above vi/emacs encourage the normalization “things aren’t working well; and I’m powerless to fix it.”

To illustrate my point, if my colleague’s VSC config is broken, or if it’s taking way too long to detect python tests, or what have you, my colleague’s unfamiliarity with the layer of abstraction just below the editor (jedi, pytest, pylanguageserver), means they view the situation as inevitable, impenetrable, and part of the necessary cost of development.

With vi and emacs, you are usually aware of the programs that your IDE is dependent one, and you learn how to tune them. One might say that one shouldn’t need to concern oneself with things at that level of detail, but in practice you need to, if you’re interested in being the most effective composer of programs, no matter what IDE you choose.

For the curious and patient among us, it’s an eye-opening experience, to try and replicate your most used features of VS Code in vi or emacs. It’ll take you a while, but you’ll come out of it armed to debug and solve the kind of meta problems that most people (in my experience) view as the Sisyphean “cost of doing business”.

[tossAfterUsing]

I think this is prevalent in computer use generally. I came up on Dos & Win 3.1, and at every level the OS is trying to abstract the functionality from you.

Imagine trying to understand what a "driver" is without having a sense of what computer programming does... no way.

What i'm saying is: it's not just the IDEs... it's a mentality about computing.

And for one thing, it's the "i can do this quicker with an IDE" or "i can do this faster with a computer"

surely a computer can make things happen quickly, but truly understanding your tools takes much much longer than anybody realizes.

[teddyh]

> Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.

Just last week I opened, edited, and saved, a 4 Gigabyte SQL dump file, in Emacs. It was a bit slower than usual, but still well usable, and certainly no crashes.

[corecoder]

You're right, I just opened a 1.2gb file (obtained with base64 -b 60) in fundamental mode, and it actually works decently enough.

I tried the same with Sublime Text: it took a long while to open the file but, once opened, navigating the file was very slick, I could scroll from top to end and vice versa in a breeze, so I would say that Sublime Text still wins this one.

[edited to clarify: Emacs opened the file in just a few seconds, but then going to the end of the buffer, to the beginning, to line 100.000 is quite slow.]

[mafm]

Large files seem fine in emacs as long as the lines are not too long. A 100MB file is no problem if there are less than a couple of hundred characters per line. If the average line is 2K characters, emacs will be unusable.

[disgruntledphd2]

As long as you turn off syntax highlighting, it's fine. But it's annoying that you need to do that.

[teddyh]

I didn’t. I kept syntax highlighting on. And it was still fine.

[cyrialize]

> The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.

I 100% agree with this. The customizability of Emacs is another double-edged sword.

On one hand you can do whatever you want within Emacs. On the other hand if you're not careful your configuration could become a gigantic mess of code that is hard to get through and debug.

You can also run into situations where you need to do a particular $thing. Sometimes that $thing are 1-2 lines of elisp, requiring a package, or just copy-pasting some lines of elsip. Other times that $thing will take hours or days to get working.

You can also find yourself in a situation where you were knee-deep in elisp customizing Emacs and then you take a break or want to switch over to a different task. Depending on what state you left your customization in Emacs could end up being broken or hard to work with until you finish your customization.

(These are all things I've personally run into).

[metroholografix]

Emacs offers so many tools for interactive development and debugging that your first scenario should never happen, assuming you learn what's available and how to use it. Of the systems in use today, only Smalltalk has better introspective capabilities. Common Lisp through its Genera manifestation is superior even to that, but not easily available.

Emacs is the only contemporary widely-used system that can really be described as an apex / convergence point of stability, extensibility and self-empowerment. It is the clearest manifestation of "computers are an extension of the human mind" idea that goes all the way back to control theory/cybernetics, Licklider ("Man-Computer Symbiosis"), Engelbart, Alan Kay ..

One reason Emacs is such a rabbit hole, is that it always asks more of you. It always reminds you, assuming your mind is receptive, of the sheer potential on offer. Like any iconoclastic technology, it exhibits agency in that it tempts you to start using it in the way it wants to be used! And that's powerful. Very powerful. You're not simply writing scripts to scratch a temporary itch, but really learning about how to develop strategies to better manage information. You are expanding your own mind (cybernetic fusion) and programming the new metasystem at the same time. That's not an easy problem to solve but perseverance will bring ample reward.

What does it say about the current state of affairs when the typical reaction to experiencing Emacs for the first time is one of instant recoil due to the size of the set of possibilities now made available? We've been so conditioned by tools that operate in A-B-C fashion to expect a single, well-lighted path that we become dissonant to an alternative that opens up entirely different ways of thinking about and dealing with information.

As to your last point, you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things. Eventually you'll reach the point where this sort of decision is automatic and seldom needed.

[cyrialize]

> Emacs gives you so many tools for interactive development and debugging that your first scenario should never happen, assuming you learn what's available and how to use it.

Haha, I first used Emacs without knowing how to use the interactive development and debugging tools. I learned how to use the tools after I kept on running into issues.

> you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things.

This is a great idea! I'm going to do this from now on.

> Emacs is the only system available today that can really be described as an apex / convergence point of stability, extensibility and self-empowerment.

I absolutely agree. Using Emacs just feels so /cool/. The only time I've felt limited by Emacs has never really been Emacs' fault, it was either I didn't know enough elisp or it was due to some other program or process not interacting nicely with Emacs (which could be fixed if I knew more elisp).

[frank2]

>As to your last point, you can always fire up a new Emacs process and do your highly experimental customization there

I guess I didn't feel confident in my ability to adhere to that policy (of making changes only to the secondary Emacs process), so what I do is keep a backup of my Elisp code with the result that

   emacs -q -l <path to backup init file>

always opens a process usable by me.

[ledauphin]

i commit all of my Emacs config to git and use version control, so in theory i can just git checkout abcdef1234 and I'm back up and running.

[xkriva11]

Can you, please, describe, why do you think that Genera was superior to Smalltalk? I never had the opportunity to test it for real; however, I checked a lot of materials about Genera, and my impressions were the opposite. So I would really appreciate some arguments.

[metroholografix]

You should really try and use it if you are seriously interested in this paradigm. You can get your hands on it with a bit of searching. As for comparing the two, the philosophies and ideas are similar. Obviously there was significant cross-pollination.

Smalltalk always had an experimental, research-oriented aura around it. It did end up in industry but in a degraded, business sense did not live up to its potential at all in that domain. The Smalltalk environments that have significant value today (mainly Squeak and to a somewhat lesser extent Pharo) are firmly rooted in research.

Genera embraces the same philosophies but also hones them to an extreme degree through the forge of practicality. Its systemic cohesion and attention to detail is unparalleled. There is little "slack" and you don't get the sense that there exist systemic aspects that were not extremely well thought-out in both design and implementation.

[_lqaf]

What's interesting to me is that some users seem to "imprint" like this on the first serious editor they use.

I certainly did with vi. I've jumped editors a bunch of times and still use others for specific tasks, but always come back. I'm guessing it is some combination of learning something complex - the first thing in a new area you study tends to inform how you look at other things in that area. And muscle memory.

FYI, on the Mac, BBEdit handles huge files like a champ.

[jolmg]

> The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.

I just tried opening a 1.1GB SQL dump in vim. It took 11 seconds or so to open. That was pretty slow, but after it opened, it was pretty fluid. I could jump to the end or the middle of the file in an instant and move around like it was nothing.

EDIT: I just grew it to 10GB, and though it took longer to open, vim still works fluidly after it does. Saving the file does take about a minute or two, though.

I was surprised to find that ex wasn't able to open the 1.1GB file. It returns an error actually saying that the file is too large. Since feedback is very minimal, I would have expected it to work by loading the file incrementally in a small buffer like less does without even worrying about the whole thing at the start (no displaying total number of lines, etc.).

ed was able to open the 1.1GB file, but not the 10G one. It returns an error saying that there is no space left on device. I imagine it refers to RAM. That's pretty disappointing.

[ethelward]

> Saving the file does take about a minute or two, though.

Last time I strace-ed vim, it did a ftruncate to 0 on the original file before writing the whole content back; so no suprise it's rather slow if it dumps 10GB on disk :)

[jolmg]

Yeah, I wasn't expecting it not to write the whole 10GB. I don't think optimizing to write just the changes is worth it. Probably no editor has done something like that. I mean if the user inserts or deletes near the beginning of the file, there's no other choice but to write the whole thing to shift the content, anyways. It's just not worth the additional complexity to minimize the writes.

[anthk]

I think ed uses a tmp file.

You can try a custom sam(1) fork (it uses structural regex, google/ddg them): https://github.com/deadpixi/sam

sam -d for the classic cli mode.

[jolmg]

Yeah, ex too. I didn't know sam had a cli mode. Unfortunately, the one I have installed from[1] coredumps with the 1.1GB file after trying to write to a temp file.

[1] https://swtch.com/plan9port/

[anthk]

That's the plan9 port edition, maybe the forked one works better. Use "sam -d" for the cli version. You won't miss a lot in the end.

[robenkleene]

I just wrote about this exact progression from TextMate to Visual Studio Code (and why I think VSCode is the end of the road) here https://blog.robenkleene.com/2020/04/13/is-visual-studio-cod...

[nindalf]

I mostly agree with what you've written. VSC is a great product and I can't imagine moving away from it.

However, the team behind VSC has made a couple of fundamental contributions to the IDE space that makes it's continued dominance less likely. The Language Server and Debugging Server protocols that were pioneered by them mean that language support is no longer tied to a particular text editor. Clangd (C++) or rust-analyzer (Rust) and other language servers will (mostly) work just as well on any editor as long as it implements support for the protocol. These protocols have lowered the barrier for entry for text editors.

[RMPR]

I second this, I used to have VSCode installed alongside Vim, but LSP allows to have a proper autocompletion virtually effortlessly, or at least more easily than before.

Now I can't think of a reason to switch from Neovim :)

[celeritascelery]

> However, the team behind VSC has made a couple of fundamental contributions to the IDE space that makes it's continued dominance less likely.

It has always really confused me why they made LSP. It seems like the exact opposite of something a Microsoft product would do.

[omaranto]

My impression from what I've read about VS Code is that it has lots great lightweight IDE functionality (stuff that depends on parsing code), but it doesn't seem to actually have a lot of text editing functionality like Vim or Emacs does. It has multiple cursors, which is great, but that seems to be about it.

In Emacs I can quickly select by units of characters, words, lines, sentences, paragraphs, parenthesized expression, contents of a string, LaTeX environment, etc. And there are commands to sort lines or paragraphs, change case, apply rot13, run a google search, swap two units, delete text until the next occurrence of a character or a string, etc. Vim offers a similarly rich ranges of text editing operations. Does VS Code? If so it seems sort of hidden, I couldn't find more than a handful of text editing operations in the manual.

Maybe the IDE-like features are so good that people put up with a lack of text editing operations, but that doesn't really help people like me that mostly edit prose.

Another issue is that VS Code doesn't seem to be made for easy scriptability and extension. Emacs is so easy to extend, I'll often write commands I only ever intend to use while editing one particular file. For example, I was organizing a conference once and had file with all the talk submissions, each with an ID, speaker, title and summary. I had a little table were I was planning the schedule by putting talk IDs in the time slots. I wrote a command to insert a talk ID given the speaker name (with completion!), and command to flash the speaker and title of the talk ID under the cursor. With those, shuffling the IDs around was a breeze. This was a total of about 10 lines of code which took maybe 5 minutes to write, and it gave me a bespoke UI perfect for planning that specific conference. I stored the code in the same file as all the talk information and the timetable: neat, tidy and self-contained.

I know VS Code is extensible, but it seems to be pretty high-ceremony. As far as I know I can't type a JavaScript function in buffer, select it and press a key combo to suddenly have a new editor command defined. I think I need to package the code as an extension, and the code needs to be stored in files, maybe even in a specific directory structure with some metadata?

I would love to be wrong about both the lack of text editing features and about how cumbersome extending VS Code is. (And for all I know I am wrong, I haven't tried using it for more than a couple of hours --the impressions here don't come from that but from reading the online documentation and people's blog posts.)

[metreo]

The major concession I have for still using Emacs quite a bit in light of the elegance of VSCode you've pointed out is that I can do extended coding across multiple projects and runtime buffers without having to even think about reaching for my mouse.

This is also why I still use tmux come to think about it.

[jjav]

> The odd thing about Emacs is that its vastly superior customizability (or malleabilty as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.

Investing in tools is generally good ROI, but investing in tools that stand the test of time and won't go away is the best ROI.

Yes, I've probably spent a cumulative few weeks customizing emacs. But I've been using it since 1991 and expect to continue using it for the rest of my life. That's as good as it gets for a tool.

When I'm forced to use some tool du jour I don't bother spending much any time customizing it because I know it is a passing fad, soon to fade. So why bother. But timeless tools are worth the love.

[fluffything]

> I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.

For this I use the xi-editor. 20 Gb text file? No problem.

[nerdponx]

I didn't realize Xi was in a "usable" state now. What frontend do you use?

[fluffything]

It is usable for reading and editing files. Not something I'd use all day, but if I need to edit a huge file, there aren't really great options for that.

[corecoder]

Oh, that's great. I saw the announcement of xi-editor when it was in its early stages, I'll git it a try.

[RMPR]

Last time I checked there was no vim keybindings :(

[Torwald]

> but I've not yet decided if that's a bad thing or a good one.

It's a good thing, because it is time well spend.

[nerdponx]

It's a shame that the Sublime package ecosystem seems to be a shell of its former self, with once-popular packages going unmaintained or entirely deleted.

Sublime is one of the few closed-source proprietary programs that I've been more than happy to pay for, just because it's that good.

[dariusj18]

Sublime was a victim of it's own success when it came to it's packages. It was a great ecosystem, but Sublime needed a complete rework to support some more basic customization, like allowing packages to add functionality to the sidebar.

[slightwinder]

I wonder whether it would be feasible to create some limited but advanced enough standard for editor-packages which could be used with all editors. Similar to the LSP oder webExtensions that browsers have. I mean a good part of editor packages are probably quite simple and could be generalized enough to work with all mature editors.

Textmate-Package-Format for some time seems to serve that area, but somehow it died out.

[Torwald]

> but I've not yet decided if that's a bad thing or a good one.

It's a bad thing, you should watch football instead.

(The meaning of the above string is that I argue that investing spare time into hobbyistic software development is time well spent.)