Emacs 25.2 released | Hacker News Reader

Emacs 25.2 released

gnu.org

136 pointsamiralul85 comments

Dupe of https://news.ycombinator.com/item?id=14169797

I wonder how HN allowed posting a duplicate article!

When articles don't get much traction, dupes seem to be permitted by the algorithms. One post had a comment and another had 13, so it makes sense to let it through. I don't know the actual implementation, but this is what I've observed.

And the thread you linked is itself a duplicate of this: https://news.ycombinator.com/item?id=14167469

Whoops. My apologies.

For those on MacOS, I suggest this port of emacs : https://bitbucket.org/mituharu/emacs-mac/

It's basically the same as the distribution from http://emacsformacosx.com, but it supports various enhancements made for mac, eg. resize text size with trackpad, smooth buffer scrolling and SVG support, which is quite convenient when used with the jupyter notebook interface and producing plots. See for instance : http://imgur.com/gallery/vEI2z.

For compatibility with various emacs add-ons and hooks (like org-capture), I find the one that comes with Homebrew to be the best.

I've been using the Emacs that comes from homebrew with the spacemacs plugin (system? Total conversion?). Not a perfect integration when it comes to images but I stick to text and it's been great.

Exactly. brew install emacs --with-imagemagick@6 --with-dbus --with-mailutils --with-gnutls --with-cocoa --with-ctags --with-librsvg --with-modules --devel

Do people use dbus on macOS/OS X? How does Emacs integrate with it?

I don't know. Probably not. The reason I install with dbus support is to avoid having packages that rely on it not working, should a package ever rely on it (maybe mu4e notifications? idk). Take imagemagick, for example, you can still display images with Emacs without it, but you can't resize them.

I use this version too and have been very pleased with it. It's also available via Homebrew [1].

As an aside, I'm looking forward to better support for text scaling in future [2,3] as it's a feature that (if it was compatible with autocomplete and company-mode) fits my workflow better than zoom-frm.

[1]: https://github.com/railwaycat/homebrew-emacsmacport

[2]: https://github.com/company-mode/company-mode/issues/299

[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18493

Looks good but is there a prebuilt version to download? That is the main attraction to me of emacsformacosx

Since the link posted leads to the Emacs home page, the changes made are here: https://www.gnu.org/software/emacs/news/NEWS.25.2

Is there a gentle way of picking up Emacs?

I've been trying Spacemacs with Evil mode on (I'm a regular Vim user), and I can kind of manage to use it for day-to-day editing and running Make, but it feels like I'm about to be eaten by snakes because I now have to deal with three additional meta key-combos (alt-x, C-c and space-m) in addition to the one I had for i3 (now banished from alt to Win) and I also have to learn escape codes to use my terminal and use them a lot to Vim on remote hosts over SSH.

I finally got into emacs using the prelude distribution - https://github.com/bbatsov/prelude

It has sane defaults and contextual tips that help when you're getting started (and can turn off later).

I found starting from a vanilla Emacs and installing evil mode myself was much more gentle than jumping straight into spaceman.

I used this: https://github.com/technomancy/emacs-starter-kit

Some of it has been subsumed into newer emacs releases.

In general, find out which modes are considered best for whatever you are doing, install them, and then learn how to modify the configuration file to customize how the rest of the UI works.

I tried prelude and a few other starter kits, but still had trouble because the starter kits change the default behaviors, which can be confusing when trying to troubleshoot or find answers. I personally feel its better to start "vanilla" and understand the various Emacs concepts.

The built-in tutorial is good. It gets you through the basics of navigating.

Even after having used it for a few years, I enjoyed Mastering Emacs [1]. There are several "getting started" articles on the website and if you find them helpful, the book is also good, in my opinion.

Print out one of the many reference cards available (the official one is available on the Gnu website [2]).

Try org-mode [3], which is built in. It's extremely useful and a gateway to emacs.

[1]:https://www.masteringemacs.org/

