Implicit assumptions in the latest discussions

Implicit assumptions in the latest discussions

[Daniele Nicolodi]

Hello,

I admit I just read a minimal part of the posts in the current threads
about making Emacs simpler, or friendlier, or more "modern" (for a
definition of modern very different to mine). However, I would like to
express my doubts about the assumptions implicit in these discussions.

These assumptions seem to be:

1. Emacs would be better if it had a larger user base or the Emacs users
would be better served by an Emacs that appeals to a larger user base. I
think that this can be true only as far as another assumption hold,
namely that with a larger user base there would be more manpower to work
on Emacs itself, thus Emacs will become better because more people is
hacking on it.

I don't think there can be any correlation between the number of users
of Emacs and the number of hackers interesting in working on it. If the
end goal is to make Emacs development more sustainable, an easier way to
get there would be to modernize the development practices used to work
on Emacs itself. However, this is a much harder (social) problem to solve.

2. Users are not drawn to try Emacs because what Emacs is and for his
reputation, but because they expect Emacs to be like other editors.

I think that who chooses Emacs, does so because of what Emacs is and
what it has been in its long history, not because they expect something
different. If they expect something different, Emacs has an enormous
technical disadvantage compared to younger editors that are based on
different technologies and that do not want (need?) to keep
compatibility if an incredibly long history.

Probably there are better thing that can be done to make the experience
of these users better than providing "simplified" Emacs environments,
because the users that choose Emacs don't want a simplified Emacs, they
want better ways to access the power of Emacs.

Having "simplified" modes also poses the problem of allowing the users
to "graduate" from the simplified environment to the full blown one. I
haven't see this discussed.

3. Emacs is perfect as it is, but the users do not understand it.

I feel that a lot of the discussions are centered toward having ways to
simplify Emacs to make it more appealing to new users or to some very
specific classes of prospective users. Wouldn't it be more productive
and wouldn't it be better for who already has invested in Emacs (namely
the current users) to discuss ways to make Emacs better for everyone?

For example, GNU/Linux is the platform where Emacs should run best,
however, as far as I know, there is currently no way to run Emacs on a
Wayland compositor, and Wayland is the future of graphical interfaces on
GNU/Linux. Also, some of the complexity of hacking on Emacs, comes from
supporting a wide range of graphical toolkits. Wouldn't it be a
worthwhile goal to support a graphical toolkit that works on Wayland,
and then make it the only one supported (at least on GNU/Linux) and
redirect some hacking energy into making this solution a good solution
for everyone (hacking on the toolkit itself if necessary)? This would be
much more important to keep Emacs relevant in a few years from now than
a Emacs-simplified-mode.

While the use of a specific graphical toolkit may seems a technical
issue far from the current discussions, I would like to point out that
also this is mostly a "social" issue: removing support for other
toolkits will affect those that for one reason or another prefer to use
Motif Emacs.

Cheers,
Dan

Re: Implicit assumptions in the latest discussions

[Robert Pluim]

>>>>> On Thu, 17 Sep 2020 15:30:48 +0200, Daniele Nicolodi <daniele@grinta.net> said:

    Daniele> Hello,
    Daniele> I admit I just read a minimal part of the posts in the current threads
    Daniele> about making Emacs simpler, or friendlier, or more "modern" (for a
    Daniele> definition of modern very different to mine). However, I would like to
    Daniele> express my doubts about the assumptions implicit in these discussions.

    Daniele> These assumptions seem to be:

    Daniele> 1. Emacs would be better if it had a larger user base or the Emacs users
    Daniele> would be better served by an Emacs that appeals to a larger user base. I
    Daniele> think that this can be true only as far as another assumption hold,
    Daniele> namely that with a larger user base there would be more manpower to work
    Daniele> on Emacs itself, thus Emacs will become better because more people is
    Daniele> hacking on it.

    Daniele> I don't think there can be any correlation between the number of users
    Daniele> of Emacs and the number of hackers interesting in working on it. If the
    Daniele> end goal is to make Emacs development more sustainable, an easier way to
    Daniele> get there would be to modernize the development practices used to work
    Daniele> on Emacs itself. However, this is a much harder (social) problem to solve.

