Hacker News Reader

Comment by kqr | Hacker News Reader

This sounds like it's not written by an actual Emacs user... and the fact that I can tell points to the real fundamental problem of Emacs: it's not a text editor but the real thing it is is so complicated it finds it easier to market itself as a mere text editor.

What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.

It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example).

But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.

View on HN

This is something I wish someone had told me 20 years ago when I first started using emacs. The whole "it's a text editor, but also it's not really a text editor"-thing was very confusing initially.

... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more.

What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other.

I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.

You just succinctly described why my annual attempts to learn Emacs never actually go anywhere. As much as I like the idea of an all-purpose text processor construction kit, even with "starter kits" I spend a week trying to configure various languages to a point that I'm happy, find myself copying, pasting and tweaking Lisp code, invariably find weird conflicts that lead me to do web searches (which may find more Lisp code, which may be a decade out of date), and so on. I don't doubt that if I kept at it I'd eventually reach nirvana, but I frequently find myself thinking "this was just so much easier in Vim" -- and any time anything can be described as "easier in Vim", it feels like a sign of a UX problem. :)

sigh

I cannot blame you. And if vi makes you happy, I want you to enjoy the heck out of it. Between discovering emacs and making it my editor of choice I spent a few years using vi heavily, and to this day, I reflexively use it for quickly editing config files.

Regarding emacs, all I can say is that, in my experience, it gets better if you really stick with it for a while. The payoff is huge if you put in the time. But time is limited resource, vi gives you a payoff much faster, so ... like I said, if it works you, don't fix what ain't broken.

I love Emacs, but I also love the variety of editors programmers can choose from. With programmers' editors, as with society as a whole, I consider diversity an advantage.

Does that include Spacemacs? It didn't take me a week to get up and running from switching from vim.

It does, although I've gathered that I managed to try my last attempt during a period when the released version was unusually buggy around the margins. What I'd frequently find was variants of what usually happened to me with Emacs: (1) find something that wasn't enabled that I wanted to do that could (apparently) be solved by enabling a layer (or installing a package or two), (2) enable that layer (or install that package or two), (3) immediately be confronted with unexpected error messages, (4) go on a bug hunt in which at least half the web search results were variants of "I ran into these unexpected error messages, how can I fix this".

My impression -- obviously as an outsider! -- is that Emacs' immense flexibility comes at the cost of providing a lot more surface area for packages to get in one another's way. When that happens, you need to be willing and able to untangle things -- and while each individual tangle is rarely a big ask, they can add up, especially when you're coming from VSCode or Sublime Text or what have you.

> What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications.

If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?

So now there's a product that leverages the architectural advantages of Emacs, with modern defaults across the board.

Unless I was very unlucky in my decisions about what and how to learn about vscode or my ability to learn has dropped more than 10-fold between the time I learned to modify Emacs and the time I tried to learned to modify vscode (which is unlikely but not impossible: it was an interval of 28 years) emacs is much easier to learn to modify than vscode is unless one is already a web dev.

Of course, if one does learn how to modify vscode, one has a skill (namely, web dev) in much higher demand on the labor market than knowledge of Emacs Lisp.

I haven't personally used VS Code much, but from what I understand, it still runs in two castes that don't, generally, mix: there's its core code, and then there's plugins, and the latter exists on a separate plane from the former. You can't write a plugin that redefines some core behaviour. The functions internal to the core are not all automatically accessible for any plugin. Plugins don't become fully integrated with the core code to the point where the source file location is your only hint as to whether behaviour comes from a plugin or core functionality.

(A non-Emacs user might very well go "Emacs plugins can do what now?" at the description of a plugin re-defining a core function. That's a fully understandable reaction. That level of hackability is not for everyone. But as far as I can tell, it's unique to Emacs and very small set of other software.)

But I could be misunderstanding this. Maybe VS Code actually does have Emacs-level hackability, in which case I'd probably want to try it out more than I have!

No, I do not go "Emacs plugins can do what now". I rather go, "and that is supposed to be a good idea?". If you want to use Emacs as an OS, doesn't protected mode seem like a desirable feature?

From personal experience, I've benefited way more from that than I've been hurt by it. Whether that's true for all people I don't know.

Of course, you're not supposed to do it other than very carefully and it has caused me problems when some plugin has made a mistake in a way that worked for the original author but not for me, but because of the openness of the system, it's fairly easy to "overwrite it back" automatically when the plugin is loaded – and submit a patch back upstream.

So maybe this sort of system works only when a large portion of the users are hackers, and making Emacs more popular is not a good idea!