[2]:https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf

[3]:http://orgmode.org/

EDIT: Oh, and for remote hosts, I find it easiest to connect with Emacs, rather than connect and try to run Emacs from the remote host.

On remote hosts, is there a trick like having an Emacs-slave on the remote hosts? Something like SSH for Emacs, that makes use on remote systems seamless?

I guess it depends on what you're trying to accomplish. If you are trying to edit on the remote machine, just open the files directly in emacs is the best bet:

http://stackoverflow.com/a/20624538

(side note, this is one of the best parts of org-mode, it supports remote links to files. When you open the link, it will open it in a buffer and depending on your config, even switch to the correct mode).

On the same page there's a tip to set up dired (an emacs file browser) to browse the remote machine and open files within emacs.

You can also run eshell or ansi-term from within emacs, if that's what you need to do.

So I guess I don't find much need to run a client system, but I'm not 100% sure what your needs are.

I'm running i3 with alt as my modifier key on one laptop and win key on the other and run emacs just fine. I run a pretty basic setup and I really need to go pull out a few things I never use anymore. I set caps lock as control, now, though.

What really helped me get started was using a specific tool/ language. After playing around in Clojure for a while, I learned how to use emacs for a better REPL experience, but I did everything else in Sublime. Most of my school work at the time was in python so I worked on switching that workflow over to emacs. Eventually got pretty comfortable with python too. A few years later and it's now my main editor. It took a few days to figure things out, and a few months to get really comfortable, but I'm now really happy.

I run emacs in window mode and rarely use emacs in the terminal for the same reasons you mentioned. At some point I started using projectile for project management and now I can fuzzy fine files and fuzzy find projects on my system without needing to switch to the terminal. And now if I'm in a terminal, it's probably because I'm using vim on some remote host.

How is it better than e.g. enabling Vi-mode in your inputrc and just using a "vanilla" commandline REPL?

shell and multi-term have been very uncomfortabe to me, while I really liked Evil mode, the Rust linter + formatter + Cargo integration and Projectile, and Helm was pretty nice as well.

I don't think there is. I've been trying to move from vim to Emacs for a few weeks unsuccessfully, mostly for org-mode and all the agenda stuff. I still use emacs for org-mode but I don't feel comfortable using it for normal code editing.

I am using evil mode, Helm, Projectile and Jedi for completion, and even though everything is more or less configured and took me around 300 lines of elisp I still find all the time defaults that are completely different to vim and I'll have to fix at some point and I am not sure how much time and code it will take to make it feel comfortable. Just a few problems from the top of my head:

- evil-mode "u" to undo changes sometimes works and sometimes does crazy stuff. I think it has something to do with incompatible modes, specially org-mode.

- Tab doesn't work, I'll have to investigate how to make it work properly.

- The defaults for Projectile for opening files inside a project look and feel horrible, it's configurable but I'll have to investigate and probably spend a few hours writing elisp until I have it working to my taste.

- Things like ":set nowrap" don't seem to work in evil-mode, I'll have to investigate how to do the same in emacs.

- The completion is kind of weird and it appears automatically instead of using a key to activate it. Again it's configurable, but I'll have to spend a bunch of time getting it to work as I want.

- If you do ":e path/to/file" and then you try to open another file from inside emacs using ":e [TAB]" it will work as if you changed to "path/to" instead of the original directory.

And this is just from the top of my head without having used it for a few weeks now as I don't have the time to configure all that stuff. I'd say that evil-mode is not transparent enough to make the change simple.

You're touching on some of the same painpoints I encountered, though I don't know what Jedi is.

My impression is, we might both benefit from starting from a bare-bones Emacs setup and expanding that by hand.

I guess vanilla Emacs would be the most bare-bones experience, or at least the most bare-bones experience you can find help for on Google (which kinda hurts me to say, but DDG has worthless search results and only sticks in my browsers because of the !bang functionality).

Off the top of my head:

