2 ms·

> It isn't the Emacs way to second-guess our users' needs, definitely not to decide for them what is and what isn't a matter of life and death for them. We prov

> It isn't the Emacs way to second-guess our users' needs, definitely not to decide for them what is and what isn't a matter of life and death for them. We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them. > It is IMO unreasonable to make our defaults match what happens in dictatorships that you describe, because that would unnecessarily inconvenience the majority of the users. Let's not follow the bad example of the TSA (whose rationale is, unsurprisingly, also matters of life and death). Here's that same response in an alternate Gnuniverse where software development is... different...: "Thanks, Jimmy. Security is outside my wheelhouse, so let me run your ideas by a security researcher I already know and trust. Then we'll figure out the most effective way to improve TLS in Emacs without creating a maintenance burden for the project. Best, A sensible developer who knows what they don't know"

wyuenho 8y ago
LOL, if only. It'll certainly save me a lot of work. //edit BTW, those aren't my words, those are Eli's responding to Perry
- jancsika 8y ago
  It is funny, but I didn't mean it as a joke. It should generally be possible to predict the range of responses when submitting a patch to a free software project, or when posting to a free software list. If the input is "TLS" and the output is "TSA," it puts a strain on everyone and free software development suffers as a result.
kqr 8y ago
> We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them. This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing. Now that I've had the relevant comment out of the way, let me be a little more general. > It isn't the Emacs way to second-guess our users' needs This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet. It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem. However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there. I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion. So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.

wyuenho 8y ago

LOL, if only. It'll certainly save me a lot of work. //edit BTW, those aren't my words, those are Eli's responding to Perry

jancsika 8y ago
It is funny, but I didn't mean it as a joke. It should generally be possible to predict the range of responses when submitting a patch to a free software project, or when posting to a free software list. If the input is "TLS" and the output is "TSA," it puts a strain on everyone and free software development suffers as a result.

kqr 8y ago

> We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them. This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing. Now that I've had the relevant comment out of the way, let me be a little more general. > It isn't the Emacs way to second-guess our users' needs This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet. It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem. However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there. I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion. So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.