Emacs 26.3 | Hacker News Reader

Emacs 26.3

lists.gnu.org

239 pointsAnon84161 comments

Great job a very good example of programmable editor.

Emacs had been my work horse since 2002 and never disappointed. In the meantime tried many ide only vim and emacs stayed with me. Sometimes do use nano and sublime text but then back to either emacs or vi.

All those shiny IDE based on electron, Java or C++ are just too slow to be productive be it VScode, atom or eclipse or visual studio or kdevelop. I am forced to use them due to tooling support for some framework. But I avoid them as much as possible once I have configured emacs to work with the language or sdk or framework or library in question.

http://spacemacs.org/ with its org-mode and magit (https://magit.vc/) integration, combined with the modal editing of vi, is truly superior.

Don't care about your platform, desktop (I'm typically working over SSH in the cloud, so why bother?) or any of that hooplah.

Just waiting for everybody else to catch up.

I have been using Spacemacs exclusively for around three or four years and I don't know if I can actively recommend it.

The problem is that the 'stable/master' branch of Spacemacs is incredibly outdated. I found myself needing fixes or improvements that existed in 'develop' so often that I migrated over to that branch. The idea of regularly cutting stable releases just isn't done within that project so if I'm recommending Spacemacs to new users I have to give them installation instructions that aren't provided by the documentation. Also, to get more up to date documentation I need to go to the layers docs in the GitHub repo and that can be hard to track down.

Every fresh install I've setup there has just been... so many problems with melpa and pulling down packages. Most of the time I have to repeatedly delete the package cache and restart Emacs until Spacemacs successfully pulls down packages - usually using the insecure flag so that packages aren't downloaded over HTTPS.

It's just... not as a polished as installing VSCode and a bunch of extensions. Spacemacs can require a lot of work and patience and I've just had too many things break with it over time.

I've had a similar, although not as extremely bad, experience to you. It does make the project look bad, but I've actually run into this issue with lots of stuff where "stable" is horrendous to use (Debian) and gives the whole project a bad name. I wouldn't mind recommending spacemacs to a friend around my age, but I guess the issue of having to be on develop is something that would make me hesitant to recommend it to my parents (something I've genuinely considered, by the way).

I also frequently wonder how I'd introduce spacemacs to someone who hasn't used vim or emacs... I used vim for a very long time, so to me it's great that my knowledge carries over. I just don't know if it makes complete sense to say to someone "vim has better bindings than emacs, so even though this is emacs, you should learn these vim binds". Plus then they should probably still know at least the basics of emacs for screens where evil fails you, or for if they ever have to use emacs on another machine, or for when an emacs bind is better ("C-x h" seems better than ggVG to me).

as a vim user, I'd have to say no... don't recommend it to vim users. There have been, for me, too many edge cases where I just end up in that helm(?) display thing at the bottom when I was trying to do some simple thing. For ages :edit and :write and :quit didn't work. As the parent poster mentioned the installation doesn't work. You really have to be willing to work for it. I've commented about the incorrect docs and the need to tweak things to make it use insecure downloads and they seem content with the idea that there's a known workaround, that isn't mentioned in the docs.

i really _want_ to use it. I love vim's modal editing, but extending vim is a pain in the butt, and I'd love to use lisp to tweak my editor.

But, I absolutely can not recommend spacemacs right now.

Installation process is broken crap (at least on the mac) and you end up having to deal with meta-this-that-the-other way too often for simple (non-advanced) vim commands.

It sounds like you're avoiding some of the benefits that emacs brings. Helm was one of the biggest additions for me. I also love that every action is a function that can be called, and that you can make your own functions. I often hit `SPC SPC` and then run commands from helm. I've even used its fuzzy-finding search to find functions I wasn't sure existed. It's a real joy for me.

I do use `:e` and `:w` pretty often, so I'm grateful those work. I suppose I would've felt very differently if I'd ran into issues with them early on. I don't actually use `:q` from spacemacs since with emacs you often leave open all your visited files. If I do want to get rid of something, I tend to do `SPC b d` for buffer delete.

>installation doesn't work

I think on my GNU/Linux machine the installation worked for me. I first started switching to the develop branch because of a bug in one of the layers I enabled that was fixed in develop.

>insecure downloads

I definitely haven't made this change that people are mentioning.

Have you used vanilla Emacs + Evil? Any thoughts on that combination?

What do you suggest instead?

Is there a nice how-to for setting up emacs with evil mode and a reasonable set of defaults that don’t require endless tweaking?

I don't really have a suggestion, to be honest. I've only used Emacs within the context of Spacemacs and don't know of a better alternative. Maybe sometime later in my life I'll look at what Emacs looks like without Spacemacs. I've been putting that off because I haven't really learned elisp and I don't know if it's actually possible to have a more flushed out and polished emacs experience without being an elisp master.