Yeah, exactly. For example, evil-mode is still miles better than VSCode Vim plugins just because it works everywhere. Any buffer that my Emacs opens I can still use my Vim shortcuts (so it doesn't change that I open a text, a binary, file manager, a fuzzy search or PDF). Compared to this, on VSCode I basically need to explicitly say "make vim commands do this in this context" for everything I need.

My current client wants all of us to standardize on VS Code at some point, and this is by far the most annoying thing for me. I hate that if I leave the editor, it goes back to a mouse-driven design. I'm glad to hear you can change the behavior, so I guess I'll just have to do that at some point to make it work for my needs.

This is the main reason I changed and do most of my work in Emacs, keyboard only. Using it in terminal is a bit of a bonus. Onivim2 seems promising in bridging the gap, but we'll see.

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?

Almost, but not quite. VSC doesn't give you javascript access to the internals of the application, it just provides a fairly broad set of extension APIs. You can see this in how the VSC equivalent of rainbow-delimiters-mode (parentheses and brackets recolored based on their nesting depth) had to be rewritten as part of the core application for performance reasons. This wasn't necessary for emacs.

I'm doing a highly integrated language environment for a research language and faced this decision recently.

elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript.

however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text.

I remember elisp debugging as being a joy - not really finding that to be true. but I really don't want to be limited by what the VSC designers thought I should want to do with source files - actually I don't want to use source files at all.

> VSCode presents an API around a specific notion of what a language is and how it interacts with the editor

I would say Emacs has this as well, in its syntax tables. They are its schema for "what a language can be" and especially "how the editor can interact with it".

yes - but those are completely optional

That is true of any editor: they will only seeem intelligent if you ask them about the languages they have support for.

By its nature software designers have to make some decisions on what should be easy, what should be possible and what you'd be better off using some other app for.

If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice.

We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.

Emacs is not that much different there with it's C-core and lisp-land. It had even a similar case with the reimplementation of linenumber-mode in C for performance-reasons. The question is more what emacs can offer generally that vscode is lacking in ability, even just theoretically. Because in reality there are of course many features not implemented yet in vscode.

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?

For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.

> For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.

That's a personal policy choice, not a technical concern.

Let's face it, the fact it's free software is the reason it's used at all, the reason it's been hacked on by so many people, etc... It's always relevant to discuss it's free nature, especially when discussing it's popularity.

Ah, but Javascript is a profoundly terrible language to do anything in, while Lisp is a joy to write in.

Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.

> Javascript is a profoundly terrible language to do anything in

Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are

What do you find profoundly terrible about JavaScript?

eLisp? Where lexical scoping is this brand new feature that generates compiler warnings? Where the UI thread is the same as your eLisp thread? Where multiprocessing is a super clunky fork-exec with a weird side buffer? Where a simple regular expression works differently between what the user invokes and how you'd write it in a function?

Yeah, it's a super joy to write.

It is a joy. When writing code in the ivory tower :-)

As someone who uses Emacs and likes writing lisp, 100% agree. elisp is without a doubt the worst lisp still in common use.

I disagree, I like JavaScript

Elisp arguably has worse warts than Javascript. For example, non of Javascript's legacy 'var' scoping nonsense compares to elisp's archaic model of using dynamic scope for everything by default. On top of that, modern Javascript implementations are of extremely high quality, whereas Elisp is stuck with an interpreter of mediocre performance.

I have not played with VS Code a lot, but I get the impression that, yes, they aim for something similar. I'm not qualified to judge, though, how successful they are so far.

FWIW, when I hear people talk about VS Code, they appear to like it very much. But AFAICT, it has some way to go to catch up with all the functionality emacs has accreted over 30+ years.

Also, there is an effort replace the old lisp engine inside emacs with GNU Guile, which is a JIT compiler that supports Scheme, ELisp, and Javascript. I have not tried it so far, but it might become possible to customize and extend emacs with Javascript in the not-so-distant future.

Isn't the Guile effort practically dead? I remember hearing about it 10 years ago.

It was actually started in 2000 and doesn't seem to have progressed since 2014: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht...

Plus, even if it's finished, will it get any traction in the ecosystem? Will the ecosystem start moving to it to take advantage of its unique benefits? Who knows?

Bonus: Have you heard of GNU Hurd? :-)

I honestly don't know about the state or progress of Guile Emacs. I know it exists, but I haven't followed it beyond that.

Assuming it gets "finished" (is any software ever finished?), it should be no-brainer as long as it provides backward compatibility with old elisp code. And open up the emacs ecosystem to Scheme and Javascript, which could make it much more attractive to newcomers. But, as they say, I'll believe it when I see it.

The trouble with Hurd, IMHO, is that I've run out of jokes. We used to joke that it would run Duke Nukem Forever out of the box, but that one actually got finished. Then it was Perl 6, but that has arrived, too. Star Citizen maybe?

Yes, Guile Emacs got abandoned, at least the last time I checked.

Is that like what the GCC-emacs project is doing with libgccjit? They are working (and have a great start on it) version of compiling most (all?) elisp with libgccjit to speed things up a bit if I understand it correctly. I have compiled it myself and it is most certainly faster to load and do "intensive" tasks faster than stock emacs. I've loaded both DoomEmacs and SpaceEmacs successfully with it.

Not exactly, VSCode is more of an editor that can accept very advanced plugins. The "virtual JavaScript machine with a standard library for writing graphical (text) applications." is a web browser.

In a couple months I'll have been using emacs for 30 years, and it seemed like a pretty good summary to me. In that time the closest I've gotten to using any of the lisp stuff is setting some variables in my .emacs file. (and it's been fewer of those as the year go by)

I never claimed to be an emacs user. I've used Linux exclusively at home since 2001, and I've never "switched" to it or vim, though of course I have a passing familiarity with both from such things as certifications or working on other people's machines.

Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general).

But this was about its popularity relative to other editors, not relative to other scriptable framework things.

Thing is the difference between Emacs undo tree and …other editors undo is way more than the key binding. Your comment barely scratches the surface of the issue.

It's an early web browser. Elisp is an early JS. Viewing documents is just a little more complicated (download packages, sync stuff down using Git, etc)

>>What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.

Well then in that case, ship a better Lisp than emacs lisp?

Reply on news.ycombinator.com