Emacs 27.1 | Hacker News Reader

Emacs 27.1

lists.gnu.org

370 pointsddavis200 comments

I would strongly recommend everyone try the native-comp Emacs 28 branch. Native compilation of Elisp files has greatly improved performance and start-up time, with no downside.

Though it's bleeding edge, I haven't experienced any issues: everything just works.. faster!

It always amazes me that some people are willing to put in such hard work, alone, for open source. The fact that one guy managed to speed up all of Emacs 2x-20x in his spare time for no pay is frankly amazing. Certainly puts my side-projects to shame.

> It always amazes me that some people are willing to put in such hard work, alone, for open source.

For many people this is about scratching an itch, their own itch.

They improve upon it not for the sake of "open source", but for the sake of making the very same tools they rely on to be better tools.

This is how open-source used to work, and this is how it grew.

> It always amazes me that some people are willing to put in such hard work, alone, for open source.

Apart of a few well known projects, the open source world is not so rosy.

I'm building an app that exports GPX files (XML file where you can store GPS positions, POIs, routes etc).

All the examples files on the official website ( https://www.topografix.com/gpx.asp ) are broken (they return a blank page) and to validate that your file is compliant you have to compile a 15 years old C++ library first (for some reason they refuse to release a binary).

What does your app do? That's an area I'm pretty interested in.

It's a desktop (Windows) map viewer.

I have built my own OSM server to pre-generate tiles so my app has offline capabilities (I have a very slow internet connection so online maps are quite laggy).

I use it mostly to build routes that I export as gpx files to my Android phone (vehicle nav with Osmand and trekking with Iphigénie).

this sounds super useful to me (I have been in similar situations in the past @ various formats that aren’t super popular).

What sounds useful ? The app ? If you don't have complex requirements there's surely something available for your platform.

Have a look at https://gdal.org/index.html

Solved a lot of weird open formats issue we had

Thanks but I already wrote the code and after catching a couple gotchas with the validation tool it's fully compliant now.

My point was not that GPX is hard (it's not) but that when something is open source most of the time you have to put some elbow grease in it because no one is paid to make it polished.

FWIW, it took me less time to write the GPX export code than to look for a binary of the validation tool, fail, then launch WSL and compile the goddam tool.

I second every single line of this comment.

Here's the update log of the project.

https://akrl.sdf.org/gccemacs.html

With https://akrl.sdf.org/gccemacs.html#orgfc80a25 being the relevant starting point in that sea of text (the PKGBUILD is also handy for seeing what's going on: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs... )

oss will have to mature a bit like good ol corporate programming did

an OSS project will do so much and may die, the next one will try a new branch (from scratch, influenced a bit by the other or fully reusing the old ones)

to save energy it's good to think and plan for continuations.. your project will be much more useful if kept clear so other can jump in and extend or rewrite it without struggle

Is anybody distributing debian packages of builds off this branch? It's been some years since I built emacs from source...

The only tricky part for me was having to build gcc (for newer libgccjit). But it wasn't too bad. And you might not have to do that at all depending on your Debian version. Hour effort approx.

There was some minor brokenness native comp caused to my setup so still not using this branch. But most stuff did surprisingly work perfectly well.

Yeah I just ran through the checkout and configure process and found: configure: "error: Installed libgccjit has failed passing the smoke test."

FWIW this is libgccjit-10-dev, the most recently available package I could find in my install (debian based Google gLinux).

Not sure if I have the motivation to go build it, but who knows! Beats writing design docs, which is the other thing I could be doing ;-)

Yea was same for me. It's really not that bad.

   mkdir gcc
   cd gcc
   git clone git://gcc.gnu.org/git/gcc.git src
   mkdir build
   mkdir install
   PREFIX=$(pwd)/install
   cd build
   ../src/configure \
   --enable-host-shared \
   --enable-languages=jit,c++ \
   --disable-bootstrap \
   --enable-checking=release \
   --prefix=$PREFIX \
   --disable-multilib
   nice make -j4 # altering the "4" to however many cores you have

[0]

May need to install some prerequisites listed here https://gcc.gnu.org/install/prerequisites.html (the error message from the configure might not be obvious so better go through the list first, think I needed MPC and MPFR, whatever I found with apt-cache search libmpc and libmpfr worked).

And then configure and make emacs with PATH, LIBRARY_PATH, LD_LIBRARY_PATH including your gcc build (install/bin and install/lib).

[0] taken and modified from https://gcc.gnu.org/onlinedocs/gcc-6.4.0/jit/internals/index...

Have you ever tried flatpak. If so this may be helpful https://github.com/fejfighter/pgtk-emacs-flatpak Pre-configured flatpak manifest to build an emacs branch with libjanson, libgccjit and dependencies

edit: formatting

Thanks for this! I use Emacs but haven’t invested any time in my setup for a long time. After I get back from my morning hike, I am going to invest some time on this. Thanks again.

How do cool kids install Emacs with native-comp support on OSX these days? emacs-plus formula doesn't support it yet and neither does the Mitsuharu's port.

I'm not sure if I'm cool or not, but I built mine from source. Took a bit of doing. I found a helpful tutorial here:

https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058...

Oh, you're amazing! This is awesome, thank you. I just built it. Running smoothly.

I spoke too soon. I missed a step in the instructions. It's not working as expected. I'm gonna have to try again. Combining things from that gist and using some bits from here: https://gist.github.com/mikroskeem/0a5c909c1880408adf732ceba...

Me too, actually. Just found out today that it's not actually doing native comp. >:-( I haven't been able to build GCC with libjit support. (Used Clang while building; that solves some problems with GCC.) I've tried testing GCC/libjit on a smoketest and it hasn't worked. Please let me know what you get working!

Daamn... I've been building it with clang for the past hour (I dunno why the heck this taking soooo long, I think on Linux it builds much faster). I guess it won't work for me either :(

upd: Looks like the proper way of building is with gcc, but it builds without GUI. I need GUI.

Dude, if you can get it built, please either send me all the instructions or just post the binary.

Thanks for all your great tips on Twitter, btw. :)

Thank you for the kind words, I'm happy you find the tips useful. I stopped experimenting with native-comp in OSX for now. Sadly, I have only one Mac. Every attempt to compile it takes way too long, and getting Catalina running in VM is similarly challenging. But If I learn anything new I will definitely try again, and of course I will keep you posted.

I might try compiling it on my personal machine this week while I’m at work. I’ll keep you informed as well if anything interesting happens.

I just build this from source on my macbook. I noticed significantly higher CPU usage while scrolling. (30%! Non-native comp Emacs 28 w/GUI is around 10–20% when scrolling through a file with lsp mode turned on.) Is this expected? The scrolling seems to stutter at times for me. What am I doing wrong?

Did you compile all of the Elisp files using a high optimization level?

If so, you might want to get in contact with the author. I imagine that OSX isn't as well tested as Linux.

I might try setting that. I’m pretty new to all this; could you point me to where I can find instructions on how to set the optimization level?

I think you can just do:

  (setq comp-speed 3)

Then you should tell it to recompile all of your elisp files:

  (native-compile-async "~/.emacs.d/elpa/" <n> t)
  (native-compile-async "<path/to/system/elisp/files>" <n> t)

Where <n> is the number of threads you want. It's also possible than you have deferred compilation and that's the problem?

Thank you! I’ll give this all a try.

Darn it. When I try running the `native-compile-async` function, I get thrown into the debugger with a message telling me that Emacs wasn't compiled with native compiler support.

I did have to use clang instead of gcc to get past some errors about not finding Appkit.h. I'll have to do more digging and try and get gcc working. Thanks for your help though!

try this: https://github.com/daviderestivo/homebrew-emacs-head

Lots of these changes are quite significant improvements under the hood. One thing emacs has struggled with is that it has been around for a long time so many features were added when the libraries around them were quite immature, and emacs ended up with libraries that were difficult and outdated and insufficient manpower to quickly move to newer libraries. Another issue is the desire for backwards compatibility (which can rule out libraries which eg require gtk or can’t sufficiently cope with non-UTF-8 encodings).

Adding harfbuzz gives emacs much better text shaping and let’s emacs get rid of whatever ancient library they were using before. Similarly the old dependency (and security liability) on imagemagick can be dropped.

Other improvements should just allow certain elisp code to use C functions to run faster. I think it is a testament to the versatility of emacs lisp as a language that these things were good enough while implemented in pure elisp that they could still be productively used, so no one needed to first request new C functions before they could implement e.g. lsp clients or calculators.

> Adding harfbuzz gives emacs much better text shaping

FTI "If you give HarfBuzz a font and a string containing a sequence of Unicode codepoints, HarfBuzz selects and positions the corresponding glyphs from the font, applying all of the necessary layout rules and font features. HarfBuzz then returns the string to you in the form that is correctly arranged for the language and writing system."

https://harfbuzz.github.io/what-is-harfbuzz.html#what-is-tex...

Is "FTI" a thing or did you mean "FYI"?

Perhaps "For The/Those Interested"?

For Their Information. Like FYI, but presumably dan-robertson already knows! It's for the benefit of everyone else.

Some goodies in there. For example, a clear direction into making more things work when editing on remote hosts out of the box. I hope lsp/eglot pick that up, so that I can now edit on a remote host via ssh just like I could on a local one and still have semantic completion, references etc. Or the ability to just run ripgrep on the remote host transparently.

Really good call outs. Seamless toolchain integration with the remote host while on a TRAMP buffer has been a painpoint for me.

What are the specific pain points? Is it a limitation of lsp? This is one of the things that has felt magical in Emacs for near the past decade for me. So much "just works" if local or remote.

Now... Now that I am on 4g internet... I admit things can feel slow wicket than I'd care for. :(

One painpoint for me was that no matter what I tried, I couldn't get eglot to connect to a remotely started clangd. I haven't checked if that's solved now, but good to see that there's some momentum in remote editing in general.

Honest question: doesn't sshfs solve this problem? I've never understood the appeal of TRAMP, mounting the remote resources seems like a much better and less finicky solution.

You might not have the required host permission to mount a filesystem or you might not have sshfs at all (think about gnu emacs on windows).

Tramp is agnostic in most things (well, you need an ssh client at least).

Calling tramp a solution for windows is somewhat iffy though. So far I don't think there's an easy way to simply get it to work on windows (the path handling seems to forbid tramp-like paths on windows, which messes with things quite considerably).

Meh, it worked well enough for me when I had to use it on windows 7 first and 10 later (using putty as ssh client).

Yeah, you can get it to work with putty, but it's nowhere near as reliable as from Mac/Linux to server (and to be fair, network issues make it a less than optimal solution if you have a choice).

These days I just tmux on the server, open emacs and hack away (as long as you can install things on the server).

Tramp works for non-ssh remote terminals. Also it leads to remote commands running automatically rather than running commands locally against a remote fs.

TRAMP works well over slow connections and, if told to save temporary files locally, deals with connection loss pretty well.

There are some semantics differences, e.g. if a remote buffer is open then `shell-command` (M-!) will run commands on the remote machine and `shell` will open a terminal which is logged in to the remote machine. I run all my terminals in Emacs, so I use these a lot (my init.el wraps the latter in a function which invents new buffer names shell-1, shell-2, etc.).

TRAMP also feels faster to me; I presume it's due to background jobs adjusting their casual I/O usage when TRAMP is detected, like writing backup/lock files, scanning directories for VCS info, etc. which has high latency on SSHFS.

I also like using `/sudo:root@localhost:/foo` for editing local files with different user permissions (plus the same command and terminal behaviour as with SSH)

multi-hops[0] should probably be mentioned as well. Using those one can for example open a file using sudo via ssh:

    /ssh:you@remotehost|sudo:remotehost:/path

Doing any further actions on a file opened that way also applies the hops there as well. For the example above opening a shell or running a shell-command would run those through sudo on the remote host.

[0]: https://www.gnu.org/software/emacs/manual/html_node/tramp/Ad...

It's worth mentioning that this is not limited to SSH followed by sudo. It can also be used to edit remote files through a bastion host, by just adding more SSH hops to the file path.

After seven years of not working with Emacs, a few weeks ago I gave it a try. I was negative, biased and convinced that it would just be a distraction, a time waster. But the more I dived into it, I realized that the Emacs that I worked with in 2010-2013 was not the same anymore. Packages like `dash.el' or `s.el' make programming in Elisp fun! Then there are beautiful themes like `spacemacs'. Also packages for managing notes and files (`Deft' for instance).

Within a few days I migrated all my note-taking and task-managfement-systems to Emacs. Previously I was using Evernote, Bear app, Ulysses app for note taking and TaskPaper + OmniFocus for project management.

Emacs + Org-Mode replaced all those apps and many more. And it makes me `dance' with my data by using Elisp to transform all my data into ways I need and want.

I realized that I didn't use Emacs to its full potential in 2013 because I was reluctant to dive into (E)Lisp. This time I made a full dive into it. And I am absolutely loving it. I had some contanct with Scheme some twenty years ago, and that influenced me very much. But CL and Elisp offer much more.

Emacs does not need to be an IDE, but it can be a decent one. (Yes, I know and use intelliJ: PyCharm and PHPStorm). It can be used for everything text: Note taking, programming, transforming text. But via org-mode for much more than text: Project- and task-management, ascii-tables, note-management system. I even initiate my Google searches from within Emacs and keep a track of my searches via org-capture.

Thank you for all the maintainers!

Edit:

- I am a user of a Mac with a US keyboard. Using an app named "Karabiner Elements" to remap my keys. I have my caps and enter key behave like a Control key whenever I hit them in combo with other keys. That way I have two control keys in reach of both my pinkies.

- r/emacs and r/orgmode are super helpful communities

- learn to program in Lisp and have a look at Lisp macros. That's a very useful concept to write DSLs to transform code very easily. - scratch buffer is your friend in learning elisp. Place the cursor after the last colon of your code and hit `C-x C-e`, that will evaluate that line.

- Learn about debugging your Elisp code. Edebug (`edebug-defun`) is your friend. See http://blog.binchen.org/posts/my-work-flow-to-debug-emacs-pl...

- Be patient. Once you have mastered the basics, you'll fly!

Wow, thank you for introducing me to `dash.el` and `s.el`. I tried to learn Elisp a year back and was frustrating by the lack of basic functional facilities that I'm used to in my primary language (Elixir).

How do you recommend diving deeper? I feel like there is so much to Emacs that would make me much more productive, but I'm apprehensive to dive below the surface

Elixir is a beautiful language. I love the pipe operator and the elegance of the language. Much more consistent than the language I use daily (Python). Also: Coming to Python from Scheme I was missing the difference between destructive vs non-destructive operators [^1]. In Python I'd use `my_list.sort()'. That does not return the sorted list but `None', whereas `sorted(my_list)' returns a sorted copy of `my_list'. That's why I can't use method chaining in Python like this: `my_list.sort().first().to_str()'.

Re diving in Lisp:

1. I deleted my previous `.emacs` file and started from scratch.

2. I learned all about the internal help system of Emacs. `C-h f' will let me look up help for a function (it's "docstring"), `C-h v' will let me look up a variable, etc. - Navigating help via `C-h i' and then 'm' (for menu) will let me search the TOC entries in the help page. `l' (lower L) will let me go back in help.

3. Read good old recommended Lisp books. Seibel and many more are the classics.

4. Write code! Practical code that you need. Solve problems. Think of use-cases. - For instance, I needed to parse my Kindle annotations, which are saved like a log file in a file on the Kindle itself (the file is named `My Clippings.txt'. I had written a parser in Python to get the entries out of the file, now I did it in Elisp. Or you need a convenience function that performs several steps you need daily in your text-editing or org-files (creating template files, navigating the headars, whatnot).

5. Read the source code of the packages. They have wonderful examples for how to write code in Elisp. For instance `org-table.el'. It gave me many ideas for how to write idiomatic Elisp. - You can go to the source code of a package by looking up a function you use (`C-h f org-table-create RET', then click the hyperlinked package name `org-table.el'; that'll bring you right to the function in the package).

6. Read good code. For instance: Magnar Sveen. He has written many excellent packages. `dash.el' and `s.el' and some more. Check his github, read the code, and check his http://emacsrocks.com/ videos.

---

[^1]: "The names of procedures and syntactic forms that cause side effects end with an exclamation point ( ! ).". Source: https://www.scheme.com/tspl2d/intro.html

I'd very much recommend against using packages like dash and s. Most of dash can either be done with cl-lib or seq, and s are basically just wrapper functions. Both introduce bad style (look more like Clojure than Elisp) and promote inefficient (often functional) patterns.

wow, it's like I could have written this comment!

I'm starting a new project this week, and a fresh, empty org-roam database in my Spacemacs instance is really nice. I'm filing all these links and little org documents with references to each other and documenting my learning as I go. I'm also using Karabiner, Spacemacs, Org-Mode, etc etc. The Emacs subreddit is consistently one of the most helpful out there, it's fantastic.

(I used a new, clean org-roam database in an empty ~/Org folder because I wanted to leave behind all the cruft and stuff from the previous project, including potentially client-specific stuff.)

(ooh, ooh, I forgot: Emacs and org-mode are 2 things I donate to monthly. Emacs via $10 to the FSF, and org-mode via $5 via Github direct to the maintainer.)

Thanks for the tip re donation!

Edit: Re "I used a new, clean org-roam database in an empty ~/Org folder because I wanted to leave behind all the cruft and stuff from the previous project, including potentially"

Exactly what I did and what gave me a boost in learning Emacs+Elisp and a fresh start. My old `.emacs' file was holding me back!

I wonder if I should do that. I'm deep into Spacemacs and wonder if I should go for a clean Emacs approach rather than the Vim bindings.

I abandoned vim bindings (evil-mode). There were too many edge cases where it didn't work, and where I had to customize it to make it work.

With a good keyboard setup (two Control keys on the left and right) Emacs keybindings aren't that bad. Actually I like them.

This is a very important release for LSP users, as Emacs now has a fast, C-based JSON parser that speeds up e.g. lsp-mode significantly.

Nice. Is it a plug-in replacement? E.g. does eglot already make use of this, too, or will it need to be updated?

Eglot will use the native C JSON parsing if Emacs is compiled with jansson support.

lsp-mode recommends the same on its guide for improving performance: https://emacs-lsp.github.io/lsp-mode/page/performance/

I had to re-bytecode-compile lsp-mode to get it to pick up the faster JSON support (`M-x package-reinstall lsp-mode`). See `lsp-diagnose` for a quick way to check if you're good to go.

Thanks, but I'm using eglot. I might try lsp again, now that some time has passed, though.

Just a quick question on this, what's the best way to emulate an ide in emacs? I feel so overwhelmed by the options, and the additional tools you have to install alongside it. For example, python ide in emacs alone requires pyflakes, autopep8, jedi and so on... What's the most catchall, generic ide system where I don't have to fiddle with the config too much?

I've heard good things about doom emacs and spacemacs; might be worth giving one of those a try.

Doom Emacs is great an has more emphasis on performance and load time than Spacemacs

The main idea of Emacs is unlike other ide's it can be customized greatly to specific users, but Doom Emacs seems to be a ready made configuration. It seems to be opposite of the main idea behind Emacs, yet Doom Emacs seems to be getting popular. Is there anything i am missing.

You're missing that a default vanilla Emacs experience is pretty shitty. Besides, it's not like you're sacrificing any customizability with Doom/Prelude/Spacemacs, you're just getting a better starting point.

Maybe many users don't need a very specific configuration, and a great community made configuration is good enough :)

I use Spacemacs which is also a community made emacs configuration and it's great. The fact that I could have made the customization myself does not make this configuration any worse.

You can consider doom emacs a 'mod' that make it easier to manage your customized emacs config.

If anything I found doom to make it easier to stay close to the 'intended' way to customize emacs, since it heavily encourages you to use 'use-package' and 'general.el' to manage your extensions, and gives you good startup performance if you use them as intended (allowing the lazy-loading to do its work).

Although it's possible I was simply more familiar with the 'right' way to do it when I moved to Doom from Spacemacs. Either way I got the impression it felt quite close to the way to manipulate 'native' emacs (but with a lot of sensible defaults that I couldn't be bothered to figure out myself).

I went with the ‘take vanilla and adjust’ route to learn proper Emacs config-ing. Turns out, you pretty much need to implement a bunch of features on top of the 90s Emacs to get a reasonable modern editor, and there isn't a system for config snippets that are smaller than a minor mode (aside from copy-pasting from StackOverflow). I've been meaning to try Doom for some time because it seems to be an answer to just that problem.

Projects like Doom Emacs and Spacemacs are frameworks. They contain lots of well-made, battle-tested code. They are extensible, too: they usually provide clear points for user extensions and customizations.

I think what you're missing is that Emacs might be a good fit for things other than "the main idea of Emacs" (whatever that is)

But can Doom Emacs run Doom?

Here you go sir https://www.reddit.com/r/emacs/comments/f2c99b/you_can_play_...

To my mind there are two camps of language support in Emacs:

1. Languages where people put a lot of effort into implementing bespoke support inside Emacs itself (as Elisp packages)

2. Languages where no one bothered to make Emacs-specific features, but are now supported quite well via LSP

Python seems to be in the #1 camp, and that seems to be what you describe.

The #2 camp, however, is superior in my experience, so I would suggest trying that instead.

I haven't worked that much with Python for a while, but at one point I used lsp-mode and pyls and it seemed pretty good: https://emacs-lsp.github.io/lsp-mode/page/lsp-pyls/

You can also choose Microsoft's Python LSP server instead: https://emacs-lsp.github.io/lsp-python-ms/

Category 1 can be further subdivided into

1.1. Languages where people have written full parsers and analysers in Emacs Lisp.

1.2. Languages where the Emacs support relies on external programs to provide intelligence.

Only very few languages (e.g. JavaScript) fall in subcategory 1.1.

Unfortunately, js2-mode's parser isn't updated to keep pace with modern language development. I've had much better results over the last year with an LSP integration, and rarely if ever go back to js2-mode these days.

Similarly, while js2-mode's built-in formatter is quite good, Prettier is both more (and more easily) configurable and more shareable - it can enforce an agreed-upon style at the codebase level without any editor-specific tooling or configuration, and the consequent absence of bikeshedding is welcome.

Yeah LSP is taking over. I don't think category 1.1 is going to last.

Surprisingly, I never got to a good C++ setup in emacs.

Something about how we used CMakeLists and had our project set out made it difficult to get autocomplete/gtags and everything to work the way I wanted.

I know it's possible, but could never get everything to play nicely together.

On the other hand, every other language I've had a brilliant experience with in emacs (using spacemacs).

I’d try eglot with pyls for python. (The pyls server is using Jedi).

I've had generally good experiences with spacemacs. JackOfSome on YouTube has good tutorials including one on using it for Python.

This gets me basically everything that I need:

- lsp-mode (IDE smartness) - company (completion pop up) - selectrum/ivy/helm (command awesomeness) - projectile (project management) - magit (greatest Git interface you will ever use)

> greatest Git interface you will ever use

I believe the amount of people disliking magit fits on one digit

Could you share your selectrum/ivy/helm config or give me some tips? That's one part of Emacs config, in particular, that gives me the willies -- I can't figure out if I'm supposed to choose between ivy and helm or use them together or even really what the differences are between the two. I haven't even heard of selectrum, lol.

That's one of the hardest parts of trying to config Emacs in general -- so many packages and they all seem to do the same thing and I think I need just one but sometimes people have like, all of them installed. It's confusing!

You can find my config here:

https://github.com/ashton314/.dotfiles

I use selectrum for just about everything. The only reason I keep ivy and counsel around as for the packages counsel-rg (ripgrip with real time results) and swiper.

It is a very good question you ask. I have spent many months experimenting with these various packages. I actually wrote a blog post about switching from Helm to Ivy. I suppose I should write a follow up on about switching to Selrctrum.

If you would like to talk more one on one, please DM me via one of the channels listed on my blog:

https://ashton.wiersdorf.org/about/#contact

I’ll parrot “Spacemacs” along with a few other here, but here are my two main reasons why:

- Spacebar “leader” key. If you’re familiar with Vim, space is your leader key, and many functions lie behind it.

- Layers. Spacemacs has a packaging system called “layers” that are a collection of curated Emacs packages. The great thing about layers is all the wiring the layer author has done. Many packages are condensed down to a one-line config. Just add “python” to the array of installed layers in your config file and it will install a lot of what you have above. There are a few config toggles (e.g., override the language server that is used by default), but they are pretty well documented in the Spacemacs docs.

Also, use the Spacemacs develop branch! I’ve been on it for years. Master has not had many (any?) updates in a long time. If you do this make sure you are reading the docs for the develop branch when perusing layers online!

I use Spacemacs develop branch. I agree it's great, but it breaks things often. Once the next release is finally out (0.300 ?) I'll probably switch to master to have a more stable setup.

Oh and if you are a security conscious user, you might not like the fact that Spacemacs downloads tons of code which might or might not have been reviewed by someone you can trust and might or might not have been signed...

Out of interest, what have you had broken?

I've been on develop for ages, and don't really remember many breakages, I do however only pull sporadically.

I cannot really say, very often even at launch something fails and initialization is not done properly, so for example projectile (which I use to switch projects) doesn't work. When it happens I simply revert to the previous commit that worked for me and wait a bit before pulling again

I wouldn't recommend Spacemacs. I use it, it's horrible. Fragile and very bloated, and the primary maintainer doesn't really work on it any more (it hasn't seen a release in something like 3 years).

Doom Emacs is a way better choice now IMO.

Spacemacs has been in rolling-release mode for something like 3 years. Almost everyone using it just tracks the develop branch where features and fixes are merged daily.

Every time you start the develop branch it displays a huge message saying "Version 0.300 is almost out!" (with a description of how stable releases on master branch are the current objective) and it's been displaying that message for 3 years. There is a rolling branch, but the release branch isn't rolling. Spacemacs is usable but the project is calcifying, I wouldn't recommend anyone hitch their cart to it.

Like, I'm jumping ship as I write this. My job for the next few days is converting my config to Doom.

This is exactly the problem with these huge pre-configured "distros" like Spacemacs and Doom. It looks like you spend a lot of time fighting the opinionated setup of the distro. You might as well spend that time starting from vanilla Emacs and craft your own config.

FWIW while it feels like I'm constantly fighting Spacemacs, it hasn't felt that way with Doom so far. Spacemacs introduces a lot of unnecessary abstractions that are very difficult to perform surgery on whereas Doom seems closer to "sane defaults, but you can modify them easily".

I recently switched from Spacemacs (develop branch) to Doom Emacs ... Spacemacs was just too slow (but very nice, better than Doom in some ways especially the layers in Spacemacs).

I might go back and see if I can get the native-code version of Emacs running with Spacemacs, it might speed it up.

Python can never have a legit IDE because of the dynamic typing and OO, but LSP/company-mode/projectile/magit should get you on par with anything else, I'd imagine.

You want to avoid fiddling, editing config files and chasing dependencies?

Drop emacs and look elsewhere.

Emacs felt like it was stagnating around 5 to 10 years ago, but now things are just getting better and better. LSP had been a game changer, for Emacs and all other editors. The days of IDEs are numbered.

>The days of IDEs are numbered.

How? if you turn your text editor into an IDE with plugins then you make Emacs an IDE. In my mind an IDE "understands" the entire project not just the opened file.

I guess an IDE has an unclear definition, but I mean stuff like Intellij, Visual Studio, or Eclipse. With LSP along with an explosion of new languages, they don't provide as much value anymore.

A high quality language server can provide 99% of what a high quality IDE can (like Intellij). IDEs still have an edge, like with debugging, profiling, or SQL db integration. I've mostly ditched Intellij in favor of Emacs for a large Scala project, something I wouldn't have ever dreamed of doing 5 years ago.

I still use Intellij for debugging, but hopefully debugging servers and some Elisp will solve that problem soon.

That is like 10% of IDE capabilities.

Can you please list the other 90% of must have capabilities for day to day development ?

- GUI designer for each UI framework available

- Visual representation of data structures

- Navigating in binary libraries

- Architecture diagrams with two way editing

- Integration with ticket and source control systems, so that I can relate an issue with a branch and respective set of changed lines of code

- Live unit tests

- Live static analysis, as one types

- Incremental compilation, when hitting run almost everything is pre-compiled

- SQL database integration, ER diagrams, OR mappings generation

- Management of server instances and cloud services

- Memory profilers

- GC tuning tools

- Code metrics

- Graphical debuggers for GPGPU programming

- Graphical debuggers for threads, tasks and processes

- Handling of processes as single project for micro-services debugging

And a couple of other stuff, basically the kind of goodies one gets with Visual Studio Enterprise.

- full remote development suite with source synced onto remote server while IDE utilizes remote libraries and and remote compiler tool chain for code analysis.

- learning curve thats significantly smaller despite larger feature set.

These are your "must haves"?

>Can you please list the other 90% of must have capabilities for day to day development ?

- find definition

- find usages

- rename

- extract method

- detect code duplication

- highlight unused symbols(vars or functions)

- understand frameworks and libraries

- can suggest useful transformation or code simplification

- Intellij can understand type documentation like JSDoc and PHPDoc and use it in completion and highlight errors if using the wrong type or object member

- smart spellchecking, spellchecking that understand when it is in a comment or if it is a symbol name

- good VCS support(diff, commit, push)

- good debugging support

- IDEs have by default a lot of linting and code analyzing tools setup, trying to go from Intellij to VS Code defaults is a big downgrade , maybe it could be partially fixed by installing many plugins but I personally want to pay for a good program made by professionals and keep them profitable(and not have JetBrains fail or get bought by Google or Microsoft)

> - find definition

> - find usages

> - rename

Emacs has these covered, especially when using LSP modes

> - extract method

I don't know what this is, sorry

> - detect code duplication

> - highlight unused symbols(vars or functions)

This is what linters and static analysis tools are for, and emacs integrates with them nicely via flycheck.

> - understand frameworks and libraries

not sure what this implies, sorry

> - can suggest useful transformation or code simplification

> - Intellij can understand type documentation like JSDoc and PHPDoc and use it in completion and highlight errors if using the wrong type or object member

More static analysis tooling, doesn't need to be built-in to the IDE, just hooked in with something like flycheck.

> - smart spellchecking, spellchecking that understand when it is in a comment or if it is a symbol name

emacs can kinda do this via flyspell but it's not perfect. You're right, this is a good idea.

> - good VCS support(diff, commit, push)

magit!

> - good debugging support

I'm mostly clueless here, sorry.

> - IDEs have by default a lot of linting and code analyzing tools setup, trying to go from Intellij to VS Code defaults is a big downgrade , maybe it could be partially fixed by installing many plugins but I personally want to pay for a good program made by professionals and keep them profitable(and not have JetBrains fail or get bought by Google or Microsoft)

aye, there's the rub. I suppose the "I" in IDE is the real value: the package deal with all the linters and analysis tools already hooked in. Various LSP modes have made it vastly easier to reach feature parity with this stuff in emacs with minimal effort, but I also definitely understand why things like Intellij are desirable and useful.

>> - understand frameworks and libraries

>not sure what this implies, sorry

A couple of things off the top of my head:

— list all HTTP endpoints in a Spring (or whatever) application, with their arguments, input and output format, possible error codes, etc.

— DSL completion, as in this example (pay close attention, it's not SQL): https://www.jetbrains.com/idea/features/screenshots/16/why_i...

— an ability to quickly jump from an ORM model to its corresponding database table

Stuff like that.

Is Emacs multithreaded?

No, it's completely single threaded. There's basically a GIL stopping it from ever being multithreaded without a serious rewrite/redesign. For long-running blocking tasks you have to use external processes (or the new dynamic module API to write an extension in C with pthreads).

Then what's the section on "Threads" about in https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.2... ?

Threads

* New variable 'main-thread' holds Emacs's main thread. This is handy in Lisp programs that run on a non-main thread and want to signal the main thread, e.g., when they encounter an error.

* 'thread-join' now returns the result of the finished thread.

* 'thread-signal' does not propagate errors to the main thread. Instead, error messages are just printed in the main thread.

* 'thread-alive-p' is now obsolete, use 'thread-live-p' instead.

* New command 'list-threads' shows Lisp threads. See the current list of live threads in a tabulated-list buffer which automatically updates. In the buffer, you can use 's q' or 's e' to signal a thread with quit or error respectively, or get a snapshot backtrace with 'b'.

These are cooperative threads, not kernel threads which can actually run at the same time. It uses threads for its abstraction as a concurrent task. Ruby and Python also have "Thread" classes which don't make system calls and are just useful as a programming pattern. Maybe one day Emacs (and Python and Ruby) will have real threads, so the idea might be to switch the implementation over to real threads without requiring any client code to be rewritten since it follows the same API as real threads.

So imagine you are using something like React/Angular or other templates you want your IDE to understand this templates and not highlight the syntax as errors, if you use a function/object defined in a js file in a template you want the IDE to make the connection. So when you want to see where a symbold defined in a .js file is sued you want to be found int the template file. You could have 2 different components that both have a thing called name - you want the IDE to not confuse this and consider this 2 different things as the same but be correct.

When I mean an IDE understand a library an example is jQuery, an IDE can have a plugin or just analyze the libraries you use (like analyze a .dll/.jar) and help you, my point is that the IDE is not limited to only the text files in your src folder, it can analyze your lib/vendors/node_moduloes folders too.

>More static analysis tooling, doesn't need to be built-in to the IDE, just hooked in with something like flycheck.

The IDE seems to work very fast as you type with incomplete code that would just fail if you run it through an external tool, not sure if this language servers stay up in background and keep state or each time you need to ask them to re-analyze everything and how fast and well works with incomplete code as you type.

About debugging support, for most stuff you just put breakpoints and press a Debug button, the code will stop and you get a nice overview like you get this days in browsers , including an eval repl in the current context where the program is paused. Super cool to understand soem complex library or framework you run it line by line and see how the framework inits, where it reads it's config , how it setups things , and all those steps that happen before your own code runs.

Extract method. maybe you work on some code that is not that clean, like some super long function and you can sport that this 12 lines of code can be made a function with some inputs and an output, you highlight the lines and use the Extract method, it will create a function from those lines and use it at the current place.

Or you have stuff like a missing parameter in the JSDoc the IDE offers to fix it , or you want to add JSDoc the IDE will create it for you, fill the types if it can detect them.

Most of this stuff are plugins , and you can turn things on and off, exclude folders, add your own rules etc - it is not a giant monolith that is not configurable.

> So imagine you are using something like React/Angular or other templates you want your IDE to understand this templates and not highlight the syntax as errors, if you use a function/object defined in a js file in a template you want the IDE to make the connection. So when you want to see where a symbold defined in a .js file is sued you want to be found int the template file. You could have 2 different components that both have a thing called name - you want the IDE to not confuse this and consider this 2 different things as the same but be correct.

Why imagine? I have emacs open and it's doing this with React right now (tide mode).

>Why imagine? I have emacs open and it's doing this with React right now (tide mode)

Cool, so Emacs understand that there are 2 different components and not get confused by react/angular sepecial syntax ? At this point is Emacs still a text editor as the initial comment that start this thread said or it become an IDE buy extending it with enough plugins? (see how this comment thread started)

Yes, jump-to-definition will work correctly in both components.

I've been calling emacs an IDE for a long time. https://news.ycombinator.com/item?id=72895

>> -extract method

> I don't know what this is, sorry

You mark/select/highlight some lines of code and then you hit a key, and this creates a method out of the code. The IDE is smart enough to see what is the "input" and what is the "output" of these lines of code, and will create a method with the right parameters and with the right return value. But usually, the IDE doesn't support all such code blocks, for example, if there is more than one "output".

>> - extract method

>I don't know what this is, sorry

In emacs, try M-x tide-refactor. It's the "extract to function in module scope" option.

For debugging, dap-mode is the lsp-mode equivalent. The not a big debugger guy but I've heard great things around the Emacs community about it.

I don't know. I'm a very heavy Emacs Doom user, but I still load up projects in Intelli-J/Rider. I find Emacs combined with ripgrep/silver searcher a nice way to search across all my projects, and treat my local code bases as a monolith. Once I find what I need, if I'm not just reading the code, I typically open of the project in a native IDE.

I'll only use Emacs for making small configuration changes, or when working with small POC type of stuff, or writing small CLI projects. I do use it extensively for magit and org-mode, org-journal, and my REST API interface via org-verb (instead of Postman/curl/httpie) though.

My emacs instance is currently editing projects in Elixir, Ruby, Python and Node. None of them remotely resembles what it would be in a Java like IDE. There is no need to "understand" a project in those languages, edit save and reload has been enough for me and my customers since 2006. For Java, I used Eclipse and Netbeans. I consider the need of an IDE as a bad smell in the design of a language.

And I consider programming languages not designed with IDE tooling in mind a design smell for the said programming language.

Any language that can be compiled is by design suited for IDE tooling. Think about it, if a compiler can analyze the code then so can an IDE.

An example of a language that can't be analyzed by IDE tooling is the English language. Case in point the English language can't be compiled either.

The parent poster is basically saying that there are languages that are so complex that to even program in these languages you (usually) need IDE tooling to assist you. C++ and Java are good examples of this.

IDEs do a good job with dynamic languages too, if you document your types and function definitions it will provide you same features as a static language. You need to avoid abusing eval or similar constructs like p[kind+"_name"].

Also worth pointing out that even static languages often have escape hatches into metaprogramming that defeat tooling.

I've seen Java codebases use reflection heavily enough to utterly confuse the IDE.

Yes, just to add the information in case someone is wondering, for example PHP has "magic" functions , I do not use this feature but is used by ORM libraries to make it easy to access table columns. But using PHPDoc I can specify the existence of this columns and then all the warnings are gone and I can get auto-completion help(this helps a lot to improve coding speed and can catch errors if you put a type in a table column name.

This will not work for stuff that is random object from a JSON but so far I never worked with random data.

Naturally it can, but it will always be an half baked experience, which is why languages like Python and Ruby are still miles away to replicate Common Lisp and Smalltalk development experience.

I rather prefer C++ and Java than any of those "I don't need IDE" languages.

I have been using IDE based languages since I became a Borland customer around 1991, and while XEmacs allowed me to survive without IDEs to the point that I still remember most of my way around ELisp, I don't miss those days.

If you were designing a programming language with IDE tooling in mind, what are the things that Common Lisp and Smalltalk do to better assist IDEs than Python/Ruby?

Anders explains it better than me,

"Anders Hejlsberg on Modern Compiler Construction"

https://www.youtube.com/watch?v=wSdV1M7n4gQ

Basically ability to see the language AST at all time, do time checking with broken code, incremental compilation, REPL and IDE editing experience is fused together.

Here is another short examples,

"7 minutes of Pharo Smalltalk for Rubyists"

https://www.youtube.com/watch?v=HOuZyOKa91o

"MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk"

https://www.youtube.com/watch?v=eGaKZBr0ga4

I think you are used to your way of doing things and your opinion is limited by your perspective. I would suggest you be open to new things, try a trial version of an Intellij IDE(with an open mind)

It makes logical sense that a program that can understand the entire project provide you more help then a more limited program. For example you refactor some code and make a typo in a function name, now because you changed the function name this function is no longer used from other code(because that code uses an old name), because is not used anymore it is highlighted in the IDE as unused and you just caught a typo error (I am expecting now that TDD would have caught this, or a typo in a var name but not everybody is testing everything and the problem is caught in the IDE without any effort from you)

I mean, that's a pretty basic feature that Emacs supports with flycheck+LSP.

I can't judge that, i tried VS Code for web dev and with it's defaults it is a big downgrade , for me it seems that LSP is not enough, you need to have something that parses the entire project libraries from vendors/mode_modules, your own JS/PHP , the html/template files and after all is parsed create a big dictionary with all symbols and what we know about them.

Can your plugin go that?

I'm not sure how language servers handle multi-language support (JS and PHP), if at all, but language servers usually do parse all the project's dependencies as well as project code and give you jump to definition, autocompletion, and popup documentation on all of it.

Wishful thinking, that only proves a complete misunderstanding what an IDE is for.

> Emacs felt like it was stagnating around 5 to 10 years ago, but now things are just getting better and better. LSP had been a game changer, for Emacs and all other editors. The days of IDEs are numbered.

Agreed with the first. Disagreed with the second.

LSP only ensures that the interests of independent Editors and bigger IDEs to a bigger degree aligns than they used to be before.

It's not a war. This should represent a win-win for everyone.

LSP in Emacs or in any editor, is only as good as the language server - in some (many?) cases the language server is effectively a headless IDE.

It's still stagnating. Emacs has something like 2% of market share. LSP doesn't add many new features. We had jump to definition etc. for decades with TAGS which was much many orders of magnitude faster than LSP. LSP just serves to foster IDE envy and make users switch to a real IDE (and honestly why wouldn't you, if you acknowledge that even a smidgen of IDE features makes you more productive). Emacs will never ever have as the same features or same types of users as IDEs--pursuing that is a losing battle. Emacs should focus on becoming as fast as vim. That's its real competition, not IDEs.

Emacs was never intended as "just a text editor" and it shouldn't strive to be one. It was the first IDE and it is infinitely better than almost any other IDE in terms of customizability. It's main drawback was a lack of very good support for non-LISP languages - TAGS are incredibly simplistic and only let you do basic code navigation. LSP solves that by leveraging the huge amounts of development effort put into VSCode's language support. This makes Emacs, which has a superior editing mode (with evil-mode), and superior customization options, one of the best IDEs available. The only other IDE I use now is Jetbrains for JVM support (because there is no good language server, unfortunately), but I don't enjoy it - you can barely customize it and the text editor sucks compared to what I can do in Emacs.

My perspective, as a mostly C++ programmer, is completely different from yours. LSP is great when it works, which unfortunately in my experience is seldom, and it is absolutely key to retaining advanced users. If someone like me, who knows emacs lisp, hates Microsoft and has used emacs for 25 years, is tempted to switch over to VSCode because of its superior C++ IDE tools then surely new programmers will not give Emacs a second look.

Is this not the exact phenomenon I was talking about? You have been able to write C++ for 25 years without Microsoft, but now you've gotten IDE envy and want to switch. Of course LSP will always work best on VS Code, which is the platform it was designed for.

I re-read your comment and yes, I think I ended up confirming your point. However, I do not agree with the conclusion that its not possible or desirable to compete with an IDE, not at all. A functioning LSP, which is completely achievable, will cure mine and probably many other's IDE envy, and that is why I think its a crucial project.

Emacs is just fetching up to others and reducing demand for manpower with LSP. It is not inovating itself, nor moving toward a better future. The core-architecture remains the same, the old problems remain the same. Manpower is hardly growing and marketshare seems to be stable or even shrinking. Competition on the other side is outpacing Emacs by leaps and bounds.

> The days of IDEs are numbered.

Nope, IDEs will never die, they just change again. Editors are becoming IDEs now, merging both to become more than before.

> The core-architecture remains the same

https://akrl.sdf.org/gccemacs.html as posted already in this thread, compiling more of emacs with gcc, very interesting change to the core architecture.

> the old problems remain the same.

from the linked article - Lexical-binding is used by default - Portable dumping used instead of unexec

What exactly are you talking about?

This are not changes to the core-architecture, just speedups for bottle-necks. This pushes a bit the boundary until you hit problems, but does not solve the problems at all.

My primary development environment is Emacs for around 7-8 years now I think (used to be pretty proficient Vim user before). I mainly program in C++ and Python, but often hack on Java, Go, Rust and Haskell. I have heavily configured my Emacs, and window/buffer/workspace/panels/keybindings (you name it) work exactly the way I want -- and its muscle memory -- to the extend that I feel paralyzed in anything else -- even if it has much reliable code browser/completion or feature X/Y.

So here's my two cents:

Even though Emacs is not mainstream, I somewhat agree that the ecosystem is much better now and I can get to configure it as IDE. Sometimes things break, sometimes it takes frustrating amount of time to configure/fix things -- which is probably 1 click away in VSCode. And regardless anything, despite LSP, nothing just works out of box or is immediately obvious. And for these reason alone I think the mainstream IDEs are here to stay.

That said, I don't care (or think doesn't matter) if Emacs remains mainstream or not, as long as the ecosystem remains healthy and strong, and it gets the work done. It will keep it afloat like past whatever 30-40 years. However, that doesn't mean it can survive without being competitive. For me, the single BIGGEST ISSUE that made me consider trying VSCode is performance. On two companies I've worked with, the C++ parser performance with LSP running is just purely BAD (more so on MacOS I think). And quite honestly I can see myself getting frustrated enough someday and move.

Seems like native JSON parsing should help with LSP performance!

> LSP had been a game changer, for Emacs and all other editors

Not for me. I've tried to use LSP for Chromium's code base(~40k files) and it was miserable. It took 8-10 hours to index it and each time the LSP server started it used 10GB of RAM to work.

Comparing it QtCreator's Code Model (the old one which everyone hates, not clang based) takes 2 Min to start from zero without blocking the GUI.

What language server did you use? These days both ccls and clangd should be able to handle Chromium.

ccls, they can handle Chromium, but after 8-10 hours of indexing and then it uses 10GB of RAM when you launch the editor.

I've used language servers in large, old codebases that took a while to parse, and they never blocked the GUI for me.

I only got intelligence on as much of the project as it had finished parsing at a given point in time, obviously, but I wasn't stuck waiting for it to finish before I could work. This was using php-language-server and lsp-mode for Emacs.

Did anyone manage to make a good Emacs config for effective React webdev?

I'm really missing graphql and styled components syntax highlighting and generally a bugless properly working webdev mode. Currently it keeps messing up indentation and losing syntax highlighting.

I tried moving to VS code, and I saw how amazing an editor designed for webdev can be. But despite all the issues, I'm still much more productive in emacs, so I went back.

I really wish it was possible to setup emacs for modern webdev, but I haven't found a way yet.

Any tips/advice?

I haven’t done any web development, so my best recommendation is to forward you to search relevant keywords and then ask questions on r/emacs or r/spacemacs

Won't get you graphql literals, but the new Emacs has much better JSX support. Reposting my setup:

""" Disclosure: I'm the author of rjsx-mode)

The best setup I've found is to use js2-mode for .js and rjsx-mode for .jsx, which parse the buffer for syntax highlighting, local refactoring (with js2r) and basic linting. For typescript, use typescript-mode. Flow support is quite bad ATM

nvm.el replaces the shell scripts from nvm.

Add a jsconfig.json to your project root and enable tide-mode for completion. This has worked far better than tern-mode, which some people recommend.

For fuller linting than what js2/rjsx offer, use flycheck. Eslint support is built-in, so it should just work, I think.

[2018 update: I prefer using tslint, which you can accomplish with:

(flycheck-add-mode 'typescript-tslint 'js2-mode)

(flycheck-add-mode 'typescript-tslint 'rjsx-mode)]

Finally, for build management, I use prodigy to run webpack, babel, ts, etc.

Using prettier-js-mode I don't worry about messed up indentation; any problems are fixed on save.

I've been using web-mode and it's awesome. Works well with jsx. My config is here https://github.com/sufyanadam/.emacs.d

I use web-mode, tide, react-snippets combined with yasnippets, and prettier. You can see my config [here](https://github.com/jidicula/dotfiles/blob/master/init.el#L61...) (or search for "react-snippets" if that line number is outdated).

I love the change to adopt XDG standards. It surprised me that this wasn't implemented sooner when I first found out about it.

IIRC 26 adopted ~/.config. Proper XDG support was coded in last year[1] but has been waiting for the next major release.

[1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=41182...

Lots of people mentioning LSP. I've been an emacs user for over 10 years now. I've installed and tried the LSP modes. I've done it with 27 and jsonc as well. They are slow as hell and buggy. Is this just the accepted way of things now? I like emacs because it's fast. I can't stand using tools that are slower than the speed I can think.

I can't speak to bugginess in general, but they're not supposed to be slow. I've used emacs with lsp modes for Haskell, Elm, Bash, and Python and they've all seemed very quick and responsive to me; if your setup is sluggish there is probably something amiss that can be fixed!

Yes you're not alone, it slows Emacs to an absolute crawl. I was excited about LSP a couple years ago when it came out, but it turns out that it's another one of those things that's better in theory than in practice. There's nothing worse than having your editor freeze up while you're typing. I've had bad experiences with clangd especially where it consumes all available memory when faced with large codebases. It's not just slow on Emacs, it's slow on the other editors that use LSP like VS Code. If I were conspiracy minded, I would think this was an elaborate a conspiracy by Microsoft to kill off programming on Linux and get everyone on Visual Studio and WSL.

You needed to upgrade a bunch of variables to account for the absurd amount of json LSP modes spit out, and use the C-based json parser that's available in 27 (I've been running from the source branch for a few months now) and I personally find lsp-mode super, super good.

It's like 100x better than TAGS files (because I don't have to generate them) and has made my navigation of a new codebase much, much more smooth and effective.

When I tried LSP for C++, speed wasn't the issue, though you do have to jump through some hoops to make sure emacs uses native JSON parsing. The problem was just stability as LSP for C++ was stupid buggy as recently as a couple of months ago.

There are multiple LSP clients though, there's lsp-mode [1] and eglot [2].

After trying out both, I prefer Eglot, mainly because I find it faster and less intrusive than lsp-mode. It also composes better with built-in packages, such as flymake . I use gopls and pyls as language servers.

1. https://github.com/emacs-lsp/lsp-mode

2. https://github.com/joaotavora/eglot

Another emacs thread with no mention[1] of straight.el. How do people sanely manage their emacs configurations without it? Is there a way to pin dependency versions that you get from MELPA or ELPA? Otherwise one risks one's setup completely breaking with a new dependency release and having no way of getting back to the old configuration!

[1] OK, one brief mention

I have some code to run an update then commit every package individually.

That way I can always get back to any previous state and I can use git bisect to find the culprit when a package update causes a regression of some kind.

Simple: You use ELPA or MELPA Stable, and if necessary clone the repo and install the package via M-x package-install-file.

Hmm, but as I understand it neither ELPA nor MELPA can be rolled back.

https://emacs.stackexchange.com/questions/28731/easiest-way-...

It seems to be the end of the infamous `unexec` function. I hope its story will not be forgotten, it's a very amusing hack :).

Emacs has been my power weapon for 30 years now and it has never left me wanting for anything else. Thanks for another great release! The last several years I have been using the “Prelude” distribution of packages and it has been great, it does just enough and doesn’t overreach. Go EMACS!!!!

Thank you for updating my favorite editor of all time ;-)

Is there a way to find out if/when this version will be available for Windows?

Awesome! Great list of updates. But what is early init?

early-init.el is loaded before the package system is initialized (which also lets you disable the package system before it can possibly be loaded -- useful for people like me who use straight.el instead), while the normal init.el happens after package-initialize.

I’ve been running on bleeding edge releases for about a month now. It’s been a bit rocky at times but I’ve overall been surprised at how stable master has been. I’m delighted to see 27 is out now. If I get fed up with 28 maybe I’ll downgrade to the new stable. :-P

The best thing with this release (as far as I am aware) is the JSON parser implemented in C. This should make lsp-more a lot snappier.

I normally do this in the lead-up to a new release, but downgrade aftwerwards.

Often, there'll be big changes on the master branch after a release, so it tends to be a little less stable (and I normally just need Emacs to work, so not interested).

> Lexical-binding is used by default

Finally, about time!

I wonder whether there's any discussion around addressing the elephant in the room: big config files.

Is there any work towards making Emacs be usable immediately, while config being loaded asynchronously in background, adding features like syntax highlighting without blocking the main editing experience?

use-package already has a way to defer configuration until it’s needed.

Yes, I'm certainly using that, but it's far from being enough to make emacs-with-config a usable replacement for the in-terminal editor.

It’s probably not what you want to hear, but I just use emacsclient for that. I agree that the startup time is annoying, though.

Yes, I just use "emacs -nw -q" (aliased as eq) when in terminals, and it's surprisingly good most of the time. But having good startup time always would make a huge difference imho, including Emacs's popularity.

Parent is talking about using "emacsclient". Basically you start Emacs in daemon mode (e.g. add "(server-start)" at end of config), and you never kill it. You just pay slow startup cost once, any subsequent client invocation after that is instantaneous.

I understand. I use it for my git commit editing in my “master” emacs. It’s just not usable when you want multiple instances in different tmux windows

I have this little handy shell function for that:

    semacs () {
        emacs --eval "(setq server-name \"$1\")" --daemon
    }

`semacs foo` then starts an emacs server named foo and and `emacsclient -s foo -c` attaches to it.

I've used use-package to get my startup time from 10-20 seconds to <500 ms. (But to be fair I did trim a lot of useless cruft.)

I don't use Emacs but is loading perf still a concern in this age of SSD ubiquity ?

Would be nice to know some stats, of course. I suspect that for most people it’s pretty bad and disk isn’t the limiting factor.

Not really. The dominent solution nowadays is to use starterpacks/distributions of emacs-configurations. Spacemacs and doom-emacs are pretty popular. Emacs-Project itself is rather conservative in that regard. Vanilla-Emacs is still ugly has hell and not much different from decades ago.

There are voices who demand to lean more toward VS Code in that aspect, so maybe in another 10+ years emacs will finally innovate itself there.

Main use-case here is to open emacs in terminal (emacs -nw) for a quick edit. Emacs in terminal doesn't look ugly at all (because of lack of GUI), and is quite usable without config actually (that's how I'm using it for quick edits, "emacs -nw -q"), but modes and configurations would be definitely helpful to have without sacrificing time-to-edit.

emacs --daemon/emacsclient solves that for me. Emacs doom, which is sort of custom distribution of emacs, also solves this problem in another way by carefully optimizing startup times. Either way, its a solved problem.

This elephant was addressed long ago by Jon Wiegly's use-package.

I’d bet my money that most people (esp those using spacemacs) have multi-second time-till-edit still.

Prelude Emacs is a great ‘distribution’ and this is great to have another amazing emacs release.

Check out sane-emacs for a sane yet simple starting config.

Reply on news.ycombinator.com