I've been planning the move to vanilla emacs for a while now. Spacemacs is a good way to see what powerful tools are out there. I'm just gonna write down which packages I actually use regularly from Spacemacs and then start my config with those and see what's missing. It will probably be a stressful transition, so I'm putting it off for now. I will probably also take the chance to manage all my emacs packages with guix at that point, too.

Doom emacs is great and way faster.

https://github.com/hlissner/doom-emacs

set capslock to ctrl and don't use any modal stuff. Also I use avy, bound to C-j, for navigation within the buffer.

Personally for me spacemacs is bit slower in startup for my liking, so I use my own custom configuration. It's just lisp at the end of the day. Also for people who prefer emacs keys instead of vi, they can start with emacs-prelude package. But it will be hard to beat custom configuration in long run.

You can also have emacs run as a daemon(1). That way you never have to wait.

1 https://wiki.archlinux.org/index.php/Emacs#As_a_daemon

There's the promise of faster Emacs (https://www.emacswiki.org/emacs/GuileEmacs written in Guile Scheme.) But it has 2 main problems: A) it's apparently stalled and B) not even it's supposedly known-good commit is compilable... :-(

This is the /real/ killer feature for me that I would find very difficult to live without and I don't know of any other editors that offer this functionality.

Being able to remotely open my editor (either from a terminal, or with X11 forwarding) with all the files I have open, exactly where I left off is incredibly useful.

I never really learned screen because daemonised emacs sufficed for me. My daemon uptimes are normally the same as my system uptimes, with the one on my VPS currently at 77 days.

A few years ago, I started using one daemon per project with server-use-tcp, each with a slightly different theme so I can easily tell them apart.

(posted from emacs-w3m)

using emacsclient in screen or tmux is kinda handy if you're using a flaky connection and keep disconnecting (like on a train)

Any benefit over using screen/tmux?

Main benefit is you don't need to remember to start your editor frame in screen/tmux and you can use both terminal and gui/x11. So when I'm at work I start emacs in X11 windows, when remote I simply ssh in and do emacsclient and connect to all the buffers I have open (if I have low latency i'll do x11 forwarding and start x11 emacsclient ) It's basically the same as tmux/screen but gives you a lot more flexibility.

Other big benefit is starting emacsclient is basically instant, so opening a file from a webbrowser or whatever is super fast (some folks have 30 second or longer emacs startup times).

Only real downside is it really sucks bringing back your state when emacs crashes and you have hundreds of buffers open for multiple projects across 20-30 emacs clients.

> Personally for me spacemacs is bit slower in startup for my liking

I have see this many times and never understood how startup time could be an issue. I startup Spacemacs at the beginning of the day, and close it when I leave. 10 second of startup time is nothing.

I never close Emacs unless I am shutting down the machine and that happens, perhaps once every month or two.

It's kind of a sign of inefficiency as, at least as far as you can tell, a similar task was done in 1/10th of the time on a 1/1000th as powerful system. This may not be true, but just as you can't get to know every person you interract with you need to use plausible correlations to make judgements and predictions.

I wonder if part of it is some people hacking emacs and going through a update-save-restart cycle instead of just evaluating their change in place.

Then again it may be the case that part of the cycle is seeing if the package management system of your custom distro (be it spacemacs, doom, or whatever) picks up and configures the new packages correctly.

I've noticed a divide between the workflows of emacs and vim users and I think it ties directly back to startup times. I'm an emacs user and, like you, I start it up once and keep it running indefinitely. Vim users tend to enter and exit the editor repeatedly during the day, typically alternating with their shell of choice.

I would say this is largely true in practice, although when I found out that vim could have multiple buffers, windows, tabs, and that you could save session files, I suddenly was keeping vim open for many hours and opening new files in my existing instance. I would say a lot of people learn vim in a hurry and don't go far beyond the basics.

10 seconds of startup time 10 years ago was nothing.

The day had 86400s then as now.

Also check out https://github.com/hlissner/doom-emacs. It has a faster start up time, and is updated regularly (everyone uses the develop branch).

Oh yes I saw it forgot to mention though.

The one thing that keeps me from moving lightweight editors like vim or emacs from the bloated IDE stuff if the ability to easily find definitions, etc. If I have hundreds or thousands of source files and I want to find the definition of say a struct or function, being able to right click->go to definition or similar is a godsend. Maybe emacs or vim have similar features via plugins though? I'm not sure.

This functionality is provided by `xref-find-definition`[1]. For many languages this defaults to using keywords from a generated tags index file, but many modes have a language server or some other more specific facility to provide this functionality at runtime. I'm not familiar with what provides that functionality for C/C++, but Ruby has `robe`, python has `jedi`, clojure has `cider`, rust has `racer`, etc. It generally requires a some setup for each language you use, but there is broad support for this functionality (and it often provides some form of symbol auto-completion as well).

Some modes also support limited refactoring tools[2], but that's not quite as common.

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

[2] https://github.com/clojure-emacs/clj-refactor.el, https://github.com/Wilfred/emacs-refactor, https://www.emacswiki.org/emacs/SemanticRefactor

My package dumb-jump might be what you want:

https://github.com/jacktasia/dumb-jump

It's easily the best zero-configuration, nigh any language symbol locator, for _any_ editor or IDE.

Thank you for that package!

Thanks to the Language Server Protocol (LSP) pioneered by VSCode, that is no longer the case. Emacs has a great lsp client (lsp-mode) and you get all the capabilities of modern text editors.

It's a great time to be alive

lightweight editors like emacs... The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again.

Ahh. "Eight Megabytes And Constantly Swapping".

Happy sigh...those were the days :-)

