Hacker News Reader

Comment by rudolfwinestock | Hacker News Reader

The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal.

See this https://www.facebook.com/notes/daniel-colascione/buttery-smo...

“Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.”

For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs.

Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs.

View on HN

For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom.

One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. The same could be said about Vim. In comparison to these two, newer editors sometimes appear too ephemeral and fragile to me. (Then again, I used to use BBedit on the Mac and just found out that it's still around! What a nice surprise!)

Both Atom and VSCode are multiplatform and can run on any platform emacs can. Hell there's a version of it that runs in-browser. Both have commercial backing and the platform is built ok Chrome. Hard to imagine a world where any of that adds up to ephemeral.

Any platform? Like the terminal on my server?

No, like your browser since it's a GUI? A terminal isn't a platform.

Not all environments have GUI or need to have it

Never said otherwise. Just assumed my statement would be clear that environments lacking a windowing system wouldn't qualify given GUIs require a windowing system.

I'd love to use Atom on a little QNX system, can you tell me where I can find the Atom distribution? It's possible to build Emacs on it.

That's my bad, I should expect stupid responses when I make a stupid statement. Major platform where, you know, it makes sense to have. You'd "love" to have Atom on your realtime OS? For what, exactly?

I'd bet he'd want to edit text; but I'm no fortune teller.

You'd probably use a text editor in that case. I'd bet most operating systems include one.

I need to work on my disruptive startup's decentralized AI blockchain machine learning product using Vue.js from my car's infotainment system.

Actually though pre-6.6 QNX had a great GUI and is capable of running on desktops and laptops just fine¹. I rather like it.

¹ Hardware support is not great but way better than you might be expecting. Either way, it runs fine in VMWare and VirtualBox. I'm currently trying to acquire some parts to build a PowerPC laptop for QNX.

Same. I used to swear by Intellij but they just kept on changing things, and even breaking things on me the odd time.

This latest emacs upgrade has been seamless and hasn't required any cognitive overhead to transition.

That said, I'll always be back to IntelliJ for heavy edits. There's nothing better for Java.

I find for less structured languages the less-structured approach engendered by emacs is an advantage.

emacs has a couple of packages working to implement the editor side of the language server protocol, so it's probably not long until it's at rough feature parity for structured editing of languages with rich semantics.

For some perspective:

BBEdit - launched in 1992 (26 years ago), still around.

Notepad++ - launched in 2003 (15 years ago), still around.

Textmate - launched in 2004 (14 years ago), still around.

Sublime - launched in 2008 (10 years ago), still around.

Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even more so Open Source ones have great survival characteristics.

That's why both Atom and VS Code seem like solid long term bets.

To see why this isn't necessarily the case, add to your list all the text editors launched between 1992 and 2008 that are no longer around ("being around" defined as being able to install and run on whatever OS you're using on your main computer with no special effort).

Exactly. The post above yours is simply an illustration of survivorship bias.

I'd be interested to hear about former mainstream editors from that time that are gone. Especially cross platform and Open Source ones :)

Brief, Multiedit, Codewright, Semware, Slickedit and Epsilon used to keep the lights on at many programming/tech magazines. You don't hear much about them anymore...

Clark Maurer still updates Slickedit at least annually though.

You made me curious as I'd never heard of any of these editors... (except for Slickedit, I think)

A bit of digging around:

Brief seems completely dead, was killed off by Borland.

Multiedit seems operational: http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product.

Semware is still technically "alive": http://www.semware.com/ It was last updated in 2005, so there's that :)

Slickedit: is definitely operational: https://www.slickedit.com/ I have no idea why you're counting it as dead?

Epsilon: seems operational http://www.lugaru.com/ They even had a release in 2018.

To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience.

Now, if a tool for developers reaches the mainstream, it super likely to stick.

I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...

The list from Softletter in the spolsky link kind of illustrated my point. Most of the editors I listed were big sellers until 1997 or so. And most of them are effectively dead with the exception of Slickedit. The reason I switched to vim was the lack of a decent text mode editor for Windows in the early 90s. I'd likely still be using Slickedit otherwise.

Also, the cited survivors have certain characteristics, like being small items with no "ecosystem" baggage and few dependencies in general.