Youʼre falling into the "the 'modern' gitlab/github etc dev practices
are better" fallacy here. Theyʼre more *familiar* to certain people,
but I donʼt really like them, because too much of the interaction is
done with a browser (and Iʼm sure Iʼm not alone). See discussions on
this list about moving to such workflows whilst ensuring that email
can still be used.

    Daniele> 2. Users are not drawn to try Emacs because what Emacs is and for his
    Daniele> reputation, but because they expect Emacs to be like other editors.

    Daniele> I think that who chooses Emacs, does so because of what Emacs is and
    Daniele> what it has been in its long history, not because they expect something
    Daniele> different. If they expect something different, Emacs has an enormous
    Daniele> technical disadvantage compared to younger editors that are based on
    Daniele> different technologies and that do not want (need?) to keep
    Daniele> compatibility if an incredibly long history.

    Daniele> Probably there are better thing that can be done to make the experience
    Daniele> of these users better than providing "simplified" Emacs environments,
    Daniele> because the users that choose Emacs don't want a simplified Emacs, they
    Daniele> want better ways to access the power of Emacs.

    Daniele> Having "simplified" modes also poses the problem of allowing the users
    Daniele> to "graduate" from the simplified environment to the full blown one. I
    Daniele> haven't see this discussed.

I think "simplified" is not the goal here, but "more familiar". Unlike
development practices, I see no issue here with offering that kind of
experience by default, since I can turn it off easily. The
"graduation" problem exists, but thatʼs easily solved with
documentation :-)

    Daniele> 3. Emacs is perfect as it is, but the users do not understand it.

    Daniele> I feel that a lot of the discussions are centered toward having ways to
    Daniele> simplify Emacs to make it more appealing to new users or to some very
    Daniele> specific classes of prospective users. Wouldn't it be more productive
    Daniele> and wouldn't it be better for who already has invested in Emacs (namely
    Daniele> the current users) to discuss ways to make Emacs better for everyone?

    Daniele> For example, GNU/Linux is the platform where Emacs should run best,
    Daniele> however, as far as I know, there is currently no way to run Emacs on a
    Daniele> Wayland compositor, and Wayland is the future of graphical interfaces on
    Daniele> GNU/Linux. Also, some of the complexity of hacking on Emacs, comes from
    Daniele> supporting a wide range of graphical toolkits. Wouldn't it be a
    Daniele> worthwhile goal to support a graphical toolkit that works on Wayland,
    Daniele> and then make it the only one supported (at least on GNU/Linux) and
    Daniele> redirect some hacking energy into making this solution a good solution
    Daniele> for everyone (hacking on the toolkit itself if necessary)? This would be
    Daniele> much more important to keep Emacs relevant in a few years from now than
    Daniele> a Emacs-simplified-mode.

Thereʼs an effort underway already to port emacs to 'pure' gtk, which
allows running directly on Wayland. See eg
<https://github.com/fejfighter/emacs>.

    Daniele> While the use of a specific graphical toolkit may seems a technical
    Daniele> issue far from the current discussions, I would like to point out that
    Daniele> also this is mostly a "social" issue: removing support for other
    Daniele> toolkits will affect those that for one reason or another prefer to use
    Daniele> Motif Emacs.

There are people who are very attached to using the Lucid toolkit, and
they have valid reasons. Once the 'pure' gtk is in, thereʼs no reason
to remove Lucid support, but there'd also be no reason to enhance it.

Robert

Re: Implicit assumptions in the latest discussions

[Daniele Nicolodi]

