So happy to see my favorite IDE for the last 30 years being actively developed and maintained. Multiple IDEs have come and gone over those 30 years, and I waved to them on their way as they arrived and then as they passed away into nothingness.
Every time a new IDE arrived, crowds cheered, and it was all the rage and fashion, while my Emacs was called "obsolete", "hard to use", "bizarre", and other things. I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.
If I could tell something to my younger self, it would be: keep faith in solutions that are open and have been around for a while, you will save a lot of time over the years.
Same here. It's the oldest continuously used piece of software for me. I tried it first on a Sun Unix workstation at the university around the late 90s. I've tried komodo, vscode, sublime, vi and many others and still use emacs. The funny thing I don't even know that many key combinations and use only a few customizations.
I was pleasantly surprised when I was issued a mac at work that most of the basic editing commands on macos text widgets support emacs key bindings (ctrl+a/e/k/p/n).
Those keybindings are one of the very few features of macOS I missed after going back to GNU/Linux. It's such a nice thought, especially with macOS using the command key for most, uh, commands - it doesn't impose any burden on non-emacs-users, but for those who are used to those keybindings, it's bliss.
> Emacs was called "obsolete", "hard to use", "bizarre", and other things.
Well, Emacs isn't designed for a common user, but for a power user. From my experience, first time using Emacs was really frustrated.
In contrary, VSCode, Atom, Sublime Text etc. were usable right from the start. But these IDEs didn't stick for me. Easy come, easy go, I guess.
Emacs and Vim, although took a lot of effort to configure them into usable text editors/IDEs, stick with me 'til these days and I'm continuing to use them in the future. The power of configurations are astounding and I can shape them into whatever I want.
> Well, Emacs isn't designed for a common user, but for a power user. From my experience, first time using Emacs was really frustrated.
That's not different from a piano. Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.
> The "out of box" experience for emacs is really, really bad.
That's not much different from a piano :-). Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.
I'm also very happy with Emacs' continued existence. Frankly, I don't know what I'd do without M-x shell plus related hacks, but I think I'd have to reinvent the concept of having arbitrary numbers of named shells with infinite output/input streams attached to them, with searchable histories, etc. Just like the unix concept that everything is a file was super powerful, so is the Emacs concept that everything is text. And of course lisp helps smooth things out whenever there are rough edges.
> I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.
"wasted" sounds a bit too hard to me. If you learn and use some tool productively for some years, even if this stops, the years were not wasted. Ephemeral things can also have value.
No, I think there is always something you can improve or add. The point, I think, is to do it carefully, though, without breaking things. Python is an example of how not to approach software evolution. Emacs and Clojure are examples of how software can be maintained over the long term without breaking backwards compatibility.
When I was young (and, ahem, stupid), I didn't care — I was all gung-ho, shoot from the hip, and if something breaks, tough. As I matured, I learned that backwards compatibility and long-term maintenance should be valued and cherished. Not just because if you're not careful, you have to fix the things that break, but also because as you start doing more and more things in your life, you have less time for each thing and you'd rather move forward rather than spend time fixing things that break.
In a field as young as software, three decades is too long for almost any software tool to remain frozen. Many new ideas might have built up — especially as the world around you (and needs) changes. You might keep writing extensions for your tool, or release periodic updates, or freeze your tool and call it “done”, and write a new tool every few years… they are all different ways to handle the same underlying mechanics.
To be fair, this release supports LSP and TreeSitter (which is super cool), but these are features that were pioneered by other editors and available elsewhere long before emacs. These ideas wouldn't be coming to emacs if it weren't for the experimentation and polishing done elsewhere.
Most definitely not. In fact, much of open source is haphazardly developed without regard for backwards compatibility, often also introducing change for no good reason (the word "cleaner" should always raise red flags).
Source: a certain developer/admin/netadmin with >30 years of experience using open source software.
As someone whose daily code editor was XEmacs during the heyday of UNIX wars, because Emacs wasn't as a friendly for GUI users, I really wouldn't call it an IDE, those were the things IBM, Borland and Microsoft were giving me on PC side.
I doubt if Emacs was a commercial product, that many people would bother to use it, same applies to VI derivatives.
If the experiece is above anything else out there, certainly it is worth paying for.
One of my favorite aspect of Emacs is its configuration file. I use an org-mode file for configuration - which means that we can have rich documentation along with the code - all neatly folded up. The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file.
Similar executable org-mode files are used to configure the environment (sway) and personal information management (email, calendar & contacts). The latter one got so complicated that I had to add an integration diagram using the draw.io app.
The other great feature of Emacs is that its keybindings are so pervasive. Most native MacOS text input widgets and modern POSIX shells like bash and zsh use Emacs-style key binds for navigation and text editing. Also anything that uses GNU readline supports them as well out of the box.
I've always seen this as an anti-pattern. You can make the documentation in an .el file as rich as you want without losing all the niceties that Emacs offers for interactively working with source code (e.g. find-{function,variable} will jump to the ephemeral dynamically generated .el file, not the actual origin of the code which is in the .org file).
Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?
Matter of preference. As an example, I may have a lot of configuration related to package X under one Org node. I merely have to "comment" the node headline to ensure none of that code gets to the config.
Your comment reveals your bias - that the code is more important than the commentary. The counterpoint is:
No. You can't make the documentation as rich as you want. I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.
> Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?
I understand what you mean. But it never seemed to be a problem for me. Anyway, the real reason why I ended up with org-mode is that I heavily customize Emacs. The only way to be able to handle that much configuration was to split it up into a dozen or so elisp files. Org-mode's biggest advantage (for me) is that it can manage complexity very well. The org-mode configuration file is neatly divided into topics along with their documentation. The topics are also folded up - so it's very easy to find certain configuration segment.
> The latter one got so complicated that I had to add an integration diagram using the draw.io app.
Amazing that this is offered up as a selling point. If I didn't know I was reading a thread full of emacs users, I'd think this was a parody of a thread full of emacs users.
> I'd think this was a parody of a thread full of emacs users.
Haha! Indeed! Let me just clarify what I meant. I have a personal information management (email, calendar & contacts) where all information is stored locally and offline. The advantage is that I will never be locked out of my own data. However, this setup has so many components for syncing the info online and to interact with it. Quite frankly many of those components should be integrated into a single application. For example, mbsync can sync mail to a mail directory. But it needs go-imapnotify to trigger it when I receive a new mail. It's so frustrating that I considered writing those applications myself.
In short, Emacs has nothing to do with the complexity. Instead, Org-mode and emacs has actually allowed me to manage that complicated configuration in one place, with lots of documentation. The draw.io diagram was for the information flow between different software components for the PIM and email setup - not for Emacs itself.
Coming back to the complicated setup for PIM, I see a lot of new developments that promises to make it simpler. Hopefully, I won't need the org-mode power in the future to rein in the complexity.
> The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file.
Can I see (an example)? Wondering how much goes into that init.el.
Treesitter and eglot are excellent. I am moving from vscode back to emacs and do far it’s been a great experience. Should’ve done that a long time ago.
Off-topic: what is an emacs quality alternative for docker? It’s such a piece of garbage for something so pervasive.
I use containers on Mac and Windows for development (and we deploy on linux). Docker for Mac is _unusably_ slow in my experience. The VM that it runs is a giant resource hog and a battery hog, and doesn't support ipv6 [0] Docker Desktop itself is (another) resource hog, wildly buggy, and painfully slow. It's the epitome of "shitty electron app".
On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].
I'd really love Emacs to have native JPEG XL support. For I use Emacs as a pictures viewer and the only thing preventing me from converting all my family pictures from JPEG to JPEG XL (it's a 22% saving which results in JPEG XL files that can be converted back, bit-for-bit, to the original JPEG file) is the lack of Emacs support for JPEG XL.
Does anyone know if it's coming? Anything in the JPEG XL or JPEG XL libs license that makes it a problem to incorporate in Emacs?
Emacs can handle JPEG XL files as long as you build it with ImageMagick enabled and ImageMagick is built with JPEG XL support.
You can try evaluating (imagemagick-types) to see if it's enabled. If it fails with "void-function" that means that your Emacs was not built with ImageMagick enabled. If it returns a list of file types but the list doesn't contain "JXL" then your libMagick might be too old or not compiled with JPEG XL support.
I did check: I'm running the latest Debian stable, Bookworm, which basically just came out and it ships ImageMagick 6.9.11 but apparently JPEG XL support was only added in 7.0.10.
Oh the joy of running Debian! (I'll see if I bump ImageMagick to a more recent version or not).
Well ofc and I know some elisp but I take it integrating libjxl (now using the "new BSD license") or another library supporting jxl is one of those things requiring C guru skills. And it's been a really long time I haven't written a line of C code.
Moreover I take it that, say, for someone who added WEBP support to Emacs, adding JPEG XL would be kinda a no-brainer.
Looks good. For me, the best recent feature is native compilation so Emacs feels super fast and responsive. I often use macOS and I wonder is going to GTK will help a lot there?
As another commenter has said native compilation has been there for a while, but you may need to explicitly enable it if you’re installing via brew or similar. The macOS port doesn’t use GTK or X unless you specifically link them. What problems are you having?
I wonder if the latency would be comparable to neovim/vim? I've only tried Emacs without nativecomp and the really noticeable input lag left a bad impression.
As someone, who jumps between neovim and emacs on a regular basis - no, neovim is much faster. If speed and general snappiness is your most concern you should stay with neovim.
But, emacs is in most cases fast enough, faster than vscode and has other advantages.
Native compilation makes a big difference, but neovim is still snappier, especially if you’re using lots of packages or a framework like doom or whatever
download the source, unpack, cd into directory, ./autogen.sh, ./configure --with-imagemagick --with-json --with-mailutils --with-modules --with-rsvg --with-gnutls --with-xml2 --with-native-compilation=aot --with-pop --without-compress-install --without-dbus, gmake (gnumake from brew), src/emacs to test, gmake install, pickup the app in nextstep and done I think.
Really happy to see this. I've been using Emacs 29+ for the past while and have enjoyed simplifying my configuration now that use-package is OOTB. I think now is a really excellent time to try Emacs if you haven't already.
I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:
> Emacs is now capable of editing files with very long lines.
The display of long lines has been optimized, and Emacs should no
longer choke when a buffer on display contains long lines. The
variable 'long-line-threshold' controls whether and when these display
optimizations are in effect.
Readit News
Every time a new IDE arrived, crowds cheered, and it was all the rage and fashion, while my Emacs was called "obsolete", "hard to use", "bizarre", and other things. I spent some time over those 30 years looking at new IDEs, trying them out, configuring them, and each and every time this was time wasted, because the IDE was discontinued, abandoned, or otherwise became useless.
If I could tell something to my younger self, it would be: keep faith in solutions that are open and have been around for a while, you will save a lot of time over the years.
I was pleasantly surprised when I was issued a mac at work that most of the basic editing commands on macos text widgets support emacs key bindings (ctrl+a/e/k/p/n).
Well, Emacs isn't designed for a common user, but for a power user. From my experience, first time using Emacs was really frustrated.
In contrary, VSCode, Atom, Sublime Text etc. were usable right from the start. But these IDEs didn't stick for me. Easy come, easy go, I guess.
Emacs and Vim, although took a lot of effort to configure them into usable text editors/IDEs, stick with me 'til these days and I'm continuing to use them in the future. The power of configurations are astounding and I can shape them into whatever I want.
That's not different from a piano. Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.
As a daily emacs user, it is all those things. It's just also awesome if you put in the time to get over the hump and learn it.
The "out of box" experience for emacs is really, really bad.
That's not much different from a piano :-). Musical instruments are not designed for "common users" or "beginners". The ones that are, are not good for playing good music.
1. https://en.m.wikipedia.org/wiki/Lindy_effect
"wasted" sounds a bit too hard to me. If you learn and use some tool productively for some years, even if this stops, the years were not wasted. Ephemeral things can also have value.
When I was young (and, ahem, stupid), I didn't care — I was all gung-ho, shoot from the hip, and if something breaks, tough. As I matured, I learned that backwards compatibility and long-term maintenance should be valued and cherished. Not just because if you're not careful, you have to fix the things that break, but also because as you start doing more and more things in your life, you have less time for each thing and you'd rather move forward rather than spend time fixing things that break.
I blame sTeve jObs.
Source: a certain developer/admin/netadmin with >30 years of experience using open source software.
I doubt if Emacs was a commercial product, that many people would bother to use it, same applies to VI derivatives.
If the experiece is above anything else out there, certainly it is worth paying for.
Deleted Comment
Similar executable org-mode files are used to configure the environment (sway) and personal information management (email, calendar & contacts). The latter one got so complicated that I had to add an integration diagram using the draw.io app.
Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?
Your comment reveals your bias - that the code is more important than the commentary. The counterpoint is:
No. You can't make the documentation as rich as you want. I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.
I understand what you mean. But it never seemed to be a problem for me. Anyway, the real reason why I ended up with org-mode is that I heavily customize Emacs. The only way to be able to handle that much configuration was to split it up into a dozen or so elisp files. Org-mode's biggest advantage (for me) is that it can manage complexity very well. The org-mode configuration file is neatly divided into topics along with their documentation. The topics are also folded up - so it's very easy to find certain configuration segment.
Amazing that this is offered up as a selling point. If I didn't know I was reading a thread full of emacs users, I'd think this was a parody of a thread full of emacs users.
Haha! Indeed! Let me just clarify what I meant. I have a personal information management (email, calendar & contacts) where all information is stored locally and offline. The advantage is that I will never be locked out of my own data. However, this setup has so many components for syncing the info online and to interact with it. Quite frankly many of those components should be integrated into a single application. For example, mbsync can sync mail to a mail directory. But it needs go-imapnotify to trigger it when I receive a new mail. It's so frustrating that I considered writing those applications myself.
In short, Emacs has nothing to do with the complexity. Instead, Org-mode and emacs has actually allowed me to manage that complicated configuration in one place, with lots of documentation. The draw.io diagram was for the information flow between different software components for the PIM and email setup - not for Emacs itself.
Coming back to the complicated setup for PIM, I see a lot of new developments that promises to make it simpler. Hopefully, I won't need the org-mode power in the future to rein in the complexity.
Can I see (an example)? Wondering how much goes into that init.el.
https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...
The .org file gets processed and the source code blocks extracted into an elisp-only file which is what actually gets executed.
Some people prefer an alternate approach[0] with the "stub" init.el that just loads other modules.
[0] https://github.com/cute-jumper/.emacs.d/blob/master/init.el
Off-topic: what is an emacs quality alternative for docker? It’s such a piece of garbage for something so pervasive.
I've been enjoying podman.
On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].
[0] https://github.com/docker/for-mac/issues/1432
[1] https://github.com/docker/for-win/issues/599
[2] https://github.com/docker/for-win/issues/1976
Nix and direnv via envrc-mode.
Does anyone know if it's coming? Anything in the JPEG XL or JPEG XL libs license that makes it a problem to incorporate in Emacs?
You can try evaluating (imagemagick-types) to see if it's enabled. If it fails with "void-function" that means that your Emacs was not built with ImageMagick enabled. If it returns a list of file types but the list doesn't contain "JXL" then your libMagick might be too old or not compiled with JPEG XL support.
I did check: I'm running the latest Debian stable, Bookworm, which basically just came out and it ships ImageMagick 6.9.11 but apparently JPEG XL support was only added in 7.0.10.
Oh the joy of running Debian! (I'll see if I bump ImageMagick to a more recent version or not).
Moreover I take it that, say, for someone who added WEBP support to Emacs, adding JPEG XL would be kinda a no-brainer.
But I fully get your point...
AFAIK native GTK should be unrelated to macOS since macOS version uses its own cocoa frontend
But, emacs is in most cases fast enough, faster than vscode and has other advantages.
Gui emacs is much, much slower than nvim
Deleted Comment
(thats on intel monterey though)
I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:
https://emacs-config-generator.fly.dev/
> Symbol's function definition is void: package-vc-install
[1]: https://emacs-config-generator.fly.dev/config?font_family=Me...
Yes!
Official release announcement: <https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>