It makes sense, I guess. As programmers, we naturally spend a lot of time with our editors of choice, so we become very attached to them, both emotionally and practically - with Emacs, at least, you accumulate your customizations and extensions over time, and you want all the time and effort you put into learning and customizing to pay off. And with any editor, there's the muscle memory - it's like you're offloading certain tasks to a dedicated piece of hardware, thus freeing your mind to focus on the task at hand. It's a kind of "lock-in", if you will, but it's the kind that enhances your productivity.

Original comment:

>One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform.

You're ignoring the first half of the sentence:

BBEdit - not on Linux

Notepad++ - not cross platform

Textmate - not cross platform

Sublime - cross platform - but can I see the source? If not, I have little faith it will be around in 20 years.

My (heavily customized) Emacs environment on Windows gives me the same experience as in Linux. No warts at all.

I wasn't ignoring it, if you notice my final argument is for cross platform and FOSS stuff: Atom, Visual Studio Code.

There's even good native editors if you want that, Scite comes to mind.

Anyway, my point was just don't dismiss out of hand, don't belittle other people. Of course, if you're happy with Emacs, continue to be happy.

Oh, and the irony of this is me railing against Emacs/Vim when I'm also a Vim user and have been for at least 10 years. I say also because I've been using VS Code quite a bit lately.

Emacs is compared to vim because both can be run in a terminal on a remote machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent chance I’d switch away from vim if I ever had a job where I could edit code locally.

I see this occasionally. Why can't you edit locally?

Sometimes it’s policy (no source code on laptops), but mostly it’s because my line of work uses the verilog language and the tool suites require “very stable” (read: archaic) versions of Linux.

Damn, that's a shame, I hope that the pay is good at least :)

do you know about TRAMP? https://www.emacswiki.org/emacs/TrampMode

Can you use ssh/scp? Emacs is able to use that to edit files remotely. I often use it when I work with small Arm Linux boards.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...

sshfs is a thing. If i had to use remote machines only, i would use tramp; not run an emacs instance on a remote machine. I haven't had good experience running editors inside tmux.

Emacs has TRAMP, which allows transparent access to files on remote systems using a variety of protocols (but mostly ssh/sftp).

...and if you haven't given TRAMP an honest shot, you definitely should. I took the leap not too long ago, and it is absolutely amazing. Whenever I can't access a host using TRAMP (does happen, but very rarely), I put off whatever task I have to do on that host for a very long time.

The fact that TRAMP lets you open files on remote systems in and of itself is fairly mundane. What makes it really cool is that it works seamlessly also with dual-pane dired, and just about anything you do in Emacs. It turns remote filesystems into local ones.

Being able to, in my regular file manager (I like Sunrise Commander), treat any combination of remote and local filesystems as though they were local, is a huge productivity boost.

It's this sort of thing that when I first saw it on Apollo's Aegis and again later on Plan 9 it was so obviously useful I figured it would just be everywhere in no time. At then Sun touted "The Network Is The Computer (TM)" and I was like here it comes! But it hasn't quite panned out that way. Considering the number of viruses and ransomware perhaps that's a good thing but it would be cool as hell if I had shared name spaces with my wife, mother, sister, etc rather than the artificial constraint of mapping into Facebook or Google Photos (for example) to share a photo album.

Not that it's the /correct/ solution, but Keybase does a good job of providing that shared-directory experience, and the free tier is pretty roomy.

Not affiliated, just getting good use out of it.

But the coolest thing by far is that you can now go the reverse direction. If you have a ssh tunnel you can run emacsclient --tramp $file on the remote system and it will pop up on your local Emacs window.

Consider my mind blown! :)

Once I had to work remotely over 2g cell phone. Using remote terminal was too painful due to huge latencies approaching 1s. What worked surprisingly well was to work on a local copy of files in a local editor and then to run command remotely I would prefix them with a script that I aliased like rc. The script rsyncs first the tree to the remote host and then run the command there. These days for much simpler setup I use lsyncd to sync file trees and then the rc command just runs the command over ssh.

For that use case, if you have Emacs locally, you could use TRAMP - which basically works the way your script does. It allows you to transparently access files, directory structures, or even run shells on remote machines. It supports many protocols; the typical way it works, is it starts an ssh connection in the background, and uses the shell to ferry the file you want to edit to your local machine, and then transparently ship it back when you save.