Tab doesn't work, I'll have to investigate how to make it work properly.

You mean for auto-complete? I think I had to do this under dotspacemacs/user-config:

  (define-key evil-insert-state-map (kbd "<C-tab>") 'hippie-expand)

Things like ":set nowrap" don't seem to work in evil-mode, I'll have to investigate how to do the same in emacs.

This worked for me, also under dotspacemacs/user-config:

  (spacemacs/toggle-truncate-lines-on)
  (add-hook 'text-mode-hook 'spacemacs/toggle-visual-line-navigation-on)

Edit: Wow, sorry, answered the wrong question. The above will enable wrapping. I'll leave it up for anyone who wants it. For me, nowrap seemed to be on by default and it drove me crazy.

After 15 years of vim, it took me a few weeks before I was using Spacemacs more often, but now I only use vim for quick changes when I'm sshed into a server. Took a lot of googling and yak shaving, but so far I'm happy and getting more productive with time. Good luck with the other issues.

First, at the risk of pissing off fellow emacs-ers -- if you're already a regular Vim user, why not stick to it? It's a great editor, and I know a lot of people who use it and are just as productive as I am with emacs. Plus, if anyone ever needs to use their computer, you won't get weird looks when you tell them Caps Lock is Control on your keyboard...

Anyway, if you absolutely want to learn something else, I'd suggest going the other way 'round, really: start with something minimal and work your way up from there.

For the first 1-2 years, I think, I've used Emacs as little more than a glorified Notepad clone (in fact, I even used it with cua-mode). I think my .emacs file was barely ten lines long. I was transitioning to Emacs from nedit, an old-ish Unix editor with a Motif UI that was getting increasingly difficult to digest and kept crashing and had trouble with Unicode and man I'm old... anyway, all I really needed it to do was let me write text and paint it in pretty colors sometimes.

I then sort of picked up its features one by one, as I needed them. The keybindings came first, because it was weird the arrow keys for motion and the other keys for everything else. Then I got a larger monitor and I could fit more than two windows on it and I installed window-mode so that I could switch between windows with M-1, M-2 and so on.

(Please remember this was 2005 or 2006 or something, a 21" CRT was a big deal for me...)

That's pretty much how I picked up everything else: first big C project was how I picked up xrefactory, then xcscope. First time I had to do big merges was how I picked up ediff, and so on.

The best thing about having something as scriptable and customizable as emacs is being able to make it work exactly the way you want it. Making it work exactly the way someone else wants it sort of defeats the purpose, I mean, any editor already works the way someone else wants it.

Edit: ah, yes, to address some of your pain points:

- Remote editing: look into something called tramp-mode. It's not perfect, and I, for one, use it sparingly, but it may fit your use case.

- Weird key combinations: I'm not sure what to say other than "you get used to them". It may be worth looking into how i3 deals with this stuff, too. I no longer use a tiling WM, but when I used ratpoison, it fit near Emacs pretty well -- I bound C-t to Ratpoison's prefix key, and just didn't use C-t for anything in Emacs. But then again, Ratpoison (and its successort, scrotwm) were both written by Emacs enthusiasts, and used similar key sequences.

If you're curious about anything else, ask away :-)

You learn emacs on 3 tracks:

The text editor, the extensions, and elisp. Pick a use case you really want to get into (Editing code in language X) and dig into that one use case first. Or taking notes (Learn Org mode). But pick just /one/ use case to start your practice.

Learn the editor:

https://www.gnu.org/software/emacs/manual/pdf/emacs.pdf

Work through it up to chapter 9. Practice each command. There is (mostly) a rhythm. Memorize and emblazon the "describe key" shortcut into thy mind. Clear your mental desk and just do it for 30 minutes. It really isn't that bad, you just have to give it a little time and practice.

Packages / Modes: There are a few packages in Emacs that are life savers. Get melpa working. Install and learn helm. Helm provides a completion buffer system for things like file selection and and commands. Helm is that /one/ thing I can't live without for extended Emacs usage.

Learn Lisp: If this is going to be more than just a toe in endeavor, you need to learn lisp. When you learn the rudiments of elisp and build a couple of small modes or extensions for yourself or customize existing modes a little so many things about emacs just "click". Want to bang out some quick math or do a quick base 64 decode? An example document:

''' This is a document where I am thinking.

Oh, I needed to do some quick math:

(- 2017 1980)[C-x e] -- result appears in Message area. '''

Things and concepts not to miss:

CUA mode / block selection, macros (very easy and nice), regions, buffers, point, mark, registers. Things you might not think much about: The kill ring. Learn and read about the kill ring.

Final thought:

M-x = never remember all the shortcuts again. With helm doing fuzzy matching you only have to remember much easier to remember english names for things. Naming is consistent for modes too, so to start searching for "what was that Org mode shortcut?" Start typing 'org pro' oh yeah, org promote! [Whack enter] indents a sub tree in my notes. Then I usually remember the shortcut from there out because it is shown on the commands. M-x along with describe key are life savers as you can go from shortcut to function name and function name to shortcut and you can lazily search through commands and buffers. Helm makes buffers easy.

To summarize:

1.) Learn the editor Emacs and focus on editing on specific type of document (Markdown, Org, programming language). Follow whatever popular setup guide you find for document type X.

2.) Learn the extensions Emacs. Helm is a must-try.