On 17/09/2020 16:01, Robert Pluim wrote:
> Youʼre falling into the "the 'modern' gitlab/github etc dev practices
> are better" fallacy here. Theyʼre more *familiar* to certain people,
> but I donʼt really like them, because too much of the interaction is
> done with a browser (and Iʼm sure Iʼm not alone). See discussions on
> this list about moving to such workflows whilst ensuring that email
> can still be used.

I don't know where you got the impression that I am advocating for Emacs
to be developed using Gitlab or Github. Advances in software carpentry
(a buzzword that nicely encompasses what I am talking about here) best
practices in the last 20 years expand to things completely unrelated to
the use of Gitlab or Github. Unfortunately, hacking on Emacs still
requires obliging to outdated conventions that only stand in the way of
contributors.

> I think "simplified" is not the goal here, but "more familiar". Unlike
> development practices, I see no issue here with offering that kind of
> experience by default, since I can turn it off easily. The
> "graduation" problem exists, but thatʼs easily solved with
> documentation :-)

I think that this "more familiar" environment is something that no one
has been asking for. Actually, the success of Emacs distributions like
Spacemacs seem to suggest that there is a large population of users that
actually prefer a "less familiar" (when compared to "mainstream" editing
environments) interaction with their editor.

> Thereʼs an effort underway already to port emacs to 'pure' gtk, which
> allows running directly on Wayland. See eg
> <https://github.com/fejfighter/emacs>.

I know, and the effort has been undergoing for years now. What I am
saying is that this effort should be probably prioritized and effort
should be put into removing barriers for it to land in Emacs as soon as
possible.

>     Daniele> While the use of a specific graphical toolkit may seems a technical
>     Daniele> issue far from the current discussions, I would like to point out that
>     Daniele> also this is mostly a "social" issue: removing support for other
>     Daniele> toolkits will affect those that for one reason or another prefer to use
>     Daniele> Motif Emacs.
> 
> There are people who are very attached to using the Lucid toolkit, and
> they have valid reasons. Once the 'pure' gtk is in, thereʼs no reason
> to remove Lucid support, but there'd also be no reason to enhance it.

The reason to remove support for obsolete toolkits is that, as long as
they need to be supported, Emacs cannot grow any functionality that
cannot be implemented with them, new functionalities must be coded
against an abstract API that must be grown to encompass them and
implemented N times. If substantial effort should be spent to
future-proof Emads, wouldn't it better to work with the maintainers of a
toolkit of choice to straighten the kinks that make some people prefer
to still use ancient toolkits?

Cheers,
Dan

Re: Implicit assumptions in the latest discussions

[Arthur Miller]

Daniele Nicolodi <daniele@grinta.net> writes:

> wouldn't it better to work with the maintainers of a
> toolkit of choice to straighten the kinks that make some people prefer
> to still use ancient toolkits?
Sure, there is some validity in that, but you still wish to be toolkit
independent in case you have to move to other platform, toolkit etc.

Re: Implicit assumptions in the latest discussions

[Daniel Martín]

Daniele Nicolodi <daniele@grinta.net> writes:
>
> I don't know where you got the impression that I am advocating for Emacs
> to be developed using Gitlab or Github. Advances in software carpentry
> (a buzzword that nicely encompasses what I am talking about here) best
> practices in the last 20 years expand to things completely unrelated to
> the use of Gitlab or Github. Unfortunately, hacking on Emacs still
> requires obliging to outdated conventions that only stand in the way of
> contributors.
>

Could you give concrete examples of those "outdated conventions"?

Re: Implicit assumptions in the latest discussions

[Caio Henrique]

Daniele Nicolodi <daniele@grinta.net> writes:

> I don't know where you got the impression that I am advocating for Emacs
> to be developed using Gitlab or Github. Advances in software carpentry
> (a buzzword that nicely encompasses what I am talking about here) best
> practices in the last 20 years expand to things completely unrelated to
> the use of Gitlab or Github. Unfortunately, hacking on Emacs still
> requires obliging to outdated conventions that only stand in the way of
> contributors.