TRAMP does not work like that. First it does not have a whole directory tree, rather it just caches the opened buffers so things like grep etc. must run remotely which sucks on a high latency link or could be much slower if the server is not very powerful VM. Second at least like 5 years ago when the last time I played with TAMP it worked really badly on an unreliable connections or when the laptop switches to different wifi network. If ssh connection hangs, the whole GUI often hangs and sometimes after reconnecting I had to throw away resent edits and reopen the buffer. It could be that nowadays things are better, but for me nothing beats my lsyncd + explicit remote command script. Even file completion works with trivial efforts. As paths in my local tree copy matches the remote paths, completing by files just works, and it is trivial to call completion scripts for remote command from the completion script for rc.

VS Code and Atom are practically guaranteed to run until the end of time at this point. The sole benefit of web apps is that they're more likely to remain functional than native ones.

Emacs is in no race with text editors. If Emacs was a pack of a dozen of eggs, text editing would be that one egg on the corner with the fragile shell. Mr. Java can beg all he wants, but one thing people don't get is that Emacs is not a text editor. It has one, yes, but it's a program where the user can interactively manipulate data presented in buffers via Lisp, and keys bound to some Lisp. Thus, it is in a league of its own. The only modern player that tried to enter was Light Table for Clojure, but it did not hold on, I guess. Then there is Climacs, Hemlock and Edwin, but they don't have much or any adoption.

I have not used one program til this day that is easier and more optimised for user customisation than Emacs. And if not much people will be using it in the future, be it so. But it will be around as long as computers with physical keyboards will be (and will probably adapt if they ever become obsolete).

Emacs is not optimized for customizations. It allows to customize everything, but the efforts required often becomes a programming project on its own. 20 years ago I spent eventually months to make the buffers switch the way I liked. Yes, i made it work precisely the way I wanted, but I suspect it would be easier to implement that feature in a native code as a patch for an editor where a configuration is just an ini file.

In any other program, such customization you made would be impossible.

The things you can customize in other editors and IDEs, you can customize through the M-x customize interface. The things you'd install as plugins, you can get from Emacs package manager. All other things that you can - with smaller or greater amount of work - alter in elisp, are more-less impossible in other editors.

Think about why one needs a sofisticated customization in an editor. It implies it's defaults reflecting the workflow of the developers are significantly different from yours. To fix this you essentially must become a developer. And since the feature you want is not what the developers want, your has to maintain the feature as long as you use the editor. Now think about all the time one spends on that. If it does not feel like fun or hobby, then one better try to find some other editor that matches what one wants by default or after 5 minutes of poking in the preferences menu.

Anybody can use any tool to their liking, obviously. But again, you are objectively wrong with Emacs. Every programmer has certain things they need to automate, certain recurrent tasks and then certain non-programming stuff. I am not a professional ptogrammer, and I use Emacs for a handful of non programming tasks. I do tens of things daily with it that is plain impossible with a preferences menu, and impossible or prohibitively hard to do with other programs.

Edit: Now I'm on the computer, I can link you to my init.el [1] so that you can skim and observe how much is configuration and how much is stuff that's possibly unique to my workflow. And how much is very useful stuff only possible in Emacs (one of my favourites is the URL routing stuff, at line 3674, something I inadvertently use tens of times a day).

[1] https://github.com/cadadr/configuration/blob/6a1e400488839b7...

Why would writing a patch for any other editor be easier (or less hard) than writing a patch for Emacs?

Emacs API is just insane with too many special cases or with other packages unexpectedly affecting semantics. Even after stepping in debugger I often could not be sure if the things worked like I thought they should work with too much unstructured global state that is randomly poked.

I use Emacs since about five years straight, every day, and have used it on and off before, and have quite some Elisp in my .emacs.d, and can say that you're totally wrong on this. Yes the language has problems, the API, having been there since many decades ago, has quirks, but not more than most of the common languages out there, JS, C/C++, Python, Ruby, Perl, what not. What modifies the global state (mark, match, etc.) is well defined, and you can avoid learning it unless you're sending patches or maintaining your own packages. And dealing with programming languages' idiosyncacies is our raison d'etre anyways.

That doesn't quite ring any bell.. Have you used edebug? I haven't seen that level of code introspection and debbugability in any other tool, even a development environment.

Emacs allows you to look into and debug any function or variable, be it internal that shipped with its core, or one that you wrote.

>I have not used one program til this day that is easier and more optimised for user customisation than Emacs

The Leo editor comes close. Unfortunately, the documentation is a bit lacking. As is the UI - almost as bad as Emac's :-). The mailing list and developers are, in my experience, very helpful and in the short time I used it, they quickly created functions/commands for me when I asked "Hey, I can do it in Emacs - how can I do it in Leo?"

