Emacs 26 Brings Generators and Threads | Hacker News Reader

Emacs 26 Brings Generators and Threads

nullprogram.com

207 pointsingve167 comments

In all honesty, the main selling point of Emacs for me isn't just how configurable it is but also how performant it is in different environments. Since VSCode uses Electron editing feels sluggish, high ram and cpu usage is expected, and there's a noticable latency between keypresses. While these may seem like trivial issues, they actually negatively impact my typing experience to a high degree.

I'm currently using the Doom-Emacs distribution for Emacs and everything is working very well. I can use vim keybindings in addition to many other customizations and improvements with very little time invested in actually writing elisp. This is mostly because the developer of the distribution is passionate and optimizes his configuration for modern languages so there is very little needed to change.

If VSCode or any other text editor managed to provide a fast yet highly configurable editing experience without draining my laptop battery instantly, I would immediately switch. So far, none have been able to meet this specification even though I have tried almost all of the common text editors.

I'm hoping a project like the Xi text editor might one day actualize my desire.

> While these may seem like trivial issues, they actually negatively impact my typing experience to a high degree.

I don't think these are trivial issues at all. I do the majority of my computing work in a text editor so it's important to me that it's as performant as possible. Imagine if, in real life, there was a slight lag every time you sent a "command" (e.g. pick up coffee). It would drive you crazy. And yet a lot of developers think that lag is acceptable in software. (I say "developers" because a lot of non-developers I meet complain about software being frustrating to use, even if they may not consciously notice it is laggy.)

People think I'm joking when I say this, but I'm so attuned to Emacs, especially when I'm in a flow state, that I can actually feel when the garbage collector kicks in. It totally throws me off. I have a bunch of optimizations set up, like running GC whenever I tab out of Emacs or am idle for 5 seconds, but sometimes I can still feel it. I hope Emacs makes some progress in this area -- I hear there's a Rust rewrite in the works :)

> If VSCode or any other text editor managed to provide a fast yet highly configurable editing experience without draining my laptop battery instantly

This is huge for me. I basically work by grabbing my laptop and sitting, standing, or laying wherever I feel like. I can't stand the idea of having an "office". So I'm acutely aware of when an application is running down my battery. Emacs is awesome in this regard because it has no noticeable energy usage, which boggles the mind when I think about how powerful it is as software. I honestly see no reason whatsoever to use anything else.

>> While these may seem like trivial issues, they actually negatively impact my typing experience to a high degree.

> I don't think these are trivial issues at all

I'm stunned that anyone would actually be OK with "a noticable latency between keypresses" in text-editors. This might be still a thing if the whole desktop is streamed on a slow network but it shuld be completely unacceptable for normal text-editing.

(Unfortunatly I do have that problem sometimes with emacs (on cygwin) with c++-files that are too large. But I won't dismiss cygwin.)

I think this bit is a piece of wisdom:

"I’m a firm believer that we should understand how things work underneath the hood so that we can make the most effective use of at them. No program should rely on the particulars of the iterator object internals for correctness, but a well-written program should employ them in a way that best exploits their expected implementation."

Here's what grinds my gears: That the cursor follows the visible buffer. It would be nice to be able to scroll to another part of a file and then just start typing and be back where I was ...

I mean I could understand if this was an efficiency thing to do with scaling to large files due to a kind of a tiling memory model or something, but emacs doesn't even do that!

It's not a huge deal I've learned to get used to using Ctrl+U-Space to get back to where I was.

I read somewhere that somebody tried to implement what I'm talking about but never really got around to trying it cause it seems a little half-baked.

Now I kind of want to try my hand at implementing this. I imagine an implementation would add a buffer-local variable holding the position of the point as of the last non-scrolling operation. This would be updated in post-command-hook, but only if the last command was not a scrolling command (which would probably have to be defined as a list of "blacklisted" commands that shouldn't change the point). This hook would also hide the cursor if the desired position of the point is off-screen and show it otherwise. Finally, a pre-command-hook would set the real point to the saved position unless the command about to be executed is a scrolling command or a mouse interaction (which should move the point to somewhere on-screen).

I've seen an implementation, but don't remember its name or how to find it again.

If I remember, I'll send an email to the address on your resumue.

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.

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.

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.

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

> 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.

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.

>>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.

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 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?"

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’!

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?

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...

> 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?

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.

What does Ctrl+U-Space do if you don't mind me asking? Is that some magic that you've bound? Mind sharing?

It's C-u <Space> in Emacs lingo; it pops the mark ring. Some actions like C-<Space>, M-< and M-> push the position of the point to the mark ring before moving it, and when you pop the mark ring, you jump to the position that was pushed most recently.

> Some actions [...] push the position of the point to the mark ring before moving it

Notably C-s and C-r (incremental search forward/backward). That in combination with C-space is the way to navigate in emacs like a pro :-)

(btw: its C-u C-space. C-u space inserts 4 whitespace)

TIL! I didn't know search pushed marks, thanks!

Not your desired behavior precisely, but Emacs does support recursive edits https://www.emacswiki.org/emacs/RecursiveEditPreservingWindo...

Although I've been using Emacs daily since 1991, I can't imagine how the code behind your link helps or how starting a recursive editing session helps with the problem you are replying to.

Acme does this, and I love it, but most people's response to seeing Acme is "what the hell? No syntax highlighting? No autocomplete?" You can also easily create a second "view" into a file with the Zerox command, which is a nice way to look at two parts of a file at once.

It's the best thing I've found for managing large numbers of buffers at once, though, and with things like acmego (go fmt + add missing imports on save) and Go guru integration (jump straight to function definition) it suits my needs pretty well.

> You can also easily create a second "view" into a file with the Zerox command, which is a nice way to look at two parts of a file at once.

Emacs has this too. You can look at a buffer from different windows, or clone-indirect-buffer in order to edit multiple parts of it simultaneously.

You're right, it's been so long since I used emacs I forgot it's a thing. Vim does it too, I think, but I only use vim to quickly edit a file.

Just about every other editor does this. That's why I miss it!

C-x 4 c

(clone-indirect-buffer-other-window) comes in handy

There are scroll-other-window and scroll-other-window-down which are usually bound to M-PgUp and M-PgDown. You can use these to scroll the other window (perhaps another buffer) while the cursor stays in the current one at the same position.

Yes I’ve been doing this as well

I use a bit of code that binds a key combo to "go back to where I was last editing", which lets me move around the file, look for something, copy it, and them go back to where I was last actually working in the file.

A thousand time this. I love Emacs, but the fact that SCROLLING MOVES THE CURSOR drives me crazy.

Seeing generators and threads being mentioned in the release announcement of a text editor feels a bit... strange.

Then again, Emacs is closer to a LISP toolkit for building text editors than it is a text editor, so I guess it's not so strange after all.

Emacs is an OS written in Lisp, with a text editor as sample application. :)