I got the same impression, and most of these sites require non-free
JavaScript. What outdated conventions are you talking about then? I'm a
new contributor and I'm born close to ~2000. The "hardest" aspect of
contributing until now has been signing the copyright assignments, which
takes a couple of days and I'm currently doing it, but this also isn't
"hard".

Using Gnus made it easy to follow the mailing lists. Debbugs is also
easy to use to track bugs. So I can contribute to Emacs without having
to exit Emacs, it's very comfy IMO.

I also like the code style conventions like not using too long lines,
since I can look at 3 different buffers at the same time.

Re: Implicit assumptions in the latest discussions

[Robert Pluim]

>>>>> On Thu, 17 Sep 2020 16:45:49 +0200, Daniele Nicolodi <daniele@grinta.net> said:

    Daniele> On 17/09/2020 16:01, Robert Pluim wrote:
    >> Youʼre falling into the "the 'modern' gitlab/github etc dev practices
    >> are better" fallacy here. Theyʼre more *familiar* to certain people,
    >> but I donʼt really like them, because too much of the interaction is
    >> done with a browser (and Iʼm sure Iʼm not alone). See discussions on
    >> this list about moving to such workflows whilst ensuring that email
    >> can still be used.

    Daniele> I don't know where you got the impression that I am advocating for Emacs
    Daniele> to be developed using Gitlab or Github. Advances in software carpentry
    Daniele> (a buzzword that nicely encompasses what I am talking about here) best
    Daniele> practices in the last 20 years expand to things completely unrelated to
    Daniele> the use of Gitlab or Github. Unfortunately, hacking on Emacs still
    Daniele> requires obliging to outdated conventions that only stand in the way of
    Daniele> contributors.

I apologise if I misrepresented your position. Itʼs just that normally
when people come here and complain about Emacs' 'non-modern'
development workflow, they mean 'use Gitlab/Github etc'.

Iʼd be interested to know what outdated conventions you mean.

    >> I think "simplified" is not the goal here, but "more familiar". Unlike
    >> development practices, I see no issue here with offering that kind of
    >> experience by default, since I can turn it off easily. The
    >> "graduation" problem exists, but thatʼs easily solved with
    >> documentation :-)

    Daniele> I think that this "more familiar" environment is something that no one
    Daniele> has been asking for. Actually, the success of Emacs distributions like
    Daniele> Spacemacs seem to suggest that there is a large population of users that
    Daniele> actually prefer a "less familiar" (when compared to "mainstream" editing
    Daniele> environments) interaction with their editor.

Nobody asks for it because the people that want it have already moved
to a different editor. People who stay acquire the ability to mold
Emacs to their wishes.

    >> Thereʼs an effort underway already to port emacs to 'pure' gtk, which
    >> allows running directly on Wayland. See eg
    >> <https://github.com/fejfighter/emacs>.

    Daniele> I know, and the effort has been undergoing for years now. What I am
    Daniele> saying is that this effort should be probably prioritized and effort
    Daniele> should be put into removing barriers for it to land in Emacs as soon as
    Daniele> possible.

I know of no barriers to it landing, apart from the usual ones about
completeness, documentation and testing.

    Daniele> While the use of a specific graphical toolkit may seems a technical
    Daniele> issue far from the current discussions, I would like to point out that
    Daniele> also this is mostly a "social" issue: removing support for other
    Daniele> toolkits will affect those that for one reason or another prefer to use
    Daniele> Motif Emacs.
    >> 
    >> There are people who are very attached to using the Lucid toolkit, and
    >> they have valid reasons. Once the 'pure' gtk is in, thereʼs no reason
    >> to remove Lucid support, but there'd also be no reason to enhance it.

    Daniele> The reason to remove support for obsolete toolkits is that, as long as
    Daniele> they need to be supported, Emacs cannot grow any functionality that
    Daniele> cannot be implemented with them, new functionalities must be coded
    Daniele> against an abstract API that must be grown to encompass them and
    Daniele> implemented N times. If substantial effort should be spent to
    Daniele> future-proof Emads, wouldn't it better to work with the maintainers of a
    Daniele> toolkit of choice to straighten the kinks that make some people prefer
    Daniele> to still use ancient toolkits?

