27 ms·

Emacs 29.1

378 points by pimeys 3y ago

michaelcampbell 3y 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?
mark_l_watson 3y 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?
- deleted 3y ago
  [deleted]
- blahgeek 3y 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
- aardvark179 3y 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?
- ducktective 3y 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.
  - lycopodiopsida 3y 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.
    - funcDropShadow 3y ago
      In my experience Emacs is slow when I enable evil. I do like vim keybinding, but using evil negates most of the benefits for me since it introduces unbearables pauses. That is with Doom emacs under Linux.
      - lycopodiopsida 3y ago
        They can be disabled in the init.el, I’ve done it for a year or so. Emacs-keybindings are less ergonomic, but also have less cognitive overhead imo.
      - ducktective 3y ago
        The exact setup I tested (evil+doom) but without nativecomp, same feedback
  - mplanchard 3y 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
  - 3836293648 3y ago
    Tui emacs is a bit slower than nvim, but close enough. Gui emacs is much, much slower than nvim
- bingemaker 3y 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?
  - kstrauser 3y ago
    Add `--with-native-comp` to that.
    - bingemaker 3y ago
      Thanks, time to try this
      - kstrauser 3y ago
        Oh, I just realized I'm using https://github.com/d12frosted/homebrew-emacs-plus https://github.com/d12frosted/homebrew-emacs-plus . I recommend using that over the default formula.
        bingemaker 3y ago
        I use this one https://github.com/daviderestivo/homebrew-emacs-head https://github.com/daviderestivo/homebrew-emacs-head
  - mediumsmart 3y 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)
- agumonkey 3y ago
  makes me wonder, is the target of native compilation something general like 386 ? can i share .eln between x86 computers ?
gjvc 3y ago
emacs has never been in better shape
- sph 3y 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 3y ago
    Gnu emacs is only 38 years old. And vscode is a fad...?
    - weebull 3y ago
      VSCode is very much a fad, much like Eclipse, Atom, Sublime and any number of others before it. Emacs and Vim just keep going whilst others fade away.
      - Aurelius108 3y ago
        I agree that sublime is a fad and maybe atom. Sublime’s biggest mistake imho way their proprietary model combined with a plugin system, it’d probably be better to either make it free or make it very ease to use. I don’t see eclipse or VSCode as fads though. To my knowledge eclipse is the only way to develop Java code on Linux platforms without paying for richer tools (let’s face it, eMacs or vim doesn’t have much support for Java). Also Microsoft seems very invested in VSCode
        shakow 3y ago
        > eclipse is the only way to develop Java code on Linux platforms without paying for richer tools All the people I know are using IntelliJ CE.
      - pk2200 3y ago
cjohansson 3y 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 3y 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 3y 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 3y ago
  X-windowing system is also MIT-licensed, were they every avoiding that license?
- hvis 3y 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 3y 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 3y ago
aardvark179 3y ago
Right, emacs upgrade is now added to the list of things to do on my day off tomorrow.
- enbugger 3y 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).
  - jackcviers3 3y 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.
    - Paul-Craft 3y ago
      Or just install spacemacs and get a lot of that set up for you for free, plus a bunch of other cool stuff.
      - vinceguidry 3y ago
        Spacemacs hinders your growth with Emacs over the long run. It hides Emacs internals from you and jumps through a lot of hoops to make Emacs feel modern. But the beauty is skin-deep and the second you start wanting something off-script, you'll find it getting in your way, with online threads and such catering towards vanilla rather than frameworks.
        Paul-Craft 3y ago
        I disagree 100%. There is literally nothing you can do within init.el that you can't do within `.spacemacs`, and you will rarely have to venture outside of `dotspacemacs/user-config ()` except to add layers or packages to the appropriate config variables so they can be installed automatically for you. I've been using emacs for over 10 years and had zero issues with making the transition. On the contrary, it's simplified my emacs life quite a bit. The only thing I have not been able to get working is `eaf`, but that's clearly not the fault of spacemacs.
lmedinas 3y 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 3y ago
  You can use M-x customize to pick configuration options from a menu.
- nequo 3y ago
  What modern feature is Emacs missing?
  - worthless-trash 3y ago
    I feel the comment was bait.
    - mm007emko 3y ago
      Exactly. I have been using git for my .emacs files and there is little I really miss from Emacs for editing files and even quite a lot of coding.
  - wiz21c 3y 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.
