From: Robert Pluim <rpluim@gmail.com>
To: Daniele Nicolodi <daniele@grinta.net>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Implicit assumptions in the latest discussions
Date: Thu, 17 Sep 2020 17:32:08 +0200 [thread overview]
Message-ID: <m27dss5shz.fsf@gmail.com> (raw)
In-Reply-To: <af35f13b-ec86-5f36-628c-cc4373fa02ca@grinta.net> (Daniele Nicolodi's message of "Thu, 17 Sep 2020 16:45:49 +0200")
>>>>> 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
next prev parent reply other threads:[~2020-09-17 15:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 13:30 Implicit assumptions in the latest discussions Daniele Nicolodi
2020-09-17 14:01 ` Robert Pluim
2020-09-17 14:45 ` Daniele Nicolodi
2020-09-17 15:04 ` Arthur Miller
2020-09-17 15:09 ` Daniel Martín
2020-09-17 15:29 ` Caio Henrique
2020-09-17 15:32 ` Robert Pluim [this message]
2020-09-17 17:41 ` Eli Zaretskii
2020-09-17 19:31 ` Mingde (Matthew) Zeng
2020-09-18 7:45 ` Emanuel Berg via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m27dss5shz.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=daniele@grinta.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.