Re: Discoverability (was: Changes for 28)

[Tom Gillespie]

Hi Stefan,
   Thank you for the opportunity to clarify some of my points. Best,
Tom

I will add that I am heartened by other ongoing discussions that indicate
a desire to figure out how to make it possible to

On Tue, Sep 8, 2020 at 7:52 PM Stefan Kangas <stefankangas@gmail.com> wrote:
> I find the analogy to be fundamentally broken.  We jest that Emacs is an
> operating system, but really it is not.  It's a text editor.

I do not think that it is a jest. Further, I think that to treat it as
such fundamentally
undermines real responsibility that Emacs has as a piece of core infrastructure.
It may be a just a text editor to you, but to others it is a language runtime no
different than the JVM, and to yet others it is the heart of their livelihood.

Emacs is as far from notepad.exe (or ed if you prefer the default editor)
as a nuclear missile submarine is from a hollowed out log. Yes, both are
technically seacraft, but a hollowed out log filled with any number of angry
pointy stick weidling men is unlikely to be able to lay waste multiple cities
in a matter of minutes.

> I don't see how the "don't break userspace" maxim of Linux kernel
> development could be applied to Emacs in any meaningful way.  We deal in
> Lisp, not ABI:s.

The example was not intended to be about the superficial implementation
details of the particular technology. It has to do with the responsibility that
a project has toward its downstream users. Projects that treat their user's
time with contempt wither and die unless they have a government mandated
monopoly or the like. Emac's has slightly more leeway than the kernel, but
if we want Emacs to be infrastructure then we have to treat it as such.
Every second that a user has to spend fixing something that broke because
of a change in Emacs has to be weighed against the potential benefit. Those
seconds are no different from the seconds that some userspace developer
(almost never) has to spend fixing something that was broken by the kernel.
Furthermore, the risk for us as developers is that we are isolated from the
realities faced by other users and are massively biased toward decisions
that benefit us and make our work easier. Therefore it seems like a good
idea to approach any changes to default behavior with great care since
it is especially difficult for a project like this to do the user studies or
collect the telemetry required to ensure that those changes don't break
countless workflows.

> >               That means that certain seemingly simple and quick
> > solutions, like changing defaults, are forever off the table.

Please excuse my hyperbole, and allow me to amend that statement
to include "If we entertain the possibility that this means that ...".

> If so, it's a new rule.  AFAICT, defaults both can and do change.
> See NEWS for Emacs 27.1.

As a sufferer under some of those changes, I am well aware of the
pain that such divergences cause the users. I acknowledge that
sometimes those changes need to be made for sake of consistency
with larger refactorings. However, the fact that they do happen should
be viewed as a failure of engineering and not an excuse for future failures.