The purpose of this survey is to get an idea of the preferences of Emacs users. Not to get an idea of the ideal Emacs users that rms cares for. Given how many MELPA packages many (most?) power users use, excluding their opinions makes for a pointless survey.

Kind of like asking people their views on healthcare, and not listing any option other than the universal healthcare options.

It's not too hard for people to learn, sure. But it's also a much steeper learning curve to get value from compared to IDEs or to VSCode. The latter are really quite nice out of the box.

And it's surely way easier for a novice to dig themselves into a hole they can't get out of with Emacs compared to VSCode.

I think spending some time to know your tools better is a good thing. But for those who don't have the time or interest, I wouldn't say Emacs is a great choice.

I then used the same customized terminal colours in my GUI theme.

It works like this:

    (if (display-graphic-p)
        (setq color-yellow "#f57900"
              color-bright-yellow "#fce94f"
              color-red "#ff6464"
              color-bright-red "#ef2929"
              color-bright-green "#73d216"
              color-green "#4e9a06"
              color-blue "#729fcf"
              color-bright-blue "#204a87"
              color-white "#babdb6"
              color-bright-white "#eeeeec"
              color-magenta "#ad7fa8"
              color-bright-magenta "#1d324b"
              color-black "#1a2022"
              color-bright-black "#2e3436"
              color-bright-cyan "#555753"
              color-cyan "#888a85")
      (setq color-black "black"
            color-white "white"
            color-red "red"
            color-green "green"
            color-blue "blue"
            color-yellow "yellow"
            color-cyan "cyan"
            color-magenta "magenta"
            color-bright-black "brightblack"
            color-bright-white "brightwhite"
            color-bright-red "brightred"
            color-bright-green "brightgreen"
            color-bright-blue "brightblue"
            color-bright-yellow "brightyellow"
            color-bright-cyan "brightcyan"
            color-bright-magenta "brightmagenta"))

With a true-colour capable terminal there's no technical reason to need to take these steps, but this approach works for me in rxvt-unicode and mintty, the two terminals I use on Linux and Windows respectively, and aren't mucked up by any level of tmux or screen nesting.

It's not as if I even have a complicated custom theme in my .emacs - I have a couple of lines, but mainly I just don't change the colours from their defaults any more. I care a great deal about what my editor looks like, but it turns out that the default colours - black text, white background, pleasantly dark font-lock colours - are perfect for me already. (I waste my time on fonts instead)

Shame though that neither common lisp or scheme are present.

To give you an idea, I used Emacs as a programming editor for a decade, and only about 2 weeks ago did I first set it up as some kind of IDE (or rather, I just installed elpy and it did it all for me). I was perfectly happy without using it as an IDE - knowing the constraints that come with it.

Please do, I just learned about dumb-jump, any more suggestions of things that worked for you?

Yes, or use .dir-locals.el like civilized ;)

Can you find me an example of a modern emacs config that creates a barebones python editor that does code completion and isn't significantly slower than jetbrains code completion? Most of what I can find is significantly out of date or just doesn't work. If its not possible or easy to find some barebones skeleton to build off of, I think the editor as a whole is too difficult to be worth using.

I tried doom but got something slower than jetbrains that also didn't work. I haven't yet found the time to invest into debugging/retrying. My next attempt will probably be me restarting, spending a few hours reading about how to use/debug packages and also getting something that does not really work. Is this really worth it?

Of course, since MS Windows doesn't have emacs daemon processes one needs to keep the emacs window open in order for it to be used to open more files in the future.

In other words, I spent a ton of time to set up emacs so that when it's already open new files will be opened in that already running instance.

On the one hand it was kinda fun to fiddle with and I was happy when it was done. On the other hand I spent a ton of time getting something to work that most other editors do automatically out of the box.

In a way that kinda sums up my experience with emacs - fun to fiddle with, but takes a lot of time to set anything up.

That said, org mode is awesome, and like single-handedly keeps me using emacs :)

The emacs 27 speed improvements is actually what inspired me to try and get a working editor out of emacs again. Previously I had something that was usable but not great for javascript.

My preferred stack is: Emacs + lsp + ccls + dumb-jump + rg + projectile + dap

It's still not perfect, but it's the best I can do.

I don't quite understand why this works without +lsp in the python language configuration. I also don't really understand the significance of lsp-mode versus eglot or whether or not this change made a difference. But -- these changes make my config a lot easier to use and build off of now.

I really hated Emacs at the time. I only stuck with it because the alternative was vi.