https://www.reddit.com/r/emacs/comments/je3eht/emacs_user_su...
This appears to be some random person doing this - doesn't appear to be sponsored or approved by rms/gnu/fsf.
(especially with non-free javascript)
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.
Who -- Questions or comments can go to contact@emacssurvey.org
Instead, I got a wonderfully done perspective on it. Has done criticism, but all constructive. And lots of hope for seeing the results.
I share his general ideas on this. I, also, don't really care for forcing standardisation. Nor do the defaults worry me. I'm convinced most of the "Emacs is hard" crowd is just send fulfilling propaganda. So many think it is harder than alternatives because that is just what you say.
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.
As an Emacs user for some decades who never really uses any other editor, I found a few questions I didn't understand very well or recognise the answers for. I suppose other users must be more ecosystem-minded than I am.
I was intrigued by the (mandatory) question about which theme you use. Does Emacs even "have" named themes?
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.
I use solarized dark
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)
https://github.com/hlissner/emacs-doom-themes/tree/screensho...
and probably many others
run load-theme to switch by name, to any you've got installed.
1. it does not specify to whom this website belongs to, neither what the purpose of this survey is
2. in programming languages, there's not even one lisp dialect. In a survey. For Emacs. :p
[Edit]: correction for 2, as there's clojure. Thanks anamexis.
In terms of time spent programming in Emacs, my dominant languages would be C, C++, C#, Scheme, ELisp and Ruby.
Seems odd to leave out the language Emacs was written in.
Shame though that neither common lisp or scheme are present.
Emacs is a good text editor and I run it for every text file I read or write. As a text editor however, emacs can never handle things like project-management, software development and testing in the same way as an IDE. Yet, it has all the features of an IDE available in some melpa repository. Unfortunately, one is always forced to configure the editor and tweak it here and there to get maybe 80% of what would be possible. And then your settings break your workflow in *that other project* or for a simple plain file. Emacs should finally acknowledge that projects are a thing and support them out-of-the-box.
I would wish for an emacs daemon that considers itself responsible for a single project and manages the language server, version control, compiler and all the other project settings. Whenever I open a file in the scope of that project, the daemon should then configure my emacs instance accordingly to work well in the context of that project.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?
I launch a different emacs server for each project I'm working on, and make any modifications necessary there. Usually I only have one project per language open at a time, but suppose I have two lisp projects (unrelated) and don't want a cluttered up set of buffers that all look almost the same (by name, some getting a number appended if they were the second opened). I'll launch a named daemon from inside the project's root directory (emacs --daemon=foo, or with my .zshrc it's just emacsd foo). Then I can access it using emacsclient -s foo (or e -s foo with my .zshrc).
If you really want it customized per project you could probably add some logic to your .emacs file or elsewhere that would run custom elisp per server, maybe check to see if the directory it was launched in has a .emacs file and evaluate that.
Yes, or use .dir-locals.el like civilized ;)
What specifically do you think is lacking, apart from having a ready-made IDE out-of-the-box in Emacs?
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 :)
I've put in a small amount of effort into this (hand-rolling a python config, using a DOOM config I found) and I get something that seems really slow if it works at all. Before I invest more time I was wondering if anyone had a screen cast or any personal experiences with this. Frankly I'd use whichever editor has the best code complete and search capabilities.
Right now I use emacs for magit and orgmode but want to expand it to other areas.
edit: screenshots / screencasts: https://emacs-lsp.github.io/lsp-mode/page/gallery/
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.
The language server for Rust that I prefer was written, and is maintained by, a JetBrains employee. For C/C++ it's hard to beat ccls, and for C# there's omnisharp-roslyn which is, again, hard to beat.
Otherwise, with dumb-jump I get superior jump-to-definition than JetBrains.
I've never found a fully satisfactory c++ setup, but always thought things like e.g. slime worked well.
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.
For python, elpy pretty much "just works" (some kicking required). It has a built-in diagnostic helper that will tell you what packages you're missing.
For anything supported by clang, company-clang or clangd work quite well.
For everything else, rtags/gtags or similar is the way to go. It uses a superficial understanding of the files, so black magic (e.g. putting `int=str` at the top of your python file) will confuse it, but it's generally good enough.
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'm using the native-compiled branch of emacs28 on macOS (see https://github.com/jimeh/build-emacs-for-macos). I'm using spacemacs, so I don't know how helpful my config will be, but for python I'm using lsp-mode with pyright on the backend.
I've been using emacs for ~2yrs, and there were a lot of things I loved about it, but code completion has always been mediocre until now.
I use XEmacs 21.4 and Sublime 3.2.2 (and sometimes editors that come with various IDEs). I also regularly use vi when logged in as 'root', as it's an established sysadmin best practice not to run third-party software as super user.
Sublime is more beautiful but I trust Emacs more (Sublime still has the odd bug) and I master Emacs commands fairly well by now (used since 1993).
The reason why is because using anything else creates unnecessary friction between me and the rest of the team. This applies to other tools as well; for example, the default way to bench-test a running web service is to "use Postman". I could use curl, and that would be easier for me, especially from a scripting standpoint, but everybody else's vocabulary is in terms of Postman, so I'm forcing myself to use that.
Definitely a "web kids" survey.
(global-set-key (kbd "å") 'hippie-expand) s-c sp-copy-sexp
s-b sp-backward-copy-sexp
s-p helm-projectile-find-file
s-f helm-find-files
s-r helm-recentf
s-R spacemacs/rename-current-buffer-file
s-0 delete-window
s-2 split-window-below
s-3 split-window-right-and-focus
s-D dired-jump
IE, a user might complain that right-to-left editing is broken in some frustrating matter, but without some weighting related to demographics (or other) that complaint might get lost in the noise.
The outcome might be that a lesser-frustrating issue may receive more development time because it simply received more complaints.
IE, instead of fixing right-to-left editing and so broaden the potential audience the developer hours might be spent on spelling errors or integrating a melpa package into core.
This is not to say there exists a right-to-left bug! I am simply using it as a hypothetical example.
I really hated Emacs at the time. I only stuck with it because the alternative was vi.
If I'd had to start over, I wouldn't have bothered.
So... I get the motivation for including this, and I understand Emacs's roots. But IMO this mindset — the one that motivated including this disclaimer - is also why efforts to "modernize" will pay an extra tax, possibly preventing its success.
Emacs has a prioritization rubric that places freedom above mainstream utility. That's perfectly fine, but it inherently limits 1) its audience size, and subsequently 2) its contributor pool and 3) financial upside - either direct or indirect (used to support the project).
This means it will always lag behind the projects that are setting the bar for what "modern" means.
I'm not sure how much this inhibits Emacs. It's architected in a certain way and there's decades of elisp code one wouldn't want to throw away. IMO this is the biggest limiting factor. Most big fundamental improvements would mean giving a lot of stuff up.
Not a huge fan of "free" software absolutists but just haven't seen this come into play too much with Emacs.
For people who do care there is a spectrum of issues they might care about, including free vs non-free. Surveys like this might even help the developers to identify which of those issues users do care about, and as such, the people behind the survey likely want to make the survey as inclusive to that spectrum as possible.
That's a great question. Whois does not provide any identifying information (other than Google as the registrar) for the domain, and the site appears to be hosted on the Google cloud.
It would be interesting to have such information. Perhaps if someone involved is here on HN, they could share that information?
>Also kind of odd for a survey about Emacs to require nonfree JavaScript.
I'd note that while the online form does require javascript (and that it's non-free is noted on the page), you aren't required to use it. Rather you also have the option to download the survey template and email it to the group.