Also if you require good keybindings in the sample application, there's always viper :)

Evil mode is far far better than viper. Do yourself a favor and switch today.

To that end I like spacemacs. But it did incur enough of a startup penalty that have have shifted back to vim.

I oscillate between them and vscode. I don’t use vim bindings in vscode though.

Run it in daemon mode. startup time is not a thing for emacs.

It's not stable enough for me. Well, my plugins aren't. I need to be able to reset state periodically.

Plus, I like to have separate instances of emacs with different groups of files from separate but related projects. I end up with a zoo of buffers commingled in daemon mode. It just doesn't fit how I work.

I wish it had an image based startup scheme... freeze an image of emacs after init is done.

What if I tell you that you can? :) You can unexec Emacs at its current working state and it will output a new executable. Startup is close to instant!

Can't seem to figure out how to do it. I can only find passing references to it.

and tetris. and a psychoanalyst. and ...

Not only that, but also a kickass calculator! And a file manager.

Emacs is an application platform, just like how the browsers are today. It has a nice way for making UIs: it's all text, parts interactive, and you can bind keys, make hooks and thus create decent, customisable applications in it. Add to that the possibility to update code on the go and advices, and you have a very nice place to make yours completely.

I wish we had a popular OS where the main UI toolkit was similar, i.e. it provided many hooks, a universal REPL and a nice interactive debugger.

The thing is such an OS would never be popular, because the vast majority of users never will be programers (again).

There is a window manager called stumpwm like that.

Well that's just a fraction of what I was talking about. StumpWM is nice, but it's the window manager. But imagine an environment where, say in the web browser you could hit C-h k, find what function is bound to the key that bookmarks the current tab, and advice that function to make a backup of the bookmarks database. And that such mechanism being built in to the OS' application programming libraries, so that writing a GUI app becomes essentially reminiscent of writing an Emacs major mode. Imagine all apps on your desktop had hooks where you could attach code to be run on certain events.

This is cool, but it's too bad folks here don't seem to have kept up with the evolution of iteratees/enumerators and free monadic computations (conduit/pipes/streaming) that other languages have pushed forwards as evolutions of the generator ideal.

The net result for common iteration ops is quite nice, and has options for reasonable optimizations in the world of lisp where macros are real.

Could you explain or link to more info please? Sounds interesting.

I thought the natural "successor" to generators was delimited continuations, rather than iteratees or free monads/algebraic effects. Do such streaming concepts map well to eager, imperative code? I've only encountered them in Haskell, where laziness makes stuff like co-induction/recursion trivial.

Certainly for conduit the laziness sort of goes away since you must sink a source and unless you do that to some observable effect the entire result disappears and no work is done at all.