This is not at all fair or accurate in terms of general architecture. The quote from Daniel Colascione describes some implementation details that can and will be improved. The same Daniel Colascione is very passionate about Emacs and spends a lot of his free time working on it.

Moreover, you did not mention any of the things that make Emacs great. Its mode-based buffer-centric architecture comes from the Lisp Machines, maps well to countless disparate tasks and has certainly stood the test of time. Emacs is essentially the closest thing we have to a Lisp Machine.

Atom and VS Code on the other hand are ad-hoc editors on top of environments that can only be said to re-implement old, dead-end ideas and do so badly.

I'm not sure why you mentioned Gosling, if not to mislead, since he's never as far as I know been a Lisper (Mocklisp is a mockery of Lisp) and his contributions to GNU Emacs -- besides inspiring Stallman to come up with something better -- were minimal and very quickly rewritten or removed. Gosling's influence to the architecture (Lisp Machines, Symbolics) and evolution of GNU Emacs has been NIL.

> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs.

Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs.

Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs.

Emacs runs in a GUI. Emacs runs in a terminal. Emacs runs on a machine halfway across the world on the other side of an SSH session. The point goes to emacs.

Emacs is far from perfect, but it's far ahead of its competition.

VS Code can be extended in Typescript: https://code.visualstudio.com/docs/extensions/overview#_writ...

Philosophically Lisp may be superior, but I'm not sure it's so clear cut in real life.

Regarding most of the features you present, a good chunk of them aren't editing features and another chunk are related to running in a limited environment (the terminal). So a big part of them aren't as strong selling points as you seem to think they are, since many people don't care about them.

One of the frequently overlooked benefits of Lisp is that the culture around Lisp actively promotes software that is /supposed/ to be extended by its user and sort of grow into the user, rather than the user growing into it.

There is also a huge difference between "building an extension" and "extending the actual code that is the running process." In Emacs, one can redefine one of its core functions at the push of a button, and suddenly all new calls will call your version of the function. If your redefined function has a breakpoint in it, you'll be able to debug-step into the core of the editor as it is running.

Not sure how well TypeScript in VS Code works in that regard.

I've found that I prefer a very nice, coherent design by someone who spent a lot of time thinking about the problem in a holistic manner, than tinkering with stuff. And I do/did tinker a lot.

IMO that's the best design: a solid, coherent design with clear extension points.

Of course, I'm the Anti-Emacs by saying this :)

JavaScript is ubiquitous and acceptable for most of the same purposes as Lisp. It has a much bigger developer ecosystem. The point goes to VSCode.

VSCode has much better integration with the languages and toolchains that people are actually using in 2018 -- Node, Go, Rust. The point goes to VSCode.

VSCode has a modern UI that looks and works like the other applications people use every day. The point goes to VSCode.

With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too. So that one's a tie, I guess. Nobody except retrocomputing enthusiasts cares about terminals anymore; when kids today hear "terminal" they think of gnome-terminal (and some of them agitate to have it replaced with something that can present a richer experience than ANSI/VT100 can).

The sun has largely set on Emacs's relevance. Objectively better tools have come along.

>>JavaScript is ubiquitous and acceptable for most of the same purposes as Lisp.

The last time I checked on this very forum, Lisp people don't even consider scheme as a lisp. Only CL and Elisp came into their category of Lisp.

>>modern UI that looks and works like the other applications people use every day

The point about vi and emacs is not have that UI for the exact opposite reasons you state. Developer tools are not every day things like scissors or door handles. These are more like specialized tools, designed for one special purpose(Text editing).

Also this whole idea of putting beginner friendliness ahead of all design goals leads to tools that are very easy for beginners to work with but do nothing more than that.

The whole point about programming is to automate complex non trivial tasks.

>>Nobody except retrocomputing enthusiasts cares about terminals anymore

Wow! Just wow! Curious to know what you work on daily.

I thought even in this era front end programmers had a fair bit of exposure to the command line.

But if you are telling me only 'retrocomputing enthusiasts' care about the terminal, I have to wonder where these sort of programmers come from.

>>With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too.

Actually no. But based on your thoughts about the terminal, I can see why you wrote that.

>>The sun has largely set on Emacs's relevance.

Emacs will never have the user share of something like Eclipse. But then eclipse won't have the life of Emacs either. These are tools aimed at different category of people.