joobus 3y 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.
- jeltz 3y 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.
- broodbucket 3y ago
  It's really not that bad, it's just different. There's pros and cons. https://git-send-email.io/ 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.
  - joobus 3y ago
    I think the mailing list flow is a hindrance to attracting the next generation of contributors.
    - precompute 3y ago
      The "next generation" of Emacs contributors will be Emacs users and will not have any issues using email for collaboration. Git was made for email. Needing a separate service for it is mostly cruft, when you have mailing lists. Yes, github has mass appeal, but a lot of software has been written with just email collaboration. As for attracting low-quality contributions, I don't think they matter. People who use Emacs and depend on it will contribute. Interest in Emacs has increased and so have the available features.
TacticalCoder 3y 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 3y ago
What an amazing release. Thank you to all that contributed and made it happen!
- goku12 3y 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 3y ago
    What kind of new packages would spawn from the introduction of PGTK?
    - goku12 3y ago
      This video discusses the work on pure gtk: https://www.youtube.com/watch?v=LPwr8WeE8jU https://www.youtube.com/watch?v=LPwr8WeE8jU . I found it by following this story. It talks about Emacs essentially becoming a GTK widget and possibility of nesting GTK widgets in Emacs. I'm not fully aware of what they will lead to.
      - marco_craveiro 3y ago
        Oh, that is extremely interesting!! It would be great to hear more about this!
pard68 3y 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 3y ago
  Is this with or without Treesitter?
  - pard68 3y 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.
  - pard68 3y 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.
- deleted 3y ago
  [deleted]
- jackcviers3 3y ago
  Probably needs its own extension like in vscode.
- shadowgovt 3y 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-Craft 3y ago
  I'm not familiar with Lit, but if emacs can't grok all the nesting, how is it even remotely human comprehensible?
TacticalCoder 3y 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 3y ago
  Why not add support? Nobody owns emacs any more or less than you!
  - TacticalCoder 3y 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 3y 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.
  - TacticalCoder 3y ago
    Ah that's interesting, I wasn't aware. I'll try that and recompile if needed, thanks a huge lot for the info!
  - TacticalCoder 3y ago
goku12 3y 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 3y 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 3y ago
    Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-vi-Mode.html https://www.gnu.org/software/bash/manual/html_node/Readline-...
  - supazek 3y ago
    Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode
- metroholografix 3y 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?
oslacci 3y 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?
- otabdeveloper4 3y 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 3y 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).
    - _a_a_a_ 3y ago
      I've found very few in many years' use. You may be a more competent user than I. Please report bugs, the devs are very responsive.
  - precompute 3y 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.
    - otabdeveloper4 3y ago
      Core Emacs is simple enough to mostly be bug-free. But any elisp package will have lots of annoying small day-to-day bugs and glitches.
ladyanita22 3y ago
It's a shame modern distros don't ship with it...
- adr1an 3y 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 3y 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/msg00452.html https://mail.gnu.org/archive/html/guix-devel/2019-03/msg0045...
  - botanical 3y ago
    There's a snap that's updated very quickly: https://github.com/alexmurray/emacs-snap/ https://github.com/alexmurray/emacs-snap/ In fact, it's already updated
    - trogdc 3y ago
      Does this have native-comp enabled? Or do you still have to build from source for that?
      - botanical 3y ago
        No, it's enabled by default. Last I built Emacs, it took me more than an hour to build. The default branch has native-compilation, tree-sitter, and json enabled. See here for the enabled flags: https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml https://github.com/alexmurray/emacs-snap/blob/master/snapcra...
  - bachmeier 3y ago
voicedYoda 3y 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
- todd8 3y 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.
- legends2k 3y 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 (CUE) work out of the box in Emacs, this wasn't hard.
- legends2k 3y 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).
globular-toast 3y ago
I haven't touched my emacs config in a while, looks like it's due for a big update! I'm excited!
billfruit 3y 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 3y 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 3y 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).
  - billfruit 3y 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..
    - legends2k 3y ago
      That'd increase the package disk footprint by a large value since there are many languages supported by Emacs by default.
    - trealira 3y ago
      Then it would just have a dependency on Clang, and you couldn't use Emacs at all (since you can't use Clang). AFAIK, the only alternative to the clangd language server is ccls: https://github.com/MaskRay/ccls https://github.com/MaskRay/ccls
ezekiel68 3y ago
Nothing kills it!
- jvandonsel 3y ago
  Except maybe a file with really long lines.
  - karthink 3y 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.
    - jvandonsel 3y ago
      Finally! Thanks.