Is Emacs Lews Therin Telamon?

There's a bunch of "plugins" for Emacs (and vim, I guess, that provide that, but I wouldn't know). xcscope largely does what I want and I've successfully used it on very large codebases (think Linux kernel + vendor-supplied HAL + a very large amount of userspace code).

It's hard to beat an IDE on a large, disorganised codebase though, I'd lie if I said I only use Emacs and never reach out for an IDE.

That sounds like it might work. The recent instance that I ran into was working on an OS kernel, where I wanted to jump interface definitions that might be in different directories

A simple one that works out of the box (I think) with vim is ctags, install it and run "ctags -R" in the code directory. Then in vim hit "ctrl-]" when your over a name to jump to it, hit "ctrl-o" take you back up a level.

It's not as sophisticated as an IDE, but it works with practically any language and is easy to customize.

using vim for go-to-definition, `gd` takes you to local definition, `gD` to global, q.v. :help gd

I find it often quicker than an IDE..

It's a pretty basic feature, so of course they can do that, and now with language servers they can do even more.

What they usually can't do is the more involved stuff, like refactoring, because there is no company who pays people to implement these for emacs/vim.

You can do refactoring in Emacs for many languages with packages like js2-refactor, clj-refactor, etc. It's language-specific.

It's true that funding is important. CIDER has benefited from this system: https://www.clojuriststogether.org/projects/

> Sometimes do use nano

After learning vim, I couldn't stand using nano. It seemed like the worst of both worlds. No efficient keybindings like vim, and no mouse support like other conventional text-areas.

Hearing/reading you say that you sometimes use nano made me curious of why and now I see that there seems to actually be quite a few features. I see it has macros, autocomplete, mouse support, autoindent, multiple buffers, editing keybindings to e.g. delete word-wise, linting support, etc.

I never knew... and totally misjudged it as a very basic text editor.

It's still basic when compared with vim or emacs, but now I hold it in far higher regard than Windows Notepad at least.

I kind of feel like that time many years ago I found out that sed had more than just s///.

I've found sublime text to be the one exception to the slow text editor trend. It's native ui instead of based on electron, wish it was open source but I'll happily pay for good software.

I run emacs -nw --daemon, but on OS X it's noticeably slower (running in iTerm, tmux) than it is on Linux. It's not what I would call snappy at all tbh. I've checked it's not my config. I wonder how come?

That's the exact setup on macOS I run as well. I also run that way on my Linux development box (iTerm2 -> tmux -> ssh -> linux -> tmux (nested) -> emacs -nw --daemon) and it feels the same to me.

I run emacs-plus macOS variant, which one are you running?

Tried everything to no avail. `history | grep "brew install emacs"` gave me this:

  brew install emacs
  brew install emacs --HEAD
  brew install emacs --with-cocoa --with-imagemagick@6 --HEAD
  brew install emacs --with-librsvg --with-cocoa --with-imagemagick@6 --HEAD
  brew install emacs --with-gnutls --with-librsvg --with- 
 cocoa --with-imagemagick@6 --HEAD
  brew install emacs --devel  --with-cocoa --with-gnutls  --with-librsvg --with-imagemagick
  brew install emacs --HEAD --use-git-head
  brew install emacs-plus --HEAD

The thing is, I like to have things like auto-import, auto-complete, errors in the editors and other nice things (in Scala typically).

With Emacs that means Ensime, and Emacs becomes just as slow as VSCode+Metals or IntelliJ.

Testify, friend.

The most flexible programmable editor is probably Acme though.

I've seen implementations of ACME's plumber as Emacs modes, I haven't seen implementations of Emacs in ACME.

ACME's plumber is very cool, and allows very easy customization of how some things work. Much easier than these things typically are in Emacs. But this behavior is implementable in Emacs (I wish it were standard), and lots of things that are hard-coded in ACME are fully customizable in Emacs.

Sure, Acme lacks - well: intentionally does not have - theming, font changing etc., although some modifications (like Acme2k) exist which change that. Acme is probably more about "getting things done" than about "looking good" ... :-) (that sounds harsher than intended - I like Emacs for its flexibility and it was my Usenet reader until last month).

