Emacs Survey
emacssurvey.orgFor the people wondering "who's asking":
https://www.reddit.com/r/emacs/comments/je3eht/emacs_user_su...
I was wondering that.
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)
I think this is more useful than anything sponsored by rms/gnu. On the mailing list they are upset that MELPA was included as an option, for example (they consider it evil).
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.
I'm not sure emacs will properly evolve as long as RMS is still involved.
Meh. I liked Emacs better when RMS still led the project than afterwards. Fewer changes that annoyed me.
RMS was definitely opinionated, but he was consistent about it, so that once you are familiar with some of his decisions, you could guess how he would decide other things.
What are some examples of recent annoyances you found?
Emacs evolution is really always just a fork away, if someone can build something better than what's there for enough users to care.
XEmacs? I liked it bether than the real thing, it still died
I will say by the time I made the transition, most of the advantages of xemacs had been addressed.
I think I had a better global search and replace method though.
What did its user count get to?
There was some discussion on the mailing list about it (before rms diverted the thread off on a tangent).
ha, that's funny! well, i think the answers will be of general interest in any case.
It's still not clear to me what this is about and what they're going to do with my information.
pretty soon you will start getting emails with offers for vi, teco, notepad.exe, vscode and cat.
Lol --
Who -- Questions or comments can go to contact@emacssurvey.org
With some comments by Bozhidar Batsov (https://github.com/bbatsov) here: https://emacsredux.com/blog/2020/10/22/state-of-emacs-survey...
Reading in another comment that there was some hostility in the official mailing list had me worried to read his take.
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.
> 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.
I'm not convinced. I recently installed VSCode after all that hype and I'm somewhat disappointed. Without referring to external media, it's not all that easy to get anything done. It isn't exactly intuitive. It takes effort like anything else.
(full disclosure: these days I'm almost exclusively an Emacs user, but for Java I might use IntelliJ instead and long time ago, when VisualAge for Java was still around, I evaluated a bunch of Java IDEs for the company I worked for)
lsp-java [1] might interest you. There was a lightning talk [2] about it at Emacs Conf 2019.
Exactly the point I'm pushing. I hasten to add that I'm not claiming the alternatives are bad. Just not as rosy as often pushed.
And on this, I just disagree. It feels faster to use vs code for people that are used to tools like vs code. For novices, though, they are all complicated.
Worse, for many IDEs, the worst hole to dig is where you tie yourself to the IDE. Too many times have I seen projects that only build on a particular desktop with the press of a button on a particular IDE. :(
I filled this in for fun - it's short enough and impersonal enough that I didn't feel I cared what happens to the data.
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?
Yes, many! I use deeper-blue. solarized-light and -dark are also good. Themes don’t seem to work well with terminal emacs though, but I haven’t dug into the issue much since I’m mostly in the GUI.
Well, I wrote my own theme so I could have a consistent experience between GUI and terminal. It meant customizing my terminal colours so they were non-awful (the minimal 16 are super-garish, I have mine tuned for less harsh contrast but also more colour differentiation considering I'm red/green colourblind).
I then used the same customized terminal colours in my GUI theme.
It works like this:
Then, later on, I use these colours for setting the faces for the cursor, region, keywords, comments, tweaking various different major modes, etc.(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.
Yup. It used to have color-themes, which I believe was a package, but maybe five years ago they switched to supporting themes as first class citizens.
I use solarized dark
Oh yes, I see there's a theme entry down in the Customize Emacs submenu at the bottom of the Options menu. Logical though that may be, I had no idea.
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)
I wanted a "none" or "default" option there. Also the one about communities (reddit etc) was mandatory and no option applied.
welcome to the wide wide world of shared themes
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.
I use doom-themes laserwave. It's in melpa. M-x customize-themes and look for themes on melpa, you can make it look like the new hotness. Also, install doom-modeline from melpa, and M-x all-the-icons-install-fonts for a really informative and beautiful mode line.
The "what did you use before Emacs" question stumped me: only one of those even existed when I started using Emacs. :)
It does. I like leuven.
I think this survey was populated without any thought.
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.
Right?
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.
Also left out LaTeX.
I generally agree, but re #2, there is Clojure.
Yes, you are correct! Thanks.
Shame though that neither common lisp or scheme are present.
I think it’s because the took the list from the stack overflow developer survey. Probably they’re hoping to pick up more general emacs users and not emacs package developers
Elisp can be used by package developers, but it is really meant to be used by Emacs users. In that, Emacs is fundamentally different than other editors. Users are not only enabled, but encouraged to extend their editor.
Yes, but if you are using emacs for other work, you are hopefully spending most of your time doing that and not writing emacs lisp.
Elisp wasn't included either, but I guess the question above covers that.
I entered this at the end:
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.I manage all my projects using a constellation of flexible (and hand-picked) tools it offers: magit for versioning, Org for documentation, note taking and time tracking, blacken, isort and prettier wrappers for my code formatting, ivy, counsel and dumb-jump for searching stuff and moving around, and I could go on and on. I understand that Emacs doesn't feel as "modern" as PyCharm or VS Code in a sense, but I don't think the "it's not an IDE" argument holds. It can be (if you want and take the time for it) a very powerful IDE, customized to exactly your needs. It can also be a lot of other things in addition. It's a difficult to classify tool, in a category of its own.
The problem is that everyone wants something different in an IDE (and the same person often wants different stuff depending on the language they are programming in). Whatever default Emacs can provide will be suboptimal for most users and cause additional dissatisfaction. People have a more open mind when when they know it doesn't include an IDE and may have to work to get one up and going than if they simply see the default one and think that's the best they'll get with Emacs.
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.
> and I could go on and on.
Please do, I just learned about dumb-jump, any more suggestions of things that worked for you?
Some other packages I can't live without: expand-region, git-link, pass, treemacs, vterm.
Have you tried Lispy [1] and it's derivatives (Lispyville if you're a vim user)? It single-handedly changed how I felt about Lisp editing.
It looks like we have a similar taste in packages. Would you mind sharing a link to your dot emacs?
If it helps, maybe not the solution you want but what I do:
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.
> 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 ;)
For others:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
Good to know, I've used file local variables but never thought about directory local variables.
"one is always forced to configure the editor and tweak it here and there to get maybe 80% of what would be possible"
What specifically do you think is lacking, apart from having a ready-made IDE out-of-the-box in Emacs?
Specifically, emacs is lacking up to date examples of how to do basic IDE functionality with emacs 27//28 and 2020 versions of packages. I don't think someone can build their own IDE without being an emacs intermediate and/or already immersed in to the emacs community.
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?
At one point I was trying to get emacs server to work, so that I wouldn't have to wait a long time for emacs to start (to be fair, part of the problem was that my config file had a pile of stuff in it that I didn't really need). After spending waaay more time on it than I really wanted to I got it working here on MS Windows.
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'm curious what made it so fiddly. I set up emacs server on Windows maybe 6-8 years ago so perhaps I've forgotten a lot. But as I recall I just made a shortcut that would send the right command line arguments to emacs on launch, and a second one that I used for the client.
This is gonna sound dumb (because it is :) ) but it took me a while to realize that on Windows there's no daemon process so you gotta keep the emacs window open.
I kept closing emacs and expecting the next startup to be super quick and it wasn't. It was clearly starting up from scratch again.
I think the server stuff on Linux / MacOS does start a daemon, but I spent a bunch of time trying to get it to work (quick startup with no visible instances) before I happened to read that one needs to keep the first instance open on Windows.
Separately but related, sometimes emacs doesn't remove the text file that it uses to figure out if there's already a server running or not when it exits. Any further instances assume that another instance is the server and they don't take over as the server themselves. Thus, the zombie text file ensures that the server functionality stops working until you delete the file yourself, manually. I was half thinking about writing an emacs function to check if the pid identified in that text file is legit (i.e., is there a running process with that pid?) and if not then delete the marker file. Somewhere around there is when I decided I didn't want to fiddle _that_ much with my editor :)
Yeah, on macOS and Linux it starts a proper daemon. On Windows, I used org-mode so heavily that the idea of closing it during the workday usually meant I was preparing to reboot for IT's 25th update push of the day.
I actually do recall the lock file not being deleted properly a couple times. It didn't happen often, probably why I had mostly forgotten about it.
> 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.
Isn't this just a matter of associating files to the right Emacs executable (emacsclient)?
It's been a while and I've forgotten a bunch, but I think I tried that and it didn't work. Maybe there were some command line parameters, so I needed to associate it with a batch file.
Plus, I wanted to press the Windows key, then type "emacs" and have that work.
I'm probably doing it wrong, but i couldn't find clear, easy, step-by-step instructions for doing this otherwise.
Integration. If I want to open emacs inside a Cmake c++ project, everything it needs is already there. But I have to configure all the tools myself. Then I switch to a python project and the same stuff has to happen again.
Does anyone have an example of emacs achieving parity with JetBrains in code completion/code searching?
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.
I can't really compare because, well, I don't use JetBrains IDEs at all, but for supported languages, emacs-lsp does provide features like code completion, lookup, inline documentation…. It is the single biggest improvement to Emacs for me since I've started using it a long, long time ago. I can tell that it works very well for at least Python and Rust. I remember TypeScript support looked nice too, though I don't do much TypeScript these days.
edit: screenshots / screencasts: https://emacs-lsp.github.io/lsp-mode/page/gallery/
It's not bad for Go either. The only issue is that gopls is still considered alpha, so it's not the most stable thing out there, but that's not Emacs's problem.
I've been using gopls with lsp-mode for a while and it's been working great, I haven't had any stability problems.
Very true - gopls has come a long way. I should note I use it every day in lsp-mode when I'm writing Go. Hiccups are much less common now than, say, a year ago.
Consider trying Emacs 27.1 with the Jansson library to help with JSON parsing if you're using an LSP-based approach in Emacs. (Apparently one of the reasons that it's sluggish is because the comms between Emacs and the corresponding language server are done in JSON, and previously Emacs' JSON parsing was a bit slow--libjansson was incorporated to speed that up). I have not used JetBrains so I don't have that comparison, but I use this Emacs arrangement with C# and have been very happy with its autocomplete/jump-to-definition/etc. capabilities. (I have used it with Python and JavaScript as well with a bit less success, but I think that is mainly because I haven't managed to get my environment configured quite right for it to be able to find everything, so that's my own shortcoming and I'd expect to have similar issues in any other editor ;) )
I'm running a self-compiled emacs 28.0.50 on osx. Part of me wants to try recompiling and/or using a homebrew formula for latest emacs just in case I did something wrong in the compile process.
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.
> achieving parity with JetBrains in code completion/code searching?
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 haven't used JetBrains for a few years but it was always pretty slow (i.e. slowed down VS notably and nearly globally) for c++ at least - so perhaps something inherent in the parsing as well though clearly that could be improved.
I've never found a fully satisfactory c++ setup, but always thought things like e.g. slime worked well.
> I've never found a fully satisfactory c++ setup
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 find it, and VSCode and Visual Studio, _astonishingly_ slow compared to Emacs + dumb-jump + rg/ag.
Depends on what language you need to support.
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.
Even VSCode is nowhere near Jetbrains. Their IDEs are rather heavy though. Doom's python+lsp works well enough for me. (My config https://github.com/NightMachinary/doom.d)
I appreciate you linking your config. I made one or two changes to my own config and it seems to have improved.
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.
Just yesterday I think I achieved such parity. Everything is working wonderfully (though, again, it's only been one day, so I can't speak to longevity).
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.
As I mentioned in another comment here, somebody gave a lightning talk about lsp-java [1] at Emacs Conf last year, which I thought looked promising.
They didn't ask the heretic question of "other editors used" (in parallel, not "before"), but I'm going to tell you the answer anyhow:
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).
I answered the survey, but I've begun the process of moving away from Emacs, and adopting what is considered the standard toolkit for a programmer in my position. And for enterprise JavaScript development, the standard editor is Visual Studio Code.
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.
I gave the parallel answers anyway, but weird none of my parallel editors were on there (let alone previous, which even I had to look up the name of to remember). No Xcode, no Visual Studio - both extremely common.
Definitely a "web kids" survey.
Is it really too much to ask from such a project to learn about its initiators and purpose in a first place directly from the site itself?
Well there was a lot of talk about this on the mailing list with a lot of core devs opposed to the idea.
I'm not on the mailing list / saw the survey first on HN. At first glance thought it was marketing spam or something.
Why would a spammer be interested in hearing opinions about Emacs?
Idk, maybe it's Google obtaining market data in order to launch a cloud-based Gemacs
So it clearly is a survey for people on the mailing list and others would just spoil the numbers :)
So they made it as shoddy looking as possible to be able to say later, well we did have a survey, but few participated?
No, it's not.
Filled it in and then managed to get the default keybinding question at the end wrong. Hope that doesn't discount my entry. It's muscle memory, damnit!
I've been using it for less than a year and I pretty much started with Doom Emacs. I know like three or four ways to open a file…but which, if any, is “the default”??? Heck if I know!!
I had to go and find a file to see what keys my fingers have been pressing all these years.
It was too short for `ESC x find-file`. :(
I always use C-x b but this was apparently the wrong answer.
That lets you switch buffers, not visit files.
Same here, I had to actually do it to check the keys :)
At the end of the survey there was a 'what is the default binding to find a file' question. I wonder how many people don't know the answer to that question. I didn't. For Doom Emacs the binding is SPC f d. I've been using Doom for two years and before that I was using Spacemacs. I have no idea what the default bindings are.
I actually had to think about that one. It is ingrained so deeply into my muscle memory that I haven't actively thought about it in a long time.
This was definitely a bit weird for what seems like a question that was probably supposed to filter out malicious responses? I happen to still use the default binding but I could easily see myself forgetting if I happened to be an evil-mode person.
Hmmm, I've never used other flavors of Emacs, but in vanilla, whenever you press C-x C-f the prompt literally says "Find file:"
i've been using space p f in doom. space f d is find directory not file. space f f is find file
no clue what the default is.
Probably M-x f or something. I started using Doom after maybe a week of trying vanilla Emacs, so I can't remember.
C-x C-f is the default for find-file
They did not ask, but Swedish letter "å" is bloody useless on Finnish keyboard, so I have
(global-set-key (kbd "å") 'hippie-expand)I use the WinKey extensively. My top two contenders are:
followed closely by:s-c sp-copy-sexp s-b sp-backward-copy-sexp
:) The rest can be enjoyed here https://github.com/Bost/dotfiles/blob/master/emacs/.spacemac...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-jumpThis is also phonetic choice as "åååå" is an expression of amazement and puzzlement.
hippie-expand is so blessed. It surprises me that all other text editors/IDE's seem to have converged on the distracting pop-up thing
It isn't possible to fill out the online form in EWW, so I'm not doing it.
One of the later questions is regarding whether a future survey should include demographic questions. I'm curious why there's any hesitation to ask? It seems there could be missing information because the questions posed aren't tied to the relative harm an issue could pose.
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.
So I guess I have been using Emacs for at least 36 years. Did they mean to say GNU Emacs?
I chuckled at "be specific" when it asked for issues you ran into when first starting to use Emacs. Whatever it was that led me to use XEmacs for a couple years at first is both completely out of my head and certainly irrelevant to people today. (I think it was something to do with OOTB integration with whatever print spooler I had configured!)
My biggest problem at first was that the Unix server (a Gould NP-1) didn't have enough memory to run an Emacs instance for every terminal in the class, so it was painfully, agonisingly slow. The joke about "Eight Megs And Continually Swapping" would have been very real, if only I had heard it then.
I really hated Emacs at the time. I only stuck with it because the alternative was vi.
Respect.
So, GNU Emacs is thinking to modernize , improvise the Emacs which i think is very good.
*improve (sorry for typo)
Mad points for a terrific survey, esp the last question (no spoilers pls). LOL, my .emacs is so hacked-up, I had to check to make sure I had the correct answer!
Props to JotForm---I accidentally closed my browser window mid-survey and upon restoring from history, it successfully picked up where I left off.
If I'd had to start over, I wouldn't have bothered.
> this requires nonfree Javascript
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.
Well, since this survey does in fact include "nonfree" javascript it would imply the authors don't subscribe to that mindset but mentioned it out of respect to those who do.
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.
People who do not care about what software is made of, under which user license, where data get stored or who reads it and for what purpose will use something like google docs. The modernized mindset is to put things on a sticky platform, preferable one which hardware keys they control, data mine everything for profit, and not have any way for "customers" to contact the company and object if the customer get kicked out of the platform.
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.
Except it is still better than those "modern" projects. I use a lot of editors in parallel, and Emacs has the best UX by a landslide. (I have 3000 lines of config in addition to using Doom, but that is what emacs is about in the first place.)
Modern doesn't have to mean nonfree
Who's behind this survey / it's not clear to me from looking at the survey page. Also kind of odd for a survey about Emacs to require nonfree JavaScript.
> Who's behind this survey / it's not clear to me from looking at the survey page.
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.
You and the poster up-thread that complained that it even mentioned that it used non-free javascript must now fight to the death!
While we do that you should read about the GPL and the reason it was created, instead of trolling while enabling nonfree software.
You are preaching to the wrong person here my friend. It doesn't exactly promote free software...