Regarding Emacs vs. VS Code, it is kind of funny that Emacs was once the canonical big, fat, bloated editor, but it did not grow much bigger since then. So today, Emacs is kind of lightweight: On my work computer, VS Code will easily gobble up half a gigabyte of RAM with only a handful of files open, while Emacs with dozens of buffers consistently stays below 100 MB.

Compared to nvi or mg, GNU Emacs is still pretty big, but I think the size-to-feature-richness ratio is more balanced in Emacs. Also, I will come out and admit that I like Emacs for being Emacs. I have tried VS Code at work, and it is not bad. But from a certain point of view, VS Code is just Emacs Re-Imagined using Javascript instead of Lisp. And Emacs just has a ~30-year head start on VS Code at being Emacs. Last, but not least, the Emacs default key bindings for moving the cursor around are by now so deeply ingrained in my muscle memory that I will not willingly switch to an editor that does not support them. And all the Emacs-keybindings extensions for VS Code I have tried were ... not quite there, yet, at least for me.

A few years ago I was astonished to see Gnome's gedit having bigger memory footprint than very tricked out Emacs.

Vi folks used to make fun of Emacs as ‘Eight Megabytes And Constantly Swapping’!

>>For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs)

Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things.

From : https://www.gnu.org/gnu/rms-lisp.en.html

Then he continued to mock lisp with an AST preprocessor for C called Ace [1989], and through Java.

vscode can only be customized by an extension. There's a bunch of one off plugins you have to install to get little bits of functionality that you can get by pasting 15 lines of elisp from the emacs wiki. If no one has built that extension yet, you have to learn to build one yourself. You could always create private "personal" extension and keep it local, but that workflow is tedious.

I'm not saying vscode is less extensible or customizable though, I'm saying there's a barrier to ad-hoc personalization that's will keep it from ever being more easily customized (unless you and I have different definitions of what is "easily customized").

Script Commands[1] is an interesting plugin that attempts to address this shortcoming, but I'd like to see something official at some point.

[1] https://marketplace.visualstudio.com/items?itemName=mklouber...

The upside for anything like this is that the barrier to entry being higher, the people who do this tend to create higher quality things overall and maybe even share them.

It's not my idea, it's the premise from

http://winestockwebdesign.com/Essays/Lisp_Curse.html

Have you looked at the VS Code marketplace? It is not great. The LSP modes are great and then here and there you get interesting extensions, but a bunch of it I would not call higher quality by any means.

(I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)

I have, and I'd fault the immaturity of the ecosystem more than anything. VS Code was launched just 3 years ago. I don't even know if it had extensions from the beginning.

The extensions I've generally used were quite solid, haven't had many problems with them.

I'd argue this is a feature more than a bug. I haven't done much with VSC, but I have done a lot with both atom and emacs (via spacemacs). How do you find out even the name of what you are looking for to find it on the wiki? Is that snippet of elisp tested (or even testable?) What does it do exactly? Is it a passive effect, or something you have to execute a command to run?

In atom, you can find packages on the website or in the dedicated search in the editor. Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.

Emacs is awesome, and currently more customizable than anything else. Tramp and Magit and Evil are best in class. But it's super difficult for a newbie to get started, and the windows compatibility is only so-so.

If you really want to just use code snippets to customize atom, you can! They have an init file for code changes, and a css file for style changes. There's even a website where you can find some of these little scripts: https://www.atom-tweaks.com/

I've found it way easier to customize Emacs, and you can do so much more. Though Atom has pretty great customizability also. This is not true of Visual Studio Code, which has much stricter plugin points.

That said, I know Lisp as well as JavaScript. Obviously, more people know JS, so might find tweaking Atom easier.

In emacs though, I don't even need the internet to figure out how to customize things. C-h is all you need. There's a book bundled in, all functions and variables have amazing built in documentation. You can search for any binding, function or var by regex, go to their code, read their doc, redefine them at runtime.

The only place where Atom wins for me is in theming.

At the end of the day though, I had to go back to Emacs for performance and memory footprint reasons. Atom was just too slow, and used up too much memory.

> Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.

Sure, and Emacs has this with MELPA (And Atom with... whatever they have). It's great paradigm and all editors should have it.

But I'm not talking about thousands of lines of copied elisp. I'm thinking about molding your editor to fit your needs. Here's an example:

