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