* Implicit assumptions in the latest discussions
@ 2020-09-17 13:30 Daniele Nicolodi
2020-09-17 14:01 ` Robert Pluim
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Daniele Nicolodi @ 2020-09-17 13:30 UTC (permalink / raw
To: Emacs developers
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
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 19:31 ` Mingde (Matthew) Zeng
2020-09-18 7:45 ` Emanuel Berg via Emacs development discussions.
2 siblings, 1 reply; 10+ messages in thread
From: Robert Pluim @ 2020-09-17 14:01 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: Emacs developers
>>>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 14:01 ` Robert Pluim
@ 2020-09-17 14:45 ` Daniele Nicolodi
2020-09-17 15:04 ` Arthur Miller
` (4 more replies)
0 siblings, 5 replies; 10+ messages in thread
From: Daniele Nicolodi @ 2020-09-17 14:45 UTC (permalink / raw
To: Emacs developers
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 14:45 ` Daniele Nicolodi
@ 2020-09-17 15:04 ` Arthur Miller
2020-09-17 15:09 ` Daniel Martín
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Arthur Miller @ 2020-09-17 15:04 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: Emacs developers
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
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
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Daniel Martín @ 2020-09-17 15:09 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: Emacs developers
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"?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
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
2020-09-17 17:41 ` Eli Zaretskii
4 siblings, 0 replies; 10+ messages in thread
From: Caio Henrique @ 2020-09-17 15:29 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: Emacs developers
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 14:45 ` Daniele Nicolodi
` (2 preceding siblings ...)
2020-09-17 15:29 ` Caio Henrique
@ 2020-09-17 15:32 ` Robert Pluim
2020-09-17 17:41 ` Eli Zaretskii
4 siblings, 0 replies; 10+ messages in thread
From: Robert Pluim @ 2020-09-17 15:32 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: Emacs developers
>>>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 14:45 ` Daniele Nicolodi
` (3 preceding siblings ...)
2020-09-17 15:32 ` Robert Pluim
@ 2020-09-17 17:41 ` Eli Zaretskii
4 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-09-17 17:41 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 13:30 Implicit assumptions in the latest discussions Daniele Nicolodi
2020-09-17 14:01 ` Robert Pluim
@ 2020-09-17 19:31 ` Mingde (Matthew) Zeng
2020-09-18 7:45 ` Emanuel Berg via Emacs development discussions.
2 siblings, 0 replies; 10+ messages in thread
From: Mingde (Matthew) Zeng @ 2020-09-17 19:31 UTC (permalink / raw
To: Daniele Nicolodi; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Implicit assumptions in the latest discussions
2020-09-17 13:30 Implicit assumptions in the latest discussions Daniele Nicolodi
2020-09-17 14:01 ` Robert Pluim
2020-09-17 19:31 ` Mingde (Matthew) Zeng
@ 2020-09-18 7:45 ` Emanuel Berg via Emacs development discussions.
2 siblings, 0 replies; 10+ messages in thread
From: Emanuel Berg via Emacs development discussions. @ 2020-09-18 7:45 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-09-18 7:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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.
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.