We use hosted Gitlab at work. I like to highlight a line in my editor, call a command in the editor and get a URL for that line in that file in that branch on our internally hosted Gitlab server (with a custom path segment prefix). This is literally maybe ~40 lines lines of very compact elisp in a global configuration file. It would probably be less in JS because I'm better at JS than elisp. It's very specific to my circumstances and doesn't really need to be generalized to anyone else.

There are ~5 different plugins in the marketplace that purport to do this, but none of them fit my use case. Which is fine, I can do this myself...

However to do this vscode I have to create an extension, edit the package.json to register the command and few other things (this is tedious, believe me), re-read/remember the plugin API, re-read/remember how to build vsix files for production, install that plugin with the command line tools, reload vscode.

If I need to make a change, do it all again. But there is no reason that the Emacs behavior couldn't be included in vscode. And maybe some day it will. But the idea that not having it and claiming that is a _feature_ or (as others have done) claim that emacs is losing to vscode in configurability misses the multitude of use cases that emacs users have benefited from for decades.

As far as testing and code quality goes, I can't really argue with that but neither can vscode users? Do you know what all your plugins are doing in the background? All of these centralized plugin repositories are significant attack vectors. Which language do you think the first big own will be written in?

For a newbie you only need to navigate, copy/paste/delete. Then you learn how to manage (multiple) buffers. It took me about a year of regular use to really feel like I could "use" emacs. Full disclosure: emacs fan. Once I started getting used to lisp prompt (M-x) or w.e its like a portal opened up to another level of understanding, realizing that you can write and execute elisp functions from right there in the editor: ex. `replace-string` or `rot13`. it has a great undo system (multiple undo histories) and a effectively unlimited copy paste delete history. search ( C-s ) is also a pleasure to use. Magit is on a whole diff level and offers the most comprehensive and organized git interface I've ever seen shy of CLI git. And all these things are interacted with common controls, so knowing the basics from the beginning of my comment opens up the rest of the fancy stuff relatively quick.

I am tied to using Emacs because so much of my work is done in SSH sessions on remote servers. I own licenses for all JetBrains IDEs, and find real value in them, but I can’t imagine not using Emacs + configurations for favorite languages + orgmode frequently and every day.

> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs.

I use Emacs as my daily driver. Your comment feels very much like from someone who hasn't realized the true powers of Emacs-Lisp. Even if someone doesn't hack in Elisp, once they discover power packages like Org mode or Magit, they will know right away that there's no competition for those out there (vim, Atom, VS Code, etc).

> For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs.

Even if that's the case, what's the point he's trying to make? Why? How does that matter to folks who are using Emacs today, and know it first hand that it's the best hackable text buffer engine out there?

If you're using a ceremonious language like Java, the automation in a modern editor could be useful. I think that's what Gosling was getting at.

Java by many definitions is a bit like assembly language of our current times.

You will end up stitching highly verbose pieces of code. Which is why Java IDEs have specific features to emit get/set functions etc.

Plus you will have to access a method hiding 5 class layers below. You will need IDEs designed to do this sort of work really well.

Emacs and Vi have been designed to largely play with Text, plus I think with Java's verbosity you are just better off with a specialized IDE.

Wouldn't call assembly programming "highly verbose". If anything it's opposite - very little boilerplate, if at all.

Do we have different ideas of what boilerplate is? Almost everything in assembly is boilerplate because there are no advanced, built in features. (Sure, modern x86 assembly is a complex language with many advanced builtins but they are generally meant to express solutions in the x86 domain, not the business domain.)

I stick to traditional definition.

> In computer programming, boilerplate code or boilerplate refers to sections of code that have to be included in many places with little or no alteration.

https://en.wikipedia.org/wiki/Boilerplate_code

So those GNU Emacs screenshots with embedded graphics are fakes?

Like: https://www.gnu.org/software/emms/screenshots.html

Not fake. My report authoring process includes a live updating PDF preview in an Emacs sidebar.

However, this graphics stuff is still bolted onto a core engine that treats everything as a text terminal.

Won't it fly away if you don't bolt it to something?

I have to admit that I mostly use IntelliJ and related products or VSCode these days, but I can't give up the emacs key bindings.

You have a source on Gosling trying to get people not to use Emacs (not calling you out; just genuinely curious)?

From ten years ago: https://www.computerworld.com.au/article/207799/don_t_use_em...

Reply on news.ycombinator.com