3.) Learn elisp and get used to the idea you are in a giant lisp machine. Running lisp code /anywhere, anytime/ in your documents is awesome.

4.) Learn the little tips and tricks.

5.) Use evil mode if you must, but I have found being fluent in Emacs is great (iPython, for example, is very Emacs biased in its readline / shortcuts). Tons of other tools (mutt) will go with vim like bindings, so taking the time to be fluent in both means you are almost guaranteed to have the right shortcuts in your brain.

6.) I feel your pain about the shortcuts. I have it mostly down to 3: Emacs, Tmux, i3. I try to ram everything through that set of shortcuts, and then a small set of my tools I use a lot use vim bindings, and I am ok with that (mutt, mitmproxy).

Thank you for the well-thought-out and very helpful post, I feel like you've given me a model of thinking that will help me get started faster.

Would you happen to have ideas about pinky-saving layouts/modifications to Emacs? I'm not quite ready to ascend to Dvorak layouts but anything short of that I'll try, I'll need to with the state of my fingers.

It's my first week, so I guess I should read the manual instead of deep-diving without scuba gear and trying to manage with Evil-tutor and wishful thinking :')

I'll start with Org mode, I've been meaning to move away from Google Calendar and into Org mode for months anyway.

Thanks again :)

I highly recommend general: https://github.com/noctuid/general.el It lets you easily bind keys in a vim leader-like way. For example, I use a macro that defines binds under a `M-SPC` leader key:

    (ap/general-define-key
      "fs" 'save-buffer)

Now I can press `M-SPC f s` instead of `C-x C-s` to save a file.

That is a neat module. I will have to play with it. But C-x C-s is burnt into my memory now.

It really helps to go through the manual in order. It is a quick read. There is also a great GNU elisp intro -- https://www.gnu.org/software/emacs/manual/pdf/eintr.pdf

Work through that before any other lisp resource. I found it he most authoritative.

Caps to control is a life saver. I mostly roll with default key bindings. It just makes life easier. I don't have any hand issues. If you do you might rethink shortcuts .... Some folks are convinced key chording is not good for their hands, but I don't have an issue with it. I don't even notice it. Good luck if that is a concern, but Emacs is extremely customizable so that helps, but get at least some level of muscle memory for the default key bindings .

Once you know what you use a lot and have the basics down you can figure out how to start customizing.

I suggest working with just evil mode for a bit, or going all the way with vanilla emacs. Spacemacs is great, but overwhelming. Also, spacemacs should not be used in sensitive contexts, because it is a massive security hole: it brings in a vast number of melpa packages, the git repositories for any one of which could be compromised. And whenever spacemacs updates, it updates all those packages for you, and melpa updates a package on any new commit to the source git repository.

Thank you for reminding me of the security implications!

I tend to forget there's a more reasons I develop on Debian Stable than "it's convenient to standardize on something you can run on prod".

Yep, that's true. They're planning to essentially fork MELPA and have their own "stable" repo of packages Spacemacs uses. I wish them luck on that, because the security issue is a concern.

That's interesting. Can you point me to where that's discussed?

IIRC I saw it in the Spacemacs release notes.

I recently tried switching to spacemacs from my custom init.el, and after a half hour switched back. It did inspire me to spend some time improving my setup, but elisp is so simple to work with once you learn it a bit, that there's really no reason not to just roll your own config.

I don't need 200+ key combinations off my leader. I have about 10 for the things I use often, and if I find myself pulling up commands from Alt+X (mapped to space x) regularly, I add that to a new leader mapping.

Use-package is really convenient to learn for setting up your config.

Other than that, the things I find I can't live without:

* Ivy/Counsul * Company * Flyckeck * Flyspell * Evil

If you take a look at spacemacs's GitHub, dive into their "layers" and pop open the packages file for any given layer for inspiration of other things to add for your desired languages/features. But integrate then yourself given the packages' instructions. You'll be far better off knowing your setup intimately than learning to skim the very large surface area of spacemacs.

> You'll be far better off knowing your setup intimately than learning to skim the very large surface area of spacemacs.

I disagree. spacemacs is not all that scary or hard. it's a thin configuration over emacs packages that all work well together. Take for instance the java layer: it has some configs to make completion work well, syntax highlighting, add things to the "mode leader menu that changes per file type" and a few other things. ootb spacemacs works very well and is a pretty good experience.

Might I ask how you've picked up Emacs?

Did you start with Spacemacs or did you have prior experience and understanding of Emacs?

Never used emacs before and I was a power vim user that was sick of all the vim extensions feeling hacky and not integrated together nicely(the vim scripting language, viml, is awful and it's no wonder that these extensions are hacky) and liked the idea of spacemacs because I used a basic version of it on vim with space as my leader. no which key popup on vim so the bindings were very simple and you had to remember them by heart (I think I used `spc e v` for "edit vimrc" and `spc e z` for edit the zsh dotfile. spc-= to format the entire file etc.)

I jumped into spacemacs and figured out how to do the vimrc bindings that I had in emacs lisp. I watched a few videos[1] from the creator of spacemacs to see how he configured his and to see what was the way to navigate files in spacemacs correctly.

watch a magit video[2][3] too... that program(I say program because it's basically full git well done) is phenomenal.

hit me up on the gitter.im channel for spacemacs if you have questions on it or emacs.

1. https://www.youtube.com/watch?v=HKF41ivkBb0 (basics of spacemacs... also check out his channel for a complete dive into each of the prefixes and how to use them)

2. https://www.youtube.com/watch?v=vQO7F2Q9DwA (basics of magit)

3. https://www.youtube.com/watch?v=mtliRYQd0j4 (more advanced features of magit like rebasing interactively and easily.)

Learn to use the help commands (press "C-h ?" for a list). Apropos especially ("C-h a"). Personally, that's what got me hooked. The self-documenting was so mind-blowing to me at the time; I would spend hours just looking commands up.

Has there been any update to the status of GuileEmacs? I have read that it aims to be "the future of Emacs", but I rarely see mention of Guile from the Emacs community.

It isn't the Emacs devs who are really asking for GuileEmacs. Rather, it’s Guile fans who are proposing to integrate a software they love into Emacs for mutual benefit. While the Emacs devs don't a priori reject such a thing, they naturally insist that the Guile-based Emacs be a mature, stable and faster piece of software before it is considered for the mainline, and that just hasn’t happened because only a handful of people are working on it.

This is the branch to watch for guile-elisp: http://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-elisp

Last thing I heard was that Guile-Elisp (and by consequence Guile-Emacs) is working, but very slow. That can be fixed but requires work. Also, Emacs internally uses a different string representation from Guile. This makes the transition between languages tough and some more glue is required.

IMHO Guile-Emacs is "nearly there". I.e. with just a little more work it could have enough momentum and attract developers to be on the trajectory of becoming the default elisp implementation in the long term.

Having the new Guile 2.2 VM drive Emacs would definitely improve things. And the C-codebase could become considerably smaller and cleaner.

Guile community probably wants guileemacs to be the future, but I think it would be only natural for emacs community to think otherwise.

I'm part of the emacs community, and not part of the Guile community (though I am a fan of Scheme, just not Guile in particular, Chicken Scheme is more my speed) and I think a Guile-based emacs would be a huge step forward, and can't wait for it to Guile to be fully integrated and all the outstanding issues to be ironed out.

I really can't understand the objections from some people in Emacs land, except for those that would prefer a Common Lisp-based Emacs, but that's not what we've got. We've got Guile, and while that might not be as great as Common Lisp (in their eyes, not mine, for me Scheme is preferable), it's still a lot better than elisp. Rejecting Guile and sticking with elisp just makes no sense to me at all.

Keep in mind that having emacs be based on Guile does not mean that all the elisp emacs packages have to be jettisoned. They will still run as elisp under Guile, and you can continue writing scripts in elisp and have them continue to run under a Guile-based emacs.

Without portability there will be no GuileEmacs to replace the official Emacs implementation. AFAIK, Guile doesn't work on Windows.

Until Guile will work natively on all major operating systems, I see no future for GuileEmacs.

This is (mostly) a bugfix release. Emacs 26 will have some major goodies, threads being one.

That's awesome! I hate blocking when I'm checking email.

I used to use Gnus, which is really bad for blocking (I used to run it in a separate Emacs instance).

Mu4e is pretty good in this respect: it offloads most of the mailbox processing work to the `mu` command, which it runs asynchronously. I fetch my email with a system service, external to Emacs.

I have a bunch of IMAP and exchange accounts. Any chance I can use them in Emacs? Last time I checked only POP3 was supported.

Gnus does do IMAP. Receiving from multiple accounts is easy, though sending from multiple accounts take a bit of work. IDK about excange.

I am a mail account hoarder (9 so far and more coming) and offlineimap together with mu4e is the best email client for multiple IMAP accounts across multiple mail servers. For sending mail I have message-mode and smtpmail.el (both come with Emacs) set up to handle composing and replying across the multiple email addresses. I also set up smtpmail to queue mail and run in a sub-process - this gives gmail-like "undo sending this email" functionality, ability to compose and reply to messages off line, and most importantly does not block the parent Emacs process when sending email, while providing better error and progress output.

Planning to write a blog post about this configuration, but in the meantime I am happy to share privately - vsedach@gmail.com

It seems amazing to me that EMACS is just now getting ready to implement multi-threading.

Isn't that so 1990's?

Please I mean no disrespect...I was first exposed to EMACS in the late 80's if I remember correctly and have followed it's growth over the many years since, but I can't help but feel that introducing non-blocking threading is something that should have happened long ago.

I never noticed that it didn't have threads and I've been using it for 10+ years. That might explain why they didn't bother adding them - it works reasonably well as is

I notice a couple times a day. Any large mode will usually cause noticeable jankiness. My usual suspects are js2-mode, email modes like gnus, and evaluating org-src blocks.

There's hacks for some of these, but having threads natively will be really nice.

the main need for threads is a non blocking ui...another example of a very extensible software with a ui that locks at any step because of how extensible it is, is kodi :p

Keep in mind that from an architectural perspective, Emacs is mostly a LISP interpreter, with a text editor implemented in it. As such, not only did it involve refactoring application code, but the core language as well.

Emacs is little outdated as an operating system, but highly advanced as an text editor.

Emacs does have some other means for asynchronous processing, like processes and timers etc., but yes, maybe threads might have come earlier. The development pace of emacs in the recent years is way more faster than it used to be though, maybe with vim and Emacs alike becoming hip again and gaining traction (new cool stuff like Org mode, Magit, etc.) (and also new cool lisps like Clojure).

Where can I get more info on Emacs 26?

The etc/NEWS file in the source code repo is constantly updated as new features come in, and thus it's a nice start.

Emacs and VIM are probably those two software pieces that to me look like from another era that I have not lived through and thus cannot get my head around.

try orgmode, way better than anything else

They're very old... but at the same time they kind of look from the future. Cool stuff.

As an Emacs user, I still don't get why they have the menu bar and tool bar, they have always been harder to use than the other methods of interaction, and most people don't discover much through them anyway since the menu bar is so cluttered.

Nonetheless, very happy with it once I put in my relatively small config.

The right-hand side of the menu bar can be helpful in application-like modes (like gnus or M-x list-packages). I agree you might as well turn it off otherwise and regain the space.

> As an Emacs user, I still don't get why they have the menu bar and tool bar

For new users and people who run emacs by mistake or to just check it out maybe?

But I agree with you, these days disabling toolbar and menu bar is my first action when configuring a new emacs environment.

When I first started using Emacs I found the menu bar useful for discovering features I had no idea existed. I quickly became fluent with the keyboard UI and can use that to explore the editor now, but it taught me not to underestimate menus. They might not be particularly useful, but they helped me find a few hidden gems.

The first thing I put in a new config is to turn off menu-bar-mode, scroll-bar-mode, and tool-bar-mode. I find they take up too much screen real estate.

Don't get me wrong, I do exactly the same thing. I'm just against removing them wholesale since I think they are valuable aids to a user who doesn't know about creating a config at all yet.

Largely because some people use it, and for those who don't putting this in their .emacs serves as a straightforward tutorial focus and a right of passage:

   (tool-bar-mode 0)
   (menu-bar-mode 0)

Wow, the Emacs website is really pretty. But I like vim's one too - I feel they symbolize the internal ideals: vim being lean and small with just the essentials (at just 230 kB) while Emacs is more fully loaded (930 kB).

mg is even smaller and has emacs bindings

And Eclipse is even bigger.

Okay, you win.

Well rather vim wants to be a text text editor while Emacs a computing environment with text editing as the central thing/main interface.

Indeed. I'm constantly tempted to try switching to a lighter, more editing-centric editor, but the kitchen sink is just too useful. Finally got around to trying EXWM this morning and was amused by the fact that I can run Steam in an Emacs buffer :D.

I am using EXWM everyday for more than a year. It has hugely improved my Emacs workflows and productivity. I would put it on par with Magit :)

It still has few rough edges, so may not be for everybody.

Care to elaborate on some of the rough edges so I can try to avoid them? I've heard bad things about Chrome and almost locked myself out of my WM by using pinentry; Not sure what other gotchas there are.

Not the original poster but here are two issues I currently have with EXWM (have been using it exclusively for about two months now):

1. If Emacs hangs/pauses, the window manager hangs/pauses. Can't really do anything in X so have to switch to a virtual console.

2. GIMP stopped bringing up working file dialogs. I think it is some EXWM configuration change I made.

You might also have issues with tooltips/popups depending on your EXWM configuration.

My biggest issue is w.r.t multiple outputs (xrandr). It works as expected, but requires decent customization effort -- which I think is not for everybody.

> fully loaded (930 kB)

I get that you meant it in comparison to 230k, but in the modern world I find it hilarious that a 930k website is being called (essentially) heavy. If only...

fun, archlinux already updated the package.

Reply on news.ycombinator.com