Interestingly, the first Emacs "plumber" which I have found after you wrote it literally uses Acme's plumber: https://github.com/alcah/sink.el

I wish Emacs had 9P support though.

So it's not the most flexible then.

I'm sick of managing 5-6 different installs of language server protocol servers. A couple are installed with my package manager (clangd), some are installed with pip (pyls), some I just have symlinked into ~/.local/bin (microsoft/python-language-server). It's overly difficult to get right.

If anyone is aware of a better way, especially for emacs users, I'd appreciate it. Is this something where docker or snapd might fit in well?

Guix or Nix should be able to handle a problem like this. They can handle normal OS packages, emacs packages, python packages, etc. Hard to say which one you should try. Maybe search the package lists on both sites to see if they have everything you need packaged already. Nix has more total packages, but Guix has a lot of emacs users.

For python just use Elpy [1] or anaconda-mode. Microsoft Language Server is nice but use it for things you can not find a package in elpa or melpa.

Obviously you can use emacs-prelude [2] or spacemacs [3] in the beginning and as you get familiar write your own init.el or packages to make it work the way you want.

I have yet to see anything like tramp allowing seemless work on file over ssh, org-mode, ledger-mode, ERC in any other editor except may be some in vi.

Indeed magit is better than any tool you will find for managing git repository. I can go on and on. You have to give it a try to see it for yourself, it pays for its learning curve over the time you use it.

Initially those parentheses looks awkward, but once you get around it with understanding lisp, you will not want to go back.

[1] https://github.com/jorgenschaefer/elpy

[2] https://github.com/bbatsov/prelude

[3] https://github.com/syl20bnr/spacemacs

I have my configs where I want them, packages installed with straight.el, managed with use-package, I'm not confused on how to set up the emacs side of things. I just want a unified mechanism to install dependencies.

> Microsoft Language Server is nice but use it for things you can not find a package in elpa or melpa.

That's overly restrictive. I use company as my capf provider and hook company into lsp, it's a nice unified interface and it never gets in my way.

What I'm looking for is a mechanism to manage the dependencies of extensions. For example, the elpy readme clearly says, "pip install jedi rope flake8 autopep8 yapf black".

Ask yourself the number of ways packages might get installed on a given system (apt, chocolatey, homebrew, pip, pacman, nix, guix), and recalibrate how smart you want humble emacs to be.

tramp is the best and well worth knowing.

It is basically emacs over ssh (although there are more possibilities)

You can install emacs on one machine, then use tramp for all the rest.

It's also great for machines that can't run emacs, for example you can edit config files on iot devices.

Other interesting things: picture mode, artist mode, pong, fireplace.