clircle 3y ago
Thank you Eli !!!
anonzzzies 3y 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 3y ago
  What aspects of Docker trouble you so?
  - maccard 3y 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 https://github.com/docker/for-mac/issues/1432 [1] https://github.com/docker/for-win/issues/599 https://github.com/docker/for-win/issues/599 [2] https://github.com/docker/for-win/issues/1976 https://github.com/docker/for-win/issues/1976
    - anonzzzies 3y ago
      I was typing this on my phone, but yes. This. Thanks! To add: Mac OS X docker actually, after a while, without errors, stops responding to running dockers and you cannot remove them without reboot. It’s total garbage, but cannot move from it as everyone uses it. So, emacs-stable alternative for docker. Maybe that should be a movement; emacs-alternative-for. I have many already; software that is fast, can run for months/years and doesn’t get slow vs stuff you need to actually reboot for to run ok. I mean emacs is bloated (yeah right, compared to whatever others are pushing out?) but disk space, even sdd is almost free; it simply runs for months without memory growth or performance degradation. The only reason I stop it because of reboot for sec updates.
jwr 3y 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.
- ramblerman 3y ago
  The lindy effect applies to lots of things in life 1. https://en.m.wikipedia.org/wiki/Lindy_effect https://en.m.wikipedia.org/wiki/Lindy_effect
- pjmlp 3y 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 3y 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.
treeblah 3y 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/ https://emacs-config-generator.fly.dev/
- thih9 3y 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=Menlo&theme=dark&feature%5B%5D=helpful&feature%5B%5D=vim&feature%5B%5D=denote&feature%5B%5D=magit&feature%5B%5D=breadcrumbs&feature%5B%5D=lisp https://emacs-config-generator.fly.dev/config?font_family=Me...
  - treeblah 3y ago
    Hm, what's your `(emacs-version)`? `package-vc-install' is only available in Emacs 29+.
    - thih9 3y ago
      Looks like it’s acually 28, my bad; thanks, I’ll update and retry later.
throw156754228 3y 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 3y 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.
teddyh 3y ago
NEWS: <https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29 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.html https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>
teddyh 3y 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!
thih9 3y 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?
- rhaps0dy 3y 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/ https://docs.doomemacs.org/latest/modules/tools/lsp/
- cutler 3y ago
  For Spacemacs remember to use the devel branch, not stable which hasn't been updated in ages.
cutler 3y 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.

378 points by pimeys 3y 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?

mark_l_watson 3y 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?

deleted 3y ago
[deleted]
blahgeek 3y 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
aardvark179 3y 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?
ducktective 3y 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.
- lycopodiopsida 3y 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.
  - funcDropShadow 3y ago
    In my experience Emacs is slow when I enable evil. I do like vim keybinding, but using evil negates most of the benefits for me since it introduces unbearables pauses. That is with Doom emacs under Linux.
    - lycopodiopsida 3y ago
      They can be disabled in the init.el, I’ve done it for a year or so. Emacs-keybindings are less ergonomic, but also have less cognitive overhead imo.
    - ducktective 3y ago
      The exact setup I tested (evil+doom) but without nativecomp, same feedback
- mplanchard 3y 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
- 3836293648 3y ago
  Tui emacs is a bit slower than nvim, but close enough. Gui emacs is much, much slower than nvim
bingemaker 3y 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?
- kstrauser 3y ago
  Add `--with-native-comp` to that.
  - bingemaker 3y ago
    Thanks, time to try this
    - kstrauser 3y ago
      Oh, I just realized I'm using https://github.com/d12frosted/homebrew-emacs-plus https://github.com/d12frosted/homebrew-emacs-plus . I recommend using that over the default formula.
      - bingemaker 3y ago
        I use this one https://github.com/daviderestivo/homebrew-emacs-head https://github.com/daviderestivo/homebrew-emacs-head
- mediumsmart 3y 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)
agumonkey 3y ago
makes me wonder, is the target of native compilation something general like 386 ? can i share .eln between x86 computers ?

gjvc 3y ago

emacs has never been in better shape

