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?
No, it's not.
Emacs Survey
41–50 of 128 posts
Re: Emacs Survey
#42I 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?
Re: Emacs Survey
#43Who'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.
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.
Re: Emacs Survey
#44> 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 audien…
Modern doesn't have to mean nonfree
Re: Emacs Survey
#45Earlier quoted context omitted.
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
Re: Emacs Survey
#46One 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.
Re: Emacs Survey
#47> 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 audien…
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.)
Re: Emacs Survey
#48> 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 audien…
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.
Re: Emacs Survey
#49Does 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…
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.
Re: Emacs Survey
#50I 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 Ema…
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.