my tip for the day:

  (global-set-key "\M-+" 'text-scale-increase)
  (global-set-key "\M--" 'text-scale-decrease)
  (global-set-key "\M-=" (lambda () (interactive) (text-scale-set 0)))

snap seems to be more about bundling dependencies with packages to make dependency management trivial.

sounds your problem is more fragmentation rather than too many servers. Adding another package manager/virtual environment manager on top of that might just be more headaches.

I just use spacemacs and it handles that for me.

Spacemacs abstracts the client side away but you still have to manage the servers yourself.

Spacemacs is disturbingly slow.

I don't know if you find spacemacs disturbingly slow while editing or just when it starts. I was disturbed by the latter and have emacs set up to run in daemon mode and have the following in my .bashrc:

  function em() {
    emacsclient -nw "$@"
  }

so that I can call "em" with any necessary arguments and start an emacs session without having to wait. Works for me (though depending on the language I might still prefer vim).

The emacs "daemon mode" works just well to solve the latter, indeed. But the general lack of asynchronous processing can be annoying, although async.el already exists.

Just choose Ivy over Helm. I thought the same, but after switching to Ivy everything got fast again.

Haven't tried that in a while... Thank you.

NEWS: https://www.gnu.org/software/emacs/news/NEWS.26.3

This page is being rendered as DejaVu Sans Mono on my Debian Firefox. This font apparently does not have the Form Feed character [1], so I am getting a bunch of nonrendered characters, once before every * heading (but not before ).

Incidentally, my emacs font face is also the same, so I am also getting a bunch of ^L in emacs C-h n.

[1] https://unicode-table.com/en/000C/

Is Form Feed ever a character that a font renders? It’s whitespace, after all. And (hard to be certain on the phone) this “website” is likely just a text file. Maybe Firefox just does not like form feed in general.

That emacs displays form feeds as the Control character ^L (which it is) is also normal, and if you just curled the file confirms that it’s just a plain old text file.

You're correct: FF is not a printable character. But I'm seeing the same issue with Firefox on Windows (with some monospace font). I suspect that the issue is what Firefox complains about in the developer console: The file does not have a defined encoding. In fact, the Content-Type header is completely missing. I guess that those replacement glyphs are just Firefox playing it safe in the face of uncertainty regarding the character encoding.

I use the page-break-lines package to show these a bit more nicely (IMO).

So ... only two relevant changes this time?

for many of us this fixes a show stopper bug while downloading packages from MELPA/ELPA. I was just trying to setup on a new Fedora box (emacs-26.2) and my setup kept failing on "Failed to download archive...".

Which change fixes that?

The new certificate mentioned in the announcement, probably.

Am I blind? I can’t see a certificate mentioned in the link or the parent’s NEWS link...

Right from the link:

> This release is mainly a maintenance release, which contains a new GPG key for GNU ELPA packages.

The release notes explicitly stated this is a maintenance release

Looks that way.

I recently tried to seriously use Emacs over my usual Vim. Mainly because I've got so used to the GNU readline emacs shortcuts in the terminal and quite like the idea of not having to switch between command and insert mode, but damn after looking into some configuration options it really is a massively complicated piece of software, I mean not to start using it, it's probably easier than Vim but just looking at all the various modes, plugins, the whole ecosystem behind it. Even emacs lisp doesn't put me off, with some albeit minor exposure to Scheme and Clojure in the past. Especially now that I have got comfortable with Vim having no plugins but knowing enough Vimscript to be productive, I really don't think I'll switch, it's too much of a commitment.

I just started with vanilla emacs, and used it for not much more than writing notes in org-mode.

It was a few months before I started editing my config files, first to get rid of the start up message, then to handle some org exports, then to do a little python programming.

Your config file grows as your use of emacs expands. I now use it for programming, task management, email, calendar, accessing remote files, git, and occasionally a little note taking.

The worst thing you can do with emacs, when starting, is to look at other peoples .emacs files. It's just intimidating

Emacs users are often so enthusiastic about all the things emacs can do that they overcomplicate the experience.

Just open emacs with no customizations.

You can do everything with a tiny handful of commands, many of which you already know: c-F for forward char, c-B for backwards char, c-P for previous line, c-N for next line. It's modeless so if you type you'll see your keystrokes. Run the tutorial to learn a few more (c-H t -- c-H is "help").

One difference in emacs compared to many other editors is that search is so lightweight that it's trivial to use search to move the cursor around. So actual "cursor movement" is less common.

I was pair programming with a colleague who's been using Emacs about as long as I have (since 1978) and the other day he learned a new command. "I can't believe I survived with this command", he said, but really, he had done just fine.

Yeah it's good advice, it's how I treat Vim really, I have a handful of keybindings to make it easier, but generally just stick to the defaults with everything and stay away from plugins.

> I recently tried to seriously use Emacs over my usual Vim.

For the fellow Vimmer, I suggest Doom Emacs. I'm using it to type this message now! Yes, it's a distribution with many batteries included, but you can eliminate what you don't need. It's quite flexible, and the dev is very responsive.

I recently dropped Vim and going with vanilla Emacs. I reconfigured my current Emacs/evil-mode config and took out everything evil related.

For the next few days I painstakingly worked through the keys. By the end of the week, I had enough. I felt too slow and my hands started aching ironically. My current Linux environment relies on me to easily switch between windows with HJKL and other shortcuts I've instituted over the years. Also, I work on two different keyboards. Both work fine with evil-mode, but one required some serious rebinding just to use vanilla Emacs.

I returned to evil mode and feel right at home. I did take some things with me, such as C-a/e for moving to the beginning and end of a line and C-d and C-k for deleting characters and lines, respectively.

I'd love to hear from Vim and Emacs users on why they preferred Emacs' bindings over Vim's, if that ever happened.

Thanks for the responders to my parent comment. I might look into spacemacs or DOOM emacs, I've heard about both and seen some videos and obviously either sound like a good way to switch over. I'm not actually having any issues with Vim that is encouraging me to switch, but stuff like org mode, email clients, magit and other things can all be run out of emacs is very intriguing indeed.

I'd personally recommend the opposite: start vanilla (with Evil) and understand why you're including every package you do. But you might not find that productive enough to stick with, so maybe try DOOM or Spacemacs as well?

Org mode is good, but most Emacs mail clients are pretty meh. The primary advantage is getting to use the same interface to everything and being able to customize everything easily. With the relatively small volume of email that I process, it's just too much work to keep all of the configuration working for mail in Emacs. Magit is cool, I think you'll enjoy it.

If you're looking for an easy switch, I'd recommend DOOM Emacs (https://github.com/hlissner/doom-emacs)

> I've got so used to the GNU readline emacs shortcuts in the terminal

If you happen to be using bash, "set -o vi" was a godsend for me.

You should also check out the relatively new setting that lets you visually track your mode.

    bind 'set show-mode-in-prompt on'

You probably shouldn't switch. I'm an emacs guy myself, but from what I can see, the advantages of vim are equal but different. If you are skilled with vim, there's probably no good reason to switch at this point. We could have a good argument about what you should have started with, but I'll pass.

As someone who has gotten the hang of the keybindings and only just started learning Vimscript, I'm curious whether you think I should stop and switch to Emacs.

My personal experience as someone who started with vim and than switched to emacs:

If you intend to do a lot of customization to your editor, or expect IDE-like features, I feel that emacs is the superior choice.

elisp is a OK scripting language. Rather quickly I could read and understand the internals of emacs packages (and of some of the emacs internals itself!), despite having basically no experience with lisp. Self-documentation and explorability is truly incredible.

I never really looked into VimL, but my understanding is that it is really not as good.

I still prefer vim bindings, so I use evil-mode on my "vanilla" emacs and vim bindings in spacemacs (well, "hybrid" bindings to be exact).

So my personal take:

- vim for sysadmin, being able to run a fast minimal editor behaving the same on multiple machines

- emacs for development, where having a "tailor-made" editor with lot of config/customization is important

> - vim for sysadmin, being able to run a fast minimal editor behaving the same on multiple machines

Have you tried TRAMP? It's not just something that lets you have your Emacs config on remote machines: it brings the remote filesystem to your machine. (It's a little like sshfs except more powerful and much more convenient.)

Since I was being asked, I'll say this is an excellent answer.

Not that guy, but IMHO if you find yourself reaching for Vimscript, that's about the point where learning Emacs/elisp is probably the better investment.

There's highly recommended pre-configured packages like Spacemacs or Doom-Emacs that ship with vi-key support enabled by default, allowing you to keep much of your muscle memory.

As this is not an overnight conversion and you are quite proficent with vim already, my advice is to:

- Get used to type "emacs file.txt" instead of "vim file.txt" in your console.

- Have a function in emacs that opens the current file in vim for those moments where you just want your trusted environment. Writing it by yourself is a good focused learning experience.

This way you'll decide (and balance) how much you want to learn every day, and little by little you'll find yourself using that function less and less.

GNU readline supports vi keybindings. Stick to the one true editing experience! https://www.gnu.org/software/bash/manual/html_node/Readline-...

if you are serious about switching go for spacemacs... it's an emacs that is tuned to be pretty good out of the box and caters mainly toward vim users.

Might I suggest GNU Nano? It has many of the same Readline shortcuts, but it's a lot simpler. It's what I've settled on. (Seriously.)

Yeah you might be right, it's tempting, simpler does sound better. I occasionally reach for nano when I'm on a system that doesn't have Vim out of the box (and I don't want to use vi, which is always there, but is just that slightly different to Vim in a few subtle ways to be annoying).

I've been trying to switch from vi to emacs. Partly for Clojure, partly because it's free and I've grown tired of trying to convince employers to buy me software tools (they never do).

Overcoming 20 years of vi muscle memory is hard. You just have to go 100% emacs and eat the reduction in productivity for a few days/weeks.

I'm getting there...

The improved js-mode in 27.x is definitely worth checking out, especially if you use React/JSX. Had many issues wrestling with indentation in previous setup. https://github.com/mooz/js2-mode/blob/master/README.md#react...

That is very good to hear. I've used Emacs for a decade, but I recently switched to VS Code because JSX support in Emacs was such a mess.

I'm a VSCode user as of a few weeks ago for the same reason. Trying to get React to play nice in emacs, especially when compared to what I got out of the box in VS Code, was an exercise in frustration. Similar problems with Elixir.

I really love spacemacs but I just genuinely don't have time to screw around with my editor constantly, so I ported the bindings I found essential from spacemacs, turned on VS Code's vim emulation, and it's actually been a pretty good experience. It's not perfect, but it's good enough.

rjsx-mode has been around for a few years and handles jsx fine. coupled with prettier mode, I don't have any complaints. have you given those two a try?

Consider the poor quality of the existing js modes for 26.x, any idea why this depends on a future version of Emacs instead of current versions?

Alternatively, could somebody convince the author of the railwaycat port (Emacs with better macOS integration) to get a version 27 out soon?

> Consider the poor quality of the existing js modes for 26.x, any idea why this depends on a future version of Emacs instead of current versions?

You might as well look at the thread js2-mode was revoked[0] and ergoemacs' article[1].

> Alternatively, could somebody convince the author of the railwaycat port (Emacs with better macOS integration) to get a version 27 out soon?

Er... I would like to point out that it's not 'railwaycat' port but more of Mitsuharu Yamamoto's port[2], and AFAIK he has claimed that he has no interest in maintaing an emacs27 version.

[0] https://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00... [1] http://ergoemacs.org/misc/emacs_javascript_mode_war.html [2] https://bitbucket.org/mituharu/emacs-mac

Disregarding the history behind js2-mode, if it has been decided that Emacs 27 will feature a much improved js-mode, I was just puzzled that it wasn't put into 26.x as a package already.

I couldn't remember the name of Yamamoto, which is why I said the author of the railwaycat port, where the latter is mostly packaging if I understand it correctly. But Yamamoto is doing most of the heavy lifting yes, and I'm thankful for it.

No. He builds off of stable releases because otherwise something could change in the underlying implementation that breaks emacs-mac. It would mean more maintenance on his part.

IIRC the creator also releases his port as a patch. You can always try to patch emacs 27 with it.

I tried vscode the other day to see what it's about and it's nice, but I found plugin development convoluted and very limiting compared to emacs.

No chance of quickly writing a script to automate something in the editor, because it takes so much time that it's not worth it for quick editor code snippets.

Other editor users simply have no concept of how easy it is to whip up some quick script to perform some task in emacs.

> Other editor users simply have no concept of how easy it is to whip up some quick script to perform some task in emacs.

I don't want to start a flamewar, but I moved most things I was doing in Emacs to Textadept a while back because I found Textadept more convenient. That's not to say TA does everything you can do in Emacs, but it replaced all of the scripting I was doing with Emacs.

You have the full power of Lua inside TA. Emacs always has a lag when I start it up, whereas TA is instant. I slowly built up functionality inside TA to the point that I realized I could replace everything I was doing in Emacs.

It's so small and lightweight that, just for fun, I wrote a "web browser" inside TA. It calls out to lynx and loads a readable text version of the page. I use a keyboard shortcut to open links. I have functions for searching the web, I can search YouTube and open the videos in VLC, and so on. This was a practical thing to do: I can use TA as a browser on really old laptops.

It maybe isn't for everyone, but in Emacs when I was doing this[1] to duplicate a line:

C-a C-SPACE C-n M-w C-y

I asked why I wasn't using a better text editor. In TA, it's C-d. Just as Emacs is an interface for Emacs Lisp, TA is an interface for Lua, and with a lot less overhead.

[1] https://stackoverflow.com/questions/88399/how-do-i-duplicate...

Of course I meant editors which I know and tried like vscode. I don't know Textadept, so it may be easy to write quick scripts in it.

As for your C-d example, it's a trivial function in emacs which I too wrote many years ago and bound to C-d, so it's not a compelling example, because it can be added trivially in emacs too.

> it can be added trivially in emacs too

Agree with everything except "trivially". Emacs is a house of cards. Pretty much every shortcut is already taken, so then you have to figure out what's already bound to C-d, and how your change is going to interact with everything else you do. For one binding it doesn't matter, but doing that kind of customization over and over gets annoying, causes the init file to balloon, and slows the startup time.

Which OS do you run Textadept on?

> No chance of quickly writing a script to automate something in the editor, because it takes so much time that it's not worth it for quick editor code snippets.

Take a look at Atom[0]: you can almost think it's a bit underpowered Emacs that uses CoffeeScript(JS) instead of Elisp.

It uses the same mental model as Emacs; the init file is a CoffeeScript file, not a JSON file with packages (like VSCode).

[0] atom.io

Does it also offer an api for plugins, instead giving access to all of the editor like emacs? Because that is one thing I found limiting in vscode that I can do only what the api devs thought of.

> Does it also offer an api for plugins, instead giving access to all of the editor like emacs?

I'm not sure what you're asking; Emacs also exposes a set of APIs. If you're asking if Atom's init file is written as a generic programming language (unlike VSCode which uses JSON), yes it is.

If you're asking if Atom's API is sufficient enough to implement radical modes (like js2-mode in Emacs), AFAIK yes. Atom by default doesn't have a terminal or a browser; but there are several packages to do them. However I'm not too familiar with the Atom's API surface; I've never used Atom as a primary editor, but more of a backup editor for when I'm recompiling Emacs/reinstalling Emacs packages, ... so I'm not sure about the last sentence.

Could you do the work in a plug-in to allow easy creation of scripts as a solution? Or is there an execution sandbox preventing that?

Also I never really thought of writing scripts for editing in emacs thanks for the brain shift that clicked for me.

If you want to write a new command for vscode then you have to register it in contribution points in the editor which is done in a json file. I don't know if you can do that dynamically and if you can't then you can't create a quick throwaway editing command either.

I very often write few lines of temporary commands if I have to do some mass editing which can be automated.

With vscode I'd have to do it in python or something outside of the editor which is much less convenient than an emacs script which can work on a file as a buffer.

Can a contribution point run commands from a random file?

I'd say no, but I'm certainly not a vscode expert.

From TFA:

> This release is mainly a maintenance release, which contains a new GPG key for GNU ELPA packages.

I have been a happy Emacs user for over 20 years. I love that I am still learning new things about it!

I'm running with the emacs version from git for a while, and on the Linux machines even with the jit, but it's pretty unstable still. The jit causes lot of memory pressure, and on save it often runs a blocking major GC, which needs half a minute or such. Or even more. Very annoying. On Mac I'm running some latest version without jit, which is also very unstable.

Have to test if 26.3 without the jit is more stable.

I treat emacs as the only alternative to vim on the server. On your own GUI machine there are plenty of alternatives.

Do people recommend the use of emacs over vim on servers? (Mainly editing server config files and reading long logs) Any good plugins to enhance its use for this use case?

I have pretty much ignored emacs for the last 15 years when I felt it didn't act as snappy as vim.

On MacOS, I wish homebrew emacs-plus can be updated with the lastest version of Emacs quickly.

I use https://emacsformacosx.com/

what is the "plus" in emacs-plus?

Try the railwaycat port.

Any improvements for the Windows GUI ? I find it to work better with WSL and VcXsrv.

As a long time Windows users, I could not understand why anyone would love emacs. It's slow on Windows and locked up often for me. When I switched to Linux on the desktop though, I understood. Input latency in emacs is less than in gnome terminal for me. Never thought I would say that emacs feel snappier than vim, but that seems to be the case in my current setup. Also, I recently discovered magit and now I don't hate using git anymore.

Emacs performance in general (not just Windows) has been a complaint forever. Back when Emacs was first launched, and machine memory was measured in megabytes, people joked it stood for Eight Megabytes And Constantly Swapping.

Today gedit has twice memory footprint of a tricked out Emacs, however.

Only back then it was true. Now it’s only slow on Windows for some reason (and maybe not universally so, though I don’t use Windows enough to have bothered investigating).

While that's true, what's not slow on windows except maybe AAA video game titles? e.g. the "right click" on the Windows 10 desktop takes time to show up (even on a high end desktop pc)... just to show a contextual menu.

It's still very slow with a lot of Elisp code (Spacemacs, for instance). Maybe the memory footprint is better than VSCode, but VSCode starts faster and is more responsive than Emacs with a ton of packages.

Still waiting for Guile Emacs to solve that.

Of all the problems Guile Emacs might have fixed, performance on Windows is not one I considered.

I don't know if it would, but I can imagine that replacing the aging Elisp interpreter would improve the situation on all systems.

Yeah but does guile even work on windows? Last time I checked it was still very much confined to *nix systems.

Guile probably would, but Guile Emacs is not ready (yet?).

I can't stand Emacs on Windows. Even trying to keep a simple TODO list in org-mode is painfully slow for me. I was explaining to a co-worker how amazing emacs and when I showed him all he saw was a lag ridden mess. I use it at home on my Linux desktop mostly with some python development and ledger-mode and it's amazing.

That's really unfortunate. I was using Emacs on Windows back around the year 2000 and it was fine. I wonder what happened in the meantime.

This is what I use and to be honest, I don't see any reason to use the windows version /at all/ for Emacs. WSL and VcXsrv requires minimal set up and works right away for me.

I used to have code in my config files to try and handle different paths, etc. when I was in windows vs linux and now I don't have to worry about that anymore.

The Windows GUI is a bit slow. I found that I disabled all the bars anyway though, so using the CLI version of GNU Emacs is acceptable even on Windows.

YMMV

The Windows version is complete unusable for me because of how slow magit is on Windows (though that's not the fault of magit or emacs).

I haven't yet tried WSL (I run Windows on a work issued laptop), so my emacs sessions run in a Linux VM to get acceptable performance.

Hehe insane, you get better performance in a virtualized environment! I understand why that could be but virtualization overhead exceeding native performance is bonkers.

You can give WSL2 a try. It has speed improvements.

> how slow magit is on Windows

I am relieved, though, that it's not just me.

From my experience, Anything that launches subprocesses is slow on Windows.

I use Emacs in Debian on WSL with X410 and it’s fine, no perceptible lag.

Git is definitely slower in Windows

Gnus is unusably slow for me. I wonder if that is related to Windows as well...

Where did you found Emacs 26.3 for Windows? The official FTP site has only 26.2 as the latest Windows binary.

This might not matter for your case specifically, but last time I was on Windows, I found it straightforward to compile it using the msys tooling. I mention msys specifically to avoid bringing cygwin.dll into the mix, which caused me no end of headaches.

http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W...

As with most things in that realm, the hard part is getting all the dependencies (libpng, etc) but (a) since msys2 switched to pacman that looks a ton easier (b) AFAIK building with those graphical libraries is a nice-to-have for w3m support, so if it's a hassle you can skip it

Just be forewarned that [again, last I checked] msys has a bad interaction if your machine is a member of an Active Directory domain, but you are road-warrior-ing and it is unable to reach the domain controller; one of my more popular SO answers: https://stackoverflow.com/questions/929495/why-is-mingw-very...

I guess you can try one in pretest?

https://alpha.gnu.org/gnu/emacs/pretest/windows/

I like https://emacsformacosx.com/

In dired-mode, now you can zip a directory using command 'Z' over the directory. Wow!

Reply on news.ycombinator.com