sph 3y 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 3y ago
  Gnu emacs is only 38 years old. And vscode is a fad...?
  - weebull 3y ago
    VSCode is very much a fad, much like Eclipse, Atom, Sublime and any number of others before it. Emacs and Vim just keep going whilst others fade away.
    - Aurelius108 3y ago
      I agree that sublime is a fad and maybe atom. Sublime’s biggest mistake imho way their proprietary model combined with a plugin system, it’d probably be better to either make it free or make it very ease to use. I don’t see eclipse or VSCode as fads though. To my knowledge eclipse is the only way to develop Java code on Linux platforms without paying for richer tools (let’s face it, eMacs or vim doesn’t have much support for Java). Also Microsoft seems very invested in VSCode
      - shakow 3y ago
        > eclipse is the only way to develop Java code on Linux platforms without paying for richer tools All the people I know are using IntelliJ CE.
    - pk2200 3y ago

cjohansson 3y 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 3y 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 3y 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 3y ago
X-windowing system is also MIT-licensed, were they every avoiding that license?
hvis 3y 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 3y 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 3y ago

aardvark179 3y ago

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

enbugger 3y 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).
- jackcviers3 3y 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.
  - Paul-Craft 3y ago
    Or just install spacemacs and get a lot of that set up for you for free, plus a bunch of other cool stuff.
    - vinceguidry 3y ago
      Spacemacs hinders your growth with Emacs over the long run. It hides Emacs internals from you and jumps through a lot of hoops to make Emacs feel modern. But the beauty is skin-deep and the second you start wanting something off-script, you'll find it getting in your way, with online threads and such catering towards vanilla rather than frameworks.
      - Paul-Craft 3y ago
        I disagree 100%. There is literally nothing you can do within init.el that you can't do within `.spacemacs`, and you will rarely have to venture outside of `dotspacemacs/user-config ()` except to add layers or packages to the appropriate config variables so they can be installed automatically for you. I've been using emacs for over 10 years and had zero issues with making the transition. On the contrary, it's simplified my emacs life quite a bit. The only thing I have not been able to get working is `eaf`, but that's clearly not the fault of spacemacs.

lmedinas 3y 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 3y ago
You can use M-x customize to pick configuration options from a menu.
nequo 3y ago
What modern feature is Emacs missing?
- worthless-trash 3y ago
  I feel the comment was bait.
  - mm007emko 3y ago
    Exactly. I have been using git for my .emacs files and there is little I really miss from Emacs for editing files and even quite a lot of coding.
- wiz21c 3y 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.

joobus 3y 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.

jeltz 3y 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.
broodbucket 3y ago
It's really not that bad, it's just different. There's pros and cons. https://git-send-email.io/ 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.
- joobus 3y ago
  I think the mailing list flow is a hindrance to attracting the next generation of contributors.
  - precompute 3y ago
    The "next generation" of Emacs contributors will be Emacs users and will not have any issues using email for collaboration. Git was made for email. Needing a separate service for it is mostly cruft, when you have mailing lists. Yes, github has mass appeal, but a lot of software has been written with just email collaboration. As for attracting low-quality contributions, I don't think they matter. People who use Emacs and depend on it will contribute. Interest in Emacs has increased and so have the available features.

TacticalCoder 3y 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 3y ago

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

goku12 3y 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 3y ago
  What kind of new packages would spawn from the introduction of PGTK?
  - goku12 3y ago
    This video discusses the work on pure gtk: https://www.youtube.com/watch?v=LPwr8WeE8jU https://www.youtube.com/watch?v=LPwr8WeE8jU . I found it by following this story. It talks about Emacs essentially becoming a GTK widget and possibility of nesting GTK widgets in Emacs. I'm not fully aware of what they will lead to.
    - marco_craveiro 3y ago
      Oh, that is extremely interesting!! It would be great to hear more about this!

pard68 3y 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 3y ago
Is this with or without Treesitter?
- pard68 3y 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.
- pard68 3y 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.
deleted 3y ago
[deleted]
jackcviers3 3y ago
Probably needs its own extension like in vscode.
shadowgovt 3y 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-Craft 3y ago
I'm not familiar with Lit, but if emacs can't grok all the nesting, how is it even remotely human comprehensible?

TacticalCoder 3y 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 3y ago
Why not add support? Nobody owns emacs any more or less than you!
- TacticalCoder 3y 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 3y 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.
- TacticalCoder 3y ago
  Ah that's interesting, I wasn't aware. I'll try that and recompile if needed, thanks a huge lot for the info!
- TacticalCoder 3y ago

goku12 3y 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 3y 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 3y ago
  Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-vi-Mode.html https://www.gnu.org/software/bash/manual/html_node/Readline-...
- supazek 3y ago
  Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode
