Emacs 29.1

https://emacsredux.com/blog/2023/07/30/emacs-29-1-released/

by pimeys • 3 years ago

378 308 3 years ago

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?

blahgeek• 3 years ago

Native compilation has been in emacs since 28.1.

AFAIK native GTK should be unrelated to macOS since macOS version uses its own cocoa frontend

aardvark1792• 3 years ago

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?

ducktective2• 3 years ago

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.

lycopodiopsida3• 3 years ago

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.

mplanchard• 3 years ago

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

38362936483• 3 years ago

Tui emacs is a bit slower than nvim, but close enough.

Gui emacs is much, much slower than nvim

bingemaker3• 3 years ago

How do you compile Emails on OSX? I use `brew install emacs-head@30 --with-cocoa` and I feel that org-mode is bit laggy. Is there a better way?

kstrauser5• 3 years ago

Add `--with-native-comp` to that.

mediumsmart• 3 years ago

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.

(thats on intel monterey though)

agumonkey4• 3 years ago

makes me wonder, is the target of native compilation something general like 386 ? can i share .eln between x86 computers ?

gjvc6• 3 years ago

emacs has never been in better shape

sph2• 3 years ago

For a 50 year old project, they have been quick to adopt new technologies like Tree Sitter lately. It definitely feels there is a lot of activity behind the scenes to remain as relevant as ever in face of editor fads such as VSCode and (ducks) NeoVIM.

hfkwer• 3 years ago

Gnu emacs is only 38 years old. And vscode is a fad...?

The_Colonel2• 3 years ago

For a 50 year old project, they have been quick to adopt new technologies like Tree Sitter lately.

From the following it sounds more like a first step towards true adoption:

built-in support for TreeSitter. This means that a few years down the road we’ll have many Emacs major modes that are much faster, robust and feature-rich.

goku1211• 3 years ago

They have even started an Android port. It's on F-Droid already - though it's not very usable yet.

spit2wind• 3 years ago

The F-Droid port comes from here: https://sourceforge.net/projects/android-ports-for-gnu-emacs

Newer builds have better usability (although there are definitely still quirks). I recommend using it with the Hacker Keyboard for easy Meta-key access.

cjohansson• 3 years ago

GNU Emacs is now dependent on TreeSitter which is a MIT-licensed project and LSP which is a Microsoft project. Also built-in support for non-gnu packages to install. Soon it will be a non-gnu project entirely. I think it's a bit sad that the ideological basis is beginning to be abandoned but I think there is not enough believers in the ideology anymore.

I would say most modern editors (Helix, Neovim) do TreeSitter and LSP better than Emacs today and probably for many years to come

YetAnotherNick• 3 years ago

MIT code could be used in GPL, but other way round is not possible. As long as there is a line of code with GPL license, entire project will be GPL.

p_l• 3 years ago

Not really, only when it can be shown that the project is derivative of the GPL code (for example, hard dependence on GNU-only library for some of its features vs. "one of the multiple possible implementations we can use is GPLed")

dimitar• 3 years ago

X-windowing system is also MIT-licensed, were they every avoiding that license?

hvis• 3 years ago

GNU Emacs is now dependent on TreeSitter which is a MIT-licensed project and LSP which is a Microsoft project

Not really dependent (you can build and use Emacs without either).

SeqDesign• 3 years ago

I think there is not enough believers in the ideology anymore

I don't know what ideology you're talking about, but the only one I've ever had is the Emacs ideology: use the best program ever made and be happy.

ilyt• 3 years ago

Tell me you know nothing about licensing without telling me you know nothing about licensing...

_a_a_a_2• 3 years ago

Seems you have prior form in not knowing what you're talking about https://news.ycombinator.com/item?id=32632468

38362936483• 3 years ago

Eh, I've been looking and haven't found anything for other editors that actually tries to use TreeSitter for anything beyond highlighting. The Emacs structural editing packages are still very WIP but at least they exist.

