emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes for emacs 28


From: Ergus
Subject: Re: Changes for emacs 28
Date: Sun, 13 Sep 2020 14:53:32 +0200

On Sun, Sep 13, 2020 at 01:59:02PM +0300, Göktuğ Kayaalp wrote:
On 2020-09-13 13:30 +03, tomas@tuxteam.de wrote:
On a more serious note, what I wanted to point out is that there
are many forces shaping what is currently perceived as "usage
friendly". Some of them stem from ergonomy research (which, of
course, focuses on some population already exposed to software
"out there", so it's part of a feedback loop), some of it stems
from some manufacturer's attempt to differentiate itself, to
grow sales, some of it, even, from a strategy of appealing to
potential decision takers (who are /not/ those who have to use
the sofware later).

A lot of that research is pseudo scientific.  E.g. some famous
‘principles’ of UX design are based on academesified opition or
misappropriation of unrelated research.  E.g. see this one [1].  If you
read the ‘scientific’ background to the ‘laws’, what you’ll see is that
some of those are shaky, and some of those are lesser than that.

We should focus on what makes users *stay* with Emacs, and what makes
such a stay comfortable.  While I see no harm in making the first steps
easier---so long as it’s reasonably backwards compatible---, I firmly
believe that Emacs is a piece of software users should come to with a
knowledge of what to expect.  That’s not to mean it should be difficult,
as some are tending to interpret, but that Emacs constitutes a certain
paradigm of computing, and that that’s the main thing it has to offer.

As an example---tho it’s inevitably a single data point---I’ve never
been a user who is unable to figure out how to change the theme or
modify something in Emacs.  But I’ve only came to stick with it when I
uncovered what _actually_ it has to offer, over some keybindings and
random customisation.  It should also be considered how so many users
stick to Emacs despite it’s apparent that they are pretty much aware
that many other editors are way easier than Emacs, for some measure of
easy, and yet they stick to Emacs, despite the unfamiliarity, despite
the supposed difficulty.

We’re asking "why people aren’t coming to Emacs in hordes" too much,
when "why are people using Emacs in the first place" is the more
important one.

I would make also these questions:

Why the vanilla emacs users almost hasn't increased or has decreases if
the number of programmers has exponentially grow in the world?  And
being emacs so powerful and old; how is it possible that it is
frequently not even listed in the GNU/Linux popular editors articles or
it is back in the list?  The emacs popularity is so low these days (even
in GNU/Linux users) that some distros still comes with emacs 24. And if
we split spacemacs and doom apart it is almost negligible... we are even
after vim.

How the emacs modifications (specially spacemacs) have found a set of
frequent developers, and a big younger community? (which is not bigger
because it is a bit overloaded of external packages IMO)

How is it possible that all those dummy and young editors have multiple
times more users and community than Emacs when they don't really bring
anything much better than us?

Are we sure we don't need that "fresh air", "new ideas" and "lot of
work" to be happening in vanilla directly? Even if we (former users)
disagree with some of them and have to add 3, 4 or 10 extra lines to our
config to disable them?

I think that when emacs was created it was a revolutionary thing; it
brought an "easier" way to do "complex" things in that time's standard
and broke many paradigms. Why now we constantly insist in "paradigm of
computing" and "historic reasons" or "because in the 90's ..."? I am a
big supporter of backward compatibility, but sometimes the problem
becomes "evolve or die".

Every software has a complex social part; and part of that is to satisfy
general user's needs (because not all the users must be programmers and
even not all programmers have to be lisp programmers or understand the
emacs internals).

Just a recent example:

It's worth nothing to have a better technical feature if most of the
users prefer something else or don't really care the benefits if they
sacrifice simplicity (like for example undo) or don't know about them or
are used to, and like something else. OTOH the strong positions about
having a normal undo-redo in vanilla ()even not by default for years and
trying to enforce the user to follow our "technically better paradigm"
just made that alternative buggy undo-redo implementations grow like
mushrooms; some of them with bad implementations and giving a bad
experience to final users.

One of the things we must understand is that even not all developers
need to be programmers, know lisp or understand the benefits of undo
over undo-redo. We need help with the documentation, the web sites,
sysadmins, designers, web designers, javascript, CSS and the other
beasts, even youtubers, publishers and journalists etc. And is more
probable that all those help here if they can do part of their work in
emacs; even if they have no idea about lisp, packages, and prefer a
black screen and CUA mode.

It's my opinion.

[1] https://lawsofux.com/

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427



reply via email to

[Prev in Thread] Current Thread [Next in Thread]