You've not been following the decades long discussion on GTK and the
closing of displays, I see: the response of the GTK devs to that was
at best rude, and definitely not helpful.

Robert

Re: Implicit assumptions in the latest discussions

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Thu, 17 Sep 2020 16:45:49 +0200
> 
> > Thereʼs an effort underway already to port emacs to 'pure' gtk, which
> > allows running directly on Wayland. See eg
> > <https://github.com/fejfighter/emacs>.
> 
> I know, and the effort has been undergoing for years now. What I am
> saying is that this effort should be probably prioritized and effort
> should be put into removing barriers for it to land in Emacs as soon as
> possible.

What kind of prioritization did you have in mind?  We don't have
developers queuing up to take up development tasks, and we have no
means of telling someone to do some job and not the other.  Emacs
development is driven by volunteers doing what they want when they
want it and when they have time.  There's no real resource management
issue here, because the resources we have cannot be managed.

We can only say that some feature would be important to have -- and
we've done so in this case.  We've also provided what I think was
constructive feedback to the person who works on this particular issue
when he asked for it.  That is about all we can do.

Re: Implicit assumptions in the latest discussions

[Mingde (Matthew) Zeng]

> I don't think there can be any correlation between the number of users
> of Emacs and the number of hackers interesting in working on it.

I don't see why there isn't an correlation.

Cheers,
Matthew

--
Mingde (Matthew) Zeng

Re: Implicit assumptions in the latest discussions

[Emanuel Berg via Emacs development discussions.]

Daniele Nicolodi wrote:

> 2. Users are not drawn to try Emacs because what
>    Emacs is and for his reputation, but because
>    they expect Emacs to be like other editors.
>
> I think that who chooses Emacs, does so because of
> what Emacs is and what it has been in its long
> history, not because they expect something
> different. [...]

People really "expect" the way you describe?

I can only tell my experience.

I opened Emacs. The font lock, or syntax highlighting
as I'd call it at that point, looked cool.

I wanted to change a bunch of stuff, like
I always do. But unlike other software, with
a rudimentary config file - which is already awesome,
at that point - see my mpv stuff [1] - not that
I used mpv back then, if it was even around - ANYWAY
- I realized that Emacs didn't provide me with just
an .rc file where I could set a bunch of options that
it would parse, no, I was actually _programming_,
and in Lisp, which I considered cool (and still do).
The step from `setq's to `defun's, I don't know when
that happened, probably right away. I realized this
whole thing was an awesome window for my own
creativity. I didn't expect anything but realized
it instantly.

I've always been obsessed by tools: text editor or
revolving hole punch, it doesn't matter, I modify
them and spend time with them like other people do
their CD collections or whatever. (People don't
collect CDs anymore.)

I don't know what features or what is different with
modern editors or where they have the huge advantage.
What I saw before Emacs were idle, nano, notepad++,
Eclipse, Visual Studio, and a couple of others;
either they were super-simple (much, much too simple)
or they had the GUI/menu based style which I pretty
much came to programming because I _didn't_ like.

So if I expected anything, which I doubt,
I absolutely did not expect Emacs to be anything like
that. In fact, the more it _wasn't_ like that, the
more I'd like it...

Maybe today there are fundamentally different
editors, different compared to nano (simple), Emacs
(Emacs), and Eclipse (GUI/menu), and every other
editor I know. Yes, it would be interesting to have
a look at them...

But, instead of making Emacs more like them in
general, let's hear it, make a list of their three
killer features that they have, and we don't. We take
it from there :)


[1] https://dataswamp.org/~incal/conf/mpv/mpv.conf
    https://dataswamp.org/~incal/conf/mpv/input.conf

    BTW mpv is perhaps a poor example here because it
    is also extendible, with Lua.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal