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

> maintenance of the .emacs files

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

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

I changed from .emacs to .emacs.d/init.el when it became possible, because that seems neater. Some years later I decided to see what fancy packages the young folks like, and started using vertico, orderless, marginalia, embark, and consult. I'm still going to reserve judgment on embark and consult, but at least the first three packages are certainly great additions.

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

My point is: the api of of emacs is fairly stable. And your point is?

I have ~80 lines outside the customize variable block added by emacs. Nothing too fancy but there are a few hot keys and functions that I can't live without.

What modern feature is Emacs missing?

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

Doom Emacs loads very fast so theoretically it's possible to configure Emacs to be fast too (mine starts in a second, cold start is a little slower).

But I think most people don't care about it enough because they either never close Emacs and/or use it in server-mode where emacsclient is pretty much instantaneous. Can I ask why you don't like doing that?

Because I conserve energy: I turn my PC off at the end of each session (so about one/two times a day). And because the "sleep" mode is not reliable (I have a 14 years old PC, upgraded in RAM and GPU and SDD; and here I conserve hardware).

So having things take time on start up is an annoyance to me (but I live with it, I was just saying that emacs is slower than VSCode)

So your point is that emacs is slow on slow hardware?

I’m sure vscode would chew through resources during a heavy session, have you benchmarked more than just the startup of the application?

my overall feeling on my own (slow) PC is that VSCode is faster on load (or, to be exact, I perceive it be to be faster) and provides a few features that I don't have on emacs.

You're right: once VSCode is in memory I think it uses more of it. But that's barely nothing when compared to rust-analyzer (which emacs LSP uses too).

I use Doom Emacs with the Yamamoto port of Emacs [1] on MacOS (M1) and the startup time is quite slow: it takes around 6-7 sec. for the editor window to show up. It doesn’t bother me too much since I usually start it once a day and just never close it, as you mentioned.

However, I also have many plugins installed, so it might be just that. I wonder if it is possible to install a separate instance of Emacs, then I would be able to test the performance without all the plugins and configuration.

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

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

who ever does such a thing? Emacs starts up on my machine soon after I login. It remains open until I logout. Current instance has 123 buffers (files). Loading speed just isn't important to me as a full-time native (C++) developer.

> - robust LSP

I tried LSP a bit. Gave up because it just didn't really help me with my actual work. Could understand why someone with less experience programming would find it helpful, but it just wasn't so for me (I use emacs dynamic completion a lot)

Emacs on my system is ~8sec load time, vs ~5sec load time for Code. I have not optimized either (but I have decided on using Straight as package manager on Emacs, which is arguably faster than the built-in).

I use LSP a lot (through eglot with Emacs-29). For each "mode" in Emacs there are alternatives to LSP, mostly what was there before LSP, which may be equally good. However, I found that switching to LSP simplified my setup, and having the same functionality/keybindings between modes is great, e.g. my projects switch me between Python, Rust, and Java, earlier that was basically three different "IDEs", while today they're very similar.

Run emacs as a server when you start the machine and use emacsclient to connect with it. Way faster start times.

> Emacs on my system is ~8sec load time, vs ~5sec load time for Code

yeah, but i don't give a damn. I do this once every few weeks.

ps. also, emacs is < 3 secs on my system, so even if i did care ...

What is "dynamic completion" ?

I have it bound to Ctrl-\ ... Emacs scans backwards through the current buffer, then all other buffers, to look for completions for the word at the cursor. Press it again (after one completion) and it will cycle through other possible completions (and keep doing this as long as you keep pressing that).

It's great for completing variable names, but also if you writing just regular text, finishing longer words and so on.

That sounds like

    M-x dabbrev-expand

which is bound to M-/ by default (and yeah, I love it). Though I do like the context sensitive completions that lsp provides as well. They are particularly good for showing you structure members (since the language server knows the types).

> Could understand why someone with less experience programming would find [LSP] helpful

Have you considered the possibility that people with more experience programming than you might find it useful?

Yes.

Then that covers everyone.

Parent does have quite a bit of experience:

https://en.wikipedia.org/wiki/Paul_Davis_(programmer)

I'm so used to empty boasts and humblebrags from tyros on HN that I overlooked the real McCoy. That's on me.

I hope to one day be cool enough to write my own Wikipedia entry

So renaming all the symbols in your whole project with just one command is not for you ? Navigating to declaration/searching all the usages of a symbol etc. All that isn't for you ? And these are the two most basic features You make it sound like LSP is a small gimmick that appeals to less experienced developer while it's actually a huge productivity boost that has literally no link to being experienced or not.

I also think that parent's comment is overly dismissive of LSP. But for me, Emacs with lsp-mode does the things that you describe.

I mean, I wanted to love LSP. Everything I read about it suggested that I would. But I tried it out for two weeks, working (as normal) on my 600k LOC C++ project, and found it somewhere between irritating and not-actually-helpful.

I appreciate that people who started programming with such tools probably come to rely on it the way I rely on dynamic completion in emacs (which is a lot).

Considering C++ is almost impossible to write reliably good tools for it's entirely possible that LS for C++ is simply not very good and that with languages that can reliably provide a good LS experience you'd view this differently. I don't think it has anything to do with programming experience level. I've programmed for 24 years and I find language servers great when I can have them. 20 or so years on top of this is unlikely to change anything.

For what it's worth I'd use CLion for C++, most likely, if I ever wanted to go back to C++ outside of tiny sandbox projects.

P.S. Language servers are great for smaller ecosystems where no one can really afford to make or fund much beefier tools like IDEs, so a language server can be created by a community member and be used with pretty much all relevant editors almost instantly, meaning the ROI for the community is massive.