But certainly iteratees as an independent went out of fashion when conduit and pipes came on scene.

Anyone know when the Windows builds will be available for download?

An inofficial build is available here: https://www.reddit.com/r/emacs/comments/8n2wga/emax642018052...

I got it from here: http://alpha.gnu.org/gnu/emacs/pretest/windows/

It works flawlessly. I just dropped it (26.1) in on top of my existing setup and had to do nothing else and I'm working away on it right now.

When I was downloading at least, I had to download it and the dependencies separately. The README says there should be a unified zip-file but it wasn't there at the time.

Had some issues with Windows 10 refusing to merge the directories from the deps package so had to drop to a cygwin shell but it actually worked quite well even without the deps.

Flyspell in Emacs 26.1 seems to require a version of Aspell that is not officially available for Windows. I might need to put off the upgrade until I can attempt to compile a newer Aspell for Windows myself.

"Error enabling Flyspell mode: (aspell release 0.60 or greater is required)"

In case anyone else was facing this problem (and isn't too committed to Aspell as a backend for Flyspell), the version of Hunspell from ezwinports[1] (version 1.3.2 at time of posting) seems to be working with Emacs 26.1 on Windows.

[1] https://sourceforge.net/projects/ezwinports/files/

I'm not sure how you feel about cygwin? aspell 0.6 is available from there, and I've just tried it out with emacs and it works well.

Does anyone happen to know why e-lisp iterators stop on a magic `iter-end-of-sequence` instead of on `nil`? That doesn't seem Lispy.

Probably because the sequence might contain nil as an element, and you don't want to short-circuit the iteration when that's the case.

For the same reason, it's the usual thing in Lisps to break on a sentinel value (defaulting to EOF or similar) when reading sexprs from a file. In cases where nil isn't a valid element, you can always specify nil as the sentinel.

A likely reason is that it makes it possible to iterate through a list like `'((1 2) () (a b c))`. If you have to do in-band signaling, make it something unique and obscure.

In addition to the sentinel/in-band replies, they also put properties on that symbol: https://github.com/emacs-mirror/emacs/blob/81b5131e11fa96d32... ( https://www.gnu.org/software/emacs/manual/html_node/elisp/Sy... )

When is it getting it's own thread scheduler and bootloader?

Weird place to vent. But I find it so interesting that Emacs in all it's wisdom does not have (to me) acceptable undo behavior. Sometimes when I want to undo a bit, it undoes so much that I have to do a few seconds of copy-pasting.

You should try undo tree (http://www.dr-qubit.org/undo-tree.html), it's a must have extension which brings proper undo-redo and a tree visualisation of history with diffs and many other options.

undo-tree is great! I use it like a "mini git", it supports branches/forks, so I can usually just try something in any order and easily go back to where I want to be. I use it in combination with Evil (vim) bindings, and everything works like a dream.

I'll second the recommendation to use undo-tree. If your undo history is going to be tree-like, which it is in Emacs, then you might as well be able to visualize and manipulate that tree directly.

Trying it out for the first time. Love this line in the docs:

"The only downside to this more advanced yet simpler undo system is that it was inspired by Vim."

Undo has many weird sides but what you describe rarely happen to me, if at all

I still haven't figured out how the undo-direction works in emacs. It feels like half the time I'd inadvertently end up redoing.

If you did an undo in the history, it will look like a redo. So if you just did a bunch of undos, it will feel like redoing, but you are actually removing changes made by your undo.

it treats the undos as new changes to the buffer, and adds ;; them to the history:

Well, it's a true full "undo" behavior. It's a bit annoying at times because edits are not grouped, but you can see your entire editing history when you're undoing: no edit is ever lost in this manner.

As typical in emacs, this is not the only undo behavior you can have. undo-tree behaves very similarly to vim by default, but still preserves the entire editing history (with branching), which is visible graphically with "C-x u".

I too find the undo behavior quite confusing. I don't know the implementation, but I guess it is because by default instead of unwinding the stack of operations it does something like doing the opposite action. This means that sometimes you may redo an operation by mistake: for example

- Paste 5 time the same line - Press undo 3 times: removes 3 lines - Move the cursor by one character - Press undo 2 times: instead of removing 2 lines it adds back 2

It would be better if the two operations (undo/redo) would be distinct.

Basically "Undos" become actions that you can later "Undo". It's very weird. I accept that it means you never loose a change but it does feel a bit like boiling the ocean to produce some salt ... that said, it's an "alternative approach" that does have its merits. I like that about emacs, it challenges your assumptions and makes you think! As much concept art as a tool in itself.

The undo system is confusing if you are accustomed to undo/redo in practically every other piece of software, but it does make sense (in its own kind of way). See the documentation for the undo commmand[1]. Emacs undo is powerful albeit with more cognitive load to use.

I have occasionally had to take over the controls for new emacs users while pair programming because the undo, while logical and consistent, doesn’t work as it does in other software. Each consecutive sequence of undo commands, once interrupted by any command that is not an undo is considered itself to be an atomic undoable change. This means that there is no need for a redo command, just stop undoing and the last undo sequence can be undone. Because emacs has a large undo limit you can keep undoing even past sequences of undos back to the original edit points of the file’s history.

That probably made no sense if you haven’t already mastered it, but another way to think of it is that edits and undos produce a branching tree of all the history of changes being made to the file. The entire tree of changes can be navigated with one command (undo) because that command makes a traversal of the tree, kind of like a post-order tree traversal. This is sufficiently confusing in practice that seeing the nanigation through the tree via the popular undo-tree emacs package helps a lot. I use the undo-tree command when I want to get to a version of the file not on the current main line of edits.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Un...

Thanks for the tip! Despite using emacs for decades, I never properly read the undo docs.

I'll try binding the undo keystroke to "undo-only", and a redo to normal undo definition, to see if I can get something approximating undo/redo semantics.

Anyone that wants to use emacs seriously has to learn a about the kill ring. Something like Helm kill ring is great. It lets you go way back in time and re-pasted killed things.

The problem with this is I'm a web dev and I can't really do all my work in emacs. For backend people you can live entirely in emacs. Once you hit the frontend you have to start interacting with a browser. That's why I always get a clipboard manager and have my editor kill (cut) to the clipboard. Then I can hit C-V and get a popup menu (similar to helm kill ring, navigable both with mouse and keyboard) with the last 100 or so things I've cut/copied.

Vim also has an undo tree, but still manages to retain a sane user experience.

Not that Vim is any paragon of UX design. The point is that you can have a powerful undo system without breaking user expectations.

> Vim also has an undo tree

There is an undo-tree implementation for Emacs (based off of Vim), but the default undo described above isn't an undo-tree.

That's odd, I find the default undo to be perfect. Never had a problem with it. What do you mean by "undo a bit"? A bit of typing? For that I use M-backspace, not undo. Undo is for reverting commands really. Like kill line, oops, undo.

My gripe is that I only just discovered the other day it chokes on large files, and even the vlfi (very large files) extension is quite cumbersome. I was quite dismayed to tell you the truth!

Emacs usually doesn't choke on large files, but it chokes on very long lines.

E.g. SQL dumps and such.

There are two separate issues at play here:

Emacs' redisplay algorithm is not very efficient if you have very long lines. On the other had on old emacs versions (before 23 IIRC) this was significantly worse as it also had weird UX implications (C-p/C-n working in terms of logical, as opposed to displayed, lines and unability to sanely display lines that are longer than width*height of window).

Other problem is that the gap-buffer data structure is very suboptimal when you start to move the point by multi-MB offsets (which in emacs' case imcludes operations like scrolling to the other end of buffer using scrollbar) as it involves doing memmove() of this multi-MB block of memory.

I can understand being confused by emacs' undo but I don't understand what copy-pasting has to do with it. If you undo too much then you can effectively "re-do" by stopping your undo sequence (simply moving the cursor around for instance) and then undo your undoing?

A big advantage of emacs' tree-like undo is that you never lose any part of your history unlike a naive linear undo sequence. Like in this Firefox edit box for instance, if I type a word, undo it then type an other word I can't go back to the state I was in before I undid the first word. With Emacs I can usually restore any previous state my buffer was in (within the limits of the size of the undo buffer that is).

try redo+:

https://www.emacswiki.org/emacs/redo+.el

Emacs provides comprehensive building blocks for any kind of undo/redo system you could want, while providing it's very basic example implementation of undo/redo. Many other packages exist that focus on different ways to do this.

If you really want to bake your noodle, try undo-tree-mode some time.

I love the Emacs OS, but I'm just not thrilled with the editor that comes default with it. Has anyone ported Visual Studio Code to run on Emacs OS yet?

All jokes aside, is it the ui if vscode that you prefer? I have a hard time nailing it down, but aside from configuration, I do like vscode.

I might use it more if we weren’t stuck in an old version of rhel at work.

The dream is to have an Emacs with a modern UI like VSCode

I think your best bet would be to start with vscode and work toward what you like about emacs.

For me, the only thing emacs has going for it are the plugins. If I could get the plugins I use in VSCode I'd never look back. Mainly this comes down to CIDER. But a lot of people have put person-years of work into cider. And it's hard to imagine them embracing vscode.

Rather than porting plugins or making an elisp interpreter, if I were passionate enough about it, I would look for a path to being able to run a bridge (as a vscode plugin) to a headless emacs.

I have no clue how that would be done, but If I chose to believe it was possible, I would try to write an network based API to emacs as an elisp plugin to start, enabling other front ends as neovim does.

Reply on news.ycombinator.com