metroholografix 3y 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?

oslacci 3y 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?

otabdeveloper4 3y 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 3y 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).
  - _a_a_a_ 3y ago
    I've found very few in many years' use. You may be a more competent user than I. Please report bugs, the devs are very responsive.
- precompute 3y 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.
  - otabdeveloper4 3y ago
    Core Emacs is simple enough to mostly be bug-free. But any elisp package will have lots of annoying small day-to-day bugs and glitches.

ladyanita22 3y ago

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

adr1an 3y 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 3y 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/msg00452.html https://mail.gnu.org/archive/html/guix-devel/2019-03/msg0045...
- botanical 3y ago
  There's a snap that's updated very quickly: https://github.com/alexmurray/emacs-snap/ https://github.com/alexmurray/emacs-snap/ In fact, it's already updated
  - trogdc 3y ago
    Does this have native-comp enabled? Or do you still have to build from source for that?
    - botanical 3y ago
      No, it's enabled by default. Last I built Emacs, it took me more than an hour to build. The default branch has native-compilation, tree-sitter, and json enabled. See here for the enabled flags: https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml https://github.com/alexmurray/emacs-snap/blob/master/snapcra...
- bachmeier 3y ago

voicedYoda 3y 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

todd8 3y 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.
legends2k 3y 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 (CUE) work out of the box in Emacs, this wasn't hard.
legends2k 3y 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).

globular-toast 3y ago

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

billfruit 3y 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 3y 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 3y 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).
- billfruit 3y 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..
  - legends2k 3y ago
    That'd increase the package disk footprint by a large value since there are many languages supported by Emacs by default.
  - trealira 3y ago
    Then it would just have a dependency on Clang, and you couldn't use Emacs at all (since you can't use Clang). AFAIK, the only alternative to the clangd language server is ccls: https://github.com/MaskRay/ccls https://github.com/MaskRay/ccls

ezekiel68 3y ago

Nothing kills it!

jvandonsel 3y ago
Except maybe a file with really long lines.
- karthink 3y 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.
  - jvandonsel 3y ago
    Finally! Thanks.

clircle 3y ago

Thank you Eli !!!

anonzzzies 3y 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 3y ago
What aspects of Docker trouble you so?
- maccard 3y 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 https://github.com/docker/for-mac/issues/1432 [1] https://github.com/docker/for-win/issues/599 https://github.com/docker/for-win/issues/599 [2] https://github.com/docker/for-win/issues/1976 https://github.com/docker/for-win/issues/1976
  - anonzzzies 3y ago
    I was typing this on my phone, but yes. This. Thanks! To add: Mac OS X docker actually, after a while, without errors, stops responding to running dockers and you cannot remove them without reboot. It’s total garbage, but cannot move from it as everyone uses it. So, emacs-stable alternative for docker. Maybe that should be a movement; emacs-alternative-for. I have many already; software that is fast, can run for months/years and doesn’t get slow vs stuff you need to actually reboot for to run ok. I mean emacs is bloated (yeah right, compared to whatever others are pushing out?) but disk space, even sdd is almost free; it simply runs for months without memory growth or performance degradation. The only reason I stop it because of reboot for sec updates.

jwr 3y 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.

ramblerman 3y ago
The lindy effect applies to lots of things in life 1. https://en.m.wikipedia.org/wiki/Lindy_effect https://en.m.wikipedia.org/wiki/Lindy_effect
pjmlp 3y 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 3y 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.

treeblah 3y 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/ https://emacs-config-generator.fly.dev/

thih9 3y 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=Menlo&theme=dark&feature%5B%5D=helpful&feature%5B%5D=vim&feature%5B%5D=denote&feature%5B%5D=magit&feature%5B%5D=breadcrumbs&feature%5B%5D=lisp https://emacs-config-generator.fly.dev/config?font_family=Me...
- treeblah 3y ago
  Hm, what's your `(emacs-version)`? `package-vc-install' is only available in Emacs 29+.
  - thih9 3y ago
    Looks like it’s acually 28, my bad; thanks, I’ll update and retry later.

throw156754228 3y 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 3y 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.

teddyh 3y ago

NEWS: <https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29 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.html https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>

teddyh 3y 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!

thih9 3y 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?

rhaps0dy 3y 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/ https://docs.doomemacs.org/latest/modules/tools/lsp/
cutler 3y ago
For Spacemacs remember to use the devel branch, not stable which hasn't been updated in ages.

cutler 3y 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.