Emacs has code peek.

With lsp-mode it has that little window: https://emacs-lsp.github.io/lsp-ui/#lsp-ui-peek

Personally I use eglot with consult which temporarily switches the entire buffer to do the "peek" functionality rather than popping up a tiny window: https://github.com/minad/consult

I wonder why everyone's having such long startup time for emacs - like 6 to 8 seconds. Mine has a lot of add-on packages and it still manages to start up in 2 seconds (It's a server. So that happens only once in a session). I haven't done much optimization either - unless you count a lot of autoloads that you automatically get with use-package.

I feel the comment was bait.

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.

A text editor.

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

Edit:

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

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

Relax, we‘re talking about an editor, not someone‘s religion.

Blasphemy! Repent and join the Church of Emacs!

Is what I should say to you since you were involved in the editor war while I was not. I have not even said anything on this topic other than that there are tons of VS Code users here so the "unpopular opinion" makes zero sense and just feels like you were being rude to Emacs users (of which I am not one). I downvoted you because you were doing editor warring.

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

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

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

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

Modern features:

1. lsp-mode/eglot

2. package management

3. treesitter grammars

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

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

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

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

8. Interactive repl.

9. 5 different terminal emulators built-in.

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

11. github, gitlab integration with magit.

12. Copilot, tabnine, and chatGPT integration.

13. Hundreds of themes.

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

15. Use any ttf.

16. Mouse editing and command binding.

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

18. Refactoring with lsp.

19. Autocompletion and jump to source.

20. Session save and restoration with desktop-save.

21. Slack integration.

22. Debugger with dap-mode.

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

24. blame with.magit-blame.

25. Pixel scrolling.

25. Transparency with seethru.

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

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

30. Containerized deployment via flatpak.

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

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

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

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

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

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

> But vscode has basically all of it out of the box.

Are you sure ?

I think you might want to contemplate that "Fashionable" is semantically equivalent to 'dated'. You are excited that it's dated to 'now'.

I know you see this fashionable UX as an advantage, but what I think about is how you're going to have fashionable evolution in UX thinking inflicted on you. It feels to me like someone coming into my shop and moving all my tools.

Gratuitous example from an adjacent area of nerdliness: Were you around when Microsoft decided to drop the UX they'd been using for a few decades and change to "The Ribbon" ?

> You are excited that it's dated to 'now'.

Yes, I am. That's very convenient for me.

> Were you around when Microsoft decided to drop the UX they'd been using for a few decades and change to "The Ribbon" ?

I was, and you're right. Microsoft functionally owns the chrome for vscode and it isn't as configurable as far as I can tell as emacs at that layer. There's certainly a possibility they will make a decision later to mess everything up.

But for now, my previous observation stands. I have to do less configuration out of the box to get vscode into a daily use work configuration than a naked emacs install.

I highlight this because it's not an unsolvable problem for emacs. It requires making a recommended default configuration. That will be more correct for the 95% use case and advocating that configuration on the install channels for the tool.

> I highlight this because it's not an unsolvable problem for emacs. It requires making a recommended default configuration that will be more correct for the 95% use case and advocating that configuration on the install channels for the tool.

For people interested in this, I know about Doom Emacs [1] and Spacemacs [2].

[1] https://github.com/doomemacs/doomemacs [2] https://github.com/syl20bnr/spacemacs

Why downvote this guy for essentially just pointing out that Emacs isn't terribly useful out of the box if you want to develop software? This is objectively true, isn't it?

It is like assembling IKEA furniture if IKEA furniture didn't come with a usable manual and there are nine different descriptions online of how to assemble your new chair. Of which 5 don't actually produce a chair and two that are strangely incompatible with how you prefer to situate your couch.

Rather than be angry with people for pointing out something that is very likely to be true, how about listening to _valid_ user criticisms? And perchance see if something can be learned from it?

This is valid feedback.

> Why downvote this guy for essentially just pointing out that Emacs isn't terribly useful out of the box if you want to develop software? This is objectively true, isn't it?

I don't think that's true.

Do you include installing emacs packages as out of the box as you would vscode plugins though?

Well, it is or it isn't.

Here's what you can try: do a clean install of both, then document the steps you had to take to get VS Code + Go plugin to work vs getting Emacs to within a reasonable fraction of what VS Code will provide. Post your Emacs config when you are done. (As well as links to the sources where you found working configurations).

PS: good luck nailing the language server stuff on the first try on Emacs.

Quite easy - install doom emacs, comment out the ;;(go +lsp) in init.el and run doom sync. You are done and can do go development now with 1 line of config.

vscode recommends plugins to install as it encounters file types they would be appropriate for. It's not strictly out of the box, but it's fairly close to out of the box... Out of the box, vscode comes configured to guide the developer to enhance it as needed.

vscode has a lot for itself, but i see my colleagues use it, it's still too mainstream and enterprisey. the git interface adds more confusion and reduces speed..

No disagreement. I find myself just using terminal instead of the vscode git interface almost all the time.

I don't understand why this was downvoted.

Vscode out-the-box is much more complete for coding than Emacs out-the-box.

While my Emacs-foo is not that great, I have relied on it for a lot over 25 years of programming. Recently, though, I gave Vscode a try, and while it's buggy as hell when you load up on the extensions you need, it's not that bad!

Slow? Yes, compared to a Vim or Emacs similarly set up. A wee bit bloated? Certainly, compared to my Vim and Emacs configuration.

But, really, it's the one I recommend to new developers. Not Vim, nor Emacs, even though I use those myself.

postmodern features: [e]lisp metalevel customization

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

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

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