(And also some have been based on the out of tree implementation that's been around for a while now)

Example: https://github.com/mickeynp/combobulate

lawn• 3 years ago

There are quite a few packages for neovim that use treesitter for structural editing, folding, jumping and viewing.

goku1211• 3 years ago

LSP which is a Microsoft project

Emacs' LSP client Eglot and many of the LSP servers have nothing to do with Microsoft. Honestly, LSP is one project that I'm thankful to MS for. Personally, I value open standards like LSP more than any single FOSS project.

natrys2• 3 years ago

LSP I can probably understand, mostly for performance reasons. Native json parsing and native compilation goes a long way, but clients written in elisp seems susceptible to edge cases where it's not performant enough because UI and IO runs in same thread in Emacs. Not insurmountable even without multithreading, some newer clients that uses better IPC or the dynamic module system are not constrained by Elisp requirement and seems to be doing fine in terms of performance.

The dynamic module system is generally a win for pragmatism over ideology, and it has been around for 7 years already. You can't do everything, like say extending core graphics of Emacs, but you can do a lot in any language of your choice if you feel constrained by Elisp. Tree-Sitter feature is built on top of that so it's not clear to me why do you think Emacs can't do better than say neovim. I use neovim and tree-sitter daily and generally don't think tree-sitter itself is rock solid yet, I run into indentation and slow query issues semi-routinely. But I am much more impressed with the work happening on Emacs community that leverages tree-sitter for advanced tooling [1].

[1] https://github.com/mickeynp/combobulate

pkkm2• 3 years ago

Why is it a problem that LSP was originally invented by Microsoft? It's an open protocol with many free-software implementations. You don't have to use any Microsoft code if you don't want to.

Besides, even if that wasn't the case, Emacs has long had a policy of interoperating with non-free software. It runs on versions of Windows from 98 to 11. That's not because its developers don't value free software, but because they realize that this is a more effective way of convincing people to use free software than insisting on absolute purity.

aardvark1792• 3 years ago

Right, emacs upgrade is now added to the list of things to do on my day off tomorrow.

enbugger• 3 years ago

First I thought that emacs/vim are about productivity. You invest some time to learn its concepts and train muscle memory. In the end of it turned out that you have to forget about spending weekends away from your PC. Not much time was actually saved. My conclusion from all this: this is just another way of doing things with no huge benefits but with bigger portion of loses (at least because this is not mainstream).

jackcviers33• 3 years ago

Use helm-M-x and which-key, and avoid anything but use-package and customize. You don't have to eat the muscle-memory elephant all at once.

shadowgovt8• 3 years ago

The main advantage of encountered is that it doesn't go away.

I've been in contexts where I can't use vscode and I've been in contexts where I can't use intelliJ and so on. The contexts where I can't use emacs (specifically, emacs configured to my preferences) are thin on the ground.

It's a space alien user interface and software abstraction relative to most out there, but the payoff is I never have to put it down.

rout395742• 3 years ago

More like someone who works on their own car. Yeah, they lose the occasional weekend to the maintenance, but they love that they've had the same car for 35 years.

However with Emacs, there are a few thousand other people working on the car too, so despite the fact it's the volkswagen beetle you bought in 1972 and your butt shape is indelibly formed in the cockpit, it has _also_ got electric power train, full self driving and JATOs. :)

throwanem• 3 years ago

Yeah, that couple hours a year is a real killer.

lmedinas3• 3 years ago

I love Emacs (it was my main editor in the last 20 years) but i can't justify anymore to use it due to lack of modern feature, ease of use and maintenance of the .emacs files. Maybe i'm getting too old to constant exercise my memory or to tinker configuration files. Nowadays i just use VSCode and occasionally nvim.

massysett• 3 years ago

You can use M-x customize to pick configuration options from a menu.

nequo4• 3 years ago

What modern feature is Emacs missing?

worthless-trash2• 3 years ago

I feel the comment was bait.

wiz21c4• 3 years ago

- fast loading (vscode loads much faster on my computer; specially if I have a lot of open files)

- code "peek" (that little windows is super useful)

- good integration with debugger (again, vscode kills it here). For example: how to look a at a numpy array in emacs (in vscode there's a data viewer for that)

- robust LSP (for example, when I complete a formatting string f"{... on a big file, emacs simply becomes unresponsive for a minute or so (it's much quicker ona powerful computer though); pylance is simply superior on edge cases.

But although I'm a long time emacs user, there's one thngs where VSCode is much better, it's discoverability. I've learned much of what I need in 2-3 weeks, without ever looking at a manual.

Note: I'm a regular emacs user since since about 10 years (I came for the freedom, stayed for the community). I'm using VSCode since about a year.

I'll be happy to ear a way to make my emacs better.

derekzhouzhen2• 3 years ago

maintenance of the .emacs files

What maintenance? I have not changed a single line of my .emacs file for 3 years.

rurban• 3 years ago

I have to admit, I added a couple of lines since 1995. About 10 or so

lmedinas3• 3 years ago

if your .emacs has 10 LOC it makes it definitely easy. My .emacs is ±360 LOC.

submeta2• 3 years ago

In the same boat. Still like it a lot, but I started using VS Code for serious coding. But unpopular opinion here. So expect to get downvoted a lot.

Edit:

The unpopular opinion is to say that one has stopped tinkering with Emacs for hours and started using a tool like VS Code or intelliJ to do actual coding work.

jeltz3• 3 years ago

VS Code is extremely popular here do I have no idea what you are talking about.

User232• 3 years ago

IntelliJ is lightyears ahead of VS Code or any other LSP using editor including Emacs for what it’s good at, namely working with Java in complex ways.

I will use IntelliJ or Eclipse over Emacs or VS Code for Java development any day. But having used both VS Code and Doom Emacs for other development, the latter is quicker, more featureful, and more discoverable, just as easy to configure, and more extensible.

anta40• 3 years ago

I think "tinkering for hours" is overstated. My vim/neovim and emacs setup usually take no less than 30 minutes (including installing favourite plugins/packages). Then I can use them to get my work done.

Well, I'm not that obsessed with tweaking every bits, though. When I'm using vim/emacs, I never intend to configure them into IntelliJ replacement.

jackcviers33• 3 years ago

Modern features:

1. lsp-mode/eglot

2. package management

3. treesitter grammars

4. Portability - win/linux/mac/unix/android

5. Graphical User Interface - you can browse the web and watch YouTube in Emacs. Customize has buttons, forms, menus.

6. Treemacs/Treeview/speedbar: you know the multipanel view in Intellij or the project explorer in Intellij/vscod? Yeah, that.

7. Actual macros and function definitions, without needing to post them as an extension.

8. Interactive repl.

9. 5 different terminal emulators built-in.

10. Automated fuzzy everything with helm-M-x and helm. Exactly like Command-p in vscode.

11. github, gitlab integration with magit.

12. Copilot, tabnine, and chatGPT integration.

13. Hundreds of themes.

14. We've had shareable, secure remote collaboration for over a decade with wemux.

15. Use any ttf.

16. Mouse editing and command binding.

17. Use every build tool with projectile-compile-project.

18. Refactoring with lsp.

19. Autocompletion and jump to source.

20. Session save and restoration with desktop-save.

21. Slack integration.

22. Debugger with dap-mode.

23. Individual test only runs with dap and avy-lens.

24. blame with.magit-blame.

25. Pixel scrolling.

25. Transparency with seethru.

28. Rest client with variables and session storage (like postman, but free).

29. Browse compressed files as if they are normal directories and save to them.

30. Containerized deployment via flatpak.

31. Docker, docker-compose integration, kubernetes, aws, datadog, Azure integrations...

All of this fits in around 500 lones of copy_paste/cloneable emacs configuration, most of which is use-package declarations. Nary a defun or global-bind-key in sight, and because emacs is a full elisp ide, and it is actually executable code, it's debuggable on launch, unlike myriads of json files.

I'm trying to think of anything else that can possibly be interpreted as 'modern' from a ux standpoint. I certainly can't think of a feature that Intellij has that emacs doesn't that is core to the ide experience. And most of my emacs tools are better than the vscode version of them, at least in terms of invasion into the editor buffer or integration with the editor ux.

The one thing that's not modern is the standard copy and paste commands, but that's super easy to customize. I guess you can't drag and drop buffer frame borders in multiple buffer layouts if you hide scrollbars, and the message buffer isn't resizable...

shadowgovt8• 3 years ago

But vscode has basically all of it out of the box. Maybe after installing one or two extensions, which it recommends for you and you can install via a GUI.

As someone who uses emacs most often: VSCode is shaped a lot more closely to a modern aesthetic by default. If you've been following along with emacs all this time and keep up to date with the latest changes, you can easily accrete the configuration to make your emacs look like a modern tool, but it doesn't start configured that way.

agumonkey4• 3 years ago

postmodern features: [e]lisp metalevel customization

rvdginste2• 3 years ago

I am a long-time Emacs user and used to maintain my own config, but I switched to Doom Emacs [1] a year ago. Doom Emacs is like a pre-packaged/pre-configured emacs distro. You still need to configure the features that you want to use, but it's a lot easier (and faster) than having to do everything from scratch, and definitely if you already have some emacs background anyway. For me, it makes the newer, more advanced, features more accessible. Since switching, I started to use Emacs more again.

[1] https://github.com/doomemacs/doomemacs

lmedinas3• 3 years ago

i tried Doom Emacs and the first thing that turned me down was the VI bindings, which i disabled right after install. But yeah it does the whole configuration nightmare more easy to maintain.

joobus2• 3 years ago

I am an Emacs enjoyer. My biggest issue with Emacs is that development is still done via a mailing list and patches. I wish they would adopt a Git front-end (web UI) workflow.

jeltz3• 3 years ago

As an occasional developer of PostgreSQL which also does development on the mailing list I see pros and cons with it. It is harder to discuss lines of codes in a review on the mailing list but the nature of the mailing list (threading, etc) promotes much more nuanced and constructive discussions about patches on a higher level. Something which I have yet to see in any project on Github.

Gitlab has some threading support but not very good one.

broodbucket2• 3 years ago

It's really not that bad, it's just different. There's pros and cons.

https://git-send-email.io/ has a great tutorial for getting started.

There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.

joobus2• 3 years ago

I think the mailing list flow is a hindrance to attracting the next generation of contributors.

ParetoOptimal7• 3 years ago

There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.

The further I get into "emacs for everything" the more I appreciate using email for everything.

charcircuit• 3 years ago

You can use emacs as web client

TacticalCoder5• 3 years ago

Which version am I running yet? (I know it's not too old for I regularly compile Emacs from source)

    ELISP> (emacs-version)
    "GNU Emacs 29.0.60 ..."

Ah... Time to upgrade ; )

grumpyprole• 3 years ago

What an amazing release. Thank you to all that contributed and made it happen!

goku1211• 3 years ago

And they haven't even started taking full advantage of Pure-GTK and Treesitter. This release will cause an explosion new packages based on them.

mssdvd• 3 years ago

What kind of new packages would spawn from the introduction of PGTK?

pard684• 3 years ago

Took a new job and ended up putting emacs aside. Using Google's Lit framework is unbearable on emacs. It has some deeply nested html/js in template strings and emacs can't keep up with the nesting.

rs_rs_rs_rs_rs• 3 years ago

Is this with or without Treesitter?

pard684• 3 years ago

Either. The best results I have had was with web-mode which has some basic support for it. I also tried using LSP mode and the two Lit extensions for the Typescript server but that did little to help either.

pard684• 3 years ago

Figured it out! I had LSP configured to use the two lit typescript-ls plugins but because I was using web-mode, that language-server was never kicking in. Going to try getting treesitter to do the highlighting and then hopefully LSP will provide some nice-to-haves now.

jackcviers33• 3 years ago

Probably needs its own extension like in vscode.

shadowgovt8• 3 years ago

It should be able to. Emacs has good built-in support for navigating around substructure as long as you're operating with a mode that recognizes the substructure.

Paul-Craft3• 3 years ago

I'm not familiar with Lit, but if emacs can't grok all the nesting, how is it even remotely human comprehensible?

pard684• 3 years ago

With proper syntax highlighting it's fine. But this is why I have moved away, it's hard to read without good syntax highlighting. I don't know why extensions aren't handling it. Web-mode does but only the first level or so of nesting.

weebull2• 3 years ago

Sounds like a good application for treesitter

TacticalCoder5• 3 years ago

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?

zellyn• 3 years ago

Why not add support? Nobody owns emacs any more or less than you!

TacticalCoder5• 3 years ago

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.

But I fully get your point...

donio• 3 years ago

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.

TacticalCoder5• 3 years ago

Ah that's interesting, I wasn't aware. I'll try that and recompile if needed, thanks a huge lot for the info!

TacticalCoder5• 3 years ago

... then your libMagick might be too old

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

goku1211• 3 years ago

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.

lockhouse• 3 years ago

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.

abhijeetpbodas• 3 years ago

Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-...

supazek2• 3 years ago

Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode

metroholografix• 3 years ago

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?

BeetleB3• 3 years ago

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.

goku1211• 3 years ago

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.

OO000oo• 3 years ago

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.

goku1211• 3 years ago

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.

pxc6• 3 years ago

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.

nvy2• 3 years ago

Not OP but here's mine: https://github.com/nathanvy/dotemacs

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

goku1211• 3 years ago

Sorry I couldn't post earlier. Here is a sample:

https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...

oslacci• 3 years ago

Is the configuration still "paste this mystery lisp code somewhere in a config / ini file in x,y,z place" or is it finally plug-and-play like in VSC?

otabdeveloper42• 3 years ago

M-x customize exists since forever, and is more plug-and-play than VSCode ever was.

The real problem with Emacs is the shitload of bugs that case weird, undocumented and annoying behavior. A scripting language like elips is not meant for programming something as large and complex as Emacs.

hollerith• 3 years ago

I dislike customize though whereas I like the GUI interface to settings in vscode.

I agree Emacs has too many bugs (but I haven't found anything that suits me better for maintaining notes and to-do lists and such).

precompute4• 3 years ago

The real problem with Emacs is the shitload of bugs that case weird, undocumented and annoying behavior.

Could you name a few of these "bugs"? I use Emacs for practically everything and bugs are very difficult to encounter, even on Emacs HEAD.

A scripting language like elips is not meant for programming something as large and complex as Emacs.

Well, that's just plain wrong. A lot of vanilla Emacs functionality is written in Elisp.

jks4• 3 years ago

My experience is the opposite: I can keep my init.el in version control, and it contains Lisp code that I can run and debug by hand if needed. If some mode doesn't work right, I can step through its code and examine its variables. If I want to know what a key combination does, I can ask Emacs and it will tell me something like "M-s l runs the command consult-line (found in global-map), which is an interactive native-compiled Lisp function in ‘consult.el’." So I know that the combination is defined in global-map, and the function is defined in consult.el, and I can easily find the code.

In VS Code it's certainly easy to install an extension. Some mystery thing happens, and there are new commands available and some programming language support might be enhanced, but it is all very opaque. If I wanted to debug the code, I have no clue where to start. I'm sure it's there somewhere but all this looks to me much less discoverable than in Emacs.

precompute4• 3 years ago

You will not have this issue if you bother learning emacs lisp first. C-h is your friend.

BeetleB3• 3 years ago

As a multi-decade Emacs user, this sentiment was never correct, and needs to die. You can do insanely powerful stuff in Emacs without learning elisp. I myself was a power user for 9 years before I learned elisp. While it definitely gets you to the "next level", learning it was not a revolutionary improvement.

teddyh4• 3 years ago

In the menu bar, click “Options” → “Manage Emacs Packages”. Install whatever packages you like. You can even configure third-party package repositories.

ladyanita22• 3 years ago

It's a shame modern distros don't ship with it...

adr1an3• 3 years ago

Yes! I have Ubuntu at my office and is difficult to get the latest emacs. I found a PPA but it has a bit of lagging behind..

rolandog• 3 years ago

My approach has been to install Guix, and with Guix install emacs-next (and python-wrapper, and python-pip).

I'm still a Guix newb, so all I can say is that there may be some tweaking to be done if you're using non-default paths, (e.g. XDG Base Directory Specification) [0].

[0] https://mail.gnu.org/archive/html/guix-devel/2019-03/msg0045...

botanical3• 3 years ago

There's a snap that's updated very quickly:

https://github.com/alexmurray/emacs-snap/

In fact, it's already updated

bachmeier2• 3 years ago

It would definitely be nice to have an updated PPA, but compared to some apps, Emacs is simple and fast to compile - just a ./configure followed by make. (The first time, you need to install a few dependencies, but that's automated too, something like apt-get build-dep emacs).

Y_Y2• 3 years ago

I have a script to build it myself, took a little but of time to get right, but now it works nicely and I can stay at the bleeding edge.

jjrh• 3 years ago

The core issue is there isn't a 'emacs.tiny' package that contains a small subset of emacs features.

This makes it difficult to install emacs on a resource constrainted environment like a embedded system, and hard to justify installing on a server. (Yes we can use tramp but it's not always a option)

It's a real shame and why I still need to know vi and vim.

globular-toast3• 3 years ago

Most emacs users I know retain a modicum of vi/vim knowledge for those situations where emacs isn't available. It's more because of the ubiquity of vi/vim, though. There are mini versions of emacs available like MicroEmacs and mg, the latter being more compatible with GNU Emacs.

teddyh4• 3 years ago

Debian and derivatives (like Ubuntu) have the “emacs-nox” package, which should qualify for your needs, I think?

User232• 3 years ago

One option is uEmacs (or one of its many forks such as mg). It’s tiny.

globular-toast3• 3 years ago

Built it this morning on Gentoo!

voicedYoda• 3 years ago

Every single time i open up the tutorials on how to learn emacs, a million other priorities come along. I know there are die hard fans of it, and I'd love to learn it, but with VSCode, vi, tmux, and all the MacOS tools i know, I'm not sure I'll get around to learning it before i burn out completely from engineering

legends2k6• 3 years ago

I hear you. The only way I could get around trying to learn Emacs was to stop and actually use it as my daily driver (making a pact with myself not to use another editor for 15 days). Given "normal" editor keys (cursor keys, page up/down) work out of the box in Emacs, this wasn't hard (you could enable CUA additionally for regular cut, copy, paste, I stuck with kill and yank though).

todd8• 3 years ago

Emacs is daunting, I've used it since grad school in the 80's, and I'm still familiar with only a couple of hundred packages/extensions available out of thousands that are available. Likewise, I use maybe a couple of hundred commands and key bindings (out of thousands available--Emacs interactive help with finding the commands makes this possible).

I can imagine how hard it must be to learn the basics buried within a mountain of functionality. The way I learned to use Emacs originally was by learning to use a stripped down Emacs-like editor that ran on my home PC running MS-DOS. This editor used the same basic key bindings and supported the fundamental operations one uses to edit files: navigation, directory browsing, reading and saving files and so forth, all with the same keys that full blown Emacs uses.

Instead of installing Emacs, try installing micro-Emacs (its actual name is mg). This should run on Linux, MacOS, or Windows. On the Mac, you can install mg using homebrew. This is a perfectly good editor, and it uses the keys and commands that make up most of the ones I use every day. It just has fewer features, no Org mode, no image browsing, no support for git, no Email clients, no GPG support, no Voice output, no games, etc. It's just a solid text editor that will run in text mode.

Within a few days of using mg, you will be able to navigate around a document, open and save files, browse directories, and know how to get basic help within the editor. Then try Emacs and only add extensions as you need or want them.

globular-toast3• 3 years ago

I haven't touched my emacs config in a while, looks like it's due for a big update! I'm excited!

billfruit2• 3 years ago

Does intellisense like autocomplete now work out of the box? Is company bundled in, as of recent versions? Is there any dependency on Clang to get it working for C/C++ code?

yissp• 3 years ago

You still need to set up an LSP server, so not exactly out-of-the-box. Something like clangd or ccls for C/C++.

gnuvince• 3 years ago

Eglot is the built-in LSP client. You need an external server. If you do C or C++, clangd is likely what you want. Install it (apt install clangd) and enable eglot for C or C++ files in your Emacs config, (add-hook 'c-mode-hook 'eglot-ensure).

billfruit2• 3 years ago

And if you are in a legacy system with no clang then?

Emacs is usually batteries included, couldn't an lsp server have been part of the package..

ezekiel68• 3 years ago

Nothing kills it!

jvandonsel2• 3 years ago

Except maybe a file with really long lines.

karthink• 3 years ago

This has been addressed in Emacs 29.

From the NEWS file:

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.

clircle• 3 years ago

Thank you Eli !!!

anonzzzies4• 3 years ago

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.

cropcirclbureau• 3 years ago

What aspects of Docker trouble you so?

maccard5• 3 years ago

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

[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

kstrauser5• 3 years ago

I did the same a while back.

I've been enjoying podman.

anonzzzies4• 3 years ago

Thanks will try.

ParetoOptimal7• 3 years ago

Off-topic: what is an emacs quality alternative for docker? It’s such a piece of garbage for something so pervasive.

Nix and direnv via envrc-mode.

jwr5• 3 years ago

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.

xyproto• 3 years ago

This is an emacs-centric world view and many of the same arguments applies to open source software in general.

jwr5• 3 years ago

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.

rdtsc• 3 years ago

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

krylon2• 3 years ago

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.

jon_adler2• 3 years ago

No an eMacs user myself, but do you ever imagine a time when the software might be considered “done”?

golem14• 3 years ago

TeX and LaTeX are pretty close to 'done'

knome• 3 years ago

"[a program] is never finished, only abandoned"

jwr5• 3 years ago

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.

ssivark• 3 years ago

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.

psd1• 3 years ago

Not to jump down your throat, but "eMacs" is hurting my eyes.

I blame sTeve jObs.

pama• 3 years ago

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.

nvy2• 3 years ago

Emacs was called "obsolete", "hard to use", "bizarre", and other things.

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.

jwr5• 3 years ago

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.

ramblerman• 3 years ago

The lindy effect applies to lots of things in life

1. https://en.m.wikipedia.org/wiki/Lindy_effect

pjmlp• 3 years ago

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.

hiepph• 3 years ago

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.

jwr5• 3 years ago

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.

Dobiasd• 3 years ago

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.

garfieldnate• 3 years ago

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.

treeblah2• 3 years ago

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:

https://emacs-config-generator.fly.dev/

thih93• 3 years ago

I tried generating a file [1] and got this error when running emacs:

Symbol's function definition is void: package-vc-install

[1] https://emacs-config-generator.fly.dev/config?font_family=Me...

treeblah2• 3 years ago

Hm, what's your `(emacs-version)`? `package-vc-install' is only available in Emacs 29+.

throw156754228• 3 years ago

Is performance any better than 28 on Mac？ I recently tried putting 28 on my work M1 and magit diffing on the status screen, where you can roll up diff hunks by hitting minus, was unusably slow on large files. My own Linux laptop has no such problem.

catern• 3 years ago

That's actually a git issue - git is notoriously slow on OS X, and magit uses git heavily in a way that is correspondingly slow.

teddyh4• 3 years ago

NEWS: <https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=...>

Official release announcement: <https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>

teddyh4• 3 years ago

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.

Yes!

thih93• 3 years ago

What does a new release like this mean for popular frameworks like spacemacs or doom emacs?

E.g. for lsp support, are the frameworks switching to the native one or are they going to rely on their current setup for now? Or is there no common approach?

rhaps0dy2• 3 years ago

In Doom emacs, you can add the +eglot switch to your lsp tool to use Eglot (the new setup) instead. https://docs.doomemacs.org/latest/modules/tools/lsp/

cutler3• 3 years ago

For Spacemacs remember to use the devel branch, not stable which hasn't been updated in ages.

cutler3• 3 years ago

For Clojure there's nothing better than Emacs + CIDER/nREPL. I've tried Calva/VS Code, Conjure/NeoVim and Cursive/IntelliJ but none of them come close. Maybe it's the ELisp foundation facilitating code-as-data.

michaelcampbell• 3 years ago

Sadly this doesn't play well with fzf-el (at least not with fzf-find-file). I've entered a ticket on the fzf.el github, but it seems a mostly dead or dying project.

Anyone else use fzf successfully with 29.x?

Emacs 29.1

Related Stories