"Why is emacs so square?"

"Why is emacs so square?"

[ndame]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

A user on reddit asked this once and he was not wrong, because
emacs does seem blocky compared to modern designs, which often employs
rounded corners, e.g for buttons:

https://www.webdesignerwall.com/wp-content/uploads/2010/04/button-preview.jpg

It could improve the square apperance if, for example, emacs provided some text
properties to specify rounded corners with custom radius for background colors.

[-- Attachment #2: Type: text/html, Size: 1601 bytes --]

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Perhaps we should implement a mode that puts cosmetics on Emacs
so it will appeal to those who judge by the surface of things.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[ndame]

>
> Perhaps we should implement a mode that puts cosmetics on Emacs
> so it will appeal to those who judge by the surface of things.
>

Visual impression matters. Often when I showed Emacs to people they commented on how dated it looks.

If Emacs' appearance can be improved by small things like providing support for rounded corners then it can be more appealing for people who care about visual appearance.

Re: "Why is emacs so square?"

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Perhaps we should implement a mode that puts cosmetics on Emacs

Is there any reason not to improve the default look?

> so it will appeal to those who judge by the surface of things.

I think it's unfortunate if we assume that this is all bells and
whistles.  Graphical design elements can also improve usability.

I also don't know that it's helpful to assume that the rest of the
world will take the enlightened stance.  For example, I've always
assumed that many people use Sublime Text not due to any serious
feature comparison with Emacs, but because they like its "sleek look".
I don't suggest that we should imitate proprietary junk editor <foo>,
but we should realize that these things are not wholly unimportant.

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[ndame]

> Richard Stallman rms@gnu.org writes:
>
> > Perhaps we should implement a mode that puts cosmetics on Emacs
>
> Is there any reason not to improve the default look?

When people say to me Emacs looks dated I often think the FSF should look for a graphics designer to improve the default appearance of Emacs.

Perhaps there are some who are sympatethic to the free software cause and they would do it even for free.

Re: "Why is emacs so square?"

[Emanuel Berg via Emacs development discussions.]

Stefan Kangas wrote:

> I also don't know that it's helpful to assume that the
> rest of the world will take the enlightened stance.
> For example, I've always assumed that many people use
> Sublime Text not due to any serious feature comparison
> with Emacs, but because they like its "sleek look".
> I don't suggest that we should imitate proprietary
> junk editor <foo>, but we should realize that these
> things are not wholly unimportant.

Tour de France/Giro d'Italia road race bikes look
stylish AND are fast.

UCI track cycling bikes look cool and futuristic AND
are fast.

etc etc

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

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Is there any reason not to improve the default look?

1. It will take work.

2. The code to interface Emacs to X-based GUIs needs rewriting by an
expert, and has needed it for decades.  Until it gets that rewrite,
changes in it are likely to break something.

3. We may not have any developers who are experts on that area
and capable of doing any changes well.

    > Graphical design elements can also improve usability.

I won't argue with that -- but I have a feeling that the changes
that would help are deeper issues than the shape of corners.

  >   For example, I've always
  > assumed that many people use Sublime Text not due to any serious
  > feature comparison with Emacs, but because they like its "sleek look".

Perhaps that is true.  Or perhaps its graphical interface is
substantively more natural than that of Emacs.  In Emacs, our
graphical interface is constrained by historical compatibility
and making it more natural is difficult.

Another question about them: are they among the segment of users for
whom the investment of learning Emacs would pay off?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 15 Apr 2020 22:30:20 -0400
> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> 
> Another question about them: are they among the segment of users for
> whom the investment of learning Emacs would pay off?

I don't really know the answer, but I'd like to remind all of us that
there's a lot of "propaganda" out there telling everyone to turn off
GUI features such as the menu bar and the tool bar.  The network is
full of personal init files that "proudly" do that, and forums like
Reddit are full of such advice to every newbie who asks about
configuring their Emacs.  It is hard to be enthusiastic about making
these features more modern when the community seems to be divided on
whether they should at all be present.  IMO, we should first get our
act together and decide whether these features are important, and then
speak up according to those decisions when we see advice to the
contrary.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

On 16/04/2020 01.28, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Wed, 15 Apr 2020 22:30:20 -0400
>> Cc: emacs-devel@gnu.org, ndame@protonmail.com
>>
>> Another question about them: are they among the segment of users for
>> whom the investment of learning Emacs would pay off?
> 
> I don't really know the answer, but I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.  It is hard to be enthusiastic about making
> these features more modern when the community seems to be divided on
> whether they should at all be present.  IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

That's a great point.  My personal config has the tool bar turned off.  Part of the reason is that with my desktop configuration (using a dark theme) the icons are unreadable (dark grey on a dark background, see attached screenshot), and part of the reason is that I didn't like the look of the icons in some of the (few) modes that use the tool-bar (e.g. in message-mode).  (Also, I seem to have a bug with the tool-bar: when I hover over the first two buttons it doesn't show a tooltip, but if I click on of them and close the file-selection dialog before hovering over the button again I do see a tooltip).

On the other hand, I have written some modes that override the user configuration and re-enable to tool-bar with mode-specific functions, and I haven't received complaints (see e.g. the attached screenshots).

Clément.

[-- Attachment #2: emacs-Q.png --]
[-- Type: image/png, Size: 24493 bytes --]

[-- Attachment #3: fstar-toolbar.png --]
[-- Type: image/png, Size: 18273 bytes --]

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-04-16, at 18:27, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:

> My personal config has the tool bar turned off.

Same here, though I would not force that to new users.  (Recommend,
perhaps.)

Interestingly, I am almost sure that the toolbar was turned off by
default when I started using Emacs (v18 or 19, I don't remember).  IIRC,
when after some upgrade the toolbar appeared, I turned it off at once.
Does that seem possible or is my memory wrong?

OTOH, I learned Emacs by first using the tutorial and then reading most
of the manual, so I probably have a rather atypical history wrt that.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Thu, 16 Apr 2020 20:26:54 +0200
> Cc: emacs-devel@gnu.org
> 
> Interestingly, I am almost sure that the toolbar was turned off by
> default when I started using Emacs (v18 or 19, I don't remember).

Emacs didn't have a tool bar before Emacs 21.1.

RE: "Why is emacs so square?"

[Drew Adams]

> Interestingly, I am almost sure that the toolbar was turned off by
> default when I started using Emacs (v18 or 19, I don't remember).

There was no tool-bar support till Emacs 21.

Re: "Why is emacs so square?"

[Bob Newell]

> I don't really know the answer, but I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.

Well, I certainly turn all that stuff off, but I've been using Emacs
for decades, and I'm comfortable enough now (and I also use Helm). In
earlier days I definitely made good use of the toolbar and menus. They
were not especially pretty (that didn't concern me), but they helped
me learn much more quickly.

I would, however, /never/ recommend to a newbie to turn off the menu
bar etc. You should only get to Emacs "minimalism" (a) after a long
enough time to be quite comfortable and (b) if it suits your style of
work.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>                                         IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

FWIW, I wrote up a bug report to the `better-defaults' package asking to
please keep them enabled:

https://github.com/technomancy/better-defaults/issues/37

I believe this blanket advice to disable the menu and tool bar should be
similarly discouraged whenever and wherever we can.  (EmacsWiki could be
a good place to start, and maybe some of the other "starter packs".)

Best regards,
Stefan Kangas

RE: "Why is emacs so square?"

[Drew Adams]

> FWIW, I wrote up a bug report to the `better-defaults' package asking
> to please keep [menu-bar and toolbar) enabled:
> 
> https://github.com/technomancy/better-defaults/issues/37
> 
> I believe this blanket advice to disable the menu and tool-bar should
> be similarly discouraged whenever and wherever we can.  (EmacsWiki could
> be a good place to start, and maybe some of the other "starter packs".)

I agree.

But I agree much more strongly wrt menu-bar.

Wrt the Emacs tool-bar, I think (so far) it's
mainly useful for one-off actions (e.g. click
a button to do something - no subsequent
tool-bar interaction).

That is, I'm not sure how often a tool-bar
user clicks tool-bar buttons/icons.  I kinda
doubt that someone does click-click-click on
icons.  I think it's more likely that a user
uses a particular icon fairly often, as a
shortcut to using a menu, than it is that a
user interacts frequently with multiple icons
on the tool-bar.  (I could be wrong.)

As a result of this assumption, I provide
library `tool-bar+.el', which lets you hide
the tool-bar, replacing it by just one menu-bar
pseudo-menu, `Buttons'.  Clicking that pops
up the tool-bar for the duration of one
interaction.  This is available using minor
mode `tool-bar-pop-up-mode'.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

(The same library offers an alternative,
minor mode `tool-bar-here-mode', which is the
same as the global `tool-bar-mode' except that
it affects only the current frame -- it saves
screen real estate on frames other than those
with a tool-bar.)

I think it would make sense for Emacs default
behavior to be similar to that you get by
turning on `tool-bar-pop-up-mode'.  Users would
soon enough discover `Buttons'.

One useful thing that could be added and might
be useful, which I haven't done, would be to
provide a button in every tool-bar, which
toggles the mode, e.g., turns it off, so the
tool-bar is shown by default, or turns it on,
so it is hidden by default and replaced by
pseudo-menu `Buttons'.

Re: "Why is emacs so square?"

[Jorge Javier Araya Navarro]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

El mié, 15-04-2020 a las 06:39 +0200, Stefan Kangas escribió:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Perhaps we should implement a mode that puts cosmetics on Emacs
> 
> Is there any reason not to improve the default look?
> 
> > so it will appeal to those who judge by the surface of things.
> 
> I think it's unfortunate if we assume that this is all bells and
> whistles.  Graphical design elements can also improve usability.
> 
> I also don't know that it's helpful to assume that the rest of the
> world will take the enlightened stance.  For example, I've always
> assumed that many people use Sublime Text not due to any serious
> feature comparison with Emacs, but because they like its "sleek
> look".
> I don't suggest that we should imitate proprietary junk editor <foo>,
> but we should realize that these things are not wholly unimportant.
> 
> Best regards,
> Stefan Kangas
> 

Allow me to interject: how modern does my Emacs looks (see attach)?
that is just using some packages available at MELPA (sad, I know;
ideally such cosmetic stuff should be available in ELPA and/or be ship
with new versions of Emacs and turned on by default).

[-- Attachment #2: Captura de pantalla de 2020-04-15 23-00-35.png --]
[-- Type: image/png, Size: 115021 bytes --]

Re: "Why is emacs so square?"

[Juri Linkov]

>> Perhaps we should implement a mode that puts cosmetics on Emacs
>
> Is there any reason not to improve the default look?

No reason indeed.  I started to implement rounded corners for tabs
by adding a new :style to :box face attribute with drawings implemented
like in x_draw_relief_rect but had no time to finish before the
emacs-27 pretest.  But it looks like a wrong approach anyway.

But when someone will properly implement rounded corners for buttons
they could be used for tabs as well.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 14 Apr 2020 23:00:48 -0400
> Cc: emacs-devel@gnu.org
> 
> Perhaps we should implement a mode that puts cosmetics on Emacs
> so it will appeal to those who judge by the surface of things.

I think if we had the code for making the corners round, we'd use it
more or less unconditionally.  But we don't have such code, AFAIK, so
patches to add such capabilities to Emacs are most welcome.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 15.04.2020 09:27, Eli Zaretskii wrote:
> I think if we had the code for making the corners round, we'd use it
> more or less unconditionally.  But we don't have such code, AFAIK, so
> patches to add such capabilities to Emacs are most welcome.

I think the difficulty here is to look "contemporary" and yet fit every 
platform Emacs is run on. Button widgets look different on each. Even 
between GUI toolkits. And change between releases.

The other option, of course, is to look both modern and unique, but it's 
a harder proposition, especially without a graphical designer on the 
team. And this stuff gets outdated quickly.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Apr 2020 17:17:31 +0300
> 
> On 15.04.2020 09:27, Eli Zaretskii wrote:
> > I think if we had the code for making the corners round, we'd use it
> > more or less unconditionally.  But we don't have such code, AFAIK, so
> > patches to add such capabilities to Emacs are most welcome.
> 
> I think the difficulty here is to look "contemporary" and yet fit every 
> platform Emacs is run on. Button widgets look different on each. Even 
> between GUI toolkits. And change between releases.

There are only 2 variants: native buttons (provided by some toolkit)
or the ones we draw ourselves.  And there's no requirement that they
all look the same, I think: they should have the look-and-feel of the
toolkit being used.

> The other option, of course, is to look both modern and unique, but it's 
> a harder proposition, especially without a graphical designer on the 
> team. And this stuff gets outdated quickly.

I think "modern and unique" is a contradiction of terms nowadays ;-)

Re: "Why is emacs so square?"

[Ulrich Mueller]

>>>>> On Wed, 15 Apr 2020, Eli Zaretskii wrote:

>> I think the difficulty here is to look "contemporary" and yet fit
>> every platform Emacs is run on. Button widgets look different on
>> each. Even between GUI toolkits. And change between releases.

> There are only 2 variants: native buttons (provided by some toolkit)
> or the ones we draw ourselves.  And there's no requirement that they
> all look the same, I think: they should have the look-and-feel of the
> toolkit being used.

Exactly, and I presume it would be somewhat hard to emulate the GTK+
look under Athena/Lucid or Motif. Also, what problem would it solve?

>> The other option, of course, is to look both modern and unique, but it's 
>> a harder proposition, especially without a graphical designer on the 
>> team. And this stuff gets outdated quickly.

> I think "modern and unique" is a contradiction of terms nowadays ;-)

"Modern" mostly means that everything looks like half-sucked candy.
Please resist that temptation. :-)

Re: "Why is emacs so square?"

[Alex Bennée]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Wed, 15 Apr 2020, Eli Zaretskii wrote:
>
>>> I think the difficulty here is to look "contemporary" and yet fit
>>> every platform Emacs is run on. Button widgets look different on
>>> each. Even between GUI toolkits. And change between releases.
>
>> There are only 2 variants: native buttons (provided by some toolkit)
>> or the ones we draw ourselves.  And there's no requirement that they
>> all look the same, I think: they should have the look-and-feel of the
>> toolkit being used.
>
> Exactly, and I presume it would be somewhat hard to emulate the GTK+
> look under Athena/Lucid or Motif. Also, what problem would it solve?

Surely unifying under a single cross-platform toolkit like GTK+ would
avoid having this complexity. I still run lucid because there is a long
term bug in the GTK engine which I don't understand but gets loudly
reported whenever you run it. I'm not sure if this is down to the
toolkit or the thunking Emacs has to do to have a common command loop
shared between it's GUI and terminal invocations?

>>> The other option, of course, is to look both modern and unique, but it's 
>>> a harder proposition, especially without a graphical designer on the 
>>> team. And this stuff gets outdated quickly.
>
>> I think "modern and unique" is a contradiction of terms nowadays ;-)
>
> "Modern" mostly means that everything looks like half-sucked candy.
> Please resist that temptation. :-)

There is a danger in assuming everybody wants their experience to be
like ours. My personal config may be fairly austere and minimalist but
we should aim for the out-of-the-box experience to look nice and be
intuitive for new users. I've been thinking about text editors for my
children to use as they graduate from point and click programming to
proper text and even I'm not sure I want their first experience to be
Emacs.

-- 
Alex Bennée

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Alex Bennée <alex.bennee@linaro.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 16 Apr 2020 11:14:21 +0100
> 
> > Exactly, and I presume it would be somewhat hard to emulate the GTK+
> > look under Athena/Lucid or Motif. Also, what problem would it solve?
> 
> Surely unifying under a single cross-platform toolkit like GTK+ would
> avoid having this complexity.

GTK+ is not cross-platform, it works only on some of the platforms we
support (and is not an easy toolkit to work with, based on our
experience).

> I still run lucid because there is a long term bug in the GTK engine
> which I don't understand but gets loudly reported whenever you run
> it. I'm not sure if this is down to the toolkit

This is because GTK+ has a bug that AFAIR they don't intend to fix
because they don't consider our use of GTK+ important enough (or
correct, for that matter).

> or the thunking Emacs has to do to have a common command loop shared
> between it's GUI and terminal invocations?

Not sure what thunking did you have in mind.  The handling of input in
Emacs should consider both GUI and TTY inputs, since otherwise you
will be unable to have both GUI and TTY frames in the same session,
and the likes of "emacsclient -t" won't work.

Closing displays GTK+ bug (was: "Why is emacs so square?")

[Ulrich Mueller]

>>>>> On Thu, 16 Apr 2020, Eli Zaretskii wrote:

>> I still run lucid because there is a long term bug in the GTK engine
>> which I don't understand but gets loudly reported whenever you run
>> it. I'm not sure if this is down to the toolkit

Same here.

> This is because GTK+ has a bug that AFAIR they don't intend to fix
> because they don't consider our use of GTK+ important enough (or
> correct, for that matter).

This is the state fo affairs for how long now? More than 10 years?
My guess would be that the GTK+ bug will never be fixed.

I just wonder if it wouldn't be consequent to make multi-tty features
and GTK+ mutually exclude each other. Alternatively, move to Qt instead
of GTK+ (though I can see the NIH argument there).

Re: Closing displays GTK+ bug (was: "Why is emacs so square?")

[Eli Zaretskii]

> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Alex Bennée <alex.bennee@linaro.org>,
>  emacs-devel@gnu.org
> Date: Thu, 16 Apr 2020 18:26:24 +0200
> 
> This is the state fo affairs for how long now? More than 10 years?
> My guess would be that the GTK+ bug will never be fixed.

My guess is the same.

> I just wonder if it wouldn't be consequent to make multi-tty features
> and GTK+ mutually exclude each other. Alternatively, move to Qt instead
> of GTK+ (though I can see the NIH argument there).

I doubt people will accept the former.  As for the latter: volunteers
are welcome, of course, but Qt is a C++ toolkit, which means another
non-trivial obstacle.

Re: Closing displays GTK+ bug (was: "Why is emacs so square?")

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Qt has a fatal flaw (from our point of view) -- it is released only
under GPL versions 2 and 3.  If we ever need to make a GPL version 4,
we will want to advance Emacs to GPL 4-or-later.  If we depended on Qt,
we would be blocked from upgrading the license version.  We must not
get into that difficulty.  

So we must avoid using Qt.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Closing displays GTK+ bug

[Ulrich Mueller]

>>>>> On Fri, 17 Apr 2020, Richard Stallman wrote:

> Qt has a fatal flaw (from our point of view) -- it is released only
> under GPL versions 2 and 3.  If we ever need to make a GPL version 4,
> we will want to advance Emacs to GPL 4-or-later.  If we depended on Qt,
> we would be blocked from upgrading the license version.  We must not
> get into that difficulty.  

> So we must avoid using Qt.

IIUC, only a few add-on components of Qt are licensed under the GPL.
Its core libraries are licensed under the LGPL, version 3.

Re: Closing displays GTK+ bug

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Its core libraries are licensed under the LGPL, version 3.

I was going by the information in Wikipedia, which said GPL 2 and 3.

LGPL 3-only has the same problem.  LGPL 3 is GPL 3 with some specific
extra permissions for linking with programs not under GPL 3.

Due to those extra permissions, linking Qt with GPL4-Emacs won't
violate the license of Qt.  But linking GPL4-Emacs with Qt would
violate the license of GPL4-Emacs, unless Qt qualifies as a "system
library".

If those Qt libraries are under LGPL 3-or-later, there will be no
problem.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[Adam Sjøgren via "Emacs development discussions.]

Inspired by the mention of the old GTK+-bug, I did a build of emacs like
this:

  ./configure --without-pop --with-cairo --without-dbus --with-x-toolkit=lucid && make bootstrap

And then I started Emacs on the machine:

  machine1:~$ /usr/src/emacs/src/emacs -Q --eval '(server-start)'

On another machine, I ssh'ed to the first machine, with X-forwarding
turned on, and started emacsclient:

  machine2:~$ ssh -X machine1
  machine1:~$ /usr/src/emacs/lib-src/emacsclient --create-frame /tmp/test.txt
  Waiting for Emacs...

And got an X frame displayed on the screen of machine2, as expected.

When I then end emacsclient with C-x # I'm back at the prompt. If I run
"exit", the prompt is hanging, where I would expect to be logged out of
machine1 and returned to machine2. Only after I press control-c do I get
the prompt back:

  machine1:~$ exit
  ^C
  machine2:~$ 

(When I press control-c, the message "Connection lost to X server
'localhost:10.0'" is displayed in the mini-buffer in the Emacs frame on
machine1.)

I thought this "hanging" was related to the display closing GTK+-bug,
but this is with lucid. At one point, I think, I read that it was a
dbus-related thing, but I also turned off dbus.

How do I avoid this hanging/having to press control-c?


  Best regards,

    Adam

-- 
 "I think grown-ups just act like they know what            Adam Sjøgren
  they're doing."                                      asjo@koldfront.dk

Re: Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[James Cloos]

>>>>> "Edd" == Emacs development discussions <Adam> writes:

Edd> When I then end emacsclient with C-x # I'm back at the prompt. If I run
Edd> "exit", the prompt is hanging, where I would expect to be logged out of
Edd> machine1 and returned to machine2. Only after I press control-c do I get
Edd> the prompt back:

lots of applications trigger that when forwarding x11 over openssh.

i'm not sure about other ssh implementations, but i've always suspected
a buglet in  ssh(1) or sshd(8).  or maybe in libx11?

perhaps some resource was stored in the x server and ssh holds the
forward open until it is released?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[Adam Sjøgren via "Emacs development discussions.]

James writes:

>>>>>> "Edd" == Emacs development discussions <Adam> writes:
>
> Edd> When I then end emacsclient with C-x # I'm back at the prompt. If I run
> Edd> "exit", the prompt is hanging, where I would expect to be logged out of
> Edd> machine1 and returned to machine2. Only after I press control-c do I get
> Edd> the prompt back:
>
> lots of applications trigger that when forwarding x11 over openssh.

Can you give some examples?

I can't think of any program I have seen the same thing happen with.

It is also uncommon to ssh to a machine, ask an already running program
to open a window on the remote screen, close the window and log out,
without quitting the entire program.

But that's of course exactly what I want to do with Emacs.

> perhaps some resource was stored in the x server and ssh holds the
> forward open until it is released?

Sounds likely, so I just need to figure out what it is and how to avoid
it ;-)

(Running emacsclient with nohup exhibits the problem, so it isn't as
simple as stdin/stdout/stderr.)


  Best rgards,

    Adam

-- 
 "It is a sort of cheap and cheerful kind of                Adam Sjøgren
  abstraction, but it works well in practise."         asjo@koldfront.dk

Re: Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[Robert Pluim]

>>>>> On Fri, 17 Apr 2020 18:06:13 +0200, "Adam Sjøgren via \"Emacs development discussions." <emacs-devel@gnu.org> said:

    Adam> James writes:
    >>>>>>> "Edd" == Emacs development discussions <Adam> writes:
    >> 
    Edd> When I then end emacsclient with C-x # I'm back at the prompt. If I run
    Edd> "exit", the prompt is hanging, where I would expect to be logged out of
    Edd> machine1 and returned to machine2. Only after I press control-c do I get
    Edd> the prompt back:
    >> 
    >> lots of applications trigger that when forwarding x11 over openssh.

    Adam> Can you give some examples?

    Adam> I can't think of any program I have seen the same thing happen with.

virt-manager triggers this for me. Even when Iʼve exited virt-manager.

    Adam> It is also uncommon to ssh to a machine, ask an already running program
    Adam> to open a window on the remote screen, close the window and log out,
    Adam> without quitting the entire program.

It is? I do that all the time :-)

    Adam> But that's of course exactly what I want to do with Emacs.

    >> perhaps some resource was stored in the x server and ssh holds the
    >> forward open until it is released?

    Adam> Sounds likely, so I just need to figure out what it is and how to avoid
    Adam> it ;-)

    Adam> (Running emacsclient with nohup exhibits the problem, so it isn't as
    Adam> simple as stdin/stdout/stderr.)

Hmm. Does 'disown' help?

Robert

Re: Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[Adam Sjøgren via "Emacs development discussions.]

Robert writes:

> Adam> I can't think of any program I have seen the same thing happen with.
>
> virt-manager triggers this for me. Even when Iʼve exited virt-manager.

Thanks for the example, I will see if I can reproduce it.

> Adam> It is also uncommon to ssh to a machine, ask an already running program
> Adam> to open a window on the remote screen, close the window and log out,
> Adam> without quitting the entire program.
>
> It is? I do that all the time :-)

With what other programs besides Emacs and virt-manager?

> Hmm. Does 'disown' help?

No, same behaviour.

>
> Robert
>
>

-- 
 "Python looks to me like the illegitimate spawn of         Adam Sjøgren
  C and BASIC, but then I used to program in 6502      asjo@koldfront.dk
  machine code so what do I know ..."

Re: Log out hanging after X-forwarded emacsclient [Was: Closing displays GTK+ bug]

[Robert Pluim]

>>>>> On Sat, 18 Apr 2020 19:20:26 +0200, "Adam Sjøgren via \"Emacs development discussions." <emacs-devel@gnu.org> said:
    Adam> It is also uncommon to ssh to a machine, ask an already running program
    Adam> to open a window on the remote screen, close the window and log out,
    Adam> without quitting the entire program.
    >> 
    >> It is? I do that all the time :-)

    Adam> With what other programs besides Emacs and virt-manager?

None. Everything else I use I can run locally.

Robert

Re: Log out hanging after X-forwarded emacsclient

[Adam Sjøgren via "Emacs development discussions.]

I wrote:

> When I then end emacsclient with C-x # I'm back at the prompt. If I run
> "exit", the prompt is hanging, where I would expect to be logged out of
> machine1 and returned to machine2. Only after I press control-c do I get
> the prompt back:

I spent last night tracking this down. The reason one has to press ^C to
stop ssh is that Emacs keeps the X-connection open. It is not a bug in
ssh, as far as I can tell.

This comment in src/xterm.c is no longer accurate:

  13402  /* This function is called when the last frame on a display is deleted. */
  13403  void
  13404  x_delete_terminal (struct terminal *terminal)
  13405  {

It doesn't get called when the last frame on a remote display is closed,
it is only called when the X connection is severed (i.e. by killing
ssh).

The reason is found in src/frame.c:

  2141      /* If needed, delete the terminal that this frame was on.
  2142         (This must be done after the frame is killed.)  */
  2143      terminal->reference_count--;
  2144  #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
  2145      /* FIXME: Deleting the terminal crashes emacs because of a GTK
  2146         bug.
  2147         https://lists.gnu.org/r/emacs-devel/2011-10/msg00363.html */
  2148
  2149      /* Since a similar behavior was observed on the Lucid and Motif
  2150         builds (see Bug#5802, Bug#21509, Bug#23499, Bug#27816), we now
  2151         don't delete the terminal for these builds either.  */
  2152      if (terminal->reference_count == 0 && terminal->type == output_x_window)
  2153        terminal->reference_count = 1;
  2154  #endif /* USE_X_TOOLKIT || USE_GTK */

With this Emacs doesn't actually call x_delete_terminal() when the last
frame on a display is closed, but rather waits until the X connection
disappears.

If I remove those two lines, a build with GTK crashes immediately when
the last frame on a remove display is closed (on purpose, to avoid the
endless warnings from Glib - "the GTK bug"), rather than when the X
connection is cut.

However, I can't reproduce the problem when I build Emacs with Lucid.
Closing all frames on a remote display doesn't result in a crash with
Lucid - and the prompt/ssh isn't hanging with L2152-2153 removed.

So a step towards fixing the GTK problem is to figure out whether the
"workaround" in src/frame.c is still needed for Lucid and Motif.

Ah, I've now read through the bugs referenced in the comment, and it
sounds like the problem that was handled by adding this doesn't happen
every time. When x_delete_terminal() gets called much less, the
described crashes are less likely to happen.

I guess it could be #ifdef'ed again, if the GTK problem is fixed.

Hm, ok. I just thought I would follow up on my question.


  Best regards,

    Adam

-- 
 "Kom låna törnekronan min                                  Adam Sjøgren
  Lid för konsten eller brinn"                         asjo@koldfront.dk

long-standing GTK bug (was: Log out hanging after X-forwarded emacsclient)

[andres.ramirez]

Hi Adam.

>>>>> "Adam" == Adam Sjøgren via \"Emacs development discussions <emacs-devel@gnu.org> writes:

[...]

    Adam> The reason is found in src/frame.c:

Which hints leads You from xterm.c to frame.c?

[...]

    Adam> However, I can't reproduce the problem when I build Emacs
    Adam> with Lucid.  Closing all frames on a remote display doesn't
    Adam> result in a crash with Lucid - and the prompt/ssh isn't
    Adam> hanging with L2152-2153 removed.

Next time I compile emacs. I am going to remove above lines for giving
it more testing. I use lucid toolkit.

    Adam> So a step towards fixing the GTK problem is to figure out
    Adam> whether the "workaround" in src/frame.c is still needed for
    Adam> Lucid and Motif.

I think the above could just improve user experience when using lucid
toolking combined with X-forwarding.

    Adam> Ah, I've now read through the bugs referenced in the
    Adam> comment, and it sounds like the problem that was handled by
    Adam> adding this doesn't happen every time. When
    Adam> x_delete_terminal() gets called much less, the described
    Adam> crashes are less likely to happen.

I have skimmed also the bugs referenced there. A lot of info and
situations. All of that cases would need retest.


[...]


    Adam> Hm, ok. I just thought I would follow up on my question.

Nice job. This bug affects a lot of emacs users. on 2016 I digged a
little bit on this bug aka "long-standing GTK bug". I still have my
notes from 2016. I even sketched a plan (I have never fullfilled):

Those were my conclusions from 2016:
--8<---------------cut here---------------start------------->8---
compile same source code for lucid, gtk, and nextstep
remove the abort calls {after checking all bug reports}
repeat that old gtk bug on gtk and nexstep {question is nextstep is immune as lucid}
research how was included the lucid port {get the git hash; why gtk is different from lucid}
the mac port could be useful? {macport suffers the same issue as gtk when used with x-forwarding}
--8<---------------cut here---------------end--------------->8---

Now on 2020. I would add to that list retest all cases found on frame.c
according to your email.

Best Regards

Re: long-standing GTK bug

[Adam Sjøgren via "Emacs development discussions.]

  Hi Andres,


andres.ramirez writes:

> Which hints leads You from xterm.c to frame.c?

I could not figure out why x_terminal_close() wasn't called when the
last frame on a display was closed, and that lead me to frame.c.

Took me a couple of evenings of adding a _lot_ of print-statements and
experimenting.

My original goal was to look into "the GTK bug", and this "^C
hanging"/X-connection not being closed fell out of it as a bonus.

>     Adam> Ah, I've now read through the bugs referenced in the
>     Adam> comment, and it sounds like the problem that was handled by
>     Adam> adding this doesn't happen every time. When
>     Adam> x_delete_terminal() gets called much less, the described
>     Adam> crashes are less likely to happen.
>
> I have skimmed also the bugs referenced there. A lot of info and
> situations. All of that cases would need retest.

I don't know that any of those bugs are resolved, but I think the
workaround was acknowledged to be just a workaround when it was added,
so if the problems with the scrollbars can be solved, I think the
workaround can be removed for Lucid/Motif builds.

> Nice job. This bug affects a lot of emacs users. on 2016 I digged a
> little bit on this bug aka "long-standing GTK bug".

While related, this is not "the GTK bug", nor does it resolve it.

If you remove the workaround in frame.c and remove the call to
emacs_abort() when using GTK in x_connection_closed() in xterm.c, and
the connection to a display is terminated while Emacs has a window on
that display, you'll still get an endless stream of warnings from GLib,
i.e. "the GTK bug".

I've tried updating the latest issue on this in the GTK GitLab, to see
if anyone has some clues:

 · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_795365

I haven't heard anything yet, and I would not be surprised if they still
are cross with the Emacs community.

Thanks for replying, I agree it would be really nice to get to the
bottom of this long standing issue.


  Best regards,

    Adam

-- 
 "Ett, två, tre, pang på rödbetan."                         Adam Sjøgren
                                                       asjo@koldfront.dk

Re: long-standing GTK bug

[Adam Sjøgren via "Emacs development discussions.]

I wrote:

> If you remove the workaround in frame.c and remove the call to
> emacs_abort() when using GTK in x_connection_closed() in xterm.c, and
> the connection to a display is terminated while Emacs has a window on
> that display, you'll still get an endless stream of warnings from GLib,
> i.e. "the GTK bug".

I have been looking further into it, and I think I now understand what
happens.

Emacs calls gtk_events_pending(), which then continues to
g_main_context_prepare(), in which a counter in the context structure,
in_check_or_prepare, is incremented to detect recursive calls to this
function in GLib.

Before the counter is decremented again, the X-connection disappears,
and X calls Emacs' error handler x_io_error_quitter().

The error handler closes the display¹, and Emacs then continues. But it
doesn't return to the place in g_main_context_prepare(), so the counter
isn't decremented.

When Emacs then calls gtk_events_pending() again, GLib looks at the
counter, and emits warnings about recursive calls.

At least that is what I think is happening - gleaned from adding a
breakpoint to delete_frame() and staring at this backtrace and the code
in GLib²:

  #0  delete_frame (frame=0x555556183ba5, force=force@entry=0xa170) at frame.c:1902
  #1  0x000055555559707e in x_connection_closed (dpy=dpy@entry=0x555556c58590, error_message=<optimized out>, 
      error_message@entry=0x7fffffffcf40 "Connection lost to X server 'localhost:10.0'", ioerror=ioerror@entry=true) at lisp.h:1042
  #2  0x00005555555971a9 in x_io_error_quitter (display=0x555556c58590) at xterm.c:10180
  #3  0x00007ffff6aac20e in _XIOError () at /lib/x86_64-linux-gnu/libX11.so.6
  #4  0x00007ffff6aa9985 in _XEventsQueued () at /lib/x86_64-linux-gnu/libX11.so.6
  #5  0x00007ffff6a9b511 in XPending () at /lib/x86_64-linux-gnu/libX11.so.6
  #6  0x00007ffff7435b6f in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
  #7  0x00007ffff6e1fd7f in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #8  0x00007ffff6e2072b in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #9  0x00007ffff6e208c8 in g_main_context_pending () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #10 0x00007ffff7708f0e in gtk_events_pending () at /lib/x86_64-linux-gnu/libgtk-3.so.0
  #11 0x000055555564c97d in XTread_socket (terminal=<optimized out>, hold_quit=0x7fffffffd200) at xterm.c:9398

To test my interpretation, I decided to decrement the counter in the
context structure from inside x_connection_closed(), by adding:

        GMainContext *context;
        context = g_main_context_default();
        // Try resetting recursion prevention counter:
        context->in_check_or_prepare = 0;

before calling gdk_display_close() on the display that has disappeared³.

This makes the endless stream of warnings not appear!

However, my quick test required me to copy the struct _GMainContext
definition from glib/gmain.c into xterm.c, which is not the correct way
to go about this, I'm sure.

I do feel that this is progress, though. Now we just need to figure out
the right way to handle it.

If that is for gdk_display_close() to reset the in_check_or_prepare
counter, or if it is something that can be changed in Emacs, I don't
know.

I have updated the current GTK issue⁴ with my observations, but I'm
hoping for some input from emacs-devel as well.


  Best regards,

    Adam


¹ If you change it from calling emacs_abort() to close the display, as I
  have, that is.

² https://github.com/GNOME/glib/blob/mainline/glib/gmain.c#L3530

³ https://koldfront.dk/git/emacs/commit/?h=scratch/gtk-x-disconnect&id=94eea826b6aa69ecf94301b4da251059dc89212b

⁴ https://gitlab.gnome.org/GNOME/gtk/-/issues/2315

-- 
 "When you grow up, it's not allowed."                      Adam Sjøgren
 "All the more reason I should do it *now*!"           asjo@koldfront.dk

Re: long-standing GTK bug

[Adam Porter]

"Adam Sjøgren via \"Emacs development discussions."
<emacs-devel@gnu.org> writes:

> I wrote:
>
>> If you remove the workaround in frame.c and remove the call to
>> emacs_abort() when using GTK in x_connection_closed() in xterm.c, and
>> the connection to a display is terminated while Emacs has a window on
>> that display, you'll still get an endless stream of warnings from GLib,
>> i.e. "the GTK bug".
>
> I have been looking further into it, and I think I now understand what
> happens.

Please forgive the noise, I just want to say thank you for your work on
this issue.

Re: long-standing GTK bug

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please forgive me for taking so long to respond.  I am  backlogged
500 messages I have not yet seen.  I just saw your message today.

  > > If you remove the workaround in frame.c and remove the call to
  > > emacs_abort() when using GTK in x_connection_closed() in xterm.c, and
  > > the connection to a display is terminated while Emacs has a window on
  > > that display, you'll still get an endless stream of warnings from GLib,
  > > i.e. "the GTK bug".

  > I have been looking further into it, and I think I now understand what
  > happens.

Ideally the GTK developers would fix this.  Apparently a long time has
gone by and they have not done so.  I suppose there is a reason why.
Does anyone know what it is?
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: long-standing GTK bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 08 Jun 2020 22:37:56 -0400
> Cc: emacs-devel@gnu.org
> 
>   > > If you remove the workaround in frame.c and remove the call to
>   > > emacs_abort() when using GTK in x_connection_closed() in xterm.c, and
>   > > the connection to a display is terminated while Emacs has a window on
>   > > that display, you'll still get an endless stream of warnings from GLib,
>   > > i.e. "the GTK bug".
> 
>   > I have been looking further into it, and I think I now understand what
>   > happens.
> 
> Ideally the GTK developers would fix this.  Apparently a long time has
> gone by and they have not done so.  I suppose there is a reason why.
> Does anyone know what it is?

AFAIU, they concluded that Emacs doesn't use GTK as a well-behaving
GTK application should, and so they decided not to fix this problem.

Re: long-standing GTK bug

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Ideally the GTK developers would fix this.  Apparently a long time has
  > > gone by and they have not done so.  I suppose there is a reason why.
  > > Does anyone know what it is?

  > AFAIU, they concluded that Emacs doesn't use GTK as a well-behaving
  > GTK application should, and so they decided not to fix this problem.

Did they say how a well-behaved program would do this job?
If there a way Emacs could do that?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: long-standing GTK bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: asjo@koldfront.dk, emacs-devel@gnu.org
> Date: Tue, 09 Jun 2020 20:53:42 -0400
> 
>   > AFAIU, they concluded that Emacs doesn't use GTK as a well-behaving
>   > GTK application should, and so they decided not to fix this problem.
> 
> Did they say how a well-behaved program would do this job?

I believe that should be quite clear to someone who is familiar with
how GTK applications should be written.  (I'm not one of those
experts.)

> If there a way Emacs could do that?

I think someone is working on an Emacs configuration that will support
only GTK, and that configuration should then be able to do that.

Re: long-standing GTK bug

[Adam Sjøgren]

A long time ago (Wed, 10 Jun 2020), Eli wrote:

> I think someone is working on an Emacs configuration that will support
> only GTK, and that configuration should then be able to do that.

I was intrigued by this, and today checked out the feature/pgtk branch
and compiled Emacs --with-pgtk.

The branch still retains the X connection after the last window is
closed on a second computer, and terminating the ssh-connection with ^C
terminates Emacs.

I.e. what I talked about here:

 · https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01353.html

However, if I remove the workaround - the if() that sets
terminal->reference_count to 1 in frame.c - and connect to a running
pure GTK Emacs from a different computer displaying a remote X window
using emacsclient, and then close it, Emacs keeps running on the
original screen and GTK does not spew an endless list of warnings.

So the original long standing GTK problem¹ is indeed solved by the pure
GTK branch.


  \o/,

   Adam


¹ https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg02298.html
  https://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00927.html

-- 
 "Ge mig en vinterdrog, ge mig allt du har                  Adam Sjøgren
  Kom nu jag är kroniskt låg, bara mörkret hörs"       asjo@koldfront.dk

Re: long-standing GTK bug

[Robert Pluim]

>>>>> On Sat, 08 May 2021 13:51:30 +0200, Adam Sjøgren <asjo@koldfront.dk> said:

    Adam> A long time ago (Wed, 10 Jun 2020), Eli wrote:
    >> I think someone is working on an Emacs configuration that will support
    >> only GTK, and that configuration should then be able to do that.

    Adam> I was intrigued by this, and today checked out the feature/pgtk branch
    Adam> and compiled Emacs --with-pgtk.

    Adam> The branch still retains the X connection after the last window is
    Adam> closed on a second computer, and terminating the ssh-connection with ^C
    Adam> terminates Emacs.

    Adam> I.e. what I talked about here:

    Adam>  · https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01353.html

    Adam> However, if I remove the workaround - the if() that sets
    terminal-> reference_count to 1 in frame.c - and connect to a running
    Adam> pure GTK Emacs from a different computer displaying a remote X window
    Adam> using emacsclient, and then close it, Emacs keeps running on the
    Adam> original screen and GTK does not spew an endless list of warnings.

    Adam> So the original long standing GTK problem¹ is indeed solved by the pure
    Adam> GTK branch.

Interesting, but ENOPATCH :-)

(thereʼs a separate test that needs doing using waypipe rather than
ssh X forwarding. I think that one causes an abort somewhere inside
GTK)

Robert
-- 

Re: long-standing GTK bug

[Adam Sjøgren]

Robert writes:

> Interesting, but ENOPATCH :-)

I don't know what the preferred way to go about this is, but here is
one:


Skip "keep terminal open"-workaround for pure GTK

---
 src/frame.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/frame.c b/src/frame.c
index eb5aed82f7..8fdef3941d 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2183,7 +2183,7 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
     /* If needed, delete the terminal that this frame was on.
        (This must be done after the frame is killed.)  */
     terminal->reference_count--;
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
+#if defined (USE_X_TOOLKIT) || defined (USE_GTK) && ! defined (HAVE_PGTK)
     /* FIXME: Deleting the terminal crashes emacs because of a GTK
        bug.
        https://lists.gnu.org/r/emacs-devel/2011-10/msg00363.html */
@@ -2194,7 +2194,7 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
     if (terminal->reference_count == 0 &&
 	(terminal->type == output_x_window || terminal->type == output_pgtk))
       terminal->reference_count = 1;
-#endif /* USE_X_TOOLKIT || USE_GTK */
+#endif /* USE_X_TOOLKIT || USE_GTK && ! HAVE_PGTK */
     if (terminal->reference_count == 0)
       {
 	Lisp_Object tmp;


> (thereʼs a separate test that needs doing using waypipe rather than
> ssh X forwarding. I think that one causes an abort somewhere inside
> GTK)

(I haven't tried Wayland yet, so I have no information on that.)


  Best regards,

    Adam

-- 
 "Someone said ``look, it's Milli Vanilli!'' but            Adam Sjøgren
  that's totally unfair to Milli Vanilli: at least     asjo@koldfront.dk
  they danced."

Re: long-standing GTK bug

[Robert Pluim]

>>>>> On Sun, 09 May 2021 17:11:58 +0200, Adam Sjøgren <asjo@koldfront.dk> said:

    Adam> Robert writes:
    >> Interesting, but ENOPATCH :-)

    Adam> I don't know what the preferred way to go about this is, but here is
    Adam> one:

    Adam> Skip "keep terminal open"-workaround for pure GTK

That makes things work for me if I C-c the ssh connection, but if I
kill the ssh process, emacs still exits because itʼs crashing
somewhere in the depths of GTK:

(gdb) bt
#0  __GI__exit (status=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1  0x00007ffff7766e98 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#2  0x00007ffff59046cf in _XIOError () at /lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007ffff5901d95 in _XEventsQueued () at /lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007ffff58f37e1 in XPending () at /lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff77613ef in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007ffff715657f in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff7156fdb in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007ffff7157178 in g_main_context_pending () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x000055555574e1d0 in pgtk_select
    (fds_lim=<optimized out>, rfds=rfds@entry=0x7fffffffd520, wfds=wfds@entry=0x7fffffffd5a0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd410, sigmask=sigmask@entry=0x0) at pgtkterm.c:4052

Robert
-- 

Re: long-standing GTK bug

[Adam Sjøgren]

Robert writes:

> That makes things work for me if I C-c the ssh connection,

If you have to C-c the ssh connection, the patch is not doing what it is
supposed to, so either you or I messed up.

Or maybe I'm not explaining what I'm doing expliclitly enough: I have
only tested "the happy path", i.e. closing the frame on the remote
screen and closing the ssh connection (with "exit" or C-d). The latter
hangs without this patch, and C-c'ing it crashes Emacs.

I haven't tested what happens if the connection is cut before the frame
is closed. (Also relevant, of course, but one step at a time.)


  Best regards,

    Adam

-- 
 "If not actually disgruntled, he was far from being        Adam Sjøgren
  gruntled."                                           asjo@koldfront.dk

Re: long-standing GTK bug

[Robert Pluim]

>>>>> On Mon, 10 May 2021 12:00:49 +0200, Adam Sjøgren <asjo@koldfront.dk> said:

    Adam> Robert writes:
    >> That makes things work for me if I C-c the ssh connection,

    Adam> If you have to C-c the ssh connection, the patch is not doing what it is
    Adam> supposed to, so either you or I messed up.

    Adam> Or maybe I'm not explaining what I'm doing expliclitly enough: I have
    Adam> only tested "the happy path", i.e. closing the frame on the remote
    Adam> screen and closing the ssh connection (with "exit" or C-d). The latter
    Adam> hangs without this patch, and C-c'ing it crashes Emacs.

    Adam> I haven't tested what happens if the connection is cut before the frame
    Adam> is closed. (Also relevant, of course, but one step at a time.)

I think weʼre testing different things. Iʼm doing:

1. On A: start emacs, run a server
2. On B: ssh -X A, emacsclient -c
3. On B: kill the ssh process
4. Emacs crashes

If in step 3 I C-c the connection, then with your patch Emacs
survives.

Robert
-- 

Re: long-standing GTK bug

[Adam Sjøgren]

Robert writes:

> I think weʼre testing different things. Iʼm doing:
>
> 1. On A: start emacs, run a server
> 2. On B: ssh -X A, emacsclient -c
> 3. On B: kill the ssh process
> 4. Emacs crashes

Yes, indeed we are. I am diverging:

 3. On B: close the emacsclient frame
 4. On B: exit ssh
 5. Emacs survives.

Without the patch, after (my) step 4 the prompt isn't returned until you
press ^C in the shell, and when you do press ^C, Emacs crashes.


  Best regards,

    Adam

-- 
 "Det er ikke en kritik, det er bare en                     Adam Sjøgren
  konstatering."                                       asjo@koldfront.dk

Re: long-standing GTK bug

[Óscar Fuentes]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Robert writes:
>
>> I think weʼre testing different things. Iʼm doing:
>>
>> 1. On A: start emacs, run a server
>> 2. On B: ssh -X A, emacsclient -c
>> 3. On B: kill the ssh process
>> 4. Emacs crashes
>
> Yes, indeed we are. I am diverging:
>
>  3. On B: close the emacsclient frame
>  4. On B: exit ssh
>  5. Emacs survives.
>
> Without the patch, after (my) step 4 the prompt isn't returned until you
> press ^C in the shell, and when you do press ^C, Emacs crashes.

IIUC your patch solves the problem when the network connection is
reliable, but Emacs still crashes if there is an abrupt disconnection.

Looks like an improvement :-)

Re: long-standing GTK bug

[Stefan Monnier]

Óscar Fuentes [2021-05-10 16:13:43] wrote:
> Adam Sjøgren <asjo@koldfront.dk> writes:
>> Robert writes:
>>
>>> I think weʼre testing different things. Iʼm doing:
>>>
>>> 1. On A: start emacs, run a server
>>> 2. On B: ssh -X A, emacsclient -c
>>> 3. On B: kill the ssh process
>>> 4. Emacs crashes
>>
>> Yes, indeed we are. I am diverging:
>>
>>  3. On B: close the emacsclient frame
>>  4. On B: exit ssh
>>  5. Emacs survives.
>>
>> Without the patch, after (my) step 4 the prompt isn't returned until you
>> press ^C in the shell, and when you do press ^C, Emacs crashes.
>
> IIUC your patch solves the problem when the network connection is
> reliable, but Emacs still crashes if there is an abrupt disconnection.

IIUC the difference (with the patch) is between stopping ssh via `C-c` or
via `kill`.  I wonder why this matters, and I think it's not at all
obvious if an "abrupt" network disconnection would be more like `C-c` or
more like `kill`.


        Stefan

Re: long-standing GTK bug

[Robert Pluim]

>>>>> On Mon, 10 May 2021 10:40:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> IIUC the difference (with the patch) is between stopping ssh via `C-c` or
    Stefan> via `kill`.  I wonder why this matters, and I think it's not at all
    Stefan> obvious if an "abrupt" network disconnection would be more like `C-c` or
    Stefan> more like `kill`.

In the 'C-c' case Emacs has had a chance to clean up its internal
state (with the patch applied). With 'kill' weʼre pulling the rug out
from under GTK (see the backtrace several messages up-thread).

Robert
-- 

Re: long-standing GTK bug

[Stefan Monnier]

Robert Pluim [2021-05-10 16:45:05] wrote:
>>>>>> On Mon, 10 May 2021 10:40:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
>     Stefan> IIUC the difference (with the patch) is between stopping ssh via `C-c` or
>     Stefan> via `kill`.  I wonder why this matters, and I think it's not at all
>     Stefan> obvious if an "abrupt" network disconnection would be more like `C-c` or
>     Stefan> more like `kill`.
> In the 'C-c' case Emacs has had a chance to clean up its internal
> state (with the patch applied).

Why?  What does ssh do that is gentler?

> With 'kill' weʼre pulling the rug out from under GTK (see the
> backtrace several messages up-thread).

I suspect it then also depends on the `kill` signal.

In my WM (ctwm), I can also distinguish between `f.delete` and
`f.destroy` where the first sends something like a WM_DELETE request to
the application (which Emacs treats via `handle-delete-frame`, IIRC)
whereas `f.destroy` asks the X server to cut the connection AFAIK.

Would `f.destroy` be more like the `C-c` or the `kill` case of ssh?


        Stefan

Re: long-standing GTK bug

[Robert Pluim]

>>>>> On Mon, 10 May 2021 11:00:08 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Robert Pluim [2021-05-10 16:45:05] wrote:
    >>>>>>> On Mon, 10 May 2021 10:40:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
    Stefan> IIUC the difference (with the patch) is between stopping ssh via `C-c` or
    Stefan> via `kill`.  I wonder why this matters, and I think it's not at all
    Stefan> obvious if an "abrupt" network disconnection would be more like `C-c` or
    Stefan> more like `kill`.
    >> In the 'C-c' case Emacs has had a chance to clean up its internal
    >> state (with the patch applied).

    Stefan> Why?  What does ssh do that is gentler?

I assume itʼs just shutting down the X forwarding connection
gracefully. Since that doesnʼt result in Emacs losing its existing
local display connection, thereʼs no crash.

    >> With 'kill' weʼre pulling the rug out from under GTK (see the
    >> backtrace several messages up-thread).

    Stefan> I suspect it then also depends on the `kill` signal.

    Stefan> In my WM (ctwm), I can also distinguish between `f.delete` and
    Stefan> `f.destroy` where the first sends something like a WM_DELETE request to
    Stefan> the application (which Emacs treats via `handle-delete-frame`, IIRC)
    Stefan> whereas `f.destroy` asks the X server to cut the connection AFAIK.

    Stefan> Would `f.destroy` be more like the `C-c` or the `kill` case of ssh?

I suspect like 'kill'.

Robert
-- 

Re: long-standing GTK bug

[황병희]

Hellow Adam ^^^

Adam Sjøgren <asjo@koldfront.dk> writes:

> ...
> So the original long standing GTK problem¹ is indeed solved by the pure
> GTK branch.

(Actually i'm not techinal man) anyway that is real good news!!!

Sincerely, Wayland fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: long-standing GTK bug

[Adam Sjøgren]

You may recall that around 92 weeks ago I wrote:

> However, my quick test required me to copy the struct _GMainContext
> definition from glib/gmain.c into xterm.c, which is not the correct way
> to go about this, I'm sure.
>
> I do feel that this is progress, though. Now we just need to figure out
> the right way to handle it.
>
> If that is for gdk_display_close() to reset the in_check_or_prepare
> counter, or if it is something that can be changed in Emacs, I don't
> know.
>
> I have updated the current GTK issue⁴ with my observations, but I'm
> hoping for some input from emacs-devel as well.

A recent blog post:
https://tychoish.com/post/the-emacs-daemon-gtk-bug-a-parable/ made me
aware of the continued discussion that happened on the GTK issue 11
months ago, which I had previously missed.

A very interesting comment is this one by Michel Dänzer:

    FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing
    X11 client window decorations) is able to survive Xwayland dying
    abruptly, using the new XSetIOErrorExitHandler API (which removes
    the need for longjmp hacks) available as of libX11 1.7.0.

     · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481

Which sounds like exactly what is needed, doesn't it?

Switch from using the current XIOErrorHandler to the "new"
XSetIOErrorExitHandler API to avoid the longjmp and the sketchy patchy
hackery I ended up with.

This API is available in libX11 1.7.0 - I just checked the version in
Debian stable, and it is 1.7.2, so it's not some outrageously new
bleeding edge addition.

Now we just need someone with libX11 API chops to start ... eh,
chopping!


  11 years down the line, feeling optimistic,

    Adam

-- 
 "Jeg er som en pære når jeg springer og mister min         Adam Sjøgren
  fatning!"                                            asjo@koldfront.dk

Re: long-standing GTK bug

[Po Lu]

Adam Sjøgren <asjo@koldfront.dk> writes:

> A recent blog post:
> https://tychoish.com/post/the-emacs-daemon-gtk-bug-a-parable/ made me
> aware of the continued discussion that happened on the GTK issue 11
> months ago, which I had previously missed.
>
> A very interesting comment is this one by Michel Dänzer:
>
>     FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing
>     X11 client window decorations) is able to survive Xwayland dying
>     abruptly, using the new XSetIOErrorExitHandler API (which removes
>     the need for longjmp hacks) available as of libX11 1.7.0.
>
>      · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481
>
> Which sounds like exactly what is needed, doesn't it?
>
> Switch from using the current XIOErrorHandler to the "new"
> XSetIOErrorExitHandler API to avoid the longjmp and the sketchy patchy
> hackery I ended up with.
>
> This API is available in libX11 1.7.0 - I just checked the version in
> Debian stable, and it is 1.7.2, so it's not some outrageously new
> bleeding edge addition.
>
> Now we just need someone with libX11 API chops to start ... eh,
> chopping!

It doesn't work.  The part of Mutter that inherited from Metacity is
special in how it uses GTK for various reasons, so it works for them.

The call to longjmp is not the problem.  Rather, it was the original
workaround.  Removing the longjmp will just make GTK call _exit upon an
IO error, which we cannot avoid.  (See for example the
`_gdk_x11_display_error_event' function in the GTK source code.)

Thanks.

Re: long-standing GTK bug

[Madhu]

* Po Lu <871qzktpd8.fsf @yahoo.com> :
Wrote on Wed, 02 Mar 2022 22:12:35 +0800:
> Adam Sjøgren <asjo @koldfront.dk> writes:
>
>> A recent blog post:
>> https://tychoish.com/post/the-emacs-daemon-gtk-bug-a-parable/ made
>> me aware of the continued discussion that happened on the GTK issue
>> 11 months ago, which I had previously missed.
>> A very interesting comment is this one by Michel Dänzer:
>> FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing
>> X11 client window decorations) is able to survive Xwayland dying
>> abruptly, using the new XSetIOErrorExitHandler API (which removes
>> the need for longjmp hacks) available as of libX11 1.7.0.
>> · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481
>> Which sounds like exactly what is needed, doesn't it?
>> Switch from using the current XIOErrorHandler to the "new"
>> XSetIOErrorExitHandler API to avoid the longjmp and the sketchy
>> patchy hackery I ended up with.
>> This API is available in libX11 1.7.0 - I just checked the version
>> in Debian stable, and it is 1.7.2, so it's not some outrageously new
>> bleeding edge addition.
>> Now we just need someone with libX11 API chops to start ... eh,
>> chopping!
>
> It doesn't work.  The part of Mutter that inherited from Metacity is
> special in how it uses GTK for various reasons, so it works for them.
>
> The call to longjmp is not the problem.  Rather, it was the original
> workaround.  Removing the longjmp will just make GTK call _exit upon
> an IO error, which we cannot avoid.  (See for example the
> `_gdk_x11_display_error_event' function in the GTK source code.)

I tried to do a proof of concept using XSetIOErrorExitHandler to prove
it was possible to kill the display and still have a gtk app running.

https://gitlab.gnome.org/enometh/simple4/-/raw/master/simple.c

which seemed to work. the code is a bit crufty as it includes the
longjmp path , and i have to reread it to understand it and my headaches
are interfering with thinking. When i checked there was some other snag
in moving this to emacs

Re: long-standing GTK bug

[Po Lu]

Madhu <enometh@meer.net> writes:

> I tried to do a proof of concept using XSetIOErrorExitHandler to prove
> it was possible to kill the display and still have a gtk app running.
>
> https://gitlab.gnome.org/enometh/simple4/-/raw/master/simple.c
>
> which seemed to work. the code is a bit crufty as it includes the
> longjmp path , and i have to reread it to understand it and my headaches
> are interfering with thinking. When i checked there was some other snag
> in moving this to emacs

    Display *dpy = gdk_x11_display_get_xdisplay(gdpy);
    XSetIOErrorExitHandler (dpy, x_io_error_exit_handler, &done);

=>  window = gtk_window_new ();
    gtk_window_set_title (GTK_WINDOW (window), "hello world");

Judging by the absence of arguments to `gtk_window_new', this code is
for GTK 4, correct?

The X and GTK configuration will never work with GTK 4 due to other
fundamental changes in the toolkit, and PGTK will not be able to access
X-specific APIs.

Thanks.

Re: long-standing GTK bug

[Madhu]

*  Po Lu <luangruo@yahoo.com> <87pmn3sdpm.fsf@yahoo.com>
Wrote on Thu, 03 Mar 2022 15:21:57 +0800
> Madhu <enometh@meer.net> writes:
>> I tried to do a proof of concept using XSetIOErrorExitHandler to
>> prove it was possible to kill the display and still have a gtk app
>> running.
>> https://gitlab.gnome.org/enometh/simple4/-/raw/master/simple.c
>> which seemed to work. the code is a bit crufty as it includes the
>> longjmp path , and i have to reread it to understand it and my
>> headaches are interfering with thinking. When i checked there was
>> some other snag in moving this to emacs
>
>     Display *dpy = gdk_x11_display_get_xdisplay(gdpy);
>     XSetIOErrorExitHandler (dpy, x_io_error_exit_handler, &done);
>
> =>  window = gtk_window_new ();
>     gtk_window_set_title (GTK_WINDOW (window), "hello world");
>
> Judging by the absence of arguments to `gtk_window_new', this code is
> for GTK 4, correct?
>
> The X and GTK configuration will never work with GTK 4 due to other
> fundamental changes in the toolkit, and PGTK will not be able to access
> X-specific APIs.

All very sad, yes.

I've pushed a version of the sample code which should compile and run
with gtk+-3.0 - maybe you could take a look.

Re: long-standing GTK bug

[Po Lu]

Madhu <enometh@meer.net> writes:

> I've pushed a version of the sample code which should compile and run
> with gtk+-3.0 - maybe you could take a look.

Could you adapt that code to open two different displays?  AFAICT, it
only tries to open a single display, which isn't the scenario in Emacs.

Thanks.

Re: long-standing GTK bug

[Madhu]

* Po Lu <87k0dbs5vh.fsf @yahoo.com> :
Wrote on Thu, 03 Mar 2022 18:11:14 +0800:
> Could you adapt that code to open two different displays?  AFAICT, it
> only tries to open a single display, which isn't the scenario in
> Emacs.

more cruft pushed. you can echo :2.0 > /dev/shm/display before trying to
retry connection to a display to change it.

However I think the overall approach isn't feasible for emacs: this
approach depends on gdk_close_display to clean up and remove any
GSources. i think the mainloop crashed elsewhere when some other gsource
fired - i don't have my test code and have to do it again maybe later
this week.

Re: long-standing GTK bug

[Po Lu]

Madhu <enometh@meer.net> writes:

> However I think the overall approach isn't feasible for emacs: this
> approach depends on gdk_close_display to clean up and remove any
> GSources.

Thanks.  That sounds a little closer to what I experienced trying to
work around the problem as well.

> i think the mainloop crashed elsewhere when some other gsource fired -
> i don't have my test code and have to do it again maybe later this
> week.

I look forward to your results.

Re: long-standing GTK bug

[Madhu]

* Po Lu <87fsnzrxtq.fsf@yahoo.com> :
Wrote on Thu, 03 Mar 2022 21:05:05 +0800:

> Madhu <enometh@meer.net> writes:
>> i think the mainloop crashed elsewhere when some other gsource fired
>> - i don't have my test code and have to do it again maybe later this
>> week.
>
> I look forward to your results.

I see I had misunderstood what you had said about multiple displays. The
simple.c code assumes there is only one display at a time. I'll try to
handle multiple displays and one display dying first.

Re: long-standing GTK bug

[Lars Ingebrigtsen]

Madhu <enometh@meer.net> writes:

> However I think the overall approach isn't feasible for emacs: this
> approach depends on gdk_close_display to clean up and remove any
> GSources.

And is it impossible for Emacs to rely on that?  (I know nothing of the
code in this area, but it'd be wonderful if we finally could work around
these Gtk problems.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: long-standing GTK bug

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And is it impossible for Emacs to rely on that?  (I know nothing of the
> code in this area, but it'd be wonderful if we finally could work around
> these Gtk problems.)

I think what he's saying is that `gdk_display_close' doesn't remove the
installed event sources upon disposal, which is similar to what I
experienced trying to fix the problem in GTK itself.

It seems that something in GTK keeps holding a reference to the display,
but I didn't figure out what that was.

Re: long-standing GTK bug

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I think what he's saying is that `gdk_display_close' doesn't remove the
> installed event sources upon disposal, which is similar to what I
> experienced trying to fix the problem in GTK itself.
>
> It seems that something in GTK keeps holding a reference to the display,
> but I didn't figure out what that was.

Ah, I see.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Log out hanging after X-forwarded emacsclient

[Thomas Fitzsimmons]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Hi Adam,

"Adam Sjøgren <asjo@koldfront.dk>" writes:

> Inspired by the mention of the old GTK+-bug, I did a build of emacs like
> this:
>
>   ./configure --without-pop --with-cairo --without-dbus --with-x-toolkit=lucid && make bootstrap
>
> And then I started Emacs on the machine:
>
>   machine1:~$ /usr/src/emacs/src/emacs -Q --eval '(server-start)'
>
> On another machine, I ssh'ed to the first machine, with X-forwarding
> turned on, and started emacsclient:
>
>   machine2:~$ ssh -X machine1
>   machine1:~$ /usr/src/emacs/lib-src/emacsclient --create-frame /tmp/test.txt
>   Waiting for Emacs...
>
> And got an X frame displayed on the screen of machine2, as expected.
>
> When I then end emacsclient with C-x # I'm back at the prompt. If I run
> "exit", the prompt is hanging, where I would expect to be logged out of
> machine1 and returned to machine2. Only after I press control-c do I get
> the prompt back:
>
>   machine1:~$ exit
>   ^C
>   machine2:~$ 
>
> (When I press control-c, the message "Connection lost to X server
> 'localhost:10.0'" is displayed in the mini-buffer in the Emacs frame on
> machine1.)
>
> I thought this "hanging" was related to the display closing GTK+-bug,
> but this is with lucid. At one point, I think, I read that it was a
> dbus-related thing, but I also turned off dbus.
>
> How do I avoid this hanging/having to press control-c?

This bug is still present on the master branch.  The attached patch
works for me but it may be subject to race conditions, so I will
continue testing it.  In the meantime, I figured I would reply to this
old thread in case others are interested in trying it.

Thomas


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Close-X-connection-when-emacsclient-disconnects.patch --]
[-- Type: text/x-diff, Size: 1228 bytes --]

From 21640257edc72e0c11127db60a6cfa9e92005309 Mon Sep 17 00:00:00 2001
From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Date: Tue, 9 Apr 2024 01:00:14 -0400
Subject: [PATCH] Close X connection when emacsclient disconnects

This fixes an issue reported on the mailing list:
https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00950.html

* lisp/server.el (server-handle-delete-frame): If the frame is an
X frame and DISPLAY is set, close the X connection to the display.
---
 lisp/server.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/server.el b/lisp/server.el
index b65053267a6..fb236493eae 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -509,6 +509,9 @@ server-handle-delete-frame
                             (eq proc (frame-parameter f 'client))))
                      (frame-list))))
       (server-log (format "server-handle-delete-frame, frame %s" frame) proc)
+      (let ((display (frame-parameter frame 'display)))
+        (when (and display (eq (framep frame) 'x))
+          (run-at-time nil nil (lambda () (x-close-connection display)))))
       (server-delete-client proc 'noframe)))) ; Let delete-frame delete the frame later.
 
 (defun server-handle-suspend-tty (terminal)
-- 
2.39.2

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Thu, Apr 16, 2020 at 3:22 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > Date: Thu, 16 Apr 2020 11:14:21 +0100
> >
> > Surely unifying under a single cross-platform toolkit like GTK+ would
> > avoid having this complexity.
>
> GTK+ is not cross-platform, it works only on some of the platforms we
> support (and is not an easy toolkit to work with, based on our
> experience).
>

I wrote a longer post about this topic on the emacs reddit recently, but a
short summary would be: What Eli said, plus some. There is no good
cross-platform GUI toolkit (free or otherwise), and the closest the
software world has today is Electron (which still doesn't cover everything
emacs supports). I realize that there are some partial solutions that
advertise themselves as cross-platform, but if you poke at them with a
moderately keen eye, they collapse quickly. As a practical matter, this is
a big reason that some of emacs' biggest competitors these days are based
on Electron (VS Code and Atom) and Java.

~Chad

[-- Attachment #2: Type: text/html, Size: 1702 bytes --]

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > software world has today is Electron (which still doesn't cover everything
  > emacs supports).

Is Electron free software?  If so, what is its license,
and what does Emacs do that Electron does not support?
(If there are lots of things, a few important ones would
be enough of an answer.)


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, ulm@gentoo.org, alex.bennee@linaro.org,
> 	emacs-devel@gnu.org
> Date: Fri, 17 Apr 2020 22:03:04 -0400
> 
> Is Electron free software?  If so, what is its license,

Its license is MIT, see below.

  Copyright (c) 2013-2020 GitHub Inc.

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is furnished to do so, subject to
  the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

As Eli said, Electron is covered by an MIT license. It describes itself
with this sentence:

  Build cross-platform desktop apps with JavaScript, HTML, and CSS.

It accomplishes this by uses Node.js, a JavaScript runtime built on the V8
javascript engine of Chrome. Each Electron app comes with its own
integrated copy of Chromium (the "free" parts of Google's Chrome web
browser, released under a combination of 3-clause BSD, MIT, [L]GPL, and
MS's Shared Source licenses). Without intensional malice, I'd call it a
Frankenstein's monster of both code and license.

Its major features are (in my personal opinion): Google invests effort into
making it function well across major platforms, it's "free enough" that it
can be used by various open, free, and commercial projects, and it lets
people make "desktop apps" using the widely-known web stack of JavaScript,
HTML, and CSS. It can use native code via Node's analog of an FFI. This
combination is so widely spread and optimized at this point that it's
possible to get decent performance alongside gui, threaded, network, etc.
code. It also has a reputation for being fairly bloated, in large part
because each Electron app brings its own copy of chromium, V8, node, etc.
Similarly, Electron apps are rarely well-integrated into a particular OS,
since they're mostly WWW technology; whether this bothers users or not is
currently a shifting topic, as ever more new users are used to using
web-based tech for much of their computer needs.

I hope that helps,
~Chad


On Fri, Apr 17, 2020 at 7:03 PM Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > software world has today is Electron (which still doesn't cover
> everything
>   > emacs supports).
>
> Is Electron free software?  If so, what is its license,
> and what does Emacs do that Electron does not support?
> (If there are lots of things, a few important ones would
> be enough of an answer.)
>
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

[-- Attachment #2: Type: text/html, Size: 3058 bytes --]

Re: "Why is emacs so square?"

[Po Lu]

chad <yandros@gmail.com> writes:

> As Eli said, Electron is covered by an MIT license. It describes itself with this sentence:
>
>   Build cross-platform desktop apps with JavaScript, HTML, and CSS.
>
> It accomplishes this by uses Node.js, a JavaScript runtime built on
> the V8 javascript engine of Chrome. Each Electron app comes with its
> own integrated copy of Chromium (the "free" parts of Google's Chrome
> web browser, released under a combination of 3-clause
> BSD, MIT, [L]GPL, and MS's Shared Source licenses). Without
> intensional malice, I'd call it a Frankenstein's monster of both code
> and license.
>
> Its major features are (in my personal opinion): Google invests effort
> into making it function well across major platforms, it's "free
> enough" that it can be used by various open, free, and commercial
> projects, and it lets people make "desktop apps" using the
> widely-known web stack of JavaScript, HTML, and CSS. It can use native code via
> Node's analog of an FFI. This combination is so widely spread and
> optimized at this point that it's possible to get decent performance
> alongside gui, threaded, network, etc. code. It also has a reputation
> for being fairly bloated, in large part because each Electron app
> brings its own copy of chromium, V8, node, etc. Similarly, Electron
> apps are rarely well-integrated into a particular OS, since they're
> mostly WWW technology; whether this bothers users or not is currently
> a shifting topic, as ever more new users are used to using web-based
> tech for much of their computer needs.

Electron has freedom issues.  (https://labs.parabola.nu/issues/1167)

Re: "Why is emacs so square?"

[Po Lu]

> Electron has freedom issues.  (https://labs.parabola.nu/issues/1167)

Some more relevant links:
https://www.mail-archive.com/gnu-linux-libre@nongnu.org/msg02199.html
https://bugs.chromium.org/p/chromium/issues/detail?id=28291
https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 15.04.2020 17:31, Eli Zaretskii wrote:

>> I think the difficulty here is to look "contemporary" and yet fit every
>> platform Emacs is run on. Button widgets look different on each. Even
>> between GUI toolkits. And change between releases.
> 
> There are only 2 variants: native buttons (provided by some toolkit)
> or the ones we draw ourselves.  And there's no requirement that they
> all look the same, I think: they should have the look-and-feel of the
> toolkit being used.

These are implementation options. But either the "ones we draw 
ourselves" are designed to fit each platform, or they looks the same 
across platforms, with our personal look.

The latter option is sometimes taken by professional applications in 
which the user spends most of their time (e.g. Blender, or at least some 
of it earlier versions that I've tried).

>> The other option, of course, is to look both modern and unique, but it's
>> a harder proposition, especially without a graphical designer on the
>> team. And this stuff gets outdated quickly.
> 
> I think "modern and unique" is a contradiction of terms nowadays ;-)

In principle, I disagree. But it's difficult, and it's a balancing act, 
of course, between having them look distinct and interesting, but still 
familiar enough, and not too "tacky" (meaning, a design too exotic can 
become an eyesore after a while). It's a problem that bigger companies 
put whole design departments on.

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 3559 bytes --]

For the original poster, because they might be used to running primarily a
distribution-installed version of emacs: the code for unix-based GUIs has
supported a variety of these sorts of elements for a very long time,
depending (currently) on whether you build emacs with the Athena, Lucid,
Motif, Athena3D, or gtk[,2,3] toolkits. Under macOS, one has the ns and mac
ports, and under MS Windows, it uses the local gui toolkit (which I
believe is the core W32 look and feel, not the frequently-shifting WPF,
Windows Forms, Metro, UWP, etc. standards).  Even within these systems,
there are options inside emacs for giving buttons a 3D look or not, and
there are many packages that add icons to emacs' display (via fonts, as far
as I can tell) that can 'spiffy up' emacs considerably.

It would probably be helpful for emacs' adoption if some of these gui
enhancements could be added to emacs and/or ELPA more directly. To be
specific, it would perhaps be helpful for emacs new-user adoption if people
didn't feel the need to adopt a large integrated package like Spacemacs or
DOOM emacs just to get graphical niceties -- not because those bundles are
bad, but because they add a *lot* more than just the gui enhancements. The
past couple years has seen a bit of an explosion of packages like
better-defaults or "starter kits" that aim to improve the new-user
experience without such a large overhead, but those still require getting
emacs from somewhere other than GNU or the standard distrubutions, which is
an extra hurdle.

I would be happy to help with such an effort, but I'm unsure what sorts of
changes would be acceptible to "core emacs", and I don't personally have
anything major to add to the existing set of third-party starter kits or
mega-bundles. If someone here had a clearer idea, that would be helpful.
Maybe the first step is to try to get all-the-icons (
https://github.com/domtronn/all-the-icons.el) or an analogous package
included in emacs?

Hope that helps! Thanks,
~Chad

On Wed, Apr 15, 2020 at 10:16 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 15.04.2020 17:31, Eli Zaretskii wrote:
>
> >> I think the difficulty here is to look "contemporary" and yet fit every
> >> platform Emacs is run on. Button widgets look different on each. Even
> >> between GUI toolkits. And change between releases.
> >
> > There are only 2 variants: native buttons (provided by some toolkit)
> > or the ones we draw ourselves.  And there's no requirement that they
> > all look the same, I think: they should have the look-and-feel of the
> > toolkit being used.
>
> These are implementation options. But either the "ones we draw
> ourselves" are designed to fit each platform, or they looks the same
> across platforms, with our personal look.
>
> The latter option is sometimes taken by professional applications in
> which the user spends most of their time (e.g. Blender, or at least some
> of it earlier versions that I've tried).
>
> >> The other option, of course, is to look both modern and unique, but it's
> >> a harder proposition, especially without a graphical designer on the
> >> team. And this stuff gets outdated quickly.
> >
> > I think "modern and unique" is a contradiction of terms nowadays ;-)
>
> In principle, I disagree. But it's difficult, and it's a balancing act,
> of course, between having them look distinct and interesting, but still
> familiar enough, and not too "tacky" (meaning, a design too exotic can
> become an eyesore after a while). It's a problem that bigger companies
> put whole design departments on.
>
>

[-- Attachment #2: Type: text/html, Size: 4258 bytes --]

Re: "Why is emacs so square?"

[ndame]

> For the original poster, because they might be used to running
> primarily a distribution-installed version of emacs: the code for
> unix-based GUIs has supported a variety of these sorts of elements
> for a very long time, depending (currently) on whether you build
> emacs with the Athena, Lucid, Motif, Athena3D, or gtk[,2,3]
> toolkits. Under macOS, one has the ns and mac ports, and under MS
> Windows, it uses the local gui toolkit (which I believe is the core
> W32 look and feel, not the frequently-shifting WPF, Windows Forms,
> Metro, UWP, etc. standards). 


I use the official windows build and it looks like this which is
definitely not how buttons look in windows dialogs:

https://i.imgur.com/TjaMGwF.png

The native buttons don't have a thick shadow like this.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Wed, 15 Apr 2020 20:44:16 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>,
>  Richard Stallman <rms@gnu.org>, EMACS development team <emacs-devel@gnu.org>
> 
> I use the official windows build and it looks like this which is
> definitely not how buttons look in windows dialogs:
> 
> https://i.imgur.com/TjaMGwF.png
> 
> The native buttons don't have a thick shadow like this.

We don't use the native buttons on MS-Windows.  The only native
widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
bars.

Re: "Why is emacs so square?"

[ndame]

>
> We don't use the native buttons on MS-Windows. The only native
> widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
> bars.

Interesting. I sort of assumed Emacs looks the same everywhere and
thought all emacs users saw these old fashioned buttons if they
open up Customize which I see on Windows.

But if emacs uses native buttons elsewhere then it means Emacs
can look much better on other platforms, at least as far as
we consider GUI widgets.

Wouldn't it make sense to use native controls on every graphical
platform?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 06:00:33 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "yandros@gmail.com" <yandros@gmail.com>, "dgutov@yandex.ru" <dgutov@yandex.ru>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> 
> >
> > We don't use the native buttons on MS-Windows. The only native
> > widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
> > bars.
> 
> Interesting. I sort of assumed Emacs looks the same everywhere and
> thought all emacs users saw these old fashioned buttons if they
> open up Customize which I see on Windows.

Emacs's look-and-feel varies depending on the toolkit used to build
it.  So it cannot look the same everywhere, not in every aspect of the
GUI decorations and widgets.

> But if emacs uses native buttons elsewhere then it means Emacs
> can look much better on other platforms, at least as far as
> we consider GUI widgets.

I think you are generalizing too much here.  We don't use toolkit
widgets for every element of our GUI.  So some "buttons" are native
(for example, the tool bar of the GTK+ build), while others are not.
Which toolkit build uses what widgets where depends on what the people
who wrote the related code did, not some policy decision.  And
sometimes we even have options to let users choose between native and
Emacs-implemented GUI elements, like the x-gtk-use-system-tooltips in
the GTK builds.

> Wouldn't it make sense to use native controls on every graphical
> platform?

That has advantages, of course, but also some disadvantages.
Complexity of code is one of the disadvantages, because some widgets
of some toolkits require special code (like separate input loops) to
be able to use them, or because they have some limitations (e.g., GTK
tooltips cannot display images, at least the way we invoke those
tooltips.

Re: "Why is emacs so square?"

[ndame]

On Thursday, April 16, 2020 4:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I think you are generalizing too much here. We don't use toolkit
> widgets for every element of our GUI. So some "buttons" are native
> (for example, the tool bar of the GTK+ build), while others are not.

I thought Customize buttons are native on some platforms, but I checked,
and now I see they are just faces.

It could improve appearance quite a lot if someone with a feel for graphical
design took a look at faces and created some more modern looking defaults.

Re: "Why is emacs so square?"

[ndame]

>
> It could improve appearance quite a lot if someone with a feel for graphical
> design took a look at faces and created some more modern looking defaults.

Though, of course, there is only so much you can do with colors to improve the
graphical appearance.

E.g. checking the GTK buttons they apparently have some small border and,
of course, slightly rounded corners:

https://i.stack.imgur.com/9PLof.png

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It could improve appearance quite a lot if someone with a feel for graphical
  > design took a look at faces and created some more modern looking defaults.

It was very hard to work out a set of default faces that worked
reasonably.  We had to make change after change till everyone
was happy with it.

I think that the help of a graphics UI designer could enable us to
make an improvement _if_ perse is capable of working within the
constraints that we face.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[ndame]

>
> some "buttons" are native
> (for example, the tool bar of the GTK+ build),

Just saw on reddit that a user posted a screenshot of an emacs
toolbar with really sad looking icons at the end:

https://i.imgur.com/6sIHOGt.png

They reportedly appear when you invoke M-x report-emacs-bug

I don't know what's going on here, but AFAIK there are
GPLd iconsets for all kind of icons.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 19:14:27 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "yandros@gmail.com" <yandros@gmail.com>, "dgutov@yandex.ru" <dgutov@yandex.ru>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Just saw on reddit that a user posted a screenshot of an emacs
> toolbar with really sad looking icons at the end:
> 
> https://i.imgur.com/6sIHOGt.png
> 
> They reportedly appear when you invoke M-x report-emacs-bug
> 
> I don't know what's going on here, but AFAIK there are
> GPLd iconsets for all kind of icons.

Feel free to point us to GPLed icons that can be incorporated in
Emacs.  At the time, the situation was nowhere as easy as you imply,
but maybe things have changed since then.

Re: "Why is emacs so square?"

[ndame]

>
> Feel free to point us to GPLed icons that can be incorporated in
> Emacs. At the time, the situation was nowhere as easy as you imply,
> but maybe things have changed since then.

Aren't the icons used by GTK/Gnome GPL licensed? I assumed they
were if GTK/Gnome uses them.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 16.04.2020 22:26, Eli Zaretskii wrote:
> Feel free to point us to GPLed icons that can be incorporated in
> Emacs.  At the time, the situation was nowhere as easy as you imply,
> but maybe things have changed since then.

Are these okay?

https://commons.wikimedia.org/wiki/GNOME_Desktop_icons

And an older set: https://commons.wikimedia.org/wiki/Tango_icons 
(they're supposedly released under Creative Commons).

Re: "Why is emacs so square?"

[ndame]

>
> Are these okay?
>
> https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
>


There are also the KDE icon set, though it's LGPL 3 licensed.
I don't know if it's OK in Emacs:

https://github.com/KDE/oxygen-icons

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 20:30:36 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, "yandros@gmail.com" <yandros@gmail.com>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > Are these okay?
> >
> > https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
> 
> There are also the KDE icon set, though it's LGPL 3 licensed.
> I don't know if it's OK in Emacs:
> 
> https://github.com/KDE/oxygen-icons

Someone™ needs to invest the time and effort to figure out the legal
issues, find the icons that we want out of those which are legally
fit, and post the resulting information.  We did that process at the
time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
wasn't easy.

Alternatively, someone could create our own icons, in which case they
could be even prettier than the ones pointed out here.

In any case, this is a non-trivial job, and volunteers are most
welcome to do it.  I don't think anyone is happy about the icons shown
on the tool bar by Message mode; the only reason we use them is that
we couldn't find better ones that are free and suitable for inclusion
in Emacs.

Thanks.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 17, 2020, at 16:06, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> In any case, this is a non-trivial job, and volunteers are most
> welcome to do it.  I don't think anyone is happy about the icons shown
> on the tool bar by Message mode; the only reason we use them is that
> we couldn't find better ones that are free and suitable for inclusion
> in Emacs.

What is the criteria for "suitable" ? Is that an esthetical one ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 17 Apr 2020 16:28:33 +0900
> 
> > On Apr 17, 2020, at 16:06, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > In any case, this is a non-trivial job, and volunteers are most
> > welcome to do it.  I don't think anyone is happy about the icons shown
> > on the tool bar by Message mode; the only reason we use them is that
> > we couldn't find better ones that are free and suitable for inclusion
> > in Emacs.
> 
> What is the criteria for "suitable" ? Is that an esthetical one ?

"Suitable" in all the senses mentioned in this discussion.  Including,
but not limited to, aesthetics.

Re: "Why is emacs so square?"

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

On 17.04.2020 13:00, Eli Zaretskii wrote:
>> From: Jean-Christophe Helary<jean.christophe.helary@traduction-libre.org>
>> Date: Fri, 17 Apr 2020 16:28:33 +0900
>>
>>> On Apr 17, 2020, at 16:06, Eli Zaretskii<eliz@gnu.org>  wrote:
>>>
>>> In any case, this is a non-trivial job, and volunteers are most
>>> welcome to do it.  I don't think anyone is happy about the icons shown
>>> on the tool bar by Message mode; the only reason we use them is that
>>> we couldn't find better ones that are free and suitable for inclusion
>>> in Emacs.
>> What is the criteria for "suitable" ? Is that an esthetical one ?
> "Suitable" in all the senses mentioned in this discussion.  Including,
> but not limited to, aesthetics.

I have a suggestion that might circumvent this whole discussion.

Just now, I turned on the toolbar and entered bug reporting mode with 
'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.

The attached picture shows a toolbar with an assortment of icons where 
about half obey the current theme and the rest don't. I also tried 
switching between icons themes to confirm this.

The icons to the left of "Send Message", as well as the "Kill Message" 
icon, change together with the themes. The red round thingy with an "x" 
changes only with some themes, but not with the rest. Perhaps that means 
that the icon with that name/identifier is themed more rarely. But it's 
still somewhat standard.

The rest of the icons ("Send Message", "Attach File" and the rest after 
it) never follow the theme.

Perhaps the solution, at least for the GTK builds, would be to find the 
standard icons (more concretely, icon names) that can be used for these 
buttons, instead of picking among the icon sets. The latter should be 
the user's choice, after all.

[-- Attachment #2: Screenshot from 2020-04-22 02-44-26.png --]
[-- Type: image/png, Size: 94693 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 02:54:13 +0300
> 
> Just now, I turned on the toolbar and entered bug reporting mode with 
> 'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.

I don't think I follow.  Where can I find this "GNOME theme"?  It's
not part of the Emacs release tarball, is it?

> The attached picture shows a toolbar with an assortment of icons where 
> about half obey the current theme and the rest don't. I also tried 
> switching between icons themes to confirm this.
> 
> The icons to the left of "Send Message", as well as the "Kill Message" 
> icon, change together with the themes. The red round thingy with an "x" 
> changes only with some themes, but not with the rest. Perhaps that means 
> that the icon with that name/identifier is themed more rarely. But it's 
> still somewhat standard.
> 
> The rest of the icons ("Send Message", "Attach File" and the rest after 
> it) never follow the theme.

What exactly do you mean by "icons follow the theme"? how does a theme
affect icons?

> Perhaps the solution, at least for the GTK builds, would be to find the 
> standard icons (more concretely, icon names) that can be used for these 
> buttons

AFAIR, last time we made such an effort, we indeed took icons from GTK
or GNOME or from some similar collection.  But that was a long time
ago, and in particular the two rightmost icons you see in Message mode
were not part of that set, they were added by someone later.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 09.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Wed, 22 Apr 2020 02:54:13 +0300
>>
>> Just now, I turned on the toolbar and entered bug reporting mode with 
>> 'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.
> 
> I don't think I follow.  Where can I find this "GNOME theme"?  It's
> not part of the Emacs release tarball, is it?

It's shipped by GNU/Linux distributions, typically.

> What exactly do you mean by "icons follow the theme"? how does a theme
> affect icons?

In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.

>> Perhaps the solution, at least for the GTK builds, would be to find the 
>> standard icons (more concretely, icon names) that can be used for these 
>> buttons

> AFAIR, last time we made such an effort, we indeed took icons from GTK
> or GNOME or from some similar collection.  But that was a long time
> ago, and in particular the two rightmost icons you see in Message mode
> were not part of that set, they were added by someone later.

It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 22 Apr 2020 10:05:15 -0400
> 
> > I don't think I follow.  Where can I find this "GNOME theme"?  It's
> > not part of the Emacs release tarball, is it?
> 
> It's shipped by GNU/Linux distributions, typically.

Any chance of getting a URL that I could explore?

> > What exactly do you mean by "icons follow the theme"? how does a theme
> > affect icons?
> 
> In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.

Then I don't understand the complaint.  The icons that don't change
are our private icons that aren't taken from GTK.  So how can they
"follow the theme", if they are absent there?

> >> Perhaps the solution, at least for the GTK builds, would be to find the 
> >> standard icons (more concretely, icon names) that can be used for these 
> >> buttons
> 
> > AFAIR, last time we made such an effort, we indeed took icons from GTK
> > or GNOME or from some similar collection.  But that was a long time
> > ago, and in particular the two rightmost icons you see in Message mode
> > were not part of that set, they were added by someone later.
> 
> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).

That would only help GTK users.  I thought we wanted to improve the
Emacs appearance on more than just one toolkit, especially since that
toolkit is troubled and many users avoid building with it for that
reason.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 10.29, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 22 Apr 2020 10:05:15 -0400
>>
>>> I don't think I follow.  Where can I find this "GNOME theme"?  It's
>>> not part of the Emacs release tarball, is it?
>>
>> It's shipped by GNU/Linux distributions, typically.
> 
> Any chance of getting a URL that I could explore?

Yes, of course. Here is the theme used on my machine, for example: https://github.com/linuxmint/mint-y-icons
strace-ing `emacs -Q' on my machine suggests that it loads the following icons for the default tool-bar:

  13718:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-new.svg", O_RDONLY) = 15
  13728:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-open.svg", O_RDONLY) = 15
  13747:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/window-close.svg", O_RDONLY) = 15
  13752:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-save.svg", O_RDONLY) = 15
  13757:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-undo.svg", O_RDONLY) = 15
  13762:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-cut.svg", O_RDONLY) = 15
  13767:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-copy.svg", O_RDONLY) = 15
  13772:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-paste.svg", O_RDONLY) = 15
  13777:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-find.svg", O_RDONLY) = 15

The icon naming spec is here: https://developer.gnome.org/icon-naming-spec/

>>> What exactly do you mean by "icons follow the theme"? how does a theme
>>> affect icons?
>>
>> In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.
> 
> Then I don't understand the complaint.  The icons that don't change
> are our private icons that aren't taken from GTK.  So how can they
> "follow the theme", if they are absent there?

IIUC, the claim is that there (likely) are standard icons close to the ones we use, and that using the corresponding icon names would give us good-looking icons by default on Gtk.
Concretely, for the actions shown in the message toolbar, this would be these:

mail-attachment 
document-send or mail-send
tools-check-spelling
mail-mark-important

The spec doesn't seem to have actions for marking an email unimportant or requesting an email receipt.

>>>> Perhaps the solution, at least for the GTK builds, would be to find the 
>>>> standard icons (more concretely, icon names) that can be used for these 
>>>> buttons
>>
>>> AFAIR, last time we made such an effort, we indeed took icons from GTK
>>> or GNOME or from some similar collection.  But that was a long time
>>> ago, and in particular the two rightmost icons you see in Message mode
>>> were not part of that set, they were added by someone later.
>>
>> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> 
> That would only help GTK users.  I thought we wanted to improve the
> Emacs appearance on more than just one toolkit, especially since that
> toolkit is troubled and many users avoid building with it for that
> reason.

Sure, importing icons is also a good idea.  But the OP was making the point that we can easily improve the situation without bikeshedding a specific icon choice by respecting existing user themes.

Clément.

message-mode toolbars, was: Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 18:17, Clément Pit-Claudel wrote:
> IIUC, the claim is that there (likely) are standard icons close to the ones we use, and that using the corresponding icon names would give us good-looking icons by default on Gtk.
> Concretely, for the actions shown in the message toolbar, this would be these:
> 
> mail-attachment
> document-send or mail-send
> tools-check-spelling
> mail-mark-important

Thanks for the list. Below is a patch that makes use of it.

> The spec doesn't seem to have actions for marking an email unimportant or requesting an email receipt.

Unfortunately, it doesn't. Nothing for "save-draft" either, but we're 
currently using the "gtk-close" icon for that.

Also, I dug a little deeper into that rabbit hole, and turns out, Gnus 
normally defines two sets of icons for its toolbars. The first is called 
"gnome", and the other is "retro". And in 2016 the relevant check was 
reverted (commit d88118db37d), so we've been using the "retro" version 
since. I'm guessing Lars doesn't use GTK or toolbars at all.

It seems the two versions of toolbars have diverged in contents too, so 
aside from reverting a part of that commit, someone will need to do the 
work of merging them. Hopefully into one.

Anyway, here's the patch improving the icons a little:

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index adefa0efd6..bb6a55dc80 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -7969,7 +7969,7 @@ message-tool-bar-gnome
      (mml-attach-file "attach" mml-mode-map :vert-only t)
      (mml-preview "mail/preview" mml-mode-map)
      (mml-secure-message-sign-encrypt "lock" mml-mode-map :visible nil)
-    (message-insert-importance-high "important" nil :visible nil)
+    (message-insert-importance-high "mail/important" nil :visible nil)
      (message-insert-importance-low "unimportant" nil :visible nil)
      (message-insert-disposition-notification-to "receipt" nil :visible 
nil))
    "List of items for the message tool bar (GNOME style).
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 5b8feb14a5..865a8bd4c5 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -1413,7 +1413,7 @@ x-gtk-stock-map
      ("etc/images/info" . ("dialog-information" "gtk-info"))
      ("etc/images/bookmark_add" . "n:bookmark_add")
      ;; Used in Gnus and/or MH-E:
-    ("etc/images/attach" . "gtk-attach")
+    ("etc/images/attach" . ("mail-attachment" "gtk-attach"))
      ("etc/images/connect" . "gtk-connect")
      ("etc/images/contact" . "gtk-contact")
      ("etc/images/delete" . ("edit-delete" "gtk-delete"))
@@ -1431,18 +1431,20 @@ x-gtk-stock-map
      ("etc/images/sort-descending" . ("view-sort-descending"
  				     "gtk-sort-descending"))
      ("etc/images/sort-row-ascending" . "gtk-sort-row-ascending")
+    ("etc/images/spell" . ("tools-check-spelling" "gtk-spell-check"))
      ("images/gnus/toggle-subscription" . "gtk-task-recurring")
      ("images/mail/compose" . "gtk-mail-compose")
      ("images/mail/copy" . "gtk-mail-copy")
      ("images/mail/forward" . "gtk-mail-forward")
      ("images/mail/inbox" . "gtk-inbox")
+    ("images/mail/important" . "mail-mark-important")
      ("images/mail/move" . "gtk-mail-move")
      ("images/mail/not-spam" . "gtk-not-spam")
      ("images/mail/outbox" . "gtk-outbox")
      ("images/mail/reply-all" . "gtk-mail-reply-to-all")
      ("images/mail/reply" . "gtk-mail-reply")
      ("images/mail/save-draft" . "gtk-mail-handling")
-    ("images/mail/send" . "gtk-mail-send")
+    ("images/mail/send" . ("mail-send" "gtk-mail-send"))
      ("images/mail/spam" . "gtk-spam")
      ;; Used for GDB Graphical Interface
      ("images/gud/break" . "gtk-no")

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm guessing Lars doesn't use GTK or toolbars at all.

I use GTK, but not toolbars, no.

> It seems the two versions of toolbars have diverged in contents too,
> so aside from reverting a part of that commit, someone will need to do
> the work of merging them. Hopefully into one.
>
> Anyway, here's the patch improving the icons a little:

The patch makes sense to me, I think, so please go ahead and apply.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Dmitry Gutov]

Hi Lars,

On 30.04.2020 07:27, Lars Ingebrigtsen wrote:

>> It seems the two versions of toolbars have diverged in contents too,
>> so aside from reverting a part of that commit, someone will need to do
>> the work of merging them. Hopefully into one.
>>
>> Anyway, here's the patch improving the icons a little:
> 
> The patch makes sense to me, I think, so please go ahead and apply.

I was hoping we could get it into emacs-27, though. Probably a more 
expanded version too (I should look over several other toolbars).

In the meantime, could you look into the problem of the "legacy" toolbar 
being used on full-color devices? The variable gmm-tool-bar-style, 
breakage in commit d88118db37dd543536677d7c4212a2c67621fb88. I can 
create a bug report, if you like.

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 30 Apr 2020 21:26:09 +0300
> 
> > The patch makes sense to me, I think, so please go ahead and apply.
> 
> I was hoping we could get it into emacs-27, though. Probably a more 
> expanded version too (I should look over several other toolbars).

I don't think we should change look-and-feel during a pretest, sorry.
These are sensitive issues that tend to trigger emotions, so we should
let them live on master for some time before we release them.

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Dmitry Gutov]

On 30.04.2020 21:44, Eli Zaretskii wrote:
> I don't think we should change look-and-feel during a pretest, sorry.
> These are sensitive issues that tend to trigger emotions, so we should
> let them live on master for some time before we release them.

Pardon me for insistence, but I've filed bug#40990.

Perhaps we could see if there's any negative feedback at all?

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: larsi@gnus.org, cpitclaudel@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2020 02:57:59 +0300
> 
> On 30.04.2020 21:44, Eli Zaretskii wrote:
> > I don't think we should change look-and-feel during a pretest, sorry.
> > These are sensitive issues that tend to trigger emotions, so we should
> > let them live on master for some time before we release them.
> 
> Pardon me for insistence, but I've filed bug#40990.

Thanks, I replied there.

> Perhaps we could see if there's any negative feedback at all?

I'd like to avoid waiting for feedback on this, so that Emacs 27.1
could be released sooner rather than later.

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> In the meantime, could you look into the problem of the "legacy"
> toolbar being used on full-color devices? The variable
> gmm-tool-bar-style, breakage in commit
> d88118db37dd543536677d7c4212a2c67621fb88. I can create a bug report,
> if you like.

Oh, it's this bit?

 (defcustom gmm-tool-bar-style
   (if (and (boundp 'tool-bar-mode)
           tool-bar-mode
-          (and (fboundp 'display-visual-class)
-               (not (memq (display-visual-class)
-                          (list 'static-gray 'gray-scale
-                                'static-color 'pseudo-color)))))
+          (memq (display-visual-class)
+                (list 'static-gray 'gray-scale
+                      'static-color 'pseudo-color)))
       'gnome
     'retro)

Oops.  Looks like I removed the `not' by mistake while I was cleaning up
the foundp test somehow?

That's clearly a regression and should be fixed on the emacs-27 branch,
I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Dmitry Gutov]

On 01.05.2020 01:16, Lars Ingebrigtsen wrote:
> Oh, it's this bit?
> 
>   (defcustom gmm-tool-bar-style
>     (if (and (boundp 'tool-bar-mode)
>             tool-bar-mode
> -          (and (fboundp 'display-visual-class)
> -               (not (memq (display-visual-class)
> -                          (list 'static-gray 'gray-scale
> -                                'static-color 'pseudo-color)))))
> +          (memq (display-visual-class)
> +                (list 'static-gray 'gray-scale
> +                      'static-color 'pseudo-color)))
>         'gnome
>       'retro)
> 
> Oops.  Looks like I removed the `not' by mistake while I was cleaning up
> the foundp test somehow?

Yup.

> That's clearly a regression and should be fixed on the emacs-27 branch,
> I think.

This breakage is from 2016, so it most likely got into Emacs 25.

More importantly, while I'm all for fixing bugs, I think fixing it now 
will be more risky than my icons patch, because gmm-tool-bar-style 
affects which toolbar is shown. And for message-mode, at least, the 
'gnome' and 'retro' toolbars have different contents.

Re: message-mode toolbars, was: Re: "Why is emacs so square?"

[Dmitry Gutov]

On 01.05.2020 01:16, Lars Ingebrigtsen wrote:
> Oh, it's this bit?
> 
>   (defcustom gmm-tool-bar-style
>     (if (and (boundp 'tool-bar-mode)
>             tool-bar-mode
> -          (and (fboundp 'display-visual-class)
> -               (not (memq (display-visual-class)
> -                          (list 'static-gray 'gray-scale
> -                                'static-color 'pseudo-color)))))
> +          (memq (display-visual-class)
> +                (list 'static-gray 'gray-scale
> +                      'static-color 'pseudo-color)))
>         'gnome
>       'retro)
> 
> Oops.  Looks like I removed the `not' by mistake while I was cleaning up
> the foundp test somehow?
> 
> That's clearly a regression and should be fixed on the emacs-27 branch,
> I think.

Fixed on master now.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 17:29, Eli Zaretskii wrote:
>> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> That would only help GTK users.

Yes, indeed. But it's still probably the most popular toolkit among 
GNU/Linux users.

> I thought we wanted to improve the
> Emacs appearance on more than just one toolkit,

On e.g. Lucid all icons come from the same set, at least. We can improve 
them as well (all together), but it's a fairly different task.

Speaking of other platforms, I wonder if Windows and macOS also have 
have standard sets of icons.

It would make our task easier (and the end result more native-looking) 
if we could use a similar approach.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 19:14:01 +0300
> 
> On 22.04.2020 17:29, Eli Zaretskii wrote:
> >> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> > That would only help GTK users.
> 
> Yes, indeed. But it's still probably the most popular toolkit among 
> GNU/Linux users.

And the icons look the same, no matter what distribution are we
talking about?  Doesn't something depend also on the desktop that's in
use, and perhaps also on the window manager?

> > I thought we wanted to improve the
> > Emacs appearance on more than just one toolkit,
> 
> On e.g. Lucid all icons come from the same set, at least. We can improve 
> them as well (all together), but it's a fairly different task.
> 
> Speaking of other platforms, I wonder if Windows and macOS also have 
> have standard sets of icons.

"Standard" as in "subject to change without notice" each time the
vendor decides to change the look-and-feel (which happens roughly
every 2 to 3 years).  And that's even before we solve the problem of
showing those "standard" icons in Emacs -- e.g., on Windows it is
customary to compile the icons into the binary, something that we
cannot do and then distribute the binary from the GNU FTP site.

> It would make our task easier (and the end result more native-looking) 
> if we could use a similar approach.

I'm not sure I like this direction.  It sounds like the opposite of
having an Emacs that looks more or less the same on all major
platforms.  How will the users (and newbies at that, since we are
talking about them primarily) be able to find their ways in Emacs, if
the icons change with the desktop/platform, and every few years even
on the same platform?  E.g., you buy the Emacs manual printed a year
or 2 ago, but the icons it shows are all different from what's on
display.  I don't even understand how will we be able to show the
icons in our Info manual, if the images don't come with Emacs and are
different on each platform/build.  Do we really want to go in that
direction? just to say we look "modern"?  Something people should
seriously think and make up their minds about before such decisions
are made, I guess.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 12.55, Eli Zaretskii wrote:
> I'm not sure I like this direction.  It sounds like the opposite of
> having an Emacs that looks more or less the same on all major
> platforms.  How will the users (and newbies at that, since we are
> talking about them primarily) be able to find their ways in Emacs, if
> the icons change with the desktop/platform, and every few years even
> on the same platform?  E.g., you buy the Emacs manual printed a year
> or 2 ago, but the icons it shows are all different from what's on
> display.  I don't even understand how will we be able to show the
> icons in our Info manual, if the images don't come with Emacs and are
> different on each platform/build.  Do we really want to go in that
> direction? just to say we look "modern"?  Something people should
> seriously think and make up their minds about before such decisions
> are made, I guess.

This is a legitimate worry, but you have to balance it against consistency with other applications.  When I change my desktop theme, icons change in most apps, and the same concept gets the same icon in all apps.

Emacs is partly like that, partly not: some icons change and some don't.

We can have a discussion on whether to use a unified icon set on all platforms, but in the meantime making Emacs' behavior consistent would be a plus, and should be an easy change.

Clément.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 19:55, Eli Zaretskii wrote:
> And the icons look the same, no matter what distribution are we
> talking about?  Doesn't something depend also on the desktop that's in
> use, and perhaps also on the window manager?

No, the icons looks different across themes. Hence the whole notion of 
"icon themes". But the set of icon names is fairly stable. This is what 
we'd be relying on.

See x-gtk-stock-map for some more detail.

> I'm not sure I like this direction.  It sounds like the opposite of
> having an Emacs that looks more or less the same on all major
> platforms.

Right. It's already not the case.

> How will the users (and newbies at that, since we are
> talking about them primarily) be able to find their ways in Emacs, if
> the icons change with the desktop/platform, and every few years even
> on the same platform?

People have been doing all right regarding that. At least, I haven't 
seen much criticism of GTK's approach in this regard.

> E.g., you buy the Emacs manual printed a year
> or 2 ago, but the icons it shows are all different from what's on
> display.  I don't even understand how will we be able to show the
> icons in our Info manual, if the images don't come with Emacs and are
> different on each platform/build.

The window looks are different between platforms anyway. As well as such 
fundamental thing as the placement of window's close/maximize/iconize 
buttons.

> Do we really want to go in that
> direction? just to say we look "modern"?

On GTK, we're already there. Since 22.2, apparently. Only we haven't 
been paying attention to keeping this feature in proper maintenance. I'm 
guessing because some of our core developers use other platforms, others 
build with Lucid, and the reset disable the toolbars? But that's not a 
good approach.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 20:06:08 +0300
> 
> On 22.04.2020 19:55, Eli Zaretskii wrote:
> > And the icons look the same, no matter what distribution are we
> > talking about?  Doesn't something depend also on the desktop that's in
> > use, and perhaps also on the window manager?
> 
> No, the icons looks different across themes. Hence the whole notion of 
> "icon themes". But the set of icon names is fairly stable. This is what 
> we'd be relying on.

But a given theme is not available universally, not even with the same
toolkit, I guess?

> > I'm not sure I like this direction.  It sounds like the opposite of
> > having an Emacs that looks more or less the same on all major
> > platforms.
> 
> Right. It's already not the case.

Which is already bad, IMO.  But before we make this a rule rather than
an exception or a historical accident, we should think hard whether we
really want that.  Emacs is special in several ways, and one of them
is its commonality -- you have only ever learn Emacs once, on one
platform.  It's  why I can give advice on Reddit to people that use
platforms I never did.

So this will be a significant change in direction, at least in my
eyes, and the decision should not be made casually, let alone by
default.

> > E.g., you buy the Emacs manual printed a year
> > or 2 ago, but the icons it shows are all different from what's on
> > display.  I don't even understand how will we be able to show the
> > icons in our Info manual, if the images don't come with Emacs and are
> > different on each platform/build.
> 
> The window looks are different between platforms anyway.

No, not really.  They are extremely similar, actually, modulo a few
unimportant bells and whistles.  At least the parts that are relevant
to Emacs are almost identical.

> On GTK, we're already there. Since 22.2, apparently. Only we haven't 
> been paying attention to keeping this feature in proper maintenance.

I'm asking people to think whether we _want_ that.  That we are one
leg there doesn't yet mean we decided to do that consciously.  You are
suggesting to make that a policy, and that's a serious decision, IMO.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 20:19, Eli Zaretskii wrote:
>> No, the icons looks different across themes. Hence the whole notion of
>> "icon themes". But the set of icon names is fairly stable. This is what
>> we'd be relying on.
> But a given theme is not available universally, not even with the same
> toolkit, I guess?

Indeed, it isn't. Although there's always the standard theme for GNOME 
(Adwaita) and the latest Ubuntu theme, we can look at those.

I'm not sure how that's important, though.

>> On GTK, we're already there. Since 22.2, apparently. Only we haven't
>> been paying attention to keeping this feature in proper maintenance.
> I'm asking people to think whether we_want_  that.  That we are one
> leg there doesn't yet mean we decided to do that consciously.  You are
> suggesting to make that a policy, and that's a serious decision, IMO.

First of all, I'm suggesting we fix how the icons look in the GTK build.

Then you are welcome to discuss whether macOS and Windows could use 
something like that. And whether they should. Since you're skeptical of 
this approach from the outset, I'd rather bow out of that discussion.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 20:34:45 +0300
> 
> >> On GTK, we're already there. Since 22.2, apparently. Only we haven't
> >> been paying attention to keeping this feature in proper maintenance.
> > I'm asking people to think whether we_want_  that.  That we are one
> > leg there doesn't yet mean we decided to do that consciously.  You are
> > suggesting to make that a policy, and that's a serious decision, IMO.
> 
> First of all, I'm suggesting we fix how the icons look in the GTK build.

Fixing them by replacing the current icons with prettier ones is okay.
Using the toolkit icons everywhere, as a matter of policy, is a
different matter.

> Then you are welcome to discuss whether macOS and Windows could use 
> something like that. And whether they should. Since you're skeptical of 
> this approach from the outset, I'd rather bow out of that discussion.

Forget MS-Windows and macOS, that's not my worry right now.  IIUC,
your suggestion was to use whatever native icons each toolkit offers
on Posix platforms as well, and it wasn't limited to GTK.  That is the
decision I was talking about.  I myself have no strong opinions on
this, only weak ones.  But no serious decision-making should happen
without a "red team" on board making sure we don't fall victim to
groupthink simply because no one dares to ask a question about the
nature of emperor's clothes.  I tried to present arguments to the
contrary with that in mind, so people could consider both sides.

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

On Wed, Apr 22, 2020 at 10:20 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > The window looks are different between platforms anyway.
>
> No, not really.  They are extremely similar, actually, modulo a few
> unimportant bells and whistles.  At least the parts that are relevant
> to Emacs are almost identical.
>

I would agree with this "not really" sentiment, but extend it to include
the differences between icon themes, and where such things work at the OS
level, between OS's. The point of icon themes is to make them all fit
together, and the point of standardized system icons is to have them all
fit together, and the users have shown (for many, many years now) that they
understand this, and can handle the shifts with aplomb. Yes, it is possible
for someone to install a wacky gui-customization pack that changes the
left-arrow into a sausage and the file-folder into a rainbow, but the only
people who do such things are askign for exactly that behavior, and aren't
going to be upset that emacs' toolbar changes along with everything else.

As a practical matter, emacs will need a set of reasonable fallback
defaults, for systems that don't have system-wide settings; we can continue
to use those when the gui environment doesn't help us. The result will
certainly look no worse than the current mixture of icons one can find in
the emacs toolbar. It's very likely that we can improve that set of
fallbacks by adopting a single source for them, such as the GTK or KDE
options mentioned earlier.

A techincal wrinkle here is how those icons are displayed and how they're
stored inside emacs. By way of example, the two KDE icon sets that were
suggested (Breeze and Oxygen) use different file formats: one uses PNG
images; the other SVG. (Oddly, the SVG images are distributed in several
different sizes, which would seem to belie the advantage of using scalable
images in the first place.) Scalable icons like SVG would be nice for the
current era of high- and low-density displays, but my understanding is that
SVG is the least well supported image format inside emacs across our
various platforms these days.

~Chad

[-- Attachment #2: Type: text/html, Size: 2573 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 22 Apr 2020 11:07:32 -0700
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I would agree with this "not really" sentiment, but extend it to include the differences between icon themes,
> and where such things work at the OS level, between OS's. The point of icon themes is to make them all fit
> together, and the point of standardized system icons is to have them all fit together, and the users have
> shown (for many, many years now) that they understand this, and can handle the shifts with aplomb. Yes, it
> is possible for someone to install a wacky gui-customization pack that changes the left-arrow into a sausage
> and the file-folder into a rainbow, but the only people who do such things are askign for exactly that behavior,
> and aren't going to be upset that emacs' toolbar changes along with everything else. 

There's no argument that having a capability to change the set of
icons as part of a theme would be a good feature for Emacs to have.
So arguments for having that are, from my POV, preaching to the choir.

The argument, or at least its part about which I expressed concerns,
was to use exclusively the icons provided by the toolkit+desktop that
happen to be in use.  That's an entirely different matter, if we want
to make it pour policy.

> As a practical matter, emacs will need a set of reasonable fallback defaults, for systems that don't have
> system-wide settings

Only if we decide we _want_ to use those system-wide defaults where
they do exist.

> A techincal wrinkle here is how those icons are displayed and how they're stored inside emacs.

They aren't.  They are separate image files which we load when needed.
And I think it should be left that way, because it will make it easier
for us to include new icons in the distribution.

> By way of
> example, the two KDE icon sets that were suggested (Breeze and Oxygen) use different file formats: one
> uses PNG images; the other SVG. (Oddly, the SVG images are distributed in several different sizes, which
> would seem to belie the advantage of using scalable images in the first place.) Scalable icons like SVG
> would be nice for the current era of high- and low-density displays, but my understanding is that SVG is the
> least well supported image format inside emacs across our various platforms these days.

SVG is IMO a PITA because librsvg is a monster.  But other than that,
SVG images are a fait accompli, and we need to support them well.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 21:24, Eli Zaretskii wrote:
> The argument, or at least its part about which I expressed concerns,
> was to use exclusively the icons provided by the toolkit+desktop that
> happen to be in use.  That's an entirely different matter, if we want
> to make it pour policy.

Adding a user option disabling the toolkit-desktop icons and switching 
to the fallback shouldn't be too hard.

But I think it's worth our effort to try to integrate first. It's what 
users generally expect from applications, and the effect is that the 
program fits the desktop environment better. I hear this sentiment is 
particularly strong among macOS users.

Re: "Why is emacs so square?"

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On GTK, we're already there. Since 22.2, apparently. Only we haven't
> been paying attention to keeping this feature in proper maintenance.

By the way, etc/images/README says:

* The default GTK icons were not overridden by the GNOME theme due to
a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
circulation, the GTK icons should be replaced with the equivalent
GNOME icons.

Does that mean there is some action that was planned but never
performed?  Gnome 2.16 was released in 2006.

Emacs on my macOS machine seems to use the icons from etc/images.  On
GNU/Linux (GTK) there is a different set of icons which arguably look
more "modern".

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Apr 2020 11:42:44 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> By the way, etc/images/README says:
> 
> * The default GTK icons were not overridden by the GNOME theme due to
> a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
> circulation, the GTK icons should be replaced with the equivalent
> GNOME icons.
> 
> Does that mean there is some action that was planned but never
> performed?  Gnome 2.16 was released in 2006.

Please read this longish old discussion:

  https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00258.html

The answer to this question might be buried somewhere in it.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 23.04.2020 18:04, Eli Zaretskii wrote:
>> From: Stefan Kangas<stefan@marxist.se>
>> Date: Thu, 23 Apr 2020 11:42:44 +0200
>> Cc: Eli Zaretskii<eliz@gnu.org>, Clément Pit-Claudel<cpitclaudel@gmail.com>,
>> 	Emacs developers<emacs-devel@gnu.org>
>>
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>>
>> By the way, etc/images/README says:
>>
>> * The default GTK icons were not overridden by the GNOME theme due to
>> a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
>> circulation, the GTK icons should be replaced with the equivalent
>> GNOME icons.
>>
>> Does that mean there is some action that was planned but never
>> performed?  Gnome 2.16 was released in 2006.
> Please read this longish old discussion:
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00258.html
> 
> The answer to this question might be buried somewhere in it.

I've made an attempt, but the discussion is about copyright and 
providence of files, whereas the note seems to be about some functional 
problem.

I don't really understand it what it recommends we do now. It would seem 
as if GNOME icons can override GTK ones now (in some case where it 
couldn't before (?)), we could distribute GTK icons now and rely on 
GNOME to override them as appropriate?

Re: "Why is emacs so square?"

[Alan Third]

On Thu, Apr 23, 2020 at 11:42:44AM +0200, Stefan Kangas wrote:
> Emacs on my macOS machine seems to use the icons from etc/images.  On
> GNU/Linux (GTK) there is a different set of icons which arguably look
> more "modern".

I could be wrong, but I think some distributions swap in different
images so they better match the default look of their desktop.
-- 
Alan Third

Re: "Why is emacs so square?"

[Juan José García-Ripoll]

Eli Zaretskii <eliz@gnu.org> writes:
> "Standard" as in "subject to change without notice" each time the
> vendor decides to change the look-and-feel (which happens roughly
> every 2 to 3 years).

In Windows there are no standard icons, but a few ones signifying
warnings
(https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona)

This said, there are some DLLs that have broad sets of icons and that
are available, some since Windows 95, some since Windows XP. They have
not changed and can be used
https://www.digitalcitizen.life/where-find-most-windows-10s-native-icons
This webpage provides a reference by library and code
https://diymediahome.org/windows-icons-reference-list-with-details-locations-images/
However, the default set of icons is obviously deficient in that it does
not provide the icons an editor application requires: open, save, print,
etc.

Definitely I would not recommend this path, but I would encourage having
some higher resolution icons available in PNG format, for those who use
them (I disable toolbar in my computers).

Cheers

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Wed, Apr 22, 2020 at 9:14 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Speaking of other platforms, I wonder if Windows and macOS also have
> have standard sets of icons.
>
> It would make our task easier (and the end result more native-looking)
> if we could use a similar approach.
>

Apple publishes a set of system icons for macOS (and its other OS's, if
that matters to anyone) as part of it's Human Interface Guidelines. These
are tweaked and updated with OS version, but usually are stable over
several major versions. The current set can be found here:
https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/system-icons/


HTH,
~Chad

[-- Attachment #2: Type: text/html, Size: 1168 bytes --]

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 17:29, Eli Zaretskii wrote:
> especially since that
> toolkit is troubled and many users avoid building with it for that
> reason.

Also, I think we're planning (at least as a wishlist item) to solve this 
my making a "proper" GTK backend instead of removing it.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 19:16:48 +0300
> 
> On 22.04.2020 17:29, Eli Zaretskii wrote:
> > especially since that
> > toolkit is troubled and many users avoid building with it for that
> > reason.
> 
> Also, I think we're planning (at least as a wishlist item) to solve this 
> my making a "proper" GTK backend instead of removing it.

Nothing practical, AFAIK.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Wed, 22 Apr 2020 19:16:48 +0300, Dmitry Gutov <dgutov@yandex.ru> said:

    Dmitry> On 22.04.2020 17:29, Eli Zaretskii wrote:
    >> especially since that
    >> toolkit is troubled and many users avoid building with it for that
    >> reason.

    Dmitry> Also, I think we're planning (at least as a wishlist item) to solve
    Dmitry> this my making a "proper" GTK backend instead of removing it.

Making a proper GTK backend will not remove the reason that people
build with lucid, which is wanting emacs to be able to survive X
disconnects, unless we have evidence that proper GTK works in that
scenario.

It will help with things like HiDPI autoscaling, and maybe frame
resizing.

Someone in this thread mentioned they were working on a 'proper' GTK
backend, is that anywhere near useable yet?

Robert

Re: "Why is emacs so square?"

[Iñigo Serna]

On 22 April 2020 at 18:29 +02, Robert Pluim <rpluim@gmail.com> wrote:

> Someone in this thread mentioned they were working on a 'proper' GTK
> backend, is that anywhere near useable yet?

I've been lucky enough to test Po Lu's work over the last couple of
weeks, and although it's still WIP and there are still things to work on
- in my tests, mainly related to the keyboard - the result is quite stable,
and visually excellent.
For instance, look at the screenshot he attached a couple of days ago to
one of his first emails in this thread.

I don't want to steal the attention Po Lu deserves, so I won't comment
any further, and let him to show it by himself, but I'm really excited
with his work.

Regards,
Iñigo

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Wed, 22 Apr 2020 20:02:16 +0200, Iñigo Serna <inigoserna@gmx.com> said:

    Iñigo> On 22 April 2020 at 18:29 +02, Robert Pluim <rpluim@gmail.com> wrote:
    >> Someone in this thread mentioned they were working on a 'proper' GTK
    >> backend, is that anywhere near useable yet?

    Iñigo> I've been lucky enough to test Po Lu's work over the last couple of
    Iñigo> weeks, and although it's still WIP and there are still things to work on
    Iñigo> - in my tests, mainly related to the keyboard - the result is quite stable,
    Iñigo> and visually excellent.
    Iñigo> For instance, look at the screenshot he attached a couple of days ago to
    Iñigo> one of his first emails in this thread.

    Iñigo> I don't want to steal the attention Po Lu deserves, so I won't comment
    Iñigo> any further, and let him to show it by himself, but I'm really excited
    Iñigo> with his work.

As am I. Thereʼs no hurry, but I look forward to testing it.

Robert

Re: "Why is emacs so square?"

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:


> I don't think I follow.  Where can I find this "GNOME theme"?  It's
> not part of the Emacs release tarball, is it?

GTK has their own stylesheet system.  I believe that's what Dimitry was
refering to.

> What exactly do you mean by "icons follow the theme"? how does a theme
> affect icons?

It's common practice for GTK themes that change the look-and-feel a lot
to provide an accompanying XDG icon theme, and that's what the icons in
`x-gtk-stock-map` obey.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Someone™ needs to invest the time and effort to figure out the legal
> issues, find the icons that we want out of those which are legally
> fit, and post the resulting information.  We did that process at the
> time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> wasn't easy.
>
> Alternatively, someone could create our own icons, in which case they
> could be even prettier than the ones pointed out here.

Would it make sense to add an entry about this to the TODO file?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 17 Apr 2020 09:36:15 +0200
> Cc: ndame <ndame@protonmail.com>, yandros@gmail.com, 
> 	Emacs developers <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > Alternatively, someone could create our own icons, in which case they
> > could be even prettier than the ones pointed out here.
> 
> Would it make sense to add an entry about this to the TODO file?

Sure, why not?  However, the entry would be more useful if it listed
the necessary requirements, legal and otherwise.

Thanks.

Re: "Why is emacs so square?"

[ndame]

>
> Someone™ needs to invest the time and effort to figure out the legal
> issues, find the icons that we want out of those which are legally
> fit, and post the resulting information. We did that process at the
> time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> wasn't easy.

What was the problem exactly? Gnome is a venerable free software
project, so I assume they pay attention to proper licensing.

Isn't their icons safe to use if they publish them with a GPL2 license?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 17 Apr 2020 08:50:07 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "dgutov@yandex.ru" <dgutov@yandex.ru>, "yandros@gmail.com" <yandros@gmail.com>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >
> > Someone™ needs to invest the time and effort to figure out the legal
> > issues, find the icons that we want out of those which are legally
> > fit, and post the resulting information. We did that process at the
> > time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> > wasn't easy.
> 
> What was the problem exactly? Gnome is a venerable free software
> project, so I assume they pay attention to proper licensing.

I'm sorry, I don't remember.  This was many years ago.  Please look in
the archives.

> Isn't their icons safe to use if they publish them with a GPL2 license?

IANAL, but I think it has to be GPL v2+ at least.  And perhaps we
would also need the copyright assigned to the FSF.

Once again, this is a non-trivial job to do, a discussion in a mailing
list will not solve it, trust me.

Re: "Why is emacs so square?"

[ndame]

>
> IANAL, but I think it has to be GPL v2+ at least. And perhaps we
> would also need the copyright assigned to the FSF.
>

The Gnome icons have GPL2 license already, so hopefully Richard can
enlighten us if copyright assignment of them to the FSF is necessary
or not.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The Gnome icons have GPL2 license already,

Is it GPL version-2-only or GPL version-2-or-later?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 17 Apr 2020 22:04:03 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> The Gnome icons have GPL2 license already,

    Richard> Is it GPL version-2-only or GPL version-2-or-later?

I think wikimedia is
outdated. <https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING>
says:

    This work is licenced under the terms of either the GNU LGPL v3 or
    Creative Commons Attribution-Share Alike 3.0 United States License.

    To view a copy of the CC-BY-SA licence, visit
    http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
    Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

    When attributing the artwork, using "GNOME Project" is enough.
    Please link to http://www.gnome.org where available.

(no "or later" clause, though, unless that transitively comes in via
LGPL-3 or GPL-3).

Robert

Re: "Why is emacs so square?"

[ndame]

>
> I think wikimedia is outdated.

The Gnome icons at https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
are apparently for an earlier, obsolete version. I downloaded the indicated
version (gnome-icon-theme 2.20.0) and the files in it were last changed in 2007,
but the icons still look nice.

Emacs could benefit from using these icons too, even if they are obsolete,
because they are consistent and look good.

Re: Improving icons shipped with Emacs (was: "Why is emacs so square?")

[Po Lu]

ndame <ndame@protonmail.com> writes:

> The Gnome icons at https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
> are apparently for an earlier, obsolete version. I downloaded the indicated
> version (gnome-icon-theme 2.20.0) and the files in it were last changed in 2007,
> but the icons still look nice.
>
> Emacs could benefit from using these icons too, even if they are obsolete,
> because they are consistent and look good.

Agreed.  We could also add more GTK icons to x-gtk-stock-map as a temporary
measure for right now, since they are the icons that are used in X11/GTK
builds of Emacs, and my anecdotal experience tells me that's the version
of Emacs most beginners are likely to use.

In the long term, we really need to get rid of the legacy icons, many of
which are derived from the original X Window System distribution, and
are beginning to look highly out-of-date.

Re: Improving icons shipped with Emacs

[Po Lu]

By

> Agreed.  We could also add more GTK icons to x-gtk-stock-map as a temporary
> measure for right now, since they are the icons that are used in X11/GTK
> builds of Emacs, and my anecdotal experience tells me that's the version
> of Emacs most beginners are likely to use.

I meant

> Agreed.  We could also add more GTK icons to x-gtk-stock-map as a temporary
> measure for right now, since they are the icons that are used in X11+GTK
> builds of Emacs, and my anecdotal experience tells me that's the version
> of Emacs most beginners are likely to use.

Re: Improving icons shipped with Emacs (was: "Why is emacs so square?")

[ndame]

> > Emacs could benefit from using these icons too, even if they are obsolete,
> > because they are consistent and look good.
>
> Agreed. We could also add more GTK icons to x-gtk-stock-map as a temporary
> measure for right now, since they are the icons that are used in X11/GTK
> builds of Emacs, and my anecdotal experience tells me that's the version
> of Emacs most beginners are likely to use.

I wonder if icons in an obsolete gnome branch can be relicensed. It's GPL2
currently.

It has a standard GPL2 copying file in the tree and no more:

https://launchpad.net/gnome-icon-theme/+milestone/2.20.0

Does a standard GPL2 file implies later GPL versions too?

If not then they probably woudn't mind adding a README file saying "GPL2 and
later" the question is if they want to bother with this.

Re: Improving icons shipped with Emacs

[Po Lu]

ndame <ndame@protonmail.com> writes:

> Does a standard GPL2 file implies later GPL versions too?

No, sadly.
> If not then they probably woudn't mind adding a README file saying "GPL2 and
> later" the question is if they want to bother with this.

Someone from the FSF could perhaps contact them. They might even be
willing to assign copyright to the FSF.

Re: Improving icons shipped with Emacs

[ndame]

>
> Someone from the FSF could perhaps contact them. They might even be
> willing to assign copyright to the FSF.

The tar.gz file for the Gnome 2 icons has an AUTHORS file with names
and email addresses:

https://launchpad.net/gnome-icon-theme/main/2.20.0/+download/gnome-icon-theme-2.20.0.tar.gz


Richard, don't you want to ask them to add a "GPL2 and later" (you probably know the exact
wording needed) line to the README file of this branch?

You asking them may have more weight.

Re: Improving icons shipped with Emacs

[Po Lu]

ndame <ndame@protonmail.com> writes:

> The tar.gz file for the Gnome 2 icons has an AUTHORS file with names
> and email addresses:
> https://launchpad.net/gnome-icon-theme/main/2.20.0/+download/gnome-icon-theme-2.20.0.tar.gz

Hmm thanks, I'll take a look.
> Richard, don't you want to ask them to add a "GPL2 and later" (you probably know the exact
> wording needed) line to the README file of this branch?

That would be nice.
> You asking them may have more weight.

Yeah.

Re: Improving icons shipped with Emacs

[ndame]

>
> > The tar.gz file for the Gnome 2 icons has an AUTHORS file with names
> > and email addresses:
> > https://launchpad.net/gnome-icon-theme/main/2.20.0/+download/gnome-icon-theme-2.20.0.tar.gz
>
> Hmm thanks, I'll take a look.

Actually, the latest version linked from the Gnome wiki was not the latest version of
the 2.x branch.

It's this:

https://launchpad.net/gnome-icon-theme/main/2.91.93/+download/gnome-icon-theme-2.91.93.tar.gz

Released in 2011.

It has an updated COPYING saying:

"GNOME icon theme is distributed under the terms of either GNU LGPL v.3
or Creative Commons BY-SA 3.0 license."


So they should be asked to change it to "GNU LGPL v.3 and later" and then I guess Emacs
can use it.

Re: Improving icons shipped with Emacs

[Po Lu]

ndame <ndame@protonmail.com> writes:

>>
>> > The tar.gz file for the Gnome 2 icons has an AUTHORS file with names
>> > and email addresses:
>> > https://launchpad.net/gnome-icon-theme/main/2.20.0/+download/gnome-icon-theme-2.20.0.tar.gz
>>
>> Hmm thanks, I'll take a look.
>
> Actually, the latest version linked from the Gnome wiki was not the latest version of
> the 2.x branch.
>
> It's this:
>
> https://launchpad.net/gnome-icon-theme/main/2.91.93/+download/gnome-icon-theme-2.91.93.tar.gz
>
> Released in 2011.
>
> It has an updated COPYING saying:
>
> "GNOME icon theme is distributed under the terms of either GNU LGPL v.3
> or Creative Commons BY-SA 3.0 license."
>
>
> So they should be asked to change it to "GNU LGPL v.3 and later" and then I guess Emacs
> can use it.

Nice.  RMS, could you please take a look at this?

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      > This work is licenced under the terms of either the GNU LGPL v3 or

If the icons would be part of the program, Emacs, that would be the
same situation as with Qt.  No good.

      > Creative Commons Attribution-Share Alike 3.0 United States License.

That is incompatible with every version of the GPL.  If the icons
would be part of the program, Emacs, that would be no good.

If the icons would NOT be part of the program, Emacs, then there
is no conflict.

The Emacs distribution contains many works, including textual, art,
and small programs, which are distinct from the program, Emacs.



      > To view a copy of the CC-BY-SA licence, visit
      > http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
      > Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 19.04.2020 05:20, Richard Stallman wrote:
>        > Creative Commons Attribution-Share Alike 3.0 United States License.
> 
> That is incompatible with every version of the GPL.  If the icons
> would be part of the program, Emacs, that would be no good.
> 
> If the icons would NOT be part of the program, Emacs, then there
> is no conflict.
> 
> The Emacs distribution contains many works, including textual, art,
> and small programs, which are distinct from the program, Emacs.

So, can we include them as "NOT part of the program"?

I think it's the usual approach when it comes to assets. And icons are 
not code.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 18 Apr 2020 22:20:39 -0400
> Cc: ndame@protonmail.com, emacs-devel@gnu.org
> 
>       > This work is licenced under the terms of either the GNU LGPL v3 or
> 
> If the icons would be part of the program, Emacs, that would be the
> same situation as with Qt.  No good.
> 
>       > Creative Commons Attribution-Share Alike 3.0 United States License.
> 
> That is incompatible with every version of the GPL.  If the icons
> would be part of the program, Emacs, that would be no good.
> 
> If the icons would NOT be part of the program, Emacs, then there
> is no conflict.
> 
> The Emacs distribution contains many works, including textual, art,
> and small programs, which are distinct from the program, Emacs.

What is the practical meaning of being "part of the program, Emacs" as
opposed to "being distinct from the program, Emacs"?  How does one
tell whether a given icon is in this or the other category?

E.g., we have a lot of icons in etc/images/.  We show these icons on
the tool bar and elsewhere when and where appropriate.  Are those
icons part of Emacs the program, or aren't they?

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What is the practical meaning of being "part of the program, Emacs" as
  > opposed to "being distinct from the program, Emacs"?  How does one
  > tell whether a given icon is in this or the other category?

It is a legal question.  If a file of code is under the GPL, the
GPL applies to the entire program or work that the file is part of.

But it does not apply to other, separate works that are distributed
WITH that program or work.  Separate in regard to copyright law, I
mean.

I don't know a simple way to describe this, sorry.

  > E.g., we have a lot of icons in etc/images/.  We show these icons on
  > the tool bar and elsewhere when and where appropriate.  Are those
  > icons part of Emacs the program, or aren't they?

I think it depends on how things work to display those images.
And I don't remember that.

When Emacs wants to display etc/images/attach.pbm, how does that work?
Does attach.pbm get somehow linked into Emacs?  Or does Emacs open
etc/images/attach.pbm at run time, read it, and display it?

With the first method, they are part of one combined work.

With the second method, it is valid to say they are two separate works
and treat them as such.

At least, such is the understanding I got from lawyers around 30 years ago.

With two _programs_, the issue is different.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org, ndame@protonmail.com
> Date: Sun, 19 Apr 2020 22:18:58 -0400
> 
>   > E.g., we have a lot of icons in etc/images/.  We show these icons on
>   > the tool bar and elsewhere when and where appropriate.  Are those
>   > icons part of Emacs the program, or aren't they?
> 
> I think it depends on how things work to display those images.
> And I don't remember that.
> 
> When Emacs wants to display etc/images/attach.pbm, how does that work?
> Does attach.pbm get somehow linked into Emacs?  Or does Emacs open
> etc/images/attach.pbm at run time, read it, and display it?

It's the latter.  More accurately, we look up the file in the
filesystem, then pass the full file name to an image library which we
link with Emacs, and that library reads it.  And many icon files come
with every Emacs tarball and in any binary distribution, of course.

> With the first method, they are part of one combined work.
> 
> With the second method, it is valid to say they are two separate works
> and treat them as such.

So since this is the second method, what are the legal requirements
from icon files that we bundle with Emacs?  Just a free license?  And
if so, what kind of license?  Are there any other requirements?

Thanks.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So since this is the second method, what are the legal requirements
  > from icon files that we bundle with Emacs?  Just a free license?

Yes.  Any free license will do, for the icons.

  >   And
  > if so, what kind of license?

No particular kind is required, but it shouldn't be a weird one.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[ndame]

Sent with ProtonMail Secure Email.

>
> > So since this is the second method, what are the legal requirements
>
> > from icon files that we bundle with Emacs? Just a free license?
>
> Yes. Any free license will do, for the icons.


I checked the KDE icons too and they have this text for license (excerpts):

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 3 of the License, or (at your option) any later version.


Clarification:

  The GNU Lesser General Public License or LGPL is written for
  software libraries in the first place. We expressly want the LGPL to
  be valid for this artwork library too.

  KDE Oxygen theme icons is a special kind of software library, it is an
  artwork library, it's elements can be used in a Graphical User Interface, or
  GUI.




It contains the later version clause too for LGPL, so I guess the problem
of icons is solved.


There is a choice too, both of these have this license. Emacs could even
offer a choice of icon themes for the user:


https://github.com/KDE/oxygen-icons/


https://github.com/KDE/breeze-icons/

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      > This library is free software; you can redistribute it and/or
      > modify it under the terms of the GNU Lesser General Public
      > License as published by the Free Software Foundation; either
      > version 3 of the License, or (at your option) any later version.

That is a free license, compatible with GPL 3, and will be compatible
with future GPL versions as well.

We've determined that the icons are separate works from Emacs.  So
we do not need their licenses to be compatible with any GPL versions.
We just need them to carry a reasonable free license.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There are also the KDE icon set, though it's LGPL 3 licensed.
  > I don't know if it's OK in Emacs:

If they are LGPL 3 only, I think they can't be part of a GPL-4-covered
work.  However, the icons Emacs uses may not actually be part of
Emacs, the program.  If they are not part of Emacs, the program, they
could have any license as long as it is free.  But I'd have to ask a
lawyer about it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Bob Newell]

> The other option, of course, is to look both modern and unique, but it's
> a harder proposition, especially without a graphical designer on the
> team. And this stuff gets outdated quickly.

That's the problem. What's hip today is passé tomorrow. The "modern"
look of Windows 3.1 is considered ancient and dated today. But do
today's GUIs offer more (or perhaps less!) user value?

In my initial attempt to be sarcastic, I unfortunately took too
extreme a position. so I'll say now that there is nothing wrong with
an Emacs GUI that provides true user value, and if it looks nice,
that's a plus. (But I too go to the extreme of pure text, no frills,
touchpad disabled, etc. ... it's what works for me.)

However I would (humbly this time) suggest that whatever is done in
terms of appearance not interfere with the things that make Emacs the
tool that it is.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Bob Newell]

> It could improve the square apperance if, for example, emacs provided
> some text
> properties to specify rounded corners with custom radius for
> background colors.

Oh yes, because everyone chooses Emacs for hipster graphics
rather than for a free, sophisticated tool that lets you get
work done.

You might want to try Notepad on Windows 10 or something.

-- 
Bob Newell
Honolulu, Hawai`i
- Via Gnus/BBDB/Org/Emacs/Linux

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 15, 2020, at 12:35, Bob Newell <bobnewell@bobnewell.net> wrote:
> 
> 
> 
>> It could improve the square apperance if, for example, emacs provided
>> some text
>> properties to specify rounded corners with custom radius for
>> background colors.
> 
> Oh yes, because everyone chooses Emacs for hipster graphics
> rather than for a free, sophisticated tool that lets you get
> work done.
> 
> You might want to try Notepad on Windows 10 or something.

Or you might want to think about how to provide a way to accomplish that?

That's probably more in the spirit of free software than to send people to use a non free tool, isn't it ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Bob Newell <bobnewell@bobnewell.net>
> Date: Tue, 14 Apr 2020 17:35:06 -1000
> 
> You might want to try Notepad on Windows 10 or something.

Which won't help, because the Windows 10 look and feel doesn't include
rounded corners of windows, at least not by default.

Re: "Why is emacs so square?"

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

I think the challenge would be in coming up with an approach which won't
make the terminal (non-gui) version drift from the GUI version too much.
Changing the button styles etc in the GUI menu and perhaps updating toolbar
icons etc is probably not too hard, but you cannot do much with things like
'buttons' in widgets etc (such as those used with customize) without having
to have completely different code for rendering in GUI and rendering in
terminal. This would potentially blow out maintenance and create two code
bases to manage and lets face it, one is more than enough.

I think part of the reason the GUI menus and toolbar might look dated to
many is that nearly all experienced and long-term users I know turn off the
menus and toolbar, so never see them. It has been years since I've used
either. For me, the only 'buttons' I see are the widget style buttons and
these are not really buttons - they are really text 'fake' buttons. I would
also be a little concerned about impact any attempt to change these might
have on performance (we already have quite a long thread about rendering
performance).

Just my 2 cents....


On Wed, 15 Apr 2020 at 16:35, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Bob Newell <bobnewell@bobnewell.net>
> > Date: Tue, 14 Apr 2020 17:35:06 -1000
> >
> > You might want to try Notepad on Windows 10 or something.
>
> Which won't help, because the Windows 10 look and feel doesn't include
> rounded corners of windows, at least not by default.
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2187 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Wed, 15 Apr 2020 23:57:18 +1000
> Cc: Bob Newell <bobnewell@bobnewell.net>, Emacs developers <emacs-devel@gnu.org>
> 
> I think the challenge would be in coming up with an approach which won't make the terminal (non-gui)
> version drift from the GUI version too much. Changing the button styles etc in the GUI menu and perhaps
> updating toolbar icons etc is probably not too hard, but you cannot do much with things like 'buttons' in
> widgets etc (such as those used with customize) without having to have completely different code for
> rendering in GUI and rendering in terminal.

Maybe I'm missing something, but AFAIK we already have different code
for rendering this stuff in GUI and in text-mode frames. The GUI code
inserts an image and simulates the 3D "raised button" appearance,
whereas the text-mode code shows some ASCII art instead.

Or maybe I don't understand what differences you had in mind.

> I think part of the reason the GUI menus and toolbar might look dated to many is that nearly all experienced
> and long-term users I know turn off the menus and toolbar, so never see them.

Well, I don't, FWIW.

> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
> they are really text 'fake' buttons.

Not sure what you mean by "text fake buttons".  We show a 3D
appearance on button widgets; if that's not real buttons, then what
should real buttons look like, in your opinion?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 15/04/2020 10.09, Eli Zaretskii wrote:
>> From: Tim Cross <theophilusx@gmail.com>
>> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
>> they are really text 'fake' buttons.
> 
> Not sure what you mean by "text fake buttons".  We show a 3D
> appearance on button widgets

Sometimes we do and sometimes we don't.  With my current emacs configuration, for example, I get buttons that look like this on graphical frames:

 Operate on all settings in this buffer:
 [ Revert... ] [ Apply ] [ Apply and Save ]

I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:

  echo "(require 'cus-edit)" > ~/.emacs
  emacsclient --alternate-editor="" --create-frame 

In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?

Should I open a bug report?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 13:03:03 -0400
> 
>  Operate on all settings in this buffer:
>  [ Revert... ] [ Apply ] [ Apply and Save ]
> 
> I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:
> 
>   echo "(require 'cus-edit)" > ~/.emacs
>   emacsclient --alternate-editor="" --create-frame 
> 
> In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?
> 
> Should I open a bug report?

I think it's a bug in your ~/.emacs, so a bug report will hardly solve
it.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 13.22, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 13:03:03 -0400
>>
>>  Operate on all settings in this buffer:
>>  [ Revert... ] [ Apply ] [ Apply and Save ]
>>
>> I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:
>>
>>   echo "(require 'cus-edit)" > ~/.emacs
>>   emacsclient --alternate-editor="" --create-frame 
>>
>> In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?
>>
>> Should I open a bug report?
> 
> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
> it.

I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 14:11:40 -0400
> 
> > I think it's a bug in your ~/.emacs, so a bug report will hardly solve
> > it.
> 
> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.

Of course.  Which is why I think I understand the issue.

> The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.

Initialization of stuff that depends on GUI frames and should work in
client frames needs to be done in server-after-make-frame-hook.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 14.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 14:11:40 -0400
>>
>>> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
>>> it.
>>
>> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
> 
> Of course.  Which is why I think I understand the issue.
> 
>> The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.
> 
> Initialization of stuff that depends on GUI frames and should work in
> client frames needs to be done in server-after-make-frame-hook.

I think I don't understand this part :/

To be clear, the bug that I'm talking about is that, when using the Emacs server, requiring cus-edit during initialization causes buttons to be displayed as text, not as 3D buttons.
It's really easy to run into this without realizing it.  For example, installing the `validate' package from Elpa will do it:

  emacs -Q --eval '(setq user-emacs-directory "/tmp/emacs-sandbox")' \
    -l package \
    --eval "(package-refresh-contents)" \
    --eval "(package-initialize)" \
    --eval "(package-install 'validate)" \
    --daemon

  emacsclient --create-frame # This frame doesn't use 3D buttons in e.g. customize-face

Alternatively, installing the package manually and putting `(require 'validate)` in your .emacs to be able to use (validate-setq tab-width 4) will also cause issues.

What am I missing?
Clément.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 14.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 14:11:40 -0400
>>
>>> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
>>> it.
>>
>> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
> 
> Of course.  Which is why I think I understand the issue.

Following up on my previous message, I'd argue that the following is also a problem, btw:

  emacs -Q --daemon
  emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
  emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET

The second customization window doesn't have 3D buttons.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 15:52:54 -0400
> 
>   emacs -Q --daemon
>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET
> 
> The second customization window doesn't have 3D buttons.

Because your Emacs was started as a daemon.

Re: "Why is emacs so square?"

[Stefan Monnier]

>>   emacs -Q --daemon
>>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x
>> customize-face RET bold RET then exit
>>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this
>> window, run M-x customize-face RET bold RET
>> 
>> The second customization window doesn't have 3D buttons.
>
> Because your Emacs was started as a daemon.

No, it's only because the first use of customize was on a tty frame.
The same happens if you

    emacs -Q -nw
    M-x customize-face ...
    M-x make-frame-on-display ...
    M-x customize-face ...


-- Stefan

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 03.09, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 15:52:54 -0400
>>
>>   emacs -Q --daemon
>>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
>>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET
>>
>> The second customization window doesn't have 3D buttons.
> 
> Because your Emacs was started as a daemon.

As Stefan pointed out, this isn't due to the daemon.  But even so, starting Emacs as a daemon shouldn't break 3D buttons.

A few messages ago, the following discussion happened:

>> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
>> they are really text 'fake' buttons.
> 
> Not sure what you mean by "text fake buttons".  We show a 3D
> appearance on button widgets

I was just pointing out that in may cases we don't show a 3D appearance on button widgets.  You also wrote:

> Maybe I'm missing something, but AFAIK we already have different code
> for rendering this stuff in GUI and in text-mode frames. The GUI code
> inserts an image and simulates the 3D "raised button" appearance,
> whereas the text-mode code shows some ASCII art instead.
The code is here:

(defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
					     '(("unspecified" . unspecified))))
  "If non-nil, indicate active buttons in a raised-button style.
Otherwise use brackets."
  :type 'boolean
  :version "21.1"
  :group 'custom-buffer
  :set (lambda (variable value)
	 (custom-set-default variable value)
	 (setq custom-button
	       (if value 'custom-button 'custom-button-unraised))
	 (setq custom-button-mouse
	       (if value 'custom-button-mouse 'highlight))
	 (setq custom-button-pressed
	       (if value
		   'custom-button-pressed
		 'custom-button-pressed-unraised))))

This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 10:13:58 -0400
> Cc: emacs-devel@gnu.org
> 
> This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?

I don't know.  AFAIK, we don't have infrastructure for deciding when
stuff like that needs to be re-evaluated and how to use different
results for different frames.  If someone wants to work on such
infrastructure, I think it will bring us a step closer to being able
to support different GUI frame types (like GTK, w32, NS, etc.) in the
same session.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

On 17/04/2020 10.46, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 10:13:58 -0400
>> Cc: emacs-devel@gnu.org
>>
>> This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?
> 
> I don't know.  AFAIK, we don't have infrastructure for deciding when
> stuff like that needs to be re-evaluated and how to use different
> results for different frames.  If someone wants to work on such
> infrastructure, I think it will bring us a step closer to being able
> to support different GUI frame types (like GTK, w32, NS, etc.) in the
> same session.

I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.  The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.

We'd also need a similar trick for check-boxes and the like.

WDYT?

[-- Attachment #2: custom-raised-buttons.diff --]
[-- Type: text/x-patch, Size: 1865 bytes --]

diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index d3d17fda7a..2f29a00de2 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -1599,8 +1599,7 @@ custom-search-field
   :version "24.1"
   :group 'custom-buffer)
 
-(defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
-					     '(("unspecified" . unspecified))))
+(defcustom custom-raised-buttons t
   "If non-nil, indicate active buttons in a raised-button style.
 Otherwise use brackets."
   :type 'boolean
@@ -2113,7 +2112,8 @@ custom-magic-reset
 (defface custom-button
   '((((type x w32 ns) (class color))	; Like default mode line
      :box (:line-width 2 :style released-button)
-     :background "lightgrey" :foreground "black"))
+     :background "lightgrey" :foreground "black")
+    (t :inherit custom-button-unraised))
   "Face for custom buffer buttons if `custom-raised-buttons' is non-nil."
   :version "21.1"
   :group 'custom-faces)
@@ -2137,17 +2137,23 @@ custom-button-unraised
   :version "22.1"
   :group 'custom-faces)
 
+(defface custom-button-mouse-unraised
+  '((t :inherit highlight))
+  "Mouse face for custom buffer buttons if `custom-raised-buttons' is nil."
+  :version "22.1"
+  :group 'custom-faces)
+
 (setq custom-button
       (if custom-raised-buttons 'custom-button 'custom-button-unraised))
 
 (setq custom-button-mouse
-      (if custom-raised-buttons 'custom-button-mouse 'highlight))
+      (if custom-raised-buttons 'custom-button-mouse 'custom-button-mouse-unraised))
 
 (defface custom-button-pressed
   '((((type x w32 ns) (class color))
      :box (:line-width 2 :style pressed-button)
      :background "lightgrey" :foreground "black")
-    (t :inverse-video t))
+    (t :inherit custom-button-pressed-unraised))
   "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
   :version "21.1"
   :group 'custom-faces)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 11:27:56 -0400
> 
> > I don't know.  AFAIK, we don't have infrastructure for deciding when
> > stuff like that needs to be re-evaluated and how to use different
> > results for different frames.  If someone wants to work on such
> > infrastructure, I think it will bring us a step closer to being able
> > to support different GUI frame types (like GTK, w32, NS, etc.) in the
> > same session.
> 
> I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.

Faces were always per-frame (although when you customize a face, it
changes on all frames), but faces are just the tip of the iceberg.
The general problem with GUI features is much wider.  I thought you
were talking about the more general problem.

> The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.
> 
>  (defface custom-button-pressed
>    '((((type x w32 ns) (class color))
>       :box (:line-width 2 :style pressed-button)
>       :background "lightgrey" :foreground "black")
> -    (t :inverse-video t))
> +    (t :inherit custom-button-pressed-unraised))
>    "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
>    :version "21.1"
>    :group 'custom-faces)

Why a separate face, instead of a separate definition of the same face
for non-GUI displays?

Anyway, the condition should not be on frame types, but rather on
capabilities, IMO.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 11.38, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 11:27:56 -0400
>>
>>> I don't know.  AFAIK, we don't have infrastructure for deciding when
>>> stuff like that needs to be re-evaluated and how to use different
>>> results for different frames.  If someone wants to work on such
>>> infrastructure, I think it will bring us a step closer to being able
>>> to support different GUI frame types (like GTK, w32, NS, etc.) in the
>>> same session.
>>
>> I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.
> 
> Faces were always per-frame (although when you customize a face, it
> changes on all frames), but faces are just the tip of the iceberg.
> The general problem with GUI features is much wider.  I thought you
> were talking about the more general problem.

I'm talking only about the OP's problem, which was that buttons were not displayed in 3D.

>> The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.
>>
>>  (defface custom-button-pressed
>>    '((((type x w32 ns) (class color))
>>       :box (:line-width 2 :style pressed-button)
>>       :background "lightgrey" :foreground "black")
>> -    (t :inverse-video t))
>> +    (t :inherit custom-button-pressed-unraised))
>>    "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
>>    :version "21.1"
>>    :group 'custom-faces)
> 
> Why a separate face, instead of a separate definition of the same face
> for non-GUI displays?

To be able to honor the custom-raised-buttons setting.  I wouldn't design it that way, but that's where we are.

> Anyway, the condition should not be on frame types, but rather on
> capabilities, IMO.

Agreed.
Do you know how the problem with square brackets could be solved?  Currently the custom-raised-buttons setting is used to chose a face and to decide whether to insert square brackets around buttons. Is there a clean way to make these brackets display only in text terminals?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 11:52:56 -0400
> 
> Do you know how the problem with square brackets could be solved?

Sorry, no.  Custom was always a dark corner for me.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 13.16, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 11:52:56 -0400
>>
>> Do you know how the problem with square brackets could be solved?
> 
> Sorry, no.  Custom was always a dark corner for me.

Me too, but fortunately this isn't a question about custom, it's a question about features about the display engine.  

There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 13:40:29 -0400
> 
> There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.

I don't think I understand the problem.  Faces can have different
definitions on different frames, so what is the problem, exactly?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 13.45, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 13:40:29 -0400
>>
>> There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.
> 
> I don't think I understand the problem.  Faces can have different
> definitions on different frames, so what is the problem, exactly?

The problem is to indicate that a string is a button on a text terminal.  Currently, custom does this by writing the string "[button]" with an underline on text terminals, and "button" with a raised look on graphical terminals.

This is done by inserting different text in the buffer depending on whether the display supports the `:box' face property.  Because of this, a customization buffer created on a text terminal shows "[button]" instead of "button" when displayed on a graphical terminal.

The question is: is there a way to insert something in a buffer that will display as "[button]" when shown on a text terminal and as "button" when shown on a graphical terminal?
I thought of using something like (propertize "[" 'display '(when (display-graphic-p) . "")), but it doesn't work well: when the buffer is shown on two frames (one graphical, one non-graphical), it doesn't look right in both.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 13:57:05 -0400
> 
> The question is: is there a way to insert something in a buffer that will display as "[button]" when shown on a text terminal and as "button" when shown on a graphical terminal?

Did you try using an image?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 17 Apr 2020 21:36:27 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Did you try using an image?

Or a window-specific overlay?

And btw, in the conditional 'display' spec, did you call
display-graphic-p with a frame argument?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 14.51, Eli Zaretskii wrote:
>> Date: Fri, 17 Apr 2020 21:36:27 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> Did you try using an image?

I did not.  Interesting thought! But since I need the "[" on graphical terminals, I'd use a replacement spec that says to show an empty image on graphical terminals, is that right?

> Or a window-specific overlay?

Interesting! But wouldn't I need to re-create the overlays every time the buffer is displayed in a new window?

> And btw, in the conditional 'display' spec, did you call
> display-graphic-p with a frame argument?

Yes, here's the full test:

(defface my-button
  '((((type x w32 ns) (class color))
     :box (:line-width -1 :style released-button)
     :background "lightgrey" :foreground "black")
    (t :inherit underline))
  "Button face"
  :group 'flycheck-faces)

(with-current-buffer (get-buffer-create "button")
  (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
  (insert (propertize "button" 'face 'my-button))
  (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

I put this code in button.el, then I run emacs like this:

  emacs -Q -nw -l button.el 

I display the buffer in the terminal; it looks like this: [button] with "button" underlined

Then I use M-x make-frame-on-display :0 to show the same buffer in a graphical frame.  I see this: [button] with a 3D face on "button".  If I move the point, the brackets disappear on both frames (the terminal one and the graphic one.  If I switch back to the terminal frame, the brackets reappear on both frames.

Clément.

Re: "Why is emacs so square?"

[Stefan Monnier]

> (with-current-buffer (get-buffer-create "button")
>   (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
>   (insert (propertize "button" 'face 'my-button))
>   (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

My guess is that the (selected-frame) at the time the code is run might
not be the one you think.  Maybe we should change/fix that (we had the
same problem when computing the mode/header lines).


        Stefan

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 16.14, Stefan Monnier wrote:
>> (with-current-buffer (get-buffer-create "button")
>>   (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
>>   (insert (propertize "button" 'face 'my-button))
>>   (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))
> 
> My guess is that the (selected-frame) at the time the code is run might
> not be the one you think.  Maybe we should change/fix that (we had the
> same problem when computing the mode/header lines).

Doesn't look like it, from this test:

(with-current-buffer (get-buffer-create "button")
  (insert (propertize "[" 'display '(when (and (message "[%f] On frame %S: %S"
                                                        (float-time)
                                                        (selected-frame)
                                                        (display-graphic-p (selected-frame)))
                                               (display-graphic-p (selected-frame))) . "graphic")))
  (insert (propertize "button" 'face 'my-button))
  (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

Clicking in the graphical frame reevaluates in both, and the terminal one does see nil.  Clicking in the terminal frame reevaluates only there.  In both cases the display is updated in all windows (on all frames).

Re: "Why is emacs so square?"

[Andreas Schwab]

On Apr 15 2020, Tim Cross wrote:

> icons etc is probably not too hard, but you cannot do much with things like
> 'buttons' in widgets etc (such as those used with customize) without having
> to have completely different code for rendering in GUI and rendering in
> terminal.

I don't think that is a problem, they already have different rendering
today.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: "Why is emacs so square?"

[Emanuel Berg via Emacs development discussions.]

ndame wrote:

> A user on reddit [...]

https://www.reddit.com/r/emacs/comments/23vtvd/why_is_emacs_sosquare/

> It could improve the square apperance if, for example,
> emacs provided some text properties to specify rounded
> corners with custom radius for background colors.

The thing is, you only care for decorations for a very
short time. After that, you want it as to the point
as possible.

I'm not a GUI Emacs user, but I give you half right
because last time I saw the default GUI Emacs on X it
looked like a Windows 95 application.

OTOH I'm unsure if Emacs does its own buttons. It does?
Or do they conform to the underlying look and feel, in
which case maybe one should configure the underlying OS
(e.g., the window manager, graphical/widget toolkit,
Xresources etc).

My opinion is we should make Emacs look _so cool_, and
then when people start using it they'll just remove
everything (but continue to use Emacs).

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

Re: "Why is emacs so square?"

[Christopher Lemmer Webber]

"Why is emacs so square?"

 - It was the easiest way to delineate the M-x zone!
 - We needed a shape that would save us from fitting in the kill ring!
 - Yow!  Are we feeling square yet?
 - Is it because why is emacs so square though that you came to me?
 - Emacs' lisp lead to social stigmitization that meant it never was
   accepted into the cool crowd!

Re: "Why is emacs so square?"

[ndame]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

> Oh yes, because everyone chooses Emacs for hipster graphics
> rather than for a free, sophisticated tool that lets you get
> work done.

You may not care about visual appearance, but many people do and they want a tool which is pleasant to look at.

Even on the Emacs subreddit which is a place for active Emacs users people often post packages which pimp up Emacs:

https://preview.redd.it/nu0zfp2rcds41.png?width=1072&format=png&auto=webp&s=6913236a90c2315dcddd4a4224f7d72b1ab19d19

https://i.imgur.com/ZJW9UN4.png

[-- Attachment #2: Type: text/html, Size: 935 bytes --]

Re: "Why is emacs so square?"

[ndame]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

> This is because GTK+ has a bug that AFAIR they don't intend to fix
> because they don't consider our use of GTK+ important enough (or
> correct, for that matter).

Is it hard to fix the GTK side in Emacs, so it uses GTK correctly as
the GTK developers intended, so the bug doesn't occur?

[-- Attachment #2: Type: text/html, Size: 398 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 11:16:13 +0000
> From: ndame <ndame@protonmail.com>
> 
> > This is because GTK+ has a bug that AFAIR they don't intend to fix
> > because they don't consider our use of GTK+ important enough (or
> > correct, for that matter).
> 
> Is it hard to fix the GTK side in Emacs, so it uses GTK correctly as
> the GTK developers intended, so the bug doesn't occur?

Yes.

RE: "Why is emacs so square?"

[Drew Adams]

> I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.  It is hard to be enthusiastic about making
> these features more modern when the community seems to be divided on
> whether they should at all be present.  IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

+1

And count me as one vote for the menu-bar being
important, especially for discoverability.  The
tool-bar is less important, IMO, but I'd still
vote to keep it.

Re: "Why is emacs so square?"

[Joseph Garvin]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

I think part of the problem with things like the menu bar is that if you're
using emacs at all you are demonstrating a willingness to tolerate:

* A UI that doesn't look or behave like any other application
* Keyboard shortcuts inconsistent with every other application
* A bizarre ancient vocabulary inconsistent with every other application.
e.g. no Microsoft word user has ever considered themselves to have opened a
"buffer". They open "files". They move "windows" around, not "frames." They
cut and paste not kill and yank, etc.

You are basically making a commitment to being or becoming a power user. I
certainly would not have put up with it if I didn't think it was going to
save me a lot of time as a software developer (and it does, everyday). I
doubt anyone invests the mental effort to deal with learning emacs nowadays
unless this is their goal. If you just want to do "casual" text editing
emacs is a very weird choice in 2020.

If you're a new user the idea that seeing kill and yank in the menu bar as
options helps discoverablity doesn't really hold when already nothing is
named the way you expect or acts the way you expect. If you're an
experienced user, then I would guess that like me C-h f,v,k and blog posts
are 99% of your discoverablity experience.

On Thu, Apr 16, 2020, 9:58 AM Drew Adams <drew.adams@oracle.com> wrote:

> > I'd like to remind all of us that
> > there's a lot of "propaganda" out there telling everyone to turn off
> > GUI features such as the menu bar and the tool bar.  The network is
> > full of personal init files that "proudly" do that, and forums like
> > Reddit are full of such advice to every newbie who asks about
> > configuring their Emacs.  It is hard to be enthusiastic about making
> > these features more modern when the community seems to be divided on
> > whether they should at all be present.  IMO, we should first get our
> > act together and decide whether these features are important, and then
> > speak up according to those decisions when we see advice to the
> > contrary.
>
> +1
>
> And count me as one vote for the menu-bar being
> important, especially for discoverability.  The
> tool-bar is less important, IMO, but I'd still
> vote to keep it.
>
>

[-- Attachment #2: Type: text/html, Size: 2872 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joseph Garvin <joseph.h.garvin@gmail.com>
> Date: Thu, 16 Apr 2020 10:34:24 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, emacs-devel@gnu.org, stefan@marxist.se, 
> 	ndame@protonmail.com
> 
> I think part of the problem with things like the menu bar is that if you're using emacs at all you are
> demonstrating a willingness to tolerate:
> 
> * A UI that doesn't look or behave like any other application
> * Keyboard shortcuts inconsistent with every other application
> * A bizarre ancient vocabulary inconsistent with every other application. e.g. no Microsoft word user has ever
> considered themselves to have opened a "buffer". They open "files". They move "windows" around, not
> "frames." They cut and paste not kill and yank, etc.
> 
> You are basically making a commitment to being or becoming a power user. I certainly would not have put
> up with it if I didn't think it was going to save me a lot of time as a software developer (and it does, everyday).
> I doubt anyone invests the mental effort to deal with learning emacs nowadays unless this is their goal. If you
> just want to do "casual" text editing emacs is a very weird choice in 2020.

That's definitely something we should keep in mind, but what on earth
does it have to do with turning off the GUI elements of the Emacs UI?
Or with the advice to newbies to turn them off?

> If you're a new user the idea that seeing kill and yank in the menu bar as options helps discoverablity doesn't
> really hold when already nothing is named the way you expect or acts the way you expect. If you're an
> experienced user, then I would guess that like me C-h f,v,k and blog posts are 99% of your discoverablity
> experience.

I suggest to take a good look at the menu bar, since we don't have
Kill and Yank there for a long time.  We have Cut and Copy and Paste
instead.

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-04-16, at 17:34, Joseph Garvin <joseph.h.garvin@gmail.com> wrote:

> [...] If you just want to do "casual" text editing
> emacs is a very weird choice in 2020.

Unless you came for Org-mode (though this might not be exactly "casual"
- but necessarily "power-user-ish" either).

Just my 2 cents,

-- 
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

[Ahmed Khanzada]

Joseph, a few things come to mind from reading your email:

1. Terminal-based Vim is not like a modern application, yet is more
popular than Emacs.

2. The audience for Emacs are people interested in using free
software and Lisp to extend their text editing experience. Very few of
these will be "casual editors", and in fact the FSF provides libre casual
editing software through the GNOME project.

3. If Emacs was to become a "modern" app tomorrow, an editor extended
in Lisp still only has appeal for a minority of programmers, much like
the Lisp language itself. Most programmers looking for easy and modern
experiences will likely stick with Atom and Sublime.

4. Most of the push for a "modern look" comes from the desire for Emacs
to play more nicely with proprietary platforms. Rather, the goal of
Emacs is to support platforms like GNU/Linux. Platforms that respect
your freedom, and also do not push a corporate UI/UX vision of "modernity".

(Perhaps if we do move forward with modernization, we should think of
modernization in the context of something like GNOME rather than MacOS
or Windows. Surely Emacs could be a better citizen of GNOME.)

5. Given that many of the people complaining about how Emacs looks are not
submitting patches to fix the problem themselves, resources would be diverted
from actual functionality to "modernity".

6. By the time we do major code refactoring "modernizing" Emacs on the
major proprietary platforms, what is "modern" has now once again
changed, and our resources were put towards a project with a poor return on
investment.

Basically, I don't see a "modernizing" project playing out well. We will
spend extensive time and energy on a moving target, and even if we
succeed, our Lisp-based vision still has limited appeal. Additionally, I
don't think "modernizing" Emacs advances the cause of free software,
given that there are other more popular casual libre tools for text editing
that individuals can use.

Re: "Why is emacs so square?"

[martin rudalics]

 > (Perhaps if we do move forward with modernization, we should think of
 > modernization in the context of something like GNOME rather than MacOS
 > or Windows. Surely Emacs could be a better citizen of GNOME.)

Citizenship goes both ways.  The absence of responses for

https://gitlab.gnome.org/GNOME/mutter/-/issues/840

sadly indicates that GNOME doesn't care much about us.

martin

Re: "Why is emacs so square?"

[ndame]

>
> Citizenship goes both ways. The absence of responses for
>
> https://gitlab.gnome.org/GNOME/mutter/-/issues/840
>
> sadly indicates that GNOME doesn't care much about us.
>

Gnome shell also has a development list. A way forward can
be to post to that list politely asking for a workaround until
the issue is solved:

https://mail.gnome.org/mailman/listinfo/gnome-shell-list

The developers may be more likely to respond if the asking
for help is sent to a discussion list.

Re: "Why is emacs so square?"

[Stefan Kangas]

Ahmed Khanzada <me@enzu.ru> writes:

> 1. Terminal-based Vim is not like a modern application, yet is more
> popular than Emacs.

How do you know that Vim is more popular than Emacs?

> 3. If Emacs was to become a "modern" app tomorrow, an editor extended
> in Lisp still only has appeal for a minority of programmers

I think features matters more than extension language to most users.
For example, the popularity of Vim is unlikely to be based on the
appeal of an editor extended in Vimscript.

> 4. Most of the push for a "modern look" comes from the desire for Emacs
> to play more nicely with proprietary platforms.

Why do you believe that to be the case?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Ahmed Khanzada]

On Sat, 18 Apr 2020 16:02:35 -0700,
Stefan Kangas wrote:
> 
> Ahmed Khanzada <me@enzu.ru> writes:
> 
> > 1. Terminal-based Vim is not like a modern application, yet is more
> > popular than Emacs.
> 
> How do you know that Vim is more popular than Emacs?
>

https://insights.stackoverflow.com/survey/2019#development-environments-and-tools

Nearly 20% of programmers use vim, and around 3% use Emacs.

Visual Studio Code has 54%.

> > 3. If Emacs was to become a "modern" app tomorrow, an editor extended
> > in Lisp still only has appeal for a minority of programmers
> 
> I think features matters more than extension language to most users.
> For example, the popularity of Vim is unlikely to be based on the
> appeal of an editor extended in Vimscript.

That is fair enough. But for extensible editors, features are built by a
small group of folks interested in that sort of thing. A more
"mainstream" language usually means more extensions which means more features.

> 
> > 4. Most of the push for a "modern look" comes from the desire for Emacs
> > to play more nicely with proprietary platforms.
> 
> Why do you believe that to be the case?

I suppose this is a pure assumption on my part based on my anecdotal
experience. I hear more comments about Emacs not being a nice MacOS or
Windows application than a nice GNOME application, but that is just anecdotal
evidence, and is certainly skewed by the popularity of those platforms.

Re: "Why is emacs so square?"

[Po Lu]

Ahmed Khanzada <me@enzu.ru> writes:
> That is fair enough. But for extensible editors, features are built by a
> small group of folks interested in that sort of thing. A more
> "mainstream" language usually means more extensions which means more features.

I disagree.  The amount of extensions to an editor reflect the popularity
of the editor, not whether or not the editor's extension language is
"mainstream" or not.

Plus, Emacs Lisp has a bunch of nice goodies for Emacs, since the
language itself is seamlessly integrated with the editor it extends
(such as text properties in strings, buffer-local variables, et cetera).

I would also go as far as to say that writing Emacs programs is far
easier, and involves far less boilerplate, than writing extensions for,
say, VS Code:
-------------------------------------------------------------------------------
var setting: vscode.Uri = vscode.Uri.parse("untitled:" + "C:\summary.txt");
vscode.workspace.openTextDocument(setting).then((a: vscode.TextDocument) => {
    vscode.window.showTextDocument(a, 1, false).then(e => {
        e.edit(edit => {
            edit.insert(new vscode.Position(0, 0), "Your advertisement here");
        });
    });
}, (error: any) => {
    console.error(error);
    debugger;
});
------------------------------------versus------------------------------------
(with-current-buffer (find-file "~/summary.txt")
  (set-window-point (selected-window) (point-min))
  (insert "Your advertisement here"))
------------------------------------------------------------------------------

A better language wins extensions, not a "popular" language, and Emacs
Lisp is definitely more suited to extending editors than TypeScript.

Re: "Why is emacs so square?"

[Ahmed Khanzada]

On Sat, 18 Apr 2020 17:42:07 -0700,
> A better language wins extensions, not a "popular" language, and Emacs
> Lisp is definitely more suited to extending editors than TypeScript.

I certainly agree with everyone that Lisp is fantastic, and that
extending Emacs with Emacs Lisp is a great pleasure. And that Emacs Lisp
is certainly superior to any other alternative that I know of. So please
don't think I would want Emacs to use anything other than Lisp.

However, despite Lisp being extraordinarily powerful (truly a "better
language"), no dialect of Lisp is a top 10 language. It seems unlikely
to me that there is no correlation between that fact and the popularity
and accessibility of Emacs.

However, even if there is a correlation, determining the exact nature
and extent of correlation is difficult.

Re: "Why is emacs so square?"

[Po Lu]

Ahmed Khanzada <me@enzu.ru> writes:

> However, despite Lisp being extraordinarily powerful (truly a "better
> language"), no dialect of Lisp is a top 10 language. It seems unlikely
> to me that there is no correlation between that fact and the popularity
> and accessibility of Emacs.

Paul Graham has an insightful article here:
http://www.paulgraham.com/avg.html;  IMO, it's worth reading.

Plus, if you look inside the domain of "text editor extension
languages", Emacs Lisp is definitely one of the top-10 (assuming there
are 10 at all), and is also probably the most integrated one.

You can also extend Emacs in languages other than Emacs Lisp (the native
module support comes to mind), but at that point you're giving up
exactly what makes Emacs great.

> However, even if there is a correlation, determining the exact nature
> and extent of correlation is difficult.

Agreed.

Re: "Why is emacs so square?"

[ndame]

>
> A better language wins extensions, not a "popular" language, and Emacs
> Lisp is definitely more suited to extending editors than TypeScript.

I agree that Emacs is easier to program once you learned it, but
other editors, like VSCode, has the advantage that you don't have to
learn a quirky and unfamiliar language first.

Many developers know Javascript and even if one doesn't it's more similar
to mainstream languages than lisp, so extension writers mostly has to
learn the VSCode API only.

VScode has a very nice out of the box experience. If you want support
for a language then it's one click to install it and it installs the
necessary scaffolding too, like a language server for the language.

And it has Electron for display support which has a mature browser
engine behind it, so it can support advanced graphics features out
of the box on all the supported platforms.

Out of the box experience matters. Familiarity matters (e.g supporting
standard keys on the platfrom for cut and paste). Nice appearance matters.

No wonder lot of developers choose VScode:

https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code

Re: "Why is emacs so square?"

[Po Lu]

ndame <ndame@protonmail.com> writes:

> I agree that Emacs is easier to program once you learned it, but
> other editors, like VSCode, has the advantage that you don't have to
> learn a quirky and unfamiliar language first.

> Many developers know Javascript and even if one doesn't it's more similar
> to mainstream languages than lisp, so extension writers mostly has to
> learn the VSCode API only.

Here's the problem: You have to learn the VS Code API. I'd say learning
that, and becoming reasonably proficient at it takes longer than
skimming through the Emacs Lisp intro.

> VScode has a very nice out of the box experience. If you want support
> for a language then it's one click to install it and it installs the
> necessary scaffolding too, like a language server for the language.

We have several starter packs, with similarly nice OOTB experiences.
> And it has Electron for display support which has a mature browser
> engine behind it, so it can support advanced graphics features out
> of the box on all the supported platforms.

Electron is not free software (https://labs.parabola.nu/issues/1167),
and is definitely not as well suited to providing an integrated
experience like Emacs.

For instance, even if you render raw HTML inside VS Code, you would not
be able to grab the region using VSC APIs.  I'm not sure if the VSC API
allows interacting with the DOM, but from what I can tell, it can't.

There are also various other issues, with relying on a lower-level
abstraction for "nice graphics features" (the DOM) that is outside the
editors control.

> Out of the box experience matters. Familiarity matters (e.g supporting
> standard keys on the platfrom for cut and paste). Nice appearance matters.

We have Cua mode.  No, you don't need to have it enabled by default,
since it would result in unnecessary breakage for old users.  It would
be nice if the startup screen informed users of features such as the
(hypothetical) GTK theme previously mentioned, and Cua.

I personally think that the Emacs bindings are better, and in the end
work better with Emacs itself, but I do agree that newcomers should be
allowed to familiarize themselves with Emacs before moving their
workflow (and habits) to it entirely.

> No wonder lot of developers choose VScode:
> https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code

We're here to change that :)

Re: "Why is emacs so square?"

[Po Lu]

> And it has Electron for display support which has a mature browser
> engine behind it, so it can support advanced graphics features out
> of the box on all the supported platforms.

I'd like to add that even though Electron might have some fancier
features, I don't consider it more "mature" than the Emacs display
engine, which has had a 25+ year head start to "mature".

IIRC, some important concepts in the display engine have existed since
the era of AI Lab Emacs, which gives the display engine a nearly 40 year
head-start.

Perhaps we could focus on adding missing features to Emacs' display
engine (such as the aformentioned fancy graphics, and also some other
important features that RMS has mentioned, such as variable-pitch
indentation).

Plus, if we implement those features manually, we can make sure that
they work consistently well throughout all the supported platforms.
(Which is also what you get with Electron, etc).

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 19.04.2020 08:43, Po Lu wrote:
> Perhaps we could focus on adding missing features to Emacs' display
> engine (such as the aformentioned fancy graphics, and also some other
> important features that RMS has mentioned, such as variable-pitch
> indentation).

I'm pretty sure neither "fancy graphics" inside file buffers, nor 
variable-pitch indentation are the reason for VS Code's popularity.

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm pretty sure neither "fancy graphics" inside file buffers, nor
> variable-pitch indentation are the reason for VS Code's popularity.

You have a point.  We need to figure out why VSC is so popular, and then
fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
probably counts in that area.

Re: "Why is emacs so square?"

[Bob Newell]

> You have a point.  We need to figure out why VSC is so popular, and then
> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> probably counts in that area.

In both this and other messages, I get what you're saying and the goal
of making Emacs more accessible and more appealing is laudable and
ambitious, but definitely in the realm of possibility. (I think
/maybe/ some of the discussion is focused toward coding/software
development, and Emacs is much more than that, but I'll accept that
developers make up a big part of the actual and intended audience.)

But keep in mind that I'm old and grumpy and have used Emacs for
literally decades. When I started on Emacs back in the 80s, I knew
nothing. All I had used up to that point was a series of line-oriented
editors similar to 'ed'. Now (the question of graphics put aside in
that pre-graphics era), how did I learn Emacs? I went through the
tutorial carefully and fully. By the end of that I was a fledgling
Emacs user. It was enough for me to be able to do actual work.

Then, as I needed new things, I learned them. There was no internet so
I relied upon the Emacs manuals, which were and are very good
references. I picked up elisp as necessary. And it all worked out. Did
I jump right in and use Emacs out of the box? No. I knew I was making
a long-term investment in doing the tutorial, etc.

So here's the grumpy old man part: I sometimes think that today,
software is expected to fall into the instant gratification category.
A lot of users don't want to have to learn anything, they just want a
perfect out of the box experience. But I think those are conflicting
expectations.

Yes, make Emacs appealing and user friendly. But don't forget that a
masterful tool in the end requires mastery, which can't come for free.
I certainly draw the line at saying Emacs is for everyone. I'm not
saying it's only for some sort of snooty "elite" but I am saying that
it's for those who are willing to learn, seeing some extra work as the
aforementioned long-term investment, and who have the patience reach a
worthy goal a little later rather than right this very minute.


-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Po Lu]

Bob Newell <bobnewell@bobnewell.net> writes:

> But keep in mind that I'm old and grumpy and have used Emacs for
> literally decades. When I started on Emacs back in the 80s, I knew
> nothing. All I had used up to that point was a series of line-oriented
> editors similar to 'ed'. Now (the question of graphics put aside in
> that pre-graphics era), how did I learn Emacs? I went through the
> tutorial carefully and fully. By the end of that I was a fledgling
> Emacs user. It was enough for me to be able to do actual work.

I'm also old and grumpy, and I pretty much learned Emacs the same
way (and only about a decade after you did).
It would still be nice if we had a way for making Emacs easier for
today's lazy people to learn though.

> Then, as I needed new things, I learned them. There was no internet so
> I relied upon the Emacs manuals, which were and are very good
> references. I picked up elisp as necessary. And it all worked out. Did
> I jump right in and use Emacs out of the box? No. I knew I was making
> a long-term investment in doing the tutorial, etc.

I mostly agree, but the problem is a lot of people aren't willing to
make said investment due to prior prejudice, and you need a way to clear
that prejudice up.

> So here's the grumpy old man part: I sometimes think that today,
> software is expected to fall into the instant gratification category.
> A lot of users don't want to have to learn anything, they just want a
> perfect out of the box experience. But I think those are conflicting
> expectations.

Yes.
> Yes, make Emacs appealing and user friendly. But don't forget that a
> masterful tool in the end requires mastery, which can't come for free.
> I certainly draw the line at saying Emacs is for everyone. I'm not
> saying it's only for some sort of snooty "elite" but I am saying that
> it's for those who are willing to learn, seeing some extra work as the
> aforementioned long-term investment, and who have the patience reach a
> worthy goal a little later rather than right this very minute.

I'll keep that in mind.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 20, 2020, at 13:34, Po Lu <luangruo@yahoo.com> wrote:
> 
> It would still be nice if we had a way for making Emacs easier for
> today's lazy people to learn though.

It is not that they are lazy, just like people who use a machine to do their laundry instead of doing it by hand, they use tools that have been developed without the historical constraints of Emacs.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, make Emacs appealing and user friendly. But don't forget that a
  > masterful tool in the end requires mastery, which can't come for free.
  > I certainly draw the line at saying Emacs is for everyone. I'm not
  > saying it's only for some sort of snooty "elite" but I am saying that
  > it's for those who are willing to learn, seeing some extra work as the
  > aforementioned long-term investment, and who have the patience reach a
  > worthy goal a little later rather than right this very minute.

+1.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 20, 2020, at 7:53, Po Lu <luangruo@yahoo.com> wrote:
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> I'm pretty sure neither "fancy graphics" inside file buffers, nor
>> variable-pitch indentation are the reason for VS Code's popularity.
> 
> You have a point.  We need to figure out why VSC is so popular, and then
> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> probably counts in that area.

LSP support out of the box


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 02:39, Jean-Christophe Helary wrote:

>> You have a point.  We need to figure out why VSC is so popular, and then
>> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
>> probably counts in that area.

Probably. As well as better onboarding. Some better defaults as well.

> LSP support out of the box

We're basically already there:

- M-x package-install eglot
- C-x C-f ...
- M-x eglot

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> We're basically already there:
>
> - M-x package-install eglot
> - C-x C-f ...
> - M-x eglot

Does Eglot have support for automatically downloading and installing
popular language servers (like lsp-mode does)? If it does, that would be nice.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 07:35, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> We're basically already there:
>>
>> - M-x package-install eglot
>> - C-x C-f ...
>> - M-x eglot
> Does Eglot have support for automatically downloading and installing
> popular language servers (like lsp-mode does)? If it does, that would be nice.

Not thus far. Does VS Code do that?

Sounds like a good cause for a feature request. And if such an install 
script database is added, people should chip in and help maintaining that.

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:


> Not thus far. Does VS Code do that?

Yes.  AFAICT their primary method for language support is the LSP
protocol (and LSP was also originally created for VS Code), and they
have an extension "marketplace" (closest anology here would be ELPA)
that has a nice way to install various language servers.

`lsp-mode' also has similar functionality.  It would be nice to have it
in eglot.

> Sounds like a good cause for a feature request. And if such an install
> script database is added, people should chip in and help maintaining
> that.

Agreed.

Re: "Why is emacs so square?"

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> >> You have a point.  We need to figure out why VSC is so popular, and then
> >> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> >> probably counts in that area.
>
> Probably. As well as better onboarding. Some better defaults as well.

What does onboarding mean in this context?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 12:10, Stefan Kangas wrote:
>>>> You have a point.  We need to figure out why VSC is so popular, and then
>>>> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
>>>> probably counts in that area.
>> Probably. As well as better onboarding. Some better defaults as well.
> What does onboarding mean in this context?

Maybe some improvements to the welcome screen. A better tutorial (which 
showcases advanced features, not just the "alien" part of Emacs) and/or 
some guides.

https://en.wikipedia.org/wiki/User_onboarding

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 18:48, Dmitry Gutov wrote:
> A better tutorial (which showcases advanced features, not just the 
> "alien" part of Emacs)

VS Code's tutorial to compare: 
https://code.visualstudio.com/docs/introvideos/basics

(Yes, most of it is in a video; ours doesn't have to be but it's a 
decent approach; and we could do both a video and a text version).

Improved welcome screen

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Maybe some improvements to the welcome screen.

OK, so here's a proposal for a better welcome screen.  The idea was to
get rid of the impenetrable wall of text we have now by simplifying
it.

The attached patch is a quickly hacked together proof of concept, but
could be cleaned up and finalized if it's a direction we want to take.
I've attached a screenshot of the result.

You can test the patch using:
    ./src/emacs -Q --eval '(display-about-screen)'

Best regards,
Stefan Kangas

[-- Attachment #2: new-splash.png --]
[-- Type: image/png, Size: 98530 bytes --]

[-- Attachment #3: splash.diff --]
[-- Type: text/x-patch, Size: 5328 bytes --]

diff --git a/lisp/startup.el b/lisp/startup.el
index bff10003f8..8cea923581 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1615,6 +1615,15 @@ fancy-startup-text
 Each element in the list should be a list of strings or pairs
 `:face FACE', like `fancy-splash-insert' accepts them.")
 
+(defface splash-screen
+  '((((type tty pc) (class color) (background light))
+     :foreground "green" :weight bold)
+    (((type tty pc) (class color) (background dark))
+     :foreground "yellow" :weight bold)
+    (t :height 1.2 :inherit info-title-2))
+  "Face for info titles at level 1."
+  :group 'info)
+
 (defconst fancy-about-text
   `((:face (variable-pitch font-lock-comment-face)
      "This is "
@@ -1632,69 +1641,75 @@ fancy-about-text
 	 `("GNU" ,(lambda (_button) (describe-gnu-project))
 	   "Display info on the GNU project.")))
      " operating system.\n"
-     :face (variable-pitch font-lock-builtin-face)
+     :face variable-pitch
+     "\n\n"
+
+     :face splash-screen
+     "    Getting Help\t  Free Software\t  Get Involved!\n"
      "\n"
-     ,(lambda () (emacs-version))
+     ;; >>> Line 1
+     "  • "
+     :link ("Tutorial" ,(lambda (_button) (help-with-tutorial)))
+     "    " ;;; fixme: ugly hack for alignment
+     "\t• "
+     :link ("GNU and Freedom" ,(lambda (_button) (describe-gnu-project)))
+     "\t• "
+     :link ("Contributing & Bugs"
+	    ,(lambda (_button) (info "(emacs)Contributing")))
      "\n"
-     :face (variable-pitch (:height 0.8))
-     ,(lambda () emacs-copyright)
-     "\n\n"
-     :face variable-pitch
+
+     ;; >>> Line 2
+     "  • "
+     :link ("Guided Tour"
+	    ,(lambda (_button)
+               (browse-url "https://www.gnu.org/software/emacs/tour/"))
+	    "Browse https://www.gnu.org/software/emacs/tour/")
+     "\t• "
+     :link ("Copying Conditions" ,(lambda (_button) (describe-copying)))
+     "\t• "
+     :link ("Getting New Versions" ,(lambda (_button) (describe-distribution)))
+     "\n"
+
+     ;; >>> Line 3
+     "  • "
+     :link ("Emacs Manual" ,(lambda (_button) (info-emacs-manual)))
+     "\t• "
+     :link ("Ordering Manuals" ,(lambda (_button) (view-order-manuals)))
+     "\t• "
      :link ("Authors"
 	    ,(lambda (_button)
 	      (view-file (expand-file-name "AUTHORS" data-directory))
 	      (goto-char (point-min))))
-     "\tMany people have contributed code included in GNU Emacs\n"
-     :link ("Contributing"
-	    ,(lambda (_button) (info "(emacs)Contributing")))
-     "\tHow to report bugs and contribute improvements to Emacs\n"
-     "\n"
-     :link ("GNU and Freedom" ,(lambda (_button) (describe-gnu-project)))
-     "\tWhy we developed GNU Emacs, and the GNU operating system\n"
-     :link ("Absence of Warranty" ,(lambda (_button) (describe-no-warranty)))
-     "\tGNU Emacs comes with "
-     :face (variable-pitch (:slant oblique))
-     "ABSOLUTELY NO WARRANTY\n"
+     "\n\n\n"
+
      :face variable-pitch
-     :link ("Copying Conditions" ,(lambda (_button) (describe-copying)))
-     "\tConditions for redistributing and changing Emacs\n"
-     :link ("Getting New Versions" ,(lambda (_button) (describe-distribution)))
-     "\tHow to obtain the latest version of Emacs\n"
-     :link ("Ordering Manuals" ,(lambda (_button) (view-order-manuals)))
-     "\tBuying printed manuals from the FSF\n"
+
+     ;; Horizontal Line
+     "---------------------------------------------------------------------------\n"
      "\n"
-     :link ("Emacs Tutorial" ,(lambda (_button) (help-with-tutorial)))
-     "\tLearn basic Emacs keystroke commands"
-     ,(lambda ()
-       (let* ((en "TUTORIAL")
-	      (tut (or (get-language-info current-language-environment
-					  'tutorial)
-		       en))
-	      (title (with-temp-buffer
-		       (insert-file-contents
-			(expand-file-name tut tutorial-directory)
-			;; Read the entire file, to make sure any
-			;; coding cookies and other local variables
-			;; get acted upon.
-			nil)
-		       (search-forward ".")
-		       (buffer-substring (point-min) (1- (point))))))
-	 ;; If there is a specific tutorial for the current language
-	 ;; environment and it is not English, append its title.
-	 (if (string= en tut)
-	     ""
-	   (concat " (" title ")"))))
+
+     ;; Absence of Warranty Section
+     "GNU Emacs comes with "
+     :link ("ABSOLUTELY NO WARRANTY" ,(lambda (_button) (describe-no-warranty)))
+     "\n\n"
+
+     ;; Version Information
+     :face (variable-pitch font-lock-builtin-face)
+     ,(lambda () (emacs-version))
      "\n"
-     :link ("Emacs Guided Tour"
-	    ,(lambda (_button)
-               (browse-url "https://www.gnu.org/software/emacs/tour/"))
-	    "Browse https://www.gnu.org/software/emacs/tour/")
-     "\tSee an overview of Emacs features at gnu.org\n"
-     :link ("Emacs Manual" ,(lambda (_button) (info-emacs-manual)))
-     "\tDisplay the Emacs manual in Info mode"))
+     "\n"
+
+     ;; Copyright
+     :face (variable-pitch (:height 0.8))
+     ,(lambda () emacs-copyright)
+     "\n"
+
+     ))
+
   "A list of texts to show in the middle part of the About screen.
 Each element in the list should be a list of strings or pairs
-`:face FACE', like `fancy-splash-insert' accepts them.")
+`:face FACE', like `fancy-splash-insert' accepts them."
+  )
 
 
 (defgroup fancy-splash-screen ()

Re: Improved welcome screen

[Dmitry Gutov]

Hi Stefan,

On 27.04.2020 15:30, Stefan Kangas wrote:
> OK, so here's a proposal for a better welcome screen.  The idea was to
> get rid of the impenetrable wall of text we have now by simplifying
> it.

I like this direction quite a bit. Not crazy about the part after the 
dashed line, though, but it's less clear what we can replace it with.

The "NO WARRANTY" can probably just live in the Help menu. Or move to 
the middle. Maybe by replacing the "Ordering Manuals" item which could 
obtain more prominence in "(emacs) Top". Or by having a fourth item 
there. Maybe we can have 4 items in each column.

Speaking of the Guided Tour, EWW is nifty and all, but it renders that 
page worse than any normal browser.

Re: Improved welcome screen

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I like this direction quite a bit. Not crazy about the part after the
> dashed line, though, but it's less clear what we can replace it with.

Thank you, this is good feedback.  For this first draft, I tried to
include all information that was there before.  But I'm personally
happy to incorporate further changes along the lines you suggest.

As for the version information, we could just mention the major and
minor version in the first sentence:  "This is GNU Emacs version
28.0.50, [...]"
Or we could decide that the version information is not really needed
at all for the purposes of this screen.  I don't have a very strong
opinion here except that I don't think it's ideal to advertise details
like the cairo version at the very top of the screen (as before).

> The "NO WARRANTY" can probably just live in the Help menu. Or move to
> the middle. Maybe by replacing the "Ordering Manuals" item which could
> obtain more prominence in "(emacs) Top". Or by having a fourth item
> there. Maybe we can have 4 items in each column.

I thought there was some kind of legal reason that "NO WARRANTY" is on
that screen?  If it's not, we might as well move it out of the way, I
agree.

The "Ordering Manuals" could indeed get more prominence in "(emacs)
Top" instead.

We could have four items in each column, if necessary.  Somehow humans
like it when there are only three things though - it's a general
principle in graphical design.  It "feels" better to most people for
some unknown reason.  Content obviously trumps that, but I propose we
also keep that (secondary) aspect in mind.

> Speaking of the Guided Tour, EWW is nifty and all, but it renders that
> page worse than any normal browser.

Indeed.  I filed a feature request for a new max width option:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40909

The images are also rendered to be very small, so maybe it would be
good to file a feature request for that.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Yuan Fu]

Maybe you can use variable font, and use tab to align the text? Generally, variable font looks better and more modern.

Yuan

Re: Improved welcome screen

[Stefan Kangas]

Yuan Fu <casouri@gmail.com>:

> Maybe you can use variable font, and use tab to align the text? Generally, variable font looks better and more modern.

Yes, I thought that's what I did but I must have messed something up
somewhere.  The about screen uses variable font already now, and I
think we should keep that.  Thanks for catching that mistake.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Dmitry Gutov]

On 27.04.2020 22:07, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> I like this direction quite a bit. Not crazy about the part after the
>> dashed line, though, but it's less clear what we can replace it with.
> 
> Thank you, this is good feedback.  For this first draft, I tried to
> include all information that was there before.  But I'm personally
> happy to incorporate further changes along the lines you suggest.
> 
> As for the version information, we could just mention the major and
> minor version in the first sentence:  "This is GNU Emacs version
> 28.0.50, [...]"

I don't have a particular preference. This string could be useful (I 
don't know). But the way it's displayed, and its length, leave something 
to be desired.

> Or we could decide that the version information is not really needed
> at all for the purposes of this screen.  I don't have a very strong
> opinion here except that I don't think it's ideal to advertise details
> like the cairo version at the very top of the screen (as before).

Indeed, maybe not.

>> The "NO WARRANTY" can probably just live in the Help menu. Or move to
>> the middle. Maybe by replacing the "Ordering Manuals" item which could
>> obtain more prominence in "(emacs) Top". Or by having a fourth item
>> there. Maybe we can have 4 items in each column.
> 
> I thought there was some kind of legal reason that "NO WARRANTY" is on
> that screen?  If it's not, we might as well move it out of the way, I
> agree.

Maybe Richard has an opinion on this, but (though IANAL) I don't think 
so, considering most software (libre or not) don't make this much of an 
effort to tell the user about the lack of warranty.

> The "Ordering Manuals" could indeed get more prominence in "(emacs)
> Top" instead.
> 
> We could have four items in each column, if necessary.  Somehow humans
> like it when there are only three things though - it's a general
> principle in graphical design.  It "feels" better to most people for
> some unknown reason.  Content obviously trumps that, but I propose we
> also keep that (secondary) aspect in mind.

If the "no warranty" thing is required there after all, we could do the 
four-row thing as the first improved version, get it installed, and then 
discuss further tweaks.

Because I'm guessing hiding the "Ordering Manuals" farther from sight 
can be seen as unfortunate (however much income it results in, IDK).

>> Speaking of the Guided Tour, EWW is nifty and all, but it renders that
>> page worse than any normal browser.
> 
> Indeed.  I filed a feature request for a new max width option:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40909

Thanks.

> The images are also rendered to be very small, so maybe it would be
> good to file a feature request for that.

Personally, I'd prefer if it just used the web browser installed in the 
system. But I'll take any improvement over the current state.

Re: Improved welcome screen

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 28 Apr 2020 05:49:33 +0300
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > Or we could decide that the version information is not really needed
> > at all for the purposes of this screen.  I don't have a very strong
> > opinion here except that I don't think it's ideal to advertise details
> > like the cairo version at the very top of the screen (as before).
> 
> Indeed, maybe not.

If we are talking about the "About" screen (not the startup screen, as
I initially assumed), then I think the version should be there: I'm
yet to see a program which did NOT show its version in the About menu
item.  That's where people will look for it.  It might even be the
main reason people even look at the About screen.

Re: Improved welcome screen

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> If we are talking about the "About" screen (not the startup screen, as
> I initially assumed), then I think the version should be there: I'm
> yet to see a program which did NOT show its version in the About menu
> item.  That's where people will look for it.  It might even be the
> main reason people even look at the About screen.

Same here. For testing purposes, I often run several Emacs versions in
parallel. "C-h a" is indispensable then.

Best regards, Michael.

Re: Improved welcome screen

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Same here. For testing purposes, I often run several Emacs versions in
> parallel. "C-h a" is indispensable then.

OK, so let's keep the detailed version information on the about
screen.  It clearly makes sense to have it there.

I have not yet seen anyone express the opinion that it's important to
keep the detailed version information on the welcome screen.  Maybe
it's enough to show the major and minor version there.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Dmitry Gutov]

On 28.04.2020 15:32, Stefan Kangas wrote:
> I have not yet seen anyone express the opinion that it's important to
> keep the detailed version information on the welcome screen.  Maybe
> it's enough to show the major and minor version there.

I agree.

Re: Improved welcome screen

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 27 Apr 2020 14:30:18 +0200
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> The attached patch is a quickly hacked together proof of concept, but
> could be cleaned up and finalized if it's a direction we want to take.
> I've attached a screenshot of the result.

Any rationale for losing the links that you excluded?  Or how about
keeping them, since there seems to be free space left?

Thanks.

Re: Improved welcome screen

[Dmitry Gutov]

On 27.04.2020 21:39, Eli Zaretskii wrote:
> Any rationale for losing the links that you excluded?  Or how about
> keeping them, since there seems to be free space left?

Could you give an example of an excluded link?

Re: Improved welcome screen

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 27 Apr 2020 21:48:37 +0300
> 
> On 27.04.2020 21:39, Eli Zaretskii wrote:
> > Any rationale for losing the links that you excluded?  Or how about
> > keeping them, since there seems to be free space left?
> 
> Could you give an example of an excluded link?

"Open a File", "Open Home Directory", "Customize Startup".

And if there are auto-save files, we currently show a hint to type
"M-x recover-session RET".  Is that also gone?

Re: Improved welcome screen

[Dmitry Gutov]

On 27.04.2020 22:32, Eli Zaretskii wrote:

>> Could you give an example of an excluded link?
> 
> "Open a File", "Open Home Directory", "Customize Startup".

Two things.

First: the first two items duplicate the toolbar items, so they're 
pretty unnecessary. "Customize Startup" could move somewhere else, but 
honestly, it also looks out of place, since the only apparent purpose it 
has is tell the user how to hide the start screen.

I think we better make the start screen better (like other editors do), 
so the users won't hurry to hide it right away. But keep the user 
option, of course.

> And if there are auto-save files, we currently show a hint to type
> "M-x recover-session RET".  Is that also gone?

I don't know, but we could keep it.

Second thing: I think Stefan's work is a modification of the "About" 
buffer. Whereas you are talking about the startup screen. They are close 
enough to mistake one for another, but still different. For some reason.

To Stefan: to display the latter, I run 'HOME=/tmp src/emacs'.

Re: Improved welcome screen

[Eli Zaretskii]

> Cc: stefan@marxist.se, jean.christophe.helary@traduction-libre.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 28 Apr 2020 00:29:17 +0300
> 
> > "Open a File", "Open Home Directory", "Customize Startup".
> 
> Two things.
> 
> First: the first two items duplicate the toolbar items, so they're 
> pretty unnecessary.

Some of the links Stefan did keep are also such duplicates.  Any
reason for treating them differently?

> I think we better make the start screen better (like other editors do), 
> so the users won't hurry to hide it right away. But keep the user 
> option, of course.
> 
> > And if there are auto-save files, we currently show a hint to type
> > "M-x recover-session RET".  Is that also gone?
> 
> I don't know, but we could keep it.
> 
> Second thing: I think Stefan's work is a modification of the "About" 
> buffer. Whereas you are talking about the startup screen. They are close 
> enough to mistake one for another, but still different. For some reason.

The Subject says "welcome screen", and you yourself use "startup
screen".  So I thought this is what we were talking about.

If you ask me, the About display is much less important than the
startup/welcome/splash screen.  I very much doubt newbies look at the
About display; they almost always look at the startup screen at least
once.

Re: Improved welcome screen

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > Second thing: I think Stefan's work is a modification of the "About"
> > buffer. Whereas you are talking about the startup screen. They are close
> > enough to mistake one for another, but still different. For some reason.
>
> The Subject says "welcome screen", and you yourself use "startup
> screen".  So I thought this is what we were talking about.

My intention was to modify the welcome screen, yes.  I ended up
modifying the about screen (display-about-screen) only because I
mistakenly believed they were the same.  (They are very similar, to be
sure.  But there are some differences.)

Please consider my draft as a suggestion for a new welcome screen
(display-startup-screen).

Once we have a better understanding of what should be done there, I'll
be happy to suggest similar improvements to the about screen.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Dmitry Gutov]

On 28.04.2020 09:36, Eli Zaretskii wrote:
>> Cc: stefan@marxist.se, jean.christophe.helary@traduction-libre.org,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 28 Apr 2020 00:29:17 +0300
>>
>>> "Open a File", "Open Home Directory", "Customize Startup".
>>
>> Two things.
>>
>> First: the first two items duplicate the toolbar items, so they're
>> pretty unnecessary.
> 
> Some of the links Stefan did keep are also such duplicates.  Any
> reason for treating them differently?

I'm not sure which ones you mean. The rest are _also_ duplicated in the 
menu bar, but only the two of the removed ones are present on the toolbar.

In any case, the justification is that the result looks better. And we 
can get away with that because these buttons are not essential.

> The Subject says "welcome screen", and you yourself use "startup
> screen".  So I thought this is what we were talking about.

That's what we should be talking about, yes.

> If you ask me, the About display is much less important than the
> startup/welcome/splash screen.  I very much doubt newbies look at the
> About display; they almost always look at the startup screen at least
> once.

Agreed.

Re: Improved welcome screen

[chad]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

I would suggest interested parties take a look at the "dashboard" package
for emacs; it seems to be quite popular amongst those "starter kits" that
were discussed earlier, and has iterated around the sort of features we're
talking about here. To be clear, I'm not suggesting that we just integrate
it wholesale, although if people are interested, I'd be willing to try to
ask the author(s) about doing so. More details can be found here:

  https://github.com/emacs-dashboard/emacs-dashboard

If anyone would like, I would be willing to send them a copy of the
information from that page, so they can avoid the github burden; just let
me know.

~Chad



On Tue, Apr 28, 2020 at 6:22 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 28.04.2020 09:36, Eli Zaretskii wrote:
> >> Cc: stefan@marxist.se, jean.christophe.helary@traduction-libre.org,
> >>   emacs-devel@gnu.org
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> Date: Tue, 28 Apr 2020 00:29:17 +0300
> >>
> >>> "Open a File", "Open Home Directory", "Customize Startup".
> >>
> >> Two things.
> >>
> >> First: the first two items duplicate the toolbar items, so they're
> >> pretty unnecessary.
> >
> > Some of the links Stefan did keep are also such duplicates.  Any
> > reason for treating them differently?
>
> I'm not sure which ones you mean. The rest are _also_ duplicated in the
> menu bar, but only the two of the removed ones are present on the toolbar.
>
> In any case, the justification is that the result looks better. And we
> can get away with that because these buttons are not essential.
>
> > The Subject says "welcome screen", and you yourself use "startup
> > screen".  So I thought this is what we were talking about.
>
> That's what we should be talking about, yes.
>
> > If you ask me, the About display is much less important than the
> > startup/welcome/splash screen.  I very much doubt newbies look at the
> > About display; they almost always look at the startup screen at least
> > once.
>
> Agreed.
>
>

[-- Attachment #2: Type: text/html, Size: 3009 bytes --]

Re: Improved welcome screen

[Dmitry Gutov]

On 28.04.2020 21:28, chad wrote:
> I would suggest interested parties take a look at the "dashboard" 
> package for emacs; it seems to be quite popular amongst those "starter 
> kits" that were discussed earlier, and has iterated around the sort of 
> features we're talking about here. To be clear, I'm not suggesting that 
> we just integrate it wholesale, although if people are interested, I'd 
> be willing to try to ask the author(s) about doing so. More details can 
> be found here:
> 
> https://github.com/emacs-dashboard/emacs-dashboard

Looks good, but it's a dashboard for day-to-day use (showing recent 
files, projects, maybe bookmarks, org agenda...), and we're currently 
discussing the start screen for the first time user.

After we're happy with it, we can talk about whether to modify it to 
show extra items, or to show an altogether different dashboard later 
(probably inspired by the above project).

Re: Improved welcome screen

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would suggest interested parties take a look at the "dashboard" package
  > for emacs;

Would someone who studies it please give me a summary after?
I don't need to know all the details.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Improved welcome screen

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Any rationale for losing the links that you excluded?  Or how about
> keeping them, since there seems to be free space left?

Unless I made a mistake somewhere, the links have just been re-arranged:

- "Emacs Tutorial" and "Emacs Guided Tour" was renamed to "Tutorial"
and "Guided Tour".
- "Absence of Warranty" is moved below the dashed line, linked from
the text "ABSOLUTELY NO WARRANTY".
- "Contributing" was renamed to "Contributing & Bugs".

Other than that, I think all links should still be there.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Stefan Monnier]

> +     :link ("Contributing & Bugs"

I can't remember the official name for such a thing (it's related to
"zeugma" which I learned about in the incomparable "dictionnaire superflu
à l'usage de l'élite et des nantis", which is strongly recommended
reading), but you could call it a "type error": you join with `&`
two things from different categories.


        Stefan

Re: Improved welcome screen

[Juri Linkov]

>> +     :link ("Contributing & Bugs"
>
> I can't remember the official name for such a thing (it's related to
> "zeugma" which I learned about in the incomparable "dictionnaire superflu
> à l'usage de l'élite et des nantis", which is strongly recommended
> reading), but you could call it a "type error": you join with `&`
> two things from different categories.

According to rules of the Writers Guild of America West
the word “and” located between writers' names in a writing
credit designates that the writers wrote separately and
an ampersand (“&”) denotes a writing team:
https://www.wga.org/the-guild/about-us/faq#credits4

Re: Improved welcome screen

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

Stefan Kangas <stefan@marxist.se> writes:


> OK, so here's a proposal for a better welcome screen.  The idea was to
> get rid of the impenetrable wall of text we have now by simplifying
> it.

Would it make sense to use the new Emacs logo?
You can find it at etc/images/icons/hicolor/scalable/apps/emacs.svg

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Improved welcome screen

[Stefan Kangas]

Nicolas Petton <nico@petton.fr> writes:

> Would it make sense to use the new Emacs logo?
> You can find it at etc/images/icons/hicolor/scalable/apps/emacs.svg

Sure, why not?  We could try it to see if it looks better.

Best regards,
Stefan Kangas

Re: Improved welcome screen

[Dmitry Gutov]

Hi Stefan,

On 27.04.2020 15:30, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Maybe some improvements to the welcome screen.
> 
> OK, so here's a proposal for a better welcome screen.  The idea was to
> get rid of the impenetrable wall of text we have now by simplifying
> it.

Yesterday, this was posted on Reddit as a concept: 
https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67

https://www.reddit.com/r/emacs/comments/ggnekq/a_very_minimal_but_elegant_emacs_i_think/

What do you think of the style?

It seems that the author has assigned copyright for some art to FSF in 
the past, so we could ask for an assignment for Emacs. And then base our 
screen on this, adjusting the actual information shown to best suit our 
requirements.

Re: Improved welcome screen

[Yuan Fu]

> On May 10, 2020, at 3:22 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Hi Stefan,
> 
> On 27.04.2020 15:30, Stefan Kangas wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>> Maybe some improvements to the welcome screen.
>> OK, so here's a proposal for a better welcome screen.  The idea was to
>> get rid of the impenetrable wall of text we have now by simplifying
>> it.
> 
> Yesterday, this was posted on Reddit as a concept: https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67
> 
> https://www.reddit.com/r/emacs/comments/ggnekq/a_very_minimal_but_elegant_emacs_i_think/
> 
> What do you think of the style?
> 
> It seems that the author has assigned copyright for some art to FSF in the past, so we could ask for an assignment for Emacs. And then base our screen on this, adjusting the actual information shown to best suit our requirements.
> 

Actual content aside, the style is nice, indeed.

Yuan

Re: Improved welcome screen

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Stefan,
>
> On 27.04.2020 15:30, Stefan Kangas wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> Maybe some improvements to the welcome screen.
>> OK, so here's a proposal for a better welcome screen.  The idea was to
>> get rid of the impenetrable wall of text we have now by simplifying
>> it.
>
> Yesterday, this was posted on Reddit as a concept:
> https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67
>
> https://www.reddit.com/r/emacs/comments/ggnekq/a_very_minimal_but_elegant_emacs_i_think/
>
> What do you think of the style?
>
> It seems that the author has assigned copyright for some art to FSF in the past,
> so we could ask for an assignment for Emacs. And then base our screen on this,
> adjusting the actual information shown to best suit our requirements.
It looks nice, but he could have add a link to reference card too (under
Quick help maybe). Maybe less text, skipp the info about Lisp for
example. But as idea looks nice.

Re: Improved welcome screen

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Yesterday, this was posted on Reddit as a concept:
> https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67
>
> https://www.reddit.com/r/emacs/comments/ggnekq/a_very_minimal_but_elegant_emacs_i_think/
>
> What do you think of the style?

Thanks for pointing this out.

This is very nice indeed.  It's a bit of a different direction, but I
like some of the main ideas a lot.

> It seems that the author has assigned copyright for some art to FSF in
> the past, so we could ask for an assignment for Emacs. And then base our
> screen on this, adjusting the actual information shown to best suit our
> requirements.

That's a very good idea.  I will contact him in private to see if he
wants to sign the papers, or better yet collaborate with us.

Best regards,
Stefan Kangas

PS. He is also using the very nice font "Roboto Mono".  Maybe we could
    consider adding a stronger default font selection, dependent upon
    `system-type'?

Re: Improved welcome screen

[Dmitry Gutov]

On 12.05.2020 01:59, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Yesterday, this was posted on Reddit as a concept:
>> https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67
>>
>> https://www.reddit.com/r/emacs/comments/ggnekq/a_very_minimal_but_elegant_emacs_i_think/
>>
>> What do you think of the style?
> 
> Thanks for pointing this out.
> 
> This is very nice indeed.  It's a bit of a different direction, but I
> like some of the main ideas a lot.

It's a lot different indeed, but maybe a combination could work. Your 
version improved usability while keeping (or even improving) information 
density.

This new one is pretty, but with lower density, and much too long for 
the startup screen.

>> It seems that the author has assigned copyright for some art to FSF in
>> the past, so we could ask for an assignment for Emacs. And then base our
>> screen on this, adjusting the actual information shown to best suit our
>> requirements.
> 
> That's a very good idea.  I will contact him in private to see if he
> wants to sign the papers, or better yet collaborate with us.

Thank you.

> Best regards,
> Stefan Kangas
> 
> PS. He is also using the very nice font "Roboto Mono".  Maybe we could
>      consider adding a stronger default font selection, dependent upon
>      `system-type'?

Why not.

I don't have that font installed, though, and it's still a beauty with 
"Ubuntu Mono". Just some positioning is a little bit off (the first page 
ends a tiny bit earlier than expected). Either way, we should try to 
make the startup screen work okay with the default system monospace 
fonts too.

Re: Improved welcome screen

[Colin Baxter]

Sorry to be a party pooper, but the build information is missing. For
me, that's a defect.

Best wishes,
Colin.

-- 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Improved welcome screen

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yesterday, this was posted on Reddit as a concept: 
  > https://camo.githubusercontent.com/7f0804a2670362a0623a0ede5338e5bd8655078c/68747470733a2f2f692e726564642e69742f366870626f66343078737834312e706e67

It looks basically good to me, but there are a few important detail
issues.

It needsto link to the non-warranty statement and the copying
conditions.  We want everyone to see that they are there.

It must not link to Stack Exchange, because we know it will give
advice to use nonfree software.  Also, Stack Exchange pages contain
nonfree Javascript.  I don't know what they use it for -- I was able
to browse questions and answers with LibreJS -- but they must use it
for something.  Perhaps it is necessary to ask a question, or to enter
an answer.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Perhaps we could focus on adding missing features to Emacs' display
  > > engine (such as the aformentioned fancy graphics, and also some other
  > > important features that RMS has mentioned, such as variable-pitch
  > > indentation).

  > I'm pretty sure neither "fancy graphics" inside file buffers, nor 
  > variable-pitch indentation are the reason for VS Code's popularity.

That statement may be correct, but you've changed the topic.

You're talking specifically about VS Code, which is a "source code
editor".  What I had in mind, regarding variable-pitch text, was word
processing.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 05:19, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > > Perhaps we could focus on adding missing features to Emacs' display
>    > > engine (such as the aformentioned fancy graphics, and also some other
>    > > important features that RMS has mentioned, such as variable-pitch
>    > > indentation).
> 
>    > I'm pretty sure neither "fancy graphics" inside file buffers, nor
>    > variable-pitch indentation are the reason for VS Code's popularity.
> 
> That statement may be correct, but you've changed the topic.

Did I?

> You're talking specifically about VS Code, which is a "source code
> editor".  What I had in mind, regarding variable-pitch text, was word
> processing.

The topic was Emacs's popularity, AFAICT.

It's already a good source code editor, and yet its share among 
programmers is < 5%.

As a word processor, it's a lot less capable, and adding the two 
features you mentioned above won't bring us much closer to that goal, 
compared to established options. And there are existing Free programs 
that do this better already (like LibreOffice Writer).

We certainly should enable all kinds of uses, but given the limited 
resources, I think we should play to our strengths first.

Re: "Why is emacs so square?"

[Bob Newell]

> It's already a good source code editor, and yet its share among
> programmers is < 5%.

Interesting fact, I didn't know this and had assumed it was quite a bit higher.

> As a word processor, it's a lot less capable ... And there are existing Free programs
> that do this better already (like LibreOffice Writer).

You are right, there is LibreOffice, and I don't need Emacs to be
another WYSIWYG word processor.

But that said, it's already a terrific text processor, especially with
org-mode. I've written 8 novels in English, 1 in French, and countless
short stories with Emacs. I couldn't conceive of a more productive
writing tool, and in the writing community I know of many others who
feel the same way.

The AucTeX interface to LaTeX makes publishing feasible, too, although
I admit that's yet another learning curve to traverse.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 08:07, Bob Newell wrote:

>> As a word processor, it's a lot less capable ... And there are existing Free programs
>> that do this better already (like LibreOffice Writer).
> 
> You are right, there is LibreOffice, and I don't need Emacs to be
> another WYSIWYG word processor.

I mean, new, optional, WYSIWYG modes wouldn't hurt, but they're unlikely 
to move the needle either.

> But that said, it's already a terrific text processor, especially with
> org-mode. I've written 8 novels in English, 1 in French, and countless
> short stories with Emacs. I couldn't conceive of a more productive
> writing tool, and in the writing community I know of many others who
> feel the same way.

Sure. And I've heard similar reports myself. But that's a more 
"specialized" kind of word processor. I don't know of better words to 
distinguish between the two.

Re: "Why is emacs so square?"

[Steinar Bang]

>>>>> Bob Newell <bobnewell@bobnewell.net>:

> But that said, it's already a terrific text processor, especially with
> org-mode. I've written 8 novels in English, 1 in French, and countless
> short stories with Emacs. I couldn't conceive of a more productive
> writing tool, and in the writing community I know of many others who
> feel the same way.

I haven't written any novels in it, but yeah, org-mode fills my text
processing needs as well (as well as being my notebook, time keeper and
more).

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I haven't written any novels in it, but yeah, org-mode fills my text
  > processing needs as well (as well as being my notebook, time keeper and
  > more).

When I write a pamphlet using Libre Office, I need to see how it
will appear on the page.  I need to see where line breaks and paragraph
breaks appear.

I want Emacs to be able to do tect processing that way.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I haven't written any novels in it, but yeah, org-mode fills my text
>   > processing needs as well (as well as being my notebook, time keeper and
>   > more).
>
> When I write a pamphlet using Libre Office, I need to see how it
> will appear on the page.  I need to see where line breaks and paragraph
> breaks appear.
>
> I want Emacs to be able to do tect processing that way.
When you say page, you mean a printed page on paper?

Can't that be helped with some of live preview options for a pdf or ps
or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?

Or couldn't it be possible to define some html+css to model A4 paper
size, for example:

https://codepen.io/rafaelcastrocouto/pen/LFAes

and use some of live preview options for html (eww or browseurl or
something else)? Not a wysiwyg directly, but kind-of middle ground?

Re: "Why is emacs so square?"

[Juri Linkov]

> Or couldn't it be possible to define some html+css to model A4 paper
> size, for example:
>
> https://codepen.io/rafaelcastrocouto/pen/LFAes
>
> and use some of live preview options for html (eww or browseurl or
> something else)? Not a wysiwyg directly, but kind-of middle ground?

Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
      --run-all-compositor-stages-before-draw --no-margins doc.html
or using its wrapper chromehtml2pdf.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Juri Linkov <juri@linkov.net> writes:
> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>       --run-all-compositor-stages-before-draw --no-margins doc.html
> or using its wrapper chromehtml2pdf.

there are alternatives which don't require malware:

   abiword --to=PDF -o a.pdf a.html
   soffice --headless --convert-to pdf a.html
   wkhtmltopdf -B 24 -L 24 -R 24 -T 24 a.html a.pdf

But none of those produce good documents.

As an experiment, I tried to produce the ebooks.pdf document from
org-mode, exported to html, opened in firefox, printed to pdf.  It gave
the best result.  It looked almost like the original and was easy to
tune in org-mode.  I only had to iterate a few times.

But still, all these solutions require huge dependencies.

Re: "Why is emacs so square?"

[Juri Linkov]

>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>       --run-all-compositor-stages-before-draw --no-margins doc.html
>> or using its wrapper chromehtml2pdf.
>
> there are alternatives which don't require malware:

BTW, why browse-url.el still doesn't support the Brave web browser?
Brave solved the problem of malware.  It's one of the most secure
and privacy-respecting web browsers.  Unless someone presents a reason
not to do this, I'm going to add Brave support to browse-url.el.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Jun 7, 2020, at 8:30, Juri Linkov <juri@linkov.net> wrote:
> 
>>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>>      --run-all-compositor-stages-before-draw --no-margins doc.html
>>> or using its wrapper chromehtml2pdf.
>> 
>> there are alternatives which don't require malware:
> 
> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

A piece of software that actively promotes cryptocurrency use is a scam. But maybe that's not a valid reason.

-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

>> On Jun 7, 2020, at 8:30, Juri Linkov <juri@linkov.net> wrote:
>> 
>>>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>>>      --run-all-compositor-stages-before-draw --no-margins doc.html
>>>> or using its wrapper chromehtml2pdf.
>>> 
>>> there are alternatives which don't require malware:
>> 
>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> Brave solved the problem of malware.  It's one of the most secure
>> and privacy-respecting web browsers.  Unless someone presents a reason
>> not to do this, I'm going to add Brave support to browse-url.el.
>
> A piece of software that actively promotes cryptocurrency use is a
> scam.

agree

- cryptocurency burns the world

- investors behind the brave browser seem questionable

for example, today surfaced how the brave browser is hijacking links

it seems to be malware with good marketing to fool people

RE: "Why is emacs so square?"

[Drew Adams]

> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

+1 for Brave browser.

Re: "Why is emacs so square?"

[Yuri Khan]

On Sun, 7 Jun 2020 at 06:55, Juri Linkov <juri@linkov.net> wrote:

> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

But it’s not free software.

Re: "Why is emacs so square?"

[Yuri Khan]

On Sun, 7 Jun 2020 at 14:51, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>
> On Sun, 7 Jun 2020 at 06:55, Juri Linkov <juri@linkov.net> wrote:
>
> > BTW, why browse-url.el still doesn't support the Brave web browser?
> > Brave solved the problem of malware.  It's one of the most secure
> > and privacy-respecting web browsers.  Unless someone presents a reason
> > not to do this, I'm going to add Brave support to browse-url.el.
>
> But it’s not free software.

Or is it, huh.[^1] For some reason, the FAQ on the main site[^2] has
the question “Is Brave free?”, and the answer only talks about
free-as-in-beer. To find out about the free-as-in-freedom aspect, you
have to notice the Github link in the footer.

[^1]: https://github.com/brave/brave-browser/blob/master/LICENSE
[^2]: https://brave.com/

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

ISTR that Brave _is_ free software, but has a malfeature.
So we would not want to propose its use.

I've been misinformed about this before -- we would want someone
to check carefully.

Someone could make a modified version without that.  Does this exist?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 07.06.2020 02:30, Juri Linkov wrote:
> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.

Not so sure about that:

https://news.ycombinator.com/item?id=23442027

RE: "Why is emacs so square?"

[Drew Adams]

> > BTW, why browse-url.el still doesn't support the Brave web browser?
> > Brave solved the problem of malware.  It's one of the most secure
> > and privacy-respecting web browsers.
> 
> Not so sure about that:
> 
> https://urldefense.com/v3/__https://news.ycombinator.com/item?id=23442027__;!
> !GqivPVa7Brio!PGyydJ9-LLd8XIznjSJYn6c7uA9nqpwscDwdwqEeZPfto_aWii9FMcJ-
> c7L01E0p$

Thanks for that link.  Interesting discussion.
I'm no expert on these things, but this remark
there seems relevant:

  "Brave ads are opt-in, for people who would like
   to earn "shitty" cryptocurrency by clicking on them."

I opted out, at the outset.  Perhaps I'm not aware
of some other behind-the-scenes behavior that's
problematic.  I didn't read all of the page you
link to in detail, but my (maybe naive) impression
is that if you opt out of ads that pretty much
takes care of things.

The only technical problem I've encountered with
Brave, compared to Google Chrome, is that some
dropdown/pulldown lists on some sites don't work.

Re: "Why is emacs so square?"

[Juri Linkov]

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> Brave solved the problem of malware.  It's one of the most secure
>> and privacy-respecting web browsers.
>
> Not so sure about that:
>
> https://news.ycombinator.com/item?id=23442027

Oh, I thought it would be a good option.

Re: "Why is emacs so square?"

[Stefan Monnier]

> BTW, why browse-url.el still doesn't support the Brave web browser?

I know nothing about Brave, but I'm wondering instead why it is that
browse-url.el would need special support for specific browsers.
Can't it just run "the" browser, whichever it is?


        Stefan

Re: "Why is emacs so square?"

[Basil L. Contovounesios]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>
> I know nothing about Brave, but I'm wondering instead why it is that
> browse-url.el would need special support for specific browsers.
> Can't it just run "the" browser, whichever it is?

Doesn't browse-url-default-browser try to DTRT already?

-- 
Basil

Re: "Why is emacs so square?"

[Juri Linkov]

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>
> I know nothing about Brave, but I'm wondering instead why it is that
> browse-url.el would need special support for specific browsers.
> Can't it just run "the" browser, whichever it is?

There is a lot of cruft accumulated in browse-url.el mostly for old browsers
with different handling of command line arguments for "new-window-is-tab" logic.
But it seems nowadays only three options should be sufficient:

- use the default browser found by browse-url-default-browser;
- or use Emacs browser eww;
- or allow to specify a browser program name with additional arguments.

Re: "Why is emacs so square?"

[andres.ramirez]

Hi Juri.

>>>>> "Juri" == Juri Linkov <juri@linkov.net> writes:

    Juri> nowadays only three options should be sufficient:

    Juri> - use the default browser found by browse-url-default-browser;
    Juri> - or use Emacs browser eww;

Or use emacs not default browser (w3m). Not default browser. But
arguably has more features.

    Juri> - or allow to specify a browser program name with additional arguments.

Best Regards

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Jun 8, 2020, at 7:31, Juri Linkov <juri@linkov.net> wrote:
> 
>>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> 
>> I know nothing about Brave, but I'm wondering instead why it is that
>> browse-url.el would need special support for specific browsers.
>> Can't it just run "the" browser, whichever it is?
> 
> There is a lot of cruft accumulated in browse-url.el mostly for old browsers
> with different handling of command line arguments for "new-window-is-tab" logic.
> But it seems nowadays only three options should be sufficient:
> 
> - use the default browser found by browse-url-default-browser;
> - or use Emacs browser eww;
> - or allow to specify a browser program name with additional arguments.

That makes sense.

-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

Tab-bar autoclose question

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Hi Juri:

I am wondering if maybe there is a simple method to autohide/autoclose the tabbar in some condition. For example, when I close all the other tabs and there is only one.
Is it a straightforward/out_of_the_box method to customize that? 
Best,Ergus

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

Re: Tab-bar autoclose question

[Juri Linkov]

> I am wondering if maybe there is a simple method to autohide/autoclose the
> tabbar in some condition. For example, when I close all the other tabs and
> there is only one.
>
> Is it a straightforward/out_of_the_box method to customize that?

Please try to customize ‘tab-bar-show’ to the value ‘1’
that means to hide the tab-bar when it has only one tab.

Re: Tab-bar autoclose question

[Ergus]

On Thu, Jun 11, 2020 at 12:55:13AM +0300, Juri Linkov wrote:
>> I am wondering if maybe there is a simple method to autohide/autoclose the
>> tabbar in some condition. For example, when I close all the other tabs and
>> there is only one.
>>
>> Is it a straightforward/out_of_the_box method to customize that?
>
>Please try to customize ‘tab-bar-show’ to the value ‘1’
>that means to hide the tab-bar when it has only one tab.
>

Hi Juri:

I tried this and it works pretty fine auto hiding the tab-bar. But I
have an issue.

when I add this to my init file:

(setq-default tab-bar-show 1)

then, if I open a tab with `C-x t 2` it shows the tab-bar and the new
tab, but I don't get bindings like `C-TAB`; but I get the `C-x t o`

After some checks I see that the problem is that in spite of I see the
tabs, the variable tab-bar-mode is still nil.

Any help?
Thanks in advance,

Ergus.

Re: Tab-bar autoclose question

[Juri Linkov]

>>> I am wondering if maybe there is a simple method to autohide/autoclose the
>>> tabbar in some condition. For example, when I close all the other tabs and
>>> there is only one.
>>>
>>> Is it a straightforward/out_of_the_box method to customize that?
>>
>> Please try to customize ‘tab-bar-show’ to the value ‘1’
>> that means to hide the tab-bar when it has only one tab.
>
> I tried this and it works pretty fine auto hiding the tab-bar. But I
> have an issue.
>
> when I add this to my init file:
>
> (setq-default tab-bar-show 1)
>
> then, if I open a tab with `C-x t 2` it shows the tab-bar and the new
> tab, but I don't get bindings like `C-TAB`; but I get the `C-x t o`
>
> After some checks I see that the problem is that in spite of I see the
> tabs, the variable tab-bar-mode is still nil.
>
> Any help?

This feature is currently under active development in https://debbugs.gnu.org/42052
Please help to work out the details.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > When I write a pamphlet using Libre Office, I need to see how it
  > > will appear on the page.  I need to see where line breaks and paragraph
  > > breaks appear.
  > >
  > > I want Emacs to be able to do tect processing that way.
  > When you say page, you mean a printed page on paper?

Of course.  A pamphlet is for handing out.

  > Can't that be helped with some of live preview options for a pdf or ps
  > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?

It would probably take half a minute each time.  I am sure you
understand the advantage of WYSIWYG.  Especially when the text needs
to fit in a limited space.

This is not an issue for longer documents, since it doesn't crucially matter
where the page breaks are in those.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-06-05, at 05:12, Richard Stallman <rms@gnu.org> wrote:

>   > Can't that be helped with some of live preview options for a pdf or ps
>   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>
> It would probably take half a minute each time.  I am sure you
> understand the advantage of WYSIWYG.  Especially when the text needs
> to fit in a limited space.

I think you made a typo here, it should have been "half a second"
probably.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > Can't that be helped with some of live preview options for a pdf or ps
  > >   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
  > >
  > > It would probably take half a minute each time.

  > I think you made a typo here, it should have been "half a second"
  > probably.

That would be an amazing typo.  I expect starting these various
programs to take a long time.  But if it doesn't, they might
be adequate.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >   > Can't that be helped with some of live preview options for a pdf or ps
>   > >   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>   > >
>   > > It would probably take half a minute each time.
>
>   > I think you made a typo here, it should have been "half a second"
>   > probably.
>
> That would be an amazing typo.  I expect starting these various
> programs to take a long time.  But if it doesn't, they might
> be adequate.
I don't know what kind of computer you use, of course, but if you ment
the startup time for a browser, then maybe it is a half second or so, but
does it matter? It happends once, when one start to work on a pamflet.
LibreOffice takes also a half a second if not more to startup every time
and I have quite decent machine.

If you start a Chromium process, and then connect from within Emacs with
impatient-mode, I don't think you would suffer from lack of real time
performance; not for something like a pamflet.

Another option is to use some webkit wrap + xwidgets, but I haven't
tryed it myself. No idea how easy to use or good it is, but for preview
it should probably be good enough. I have seen some Reddit threads
and YT videos where people demonstrated it, but I didn't care to try
myself.

Here is some 4 year old video where a guy is demonstrating xwidgets and
webkit to render html in gnus:

https://www.youtube.com/watch?v=J2YdjpWJJHs

(download with youtube-dl to skip proprietary js)

Very nice presentation by the way.

With HTML+CSS as intermediate file format, one can have some predefined
templates with a pamflet size, layout, typografi etc, and then just edit
content of few html tags.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The process that was suggested for viewing the page image
involved running several programs each time.  A few seconds to start each
and it could take half a minute.

I use a machine that was made in 2008 or so.  I use it because we can
boot it with libreboot.  I cannot predict when there might be a faster
machine I could use.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The process that was suggested for viewing the page image
> involved running several programs each time.  A few seconds to start each
> and it could take half a minute.
>
> I use a machine that was made in 2008 or so.  I use it because we can
> boot it with libreboot.  I cannot predict when there might be a faster
> machine I could use.
I understand.

Have you heard about company called Purism and librem project?

https://puri.sm/why-purism/

I am not sure if it is suitable enough, but they do run only free
software, from boot (coreboot) to highest level; at least as I understand
them. Also I believe they went to the length of ordering Intel cpus with
intel's "management" backdoor disabled. Just as a tip.

Re: "Why is emacs so square?"

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > When I write a pamphlet using Libre Office, I need to see how it
>   > > will appear on the page.  I need to see where line breaks and paragraph
>   > > breaks appear.
>   > >
>   > > I want Emacs to be able to do tect processing that way.
>   > When you say page, you mean a printed page on paper?
>
> Of course.  A pamphlet is for handing out.
>
>   > Can't that be helped with some of live preview options for a pdf or ps
>   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>
> It would probably take half a minute each time.  I am sure you
> understand the advantage of WYSIWYG.  Especially when the text needs
> to fit in a limited space.
I understand that wysiwyg is easier and I understand your concern
for delays. I believe those delays would not be noticable for a pamphlet
(A4/A5 size?) if you used html as intermediate format.

Anyway what about if emacs had a print-page-mode as a minor mode for
displaying some printing hints in text modes? I am not sure if I can
write such, but here is idea:

* provide a database of predefined paper sizes as specified on:
  https://www.papersizes.org/a-sizes-in-pixels.htm
  to be used as templates for width and height (in pixels)
  
* advice insert funcion(s) to check for current line pixel-width and
  pixel-height. If width or height exceed template width and height then
  insert ^L to denote page break and move point to next line and insert
  text in next line. If width is exceeded maybe it is just enough to
  move point to next line, but when height for a page is exceeded one
  would need a special char to visualize page break.

As I understand Emacs already has some support for page breaks (^L) as I
learned myself very recently :-). There is extended page handling in
Emacs and also a mode called PageMode:

https://www.emacswiki.org/emacs/PageMode

I am not sure, but what I think is missing is just to tie those things
to paper sizes and automize page creation based on some paper template
which is nothing but a pixel-width and pixel-height. I am not sure, I
haven't used PageMode myself, I just learned about it.

I am not sure how efficient it would be to check for pixel-width and height
on every char insertion, maybe there is some better way?

It would be nice if Emacs could draw a thin line to denote edges, or a
rectangle of page size below the text as word processors do, but that
would ask for some c and exposing of some graphics (XDrawRect & co) to
elisp?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 05 Jun 2020 15:01:13 +0200
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
> Anyway what about if emacs had a print-page-mode as a minor mode for
> displaying some printing hints in text modes? I am not sure if I can
> write such, but here is idea:
> 
> * provide a database of predefined paper sizes as specified on:
>   https://www.papersizes.org/a-sizes-in-pixels.htm
>   to be used as templates for width and height (in pixels)
>   
> * advice insert funcion(s) to check for current line pixel-width and
>   pixel-height. If width or height exceed template width and height then
>   insert ^L to denote page break and move point to next line and insert
>   text in next line. If width is exceeded maybe it is just enough to
>   move point to next line, but when height for a page is exceeded one
>   would need a special char to visualize page break.
> 
> As I understand Emacs already has some support for page breaks (^L) as I
> learned myself very recently :-). There is extended page handling in
> Emacs and also a mode called PageMode:
> 
> https://www.emacswiki.org/emacs/PageMode
> 
> I am not sure, but what I think is missing is just to tie those things
> to paper sizes and automize page creation based on some paper template
> which is nothing but a pixel-width and pixel-height. I am not sure, I
> haven't used PageMode myself, I just learned about it.
> 
> I am not sure how efficient it would be to check for pixel-width and height
> on every char insertion, maybe there is some better way?

All of this is already available, although not all of it is exposed to
Lisp.  Taking advantage of existing pixel-level capabilities is part
of the job of providing the features that Richard has in mind.

> It would be nice if Emacs could draw a thin line to denote edges, or a
> rectangle of page size below the text as word processors do

We already can display such thin lines, see, for example, help-fns.el
(search for ":height").  No X-level graphics is needed.

Re: "Why is emacs so square?"

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Fri, 05 Jun 2020 15:01:13 +0200
>> Cc: sb@dod.no, emacs-devel@gnu.org
>> 
>> Anyway what about if emacs had a print-page-mode as a minor mode for
>> displaying some printing hints in text modes? I am not sure if I can
>> write such, but here is idea:
>> 
>> * provide a database of predefined paper sizes as specified on:
>>   https://www.papersizes.org/a-sizes-in-pixels.htm
>>   to be used as templates for width and height (in pixels)
>>   
>> * advice insert funcion(s) to check for current line pixel-width and
>>   pixel-height. If width or height exceed template width and height then
>>   insert ^L to denote page break and move point to next line and insert
>>   text in next line. If width is exceeded maybe it is just enough to
>>   move point to next line, but when height for a page is exceeded one
>>   would need a special char to visualize page break.
>> 
>> As I understand Emacs already has some support for page breaks (^L) as I
>> learned myself very recently :-). There is extended page handling in
>> Emacs and also a mode called PageMode:
>> 
>> https://www.emacswiki.org/emacs/PageMode
>> 
>> I am not sure, but what I think is missing is just to tie those things
>> to paper sizes and automize page creation based on some paper template
>> which is nothing but a pixel-width and pixel-height. I am not sure, I
>> haven't used PageMode myself, I just learned about it.
>> 
>> I am not sure how efficient it would be to check for pixel-width and height
>> on every char insertion, maybe there is some better way?
>
> All of this is already available, although not all of it is exposed to
> Lisp.  Taking advantage of existing pixel-level capabilities is part
> of the job of providing the features that Richard has in mind.
When you say all of this, and not exposed to lisp, what exactly do you
mean? :-) Is it possible to get a pixel offset from a point with elisp?
Height, width, or whatever that could be used to calculate if current
buffer region fits iin a page or not?

(defvar ppi-72
  '((4A0 . (4768 . 6741))
    (2A0 . (3370 . 4768))
    (A0  . (2384 . 3370))
    (A1  . (1684 . 2384))
    (A2  . (1191 . 1684))
    (A3  . (842  . 1191))
    (A4  . (595  . 842 ))
    (A5  . (420  . 595 ))
    (A6  . (298  . 420 ))
    (A7  . (210  . 298 ))
    (A8  . (147  . 210 ))
    (A9  . (105  . 147 ))
    (A10 . (74   . 105 ))))

If I have a database of sizes like this, I would need to know a size in
pixel of a buffer region between some min and max points. That could be
used to either defadvice insert or to calculate and restructure text
afterwards. Maybe it is to naive, no idea, just thinking. Also I am not
sure how resolution/ppi relate to emacs buffers to be honest.


>> It would be nice if Emacs could draw a thin line to denote edges, or a
>> rectangle of page size below the text as word processors do
>
> We already can display such thin lines, see, for example, help-fns.el
> (search for ":height").  No X-level graphics is needed.
As composed of characters or as overlays with underline/overstruck or
similar? What about a rectangle in some color as a background to
symbolize a page. I understand it is not needed, but it would be nice.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: rms@gnu.org,  sb@dod.no,  emacs-devel@gnu.org
> Date: Fri, 05 Jun 2020 16:57:32 +0200
> 
> > All of this is already available, although not all of it is exposed to
> > Lisp.  Taking advantage of existing pixel-level capabilities is part
> > of the job of providing the features that Richard has in mind.
> When you say all of this, and not exposed to lisp, what exactly do you
> mean? :-) Is it possible to get a pixel offset from a point with elisp?
> Height, width, or whatever that could be used to calculate if current
> buffer region fits iin a page or not?

See window-text-pixel-size as one example of what we have.  The
underlying functionality is even more powerful.

> >> It would be nice if Emacs could draw a thin line to denote edges, or a
> >> rectangle of page size below the text as word processors do
> >
> > We already can display such thin lines, see, for example, help-fns.el
> > (search for ":height").  No X-level graphics is needed.
> As composed of characters or as overlays with underline/overstruck or
> similar?

Just look at the code, it is self-explanatory, IMO.

> What about a rectangle in some color as a background to symbolize a
> page.

You will see in the code I pointed to that we actually already produce
a rectangle, just a very thin one.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
> See window-text-pixel-size as one example of what we have.  The
> underlying functionality is even more powerful.

(window-text-pixel-size) returns nonsense in console.

>> > We already can display such thin lines, see, for example, help-fns.el
>> > (search for ":height").  No X-level graphics is needed.

X graphics is seems to be needed.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: sb@dod.no, rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 05 Jun 2020 18:15:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > See window-text-pixel-size as one example of what we have.  The
> > underlying functionality is even more powerful.
> 
> (window-text-pixel-size) returns nonsense in console.

It does?  Can you show an example?  Or, better yet, make a bug report
about the problematic case(s)?

> >> > We already can display such thin lines, see, for example, help-fns.el
> >> > (search for ":height").  No X-level graphics is needed.
> 
> X graphics is seems to be needed.

You need a GUI frame (not necessarily on X), but that's all.  There's
no need to expose Xlib calls to Lisp, which was what the original
question was about.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > See window-text-pixel-size as one example of what we have.  The
>> > underlying functionality is even more powerful.
>> 
>> (window-text-pixel-size) returns nonsense in console.
>
> It does?  Can you show an example?  Or, better yet, make a bug report
> about the problematic case(s)?

bug report sent

>> >> > We already can display such thin lines, see, for example, help-fns.el
>> >> > (search for ":height").  No X-level graphics is needed.
>> 
>> X graphics is seems to be needed.
>
> You need a GUI frame (not necessarily on X), but that's all.  There's
> no need to expose Xlib calls to Lisp, which was what the original
> question was about.

ok, thanks for clarification

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understand that wysiwyg is easier and I understand your concern
  > for delays. I believe those delays would not be noticable for a pamphlet
  > (A4/A5 size?) if you used html as intermediate format.

Could you state your proposed solution more concretely?
How would it work, which programs would it use?

  > * provide a database of predefined paper sizes as specified on:
  >   https://www.papersizes.org/a-sizes-in-pixels.htm
  >   to be used as templates for width and height (in pixels)
  
  > * advice insert funcion(s) to check for current line pixel-width and
  >   pixel-height. If width or height exceed template width and height then
  >   insert ^L to denote page break and move point to next line and insert
  >   text in next line. If width is exceeded maybe it is just enough to
  >   move point to next line, but when height for a page is exceeded one
  >   would need a special char to visualize page break.

If this works reliably, and isn't very slow, it could be good enough.
For this to work reliably requires understanding the width of text
as it will eventually be rendered, including different sizes and
variants (italic, bold, etc).

  > I am not sure how efficient it would be to check for pixel-width and height
  > on every char insertion, maybe there is some better way?

We can arrange to take note of how wide the line is,
update that incrementally in a quick way, then do more
processing when that seems necessary.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 05 Jun 2020 23:56:16 -0400
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
>   > * advice insert funcion(s) to check for current line pixel-width and
>   >   pixel-height. If width or height exceed template width and height then
>   >   insert ^L to denote page break and move point to next line and insert
>   >   text in next line. If width is exceeded maybe it is just enough to
>   >   move point to next line, but when height for a page is exceeded one
>   >   would need a special char to visualize page break.
> 
> If this works reliably, and isn't very slow, it could be good enough.
> For this to work reliably requires understanding the width of text
> as it will eventually be rendered, including different sizes and
> variants (italic, bold, etc).

FWIW, I don't think this is possible from Lisp, not with the currently
available facilities.  shr.el does something like that, and it does a
decent job with the tools it has, but IMO it is nowhere near what is
needed, and cannot handle complex situations with various complex
scripts.  It is also quite slow: I sometimes need to wait for several
seconds for it to display an email message of a couple of hundreds
lines.

Layout in Emacs has to be done in C to be both efficient and fully
capable.  Some small and simple jobs, like pixel-level alignment, can
be done in Lisp, but not the entire job as a whole.

Re: "Why is emacs so square?"

[Bob Newell]

Richard Stallman <rms@gnu.org> writes:

> This is not an issue for longer documents, since it doesn't crucially
> matter
> where the page breaks are in those.

Just as a point of interest: page breaks definitely can matter
in longer documents. I've done quite a number of books with
Emacs/LaTeX, and in doing text layout I have to take into
account widows and orphans--- for instance, having a single
line of a paragraph at the bottom of a page is a no-no, and
page breaks have to be manipulated to avoid bad typography.

That said, I've found that even for longish books with many
diagrams (my most extreme example was nearly 800 pages), the
compile and view process was fast enough not to get in the
way, and corrections and changes go very fast if using
something like synctex (I believe that's the correct name).

This is not to say that I don't see the need for WYSIWYG on
graphics-intense publications; for instance I couldn't see
doing a comic book in emacs.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Richard Stallman <rms@gnu.org> writes:
> When I write a pamphlet using Libre Office, I need to see how it
> will appear on the page.  I need to see where line breaks and paragraph
> breaks appear.
>
> I want Emacs to be able to do tect processing that way.

What are the missing pieces?

I think there are many and they would be useful for other use-cases.

Some of the use-cases I am interested in:

1) Sometimes, I need to write a letter which does not need to be an art
   work.  I wrote emacs-pdf (see
   <https://logand.com/sw/emacs-pdf/file/emacs-pdf.el.html>) to address
   that.

   It creates a PDF document from an Emacs buffer.  Only plain,
   monospace ASCII text works so far, but it can already break and count
   pages and insert headers and footers.  It is very short (about 400
   lines of elisp including comments) and requires no dependencies and
   no graphics.

   a) The next step will be unicode.

      It seems that there is some code in Emacs dealing with unicode
      fonts in order to generate postscript files.  Any pointers where
      to start with this?
  
   b) After that, emacs-pdf will understand font metrics so it will be
      possible to do layout.

      It should be possible to render HTML for example, and create
      graphical web browser as an alternative to eww.

      It should also be possible to render other formats like abw, odt,
      etc.  At least roughly, depending on how much detail in the
      corresponding spec people want to address.  I have explored simple
      conversion to text in pure elisp in emacs-unoffice
      <https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html>.

      It should be possible to write a direct PDF backend for org-mode
      and maybe enriched-mode.

      Internally, probably some kind of html like sexp based format
      should be used.  I used a sexp based format in emacs-pdf
      (transient cons tree representation) but for document processing,
      the format should not be so low level (e.g. no PDF drawing
      primitives but something like HTML primitives; or maybe mixed).

   c) It should not be difficult to add raster images and vector
      graphics to the PDF drawing code.

   d) It should be possible to add for example SVG backend.  Non-console
      Emacs can already draw SVG.  At least at the beginning, this would
      also avoid the need for image rasterisation if vector format like
      PDF or SVG is used.

      Maybe this could be used for real-time preview, before we get
      WYSIWYG.  Or maybe use pdf-tools to view the generated PDF.

2) Printing is an issue in Emacs.  I will try to implement an
   alternative which will use IPP and PDF.  No PostScript, no CUPS, if
   possible no complex configuration.

3) I use Emacs on the console a lot.  All the above should work there
   too.  In order to view images in console Emacs, I wrote
   <https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html>.
   So far there are a few functions that draw images using w3mimgdisplay
   from the w3m console web browser.  It fits images on the screen,
   unlike graphical Emacs where image display is unuseable.

   a) I would like image-mode just work with this emacs-framebuffer
      image drawing.  Any ideas, how to plug emacs-framebuffer into
      image-mode?

   b) It is a shame, that I need to reimplement such basic functions
      like image-size:

      (image-size (create-image "/tmp/a.jpg"))
      => (error "Window system frame should be used")

      framebuffer-image-size at
      https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html#l95
      does not require any dependencies and computes image size for png,
      jpeg, bmp, gif, tiff and pnm in elisp.

      It would be nice to eliminate or at least reduce the need for such
      dependencies so that many Emacs features are useable in different
      environments, like for example console.

   c) There are functions frame-width and frame-height.  Are there also
      functions something like buffer-width and buffer-height and or a
      way to compute x and y position relative to frame origin, which
      would allow me to position images exactly in the buffer similar to
      what w3m browser does?

4) Emacs is missing some kind of canvas, where things could be drawn and
   which would handle pixel precise input.

   For example, I would like to browse OpenStreetMap in Emacs.  I wrote
   a console based OSM browser osmq
   <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
   <https://osmq.eu/>.  I would prefer an Emacs based map browser.
   However, I have not figured out how to lay out images in Emacs in a
   grid and how to detect which image was clicked.  A bonus would be,
   where exactly was clicked.  Any ideas what should I look into?

   Emacs canvas should probably work like HTML canvas, which is rather
   similar to PDF or PostScript in terms of drawing interface.  I have
   explored this space in the PostScript interpreter in JavaScript
   <https://logand.com/sw/wps/index.html>.

   Not sure how difficult it would be to plug some kind of portable
   canvas into Emacs.  This seems rather low level C work.

It seems to me that these points are precondition for a WYSIWYG document
editor feature in Emacs.

Do these points resonate here?

Is somebody already implementing anything mentioned?

Or what is already implemented?

Would there be an interest in incorporating emacs-pdf, emacs-unoffice
and emacs-framebuffer (the framebuffer-image-size function?) into Emacs?

Regards,

Tomas

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Better exporting of Emacs buffers to PDF is certainly a desirable feature.
Any system for editing formatted text in Emacs will need that feature.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Fri, 05 Jun 2020 23:54:08 +0200
> Cc: emacs-devel@gnu.org
> 
>       It seems that there is some code in Emacs dealing with unicode
>       fonts in order to generate postscript files.  Any pointers where
>       to start with this?

I think you should provide more details about the particular problem
you are trying to solve here, because I don't think I understand it.
Emacs generally knows only about fonts it uses for its own display,
and it needs to load the font before it can provide information about
it.  Whereas you seem to be talking about fonts to be used in the PDF
file, not in Emacs display.

>    b) After that, emacs-pdf will understand font metrics so it will be
>       possible to do layout.

I very much doubt you can do sensible layout in Lisp.  shr.el tries,
but the result is slow and incomplete -- and it does that with text
displayed by Emacs itself, whereas you are talking about something
more ambitious.

If you want to do layout for PDF, I think one way forward would be to
implement a pdfterm.c "terminal" for Emacs, which produces PDF like
the existing *term.c backends do for supported display types.

>    c) There are functions frame-width and frame-height.  Are there also
>       functions something like buffer-width and buffer-height and or a
>       way to compute x and y position relative to frame origin, which
>       would allow me to position images exactly in the buffer similar to
>       what w3m browser does?

Yes, there are, but they need a window to compute these metrics.
Without a live window, "buffer width" is meaningless, because buffer
text doesn't define the fonts (more generally, the typefaces) used for
displaying the text.  Only a window in which a buffer is displayed
provides enough typeface information to do these calculations.

> 4) Emacs is missing some kind of canvas, where things could be drawn and
>    which would handle pixel precise input.
> 
>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
>    a console based OSM browser osmq
>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
>    However, I have not figured out how to lay out images in Emacs in a
>    grid and how to detect which image was clicked.  A bonus would be,
>    where exactly was clicked.  Any ideas what should I look into?

Emacs supports "hot spots" on images for this: a click on an image
returns information about pixel-resolution offset of the click from
the image origin.  I think that's what you want, although I'm not 100%
sure.

We also support displaying slices of images, in case that helps to
produce a smarter layout of images.

> It seems to me that these points are precondition for a WYSIWYG document
> editor feature in Emacs.

FWIW, I don't think these points are necessarily preconditions for
WYSIWYG features.  They are important and useful features, but a
WYSIWYG document editor should IMO start with something whose
beginning we have in enriched-mode.  That mode currently lacks the
ability of laying out text in variable-pitch typefaces, which I think
is the first extension of enriched-mode that should be worked on.
Followed by page layout and page breaks, intelligent sectioning
commands, etc. etc.  And yes, printing is also important, whether it
is done by producing PDF or PostScript or any other intermediate
format.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tomas Hlavaty <tom@logand.com>
>> Date: Fri, 05 Jun 2020 23:54:08 +0200
>> Cc: emacs-devel@gnu.org
>> 
>>       It seems that there is some code in Emacs dealing with unicode
>>       fonts in order to generate postscript files.  Any pointers where
>>       to start with this?
>
> I think you should provide more details about the particular problem
> you are trying to solve here, because I don't think I understand it.
> Emacs generally knows only about fonts it uses for its own display,
> and it needs to load the font before it can provide information about
> it.  Whereas you seem to be talking about fonts to be used in the PDF
> file, not in Emacs display.

I poked around a bit and it seems that what I did in emacs-pdf
(pdf-buffer function) is similar to what ps-print-buffer function does
in ps-print and ps-mule with ps-multibyte-buffer set to nil.

Now I want something like ps-multibyte-buffer, e.g. pdf-multibyte-buffer
so that I can use non-ASCII characters in the generated PDF.  So I
probably want to implement something similar to ps-multibyte-buffer
cases of non-latin-printer, bdf-font and/or bdf-font-except-latin.

There seem to be ps-bdf so maybe I have to look, if I can reuse
something when generating PDF.

>>    b) After that, emacs-pdf will understand font metrics so it will be
>>       possible to do layout.
>
> I very much doubt you can do sensible layout in Lisp.  shr.el tries,
> but the result is slow and incomplete -- and it does that with text
> displayed by Emacs itself, whereas you are talking about something
> more ambitious.

For printing, this might not be an issue.

> If you want to do layout for PDF, I think one way forward would be to
> implement a pdfterm.c "terminal" for Emacs, which produces PDF like
> the existing *term.c backends do for supported display types.

I'll have a look, thanks.

>>    c) There are functions frame-width and frame-height.  Are there also
>>       functions something like buffer-width and buffer-height and or a
>>       way to compute x and y position relative to frame origin, which
>>       would allow me to position images exactly in the buffer similar to
>>       what w3m browser does?
>
> Yes, there are, but they need a window to compute these metrics.
> Without a live window, "buffer width" is meaningless, because buffer
> text doesn't define the fonts (more generally, the typefaces) used for
> displaying the text.  Only a window in which a buffer is displayed
> provides enough typeface information to do these calculations.

I see.

There is frame-position but no window-position.  Is there a way to get
window position in a frame?

>> 4) Emacs is missing some kind of canvas, where things could be drawn and
>>    which would handle pixel precise input.
>> 
>>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
>>    a console based OSM browser osmq
>>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
>>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
>>    However, I have not figured out how to lay out images in Emacs in a
>>    grid and how to detect which image was clicked.  A bonus would be,
>>    where exactly was clicked.  Any ideas what should I look into?
>
> Emacs supports "hot spots" on images for this: a click on an image
> returns information about pixel-resolution offset of the click from
> the image origin.  I think that's what you want, although I'm not 100%
> sure.

Yes.  Is there an example how to start with this?

> We also support displaying slices of images, in case that helps to
> produce a smarter layout of images.

Great.  Is there an example?

>> It seems to me that these points are precondition for a WYSIWYG document
>> editor feature in Emacs.
>
> FWIW, I don't think these points are necessarily preconditions for
> WYSIWYG features.  They are important and useful features, but a
> WYSIWYG document editor should IMO start with something whose
> beginning we have in enriched-mode.  That mode currently lacks the
> ability of laying out text in variable-pitch typefaces, which I think
> is the first extension of enriched-mode that should be worked on.
> Followed by page layout and page breaks, intelligent sectioning
> commands, etc. etc.  And yes, printing is also important, whether it
> is done by producing PDF or PostScript or any other intermediate
> format.

Interesting.  Maybe the pdfterm.c you suggested is kind of canvas I
wrote about.  When there is all that complexity with pixel perfect
drawing and layout, it would be shame to limit it to enriched mode.  But
it is still too early to make decisions in this direction.

Thank you for your help and quick and helpful answers!

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 07 Jun 2020 10:03:35 +0200
> 
> I poked around a bit and it seems that what I did in emacs-pdf
> (pdf-buffer function) is similar to what ps-print-buffer function does
> in ps-print and ps-mule with ps-multibyte-buffer set to nil.

BDF fonts were OK when ps-mule.el and ps-bdf.el were developed, but
nowadays I think you will find that many users will object to using
bitmapped fonts in printed matter.  (There were plans to develop
ps-type1.el, but I don't think they materialized.)  Caveat emptor.

> There is frame-position but no window-position.  Is there a way to get
> window position in a frame?

Is window-edges what you want?

> >>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
> >>    a console based OSM browser osmq
> >>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
> >>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
> >>    However, I have not figured out how to lay out images in Emacs in a
> >>    grid and how to detect which image was clicked.  A bonus would be,
> >>    where exactly was clicked.  Any ideas what should I look into?
> >
> > Emacs supports "hot spots" on images for this: a click on an image
> > returns information about pixel-resolution offset of the click from
> > the image origin.  I think that's what you want, although I'm not 100%
> > sure.
> 
> Yes.  Is there an example how to start with this?

I suggest to read "Click Events" and "Accessing Mouse" in the ELisp
manual, I think the description there is clear enough to let you write
code even without examples.

> > We also support displaying slices of images, in case that helps to
> > produce a smarter layout of images.
> 
> Great.  Is there an example?

Likewise here: I suggest to read "Showing Images", where this is
described.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> There is frame-position but no window-position.  Is there a way to get
>> window position in a frame?
>
> Is window-edges what you want?

Yes, window-edges is what I was looking for, thanks.  Now I can draw
images in console exactly where they should be.

However, there seem to be problem with get-buffer-window function:

get-buffer-window returns one buffer or nil.  This seems wrong because a
buffer can be visible on many windows.

Is there a function (or trick) which returns all windows, where a
specified buffer is visible?

RE: "Why is emacs so square?"

[Drew Adams]

> get-buffer-window returns one buffer or nil.  This seems wrong because a
> buffer can be visible on many windows.

(Typo - it returns one window, not one buffer.)

> Is there a function (or trick) which returns all windows, where a
> specified buffer is visible?

`C-h f get-buffer-window-list'

(get-buffer-window-list nil nil 'visible)

RE: "Why is emacs so square?"

[Tomas Hlavaty]

Drew Adams <drew.adams@oracle.com> writes:
>> get-buffer-window returns one buffer or nil.  This seems wrong because a
>> buffer can be visible on many windows.
>
> (Typo - it returns one window, not one buffer.)

yes, sorry about that

>> Is there a function (or trick) which returns all windows, where a
>> specified buffer is visible?
>
> `C-h f get-buffer-window-list'
>
> (get-buffer-window-list nil nil 'visible)

great, thank you!

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We certainly should have a pdf-print-buffer.
One way would be to call ps-print-buffer
and then run ps2pdf.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That statement may be correct, but you've changed the topic.

  > Did I?

  > The topic was Emacs's popularity, AFAICT.

Yes.  I want Emacs to become once again popular for editing text for
publication, as it was before.

More than that, I want to use it myself that way.

  > As a word processor, it's a lot less capable, and adding the two 
  > features you mentioned above won't bring us much closer to that goal, 

A long journey has to be achieved step by step.  Since 1990 I have
planned to extend Emacs to do word processing.  If that doesn't
interest you, you don't have to help, but please don't get in the way.

  > And there are existing Free programs 
  > that do this better already (like LibreOffice Writer).

I use LibreOffice.  It works, but I very much miss the 
fundamental capabilities of Emacs.

I want to do word processing in Emacs and program commands in Emacs Lisp.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Joost Kremers]

On Tue, Apr 21 2020, Richard Stallman wrote:
> I use LibreOffice.  It works, but I very much miss the 
> fundamental capabilities of Emacs.
>
> I want to do word processing in Emacs and program commands in 
> Emacs Lisp.

Lots of people are writing books and articles in Emacs using Org 
mode, which is as close to a full-blown office suite (word 
processor, PIM, spread sheet, presentation editor) as any text 
editor will get. If you want to do word processing in Emacs, you 
should check it out and see where it can be improved/extended to 
get to where you want Emacs to go.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I found it impossible to learn what Org mode does.  Its introduction
taught how to do outline editing.  It made sense, but outline editing
useful for me, so I stopped reading.  I did not want to study use of a
mode for outline editing.

When you tell me that Emacs has important facilities -- doing jobs
very different from outline editing -- that I don't know about because
they have been integrated as "part of Org mode", my conclusion is that
we should have integrated them differently.  Those other facilities
should not be treated as "part of Org mode".  They should be separate
facilities, each one documented separately, and usable by itself.

I would like to see those facilities separated from Org mode and made
into separate first-class subsystems.  Then they can be documented in
the Emacs manual.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Nicolas Goaziou]

Hello,

Richard Stallman <rms@gnu.org> writes:

> When you tell me that Emacs has important facilities -- doing jobs
> very different from outline editing -- that I don't know about because
> they have been integrated as "part of Org mode", my conclusion is that
> we should have integrated them differently.  Those other facilities
> should not be treated as "part of Org mode".  They should be separate
> facilities, each one documented separately, and usable by itself.
>
> I would like to see those facilities separated from Org mode and made
> into separate first-class subsystems.  Then they can be documented in
> the Emacs manual.

There may be a misconception about what Org really is. It is unfortunate
if its documentation lets one think the mode is about outline editing.

  Org is both a lightweight markup language, and a major mode to edit
  it. Versatile, it is useful for keeping notes, maintaining TODO lists,
  and project planning. Powerful, it may be used as a complete authoring
  system, with support for literate programming and reproducible
  research.

Outline editing is but the design choice that was made for the major
mode to edit documents with Org syntax. To put it differently, the
common factor between the "other facilities" you mention, whatever they
are, is not the outliner part, but the markup language behind it.

As a consequence, it probably makes little sense to separate such
"facilities"---the term would need to be properly defined in the current
context, tho---, because each of them implies full support for the whole
Org syntax.

As a side node, there are attempts to proceed the other way. For example
OrgTbl minor mode, included in Org for historical reasons, edits---a
subset of---Org tables in other major modes. Likewise, Orgalist, found
in GNU ELPA, ports---a subset of---Org lists to other major modes. None
of them equates its native counterpart for the reasons explained above.

Conversely, I'm thinking out loud here, there is one external facility
that I would like to see integrated into Emacs proper, so major modes,
such as Org, could use it. It is Citeproc.el, a library for rendering
citations and bibliographies in styles described in the Citation Style
Language (CSL).

Regards,

-- 
Nicolas Goaziou

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date: Wed, 22 Apr 2020 11:12:59 +0200
> Cc: Joost Kremers <joostkremers@fastmail.fm>, emacs-devel@gnu.org
> 
> > When you tell me that Emacs has important facilities -- doing jobs
> > very different from outline editing -- that I don't know about because
> > they have been integrated as "part of Org mode", my conclusion is that
> > we should have integrated them differently.  Those other facilities
> > should not be treated as "part of Org mode".  They should be separate
> > facilities, each one documented separately, and usable by itself.
> >
> > I would like to see those facilities separated from Org mode and made
> > into separate first-class subsystems.  Then they can be documented in
> > the Emacs manual.
> 
> There may be a misconception about what Org really is. It is unfortunate
> if its documentation lets one think the mode is about outline editing.
> 
>   Org is both a lightweight markup language, and a major mode to edit
>   it. Versatile, it is useful for keeping notes, maintaining TODO lists,
>   and project planning. Powerful, it may be used as a complete authoring
>   system, with support for literate programming and reproducible
>   research.
> 
> Outline editing is but the design choice that was made for the major
> mode to edit documents with Org syntax. To put it differently, the
> common factor between the "other facilities" you mention, whatever they
> are, is not the outliner part, but the markup language behind it.

IMNSHO, the Org manual "needs work"™.  Its current form shows the long
history of the package, more than it shows what it is nowadays.  I
mean, consider this opening phrases in Introduction:

  Org is a mode for keeping notes, maintaining TODO lists, and project
  planning with a fast and effective plain-text markup language.  It also
  is an authoring system with unique support for literate programming and
  reproducible research.

     Org is implemented on top of Outline mode, which makes it possible to
  keep the content of large files well structured.  Visibility cycling and
  structure editing help to work with the tree.  Tables are easily created
  with a built-in table editor.  Plain text URL-like links connect to
  websites, emails, Usenet messages, BBDB entries, and any files related
  to the projects.

     Org develops organizational tasks around notes files that contain
  lists or information about projects as plain text.  Project planning and
  task management make use of metadata which is part of an outline node.
  Based on this data, specific entries can be extracted in queries and
  create dynamic _agenda views_ that also integrate the Emacs calendar and
  diary.  Org can be used to implement many different project planning
  schemes, such as David Allen’s GTD system.

Etc., etc.  I invite you to put yourself in the shows of a newcomer to
Org, and try to imagine how such a newcomer will be able to realize
that Org can be used as a word-processor...

So please don't be surprised that Richard thinks about this what he
thinks.

Now, suppose someone tells me that Org includes word-processing
capabilities, and I'm excited about that and want to learn how to do
that.  Here's the menu I'm presented with in the Top node:

  * Introduction::                 Getting started.
  * Document Structure::           A tree works like your brain.
  * Tables::                       Pure magic for quick formatting.
  * Hyperlinks::                   Notes in context.
  * TODO Items::                   Every tree branch can be a TODO item.
  * Tags::                         Tagging headlines and matching sets of tags.
  * Properties and Columns::       Storing information about an entry.
  * Dates and Times::              Making items useful for planning.
  * Refiling and Archiving::       Moving and copying information with ease.
  * Capture and Attachments::      Dealing with external data.
  * Agenda Views::                 Collecting information into views.
  * Markup for Rich Contents::     Compose beautiful documents.
  * Exporting::                    Sharing and publishing notes.
  * Publishing::                   Create a web site of linked Org files.
  * Working with Source Code::     Export, evaluate, and tangle code blocks.
  * Miscellaneous::                All the rest which did not fit elsewhere.
  * Hacking::                      How to hack your way around.
  * History and Acknowledgments::  How Org came into being.
  * GNU Free Documentation License:: The license for this documentation.
  * Main Index::                   An index of Org’s concepts and features.
  * Key Index::                    Key bindings and where they are described.
  * Command and Function Index::   Command names and some internal functions.
  * Variable Index::               Variables mentioned in the manual.

Hmm... which one of the chapters should I read?  I tried "Publishing"
first, but quickly realized that's not it.  Next, I tried "Exporting"
("Sharing and publishing notes.", right?) -- another false hit.
Finally, I thought maybe it's in "Markup for Rich Contents".  This
time I think I found what I was looking for, but look at that
chapter's menu:

  * Paragraphs::                   The basic unit of text.
  * Emphasis and Monospace::      Bold, italic, etc.
  * Subscripts and Superscripts:: Simple syntax for raising/lowering text.
  * Special Symbols::              Greek letters and other symbols.
  * Embedded LaTeX::               LaTeX can be freely used inside Org documents.
  * Literal Examples::             Source code examples with special formatting.
  * Images::                       Display an image.
  * Captions::                     Describe tables, images...
  * Horizontal Rules::             Make a line.
  * Creating Footnotes::           Edit and read footnotes.

This sounds like a more-or-less random collection of related tidbits,
not an explanation of how to use Org as a word-processor.  And as soon
as I go to the first section, "Paragraphs", I'm almost immediately
lost:

  Paragraphs are separated by at least one empty line.  If you need to
  enforce a line break within a paragraph, use ‘\\’ at the end of a line.

     To preserve the line breaks, indentation and blank lines in a region,
  but otherwise use normal formatting, you can use this construct, which
  can also be used to format poetry.

       #+BEGIN_VERSE
	Great clouds overhead
	Tiny black birds rise and fall
	Snow covers Emacs

	   ---AlexSchroeder
       #+END_VERSE

What are those "#+BEGIN_VERSE" and "#+END_VERSE" markers?  Do I type
them verbatim in the text of a document?  There's no answer.  (Of
course, yours truly is somewhat familiar with Org, so _I_ know the
answer.  But a newbie won't.)

This is not what a chapter about using a word processor should look
like.  It should begin with an introduction to word-processing with
Org, an overview of what's possible and what isn't; it should go on to
explaining how to start a document, how to write a heading and a
sub-heading, how to insert references, links, footnotes, and other
objects; it should then explain how to produce a TOC and an index, and
finally point me to another chapter that explains how to export my
document in a variety of formats.

A good example of how such documentation should be structured is at
the beginning of the Texinfo manual, which also describes a system for
writing documents.  Look at the first dozen of chapters there for
inspiration.

> As a consequence, it probably makes little sense to separate such
> "facilities"---the term would need to be properly defined in the current
> context, tho---, because each of them implies full support for the whole
> Org syntax.

Maybe you took the "separate" part to mean that the _code_ should be
separated or subdivided.  I'm not sure Richard meant that, but even if
he did, what I would like to see is a "separation" on the
documentation level.  Let a user who only wants to write documents
with Org be able to learn that without reading 50% of the Org manual,
in order to understand "the whole Org syntax".  Allow a user who is
only interested in GTD to be able to do just that by learning the
necessary Org commands and procedures, and little else.  Etc. etc. --
try to "separate" what Org is capable of into several large classes of
jobs, and make sure each of these classes is documented clearly and
logically, as if it were a separate manual (and maybe it really should
be a separate manual, I don't know).

I hope I explained at least what is my view of how Org should evolve
(in addition to the routine development that adds new features) -- it
should try to present a less monolith-like appearance towards new
users, and allow them to master just a part of its capabilities, the
part that they are interested in.

HTH and TIA

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have learned a lot more about Org mode from your message
than I was able ever to learn before.  Thank you.

  > This is not what a chapter about using a word processor should look
  > like.  It should begin with an introduction to word-processing with
  > Org, an overview of what's possible and what isn't; it should go on to
  > explaining how to start a document, how to write a heading and a
  > sub-heading, how to insert references, links, footnotes, and other
  > objects; it should then explain how to produce a TOC and an index, and
  > finally point me to another chapter that explains how to export my
  > document in a variety of formats.

That plan for a manual for the word-processing feature makes sense.

It appears that what people call "Org mode" is a collection of diverse
features, and what they have in common is use of a certain format of
the text.  Is that right?

I have to question the practice of treating these diverse features
conceptually as a single mode.  Although I still don't know what those
features are, if one of them is a word processor and the others are not,
they are too different to make sense conceptually that way.

It would make more sense to call them various different modes.  That
they all use a certain way of formatting the text may not be important
to mention.  If it is useful to have a name for that, I suggest the
name "Org format".  Each of these modes could say it uses "Org
format", or perhaps a variation of that.

  > > As a consequence, it probably makes little sense to separate such
  > > "facilities"---the term would need to be properly defined in the current
  > > context, tho---, because each of them implies full support for the whole
  > > Org syntax.

Maybe that is how things are now, but is there a reason why things
SHOULD be done this way?  Does each of these features need to support
"the whole Org syntax"?

It could be that the simple way of implementing them is by sharing code
that implements "the whole Org syntax".  If so, I won't argue against
sharing that code.  But it may not be useful to TALK about the fact
that each one implements "the whole Org syntax".  And it is possilble
that it is better to share only part of that code, not all.

In other words, if we don't let the concept of "Org mode" shape our thinking,
we might thing of these features differently.

  > I hope I explained at least what is my view of how Org should evolve
  > (in addition to the routine development that adds new features) -- it
  > should try to present a less monolith-like appearance towards new
  > users, and allow them to master just a part of its capabilities, the
  > part that they are interested in.

Hear, hear!

  > HTH and TIA

Hold Turnip Head and Turn It Around?  ;-}


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Joost Kremers]

On Thu, Apr 23 2020, Richard Stallman wrote:
> It appears that what people call "Org mode" is a collection of 
> diverse
> features, and what they have in common is use of a certain 
> format of
> the text.  Is that right?

That sounds just about right, yes.

> I have to question the practice of treating these diverse 
> features
> conceptually as a single mode.  Although I still don't know what 
> those
> features are, if one of them is a word processor and the others 
> are not,
> they are too different to make sense conceptually that way.

The practice has probably arisen historically, but IMHO it still 
makes sense to do so now, because probably Org's biggest strength 
is that the various features are tightly integrated. That doesn't 
mean you couldn't use Org for just one of its features, you 
definitely could, but the beauty of the system is that the 
different features aren't strictly separated.

For example, Org can be used as an agenda, to keep track of your 
appointments, daily schedule, etc., much like Google Calendar and 
other such offerings. At the same time, you can use Org to write 
your papers.

Now, you would normally keep your appointments in one file, say 
=agenda.org=, and the paper you're working on in another file, say 
=paper.org=. So far, so uninteresting. But with Org you can put 
TODO notes in =paper.org=, add deadlines, date and time stamps, 
etc., anything Org supports. Then, when you display your agenda 
(i.e., run a function that takes the contents of, in this example, 
=agenda.org=, and creates a nice overview of it in an agenda-like 
fashion), you can have the TODO items, deadlines etc. from 
=paper.org= included in this overview automatically. Try that with 
Google Calendar.

This is just one example, but it illustrates the whole point of 
Org: the system has many different features, and they all work 
together.

> It would make more sense to call them various different modes. 
> That
> they all use a certain way of formatting the text may not be 
> important
> to mention.

Actually, it's crucial to mention that. You might say it's Org's 
raison d'être. It's what makes integrating all of Org's functions 
so tightly possible.

> In other words, if we don't let the concept of "Org mode" shape 
> our thinking,
> we might thing of these features differently.

I think it would certainly help newbies getting started with Org 
to document its features separately. Eli's suggestions for 
restructuring the Org manual sound very good. I had a difficult 
time getting started with Org myself, and I can relate very well 
to the impressions that you and Eli describe.

But at the same time it should be made clear from the outset that 
Org's strength lies in its integration. I mean, I could use 
Markdown with Pandoc to write my papers, *cough* Google Calendar 
*cough* to keep track of my appointments, Jupyter for keeping 
programming notebooks and *cough* Evernote *cough* to keep notes, 
but there would be no way to link all of that. With Org, there is.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Thu, 23 Apr 2020 10:41:05 +0200
> 
> > It would make more sense to call them various different modes.
> > That they all use a certain way of formatting the text may not be
> > important to mention.
> 
> Actually, it's crucial to mention that. You might say it's Org's 
> raison d'être. It's what makes integrating all of Org's functions 
> so tightly possible.

If features are well integrated and work together well, how is it
important to know that they do it because of a certain way of
formatting text?

> But at the same time it should be made clear from the outset that 
> Org's strength lies in its integration. I mean, I could use 
> Markdown with Pandoc to write my papers, *cough* Google Calendar 
> *cough* to keep track of my appointments, Jupyter for keeping 
> programming notebooks and *cough* Evernote *cough* to keep notes, 
> but there would be no way to link all of that. With Org, there is.

You are actually describe the strength of Emacs as an integrated
package whose parts work well with one another.  And yet we have
separate manuals for major parts: Gnus, Org, Eshell, etc. -- just look
inside doc/misc/.

IOW, I don't see a contradiction here.

Re: "Why is emacs so square?"

[Joost Kremers]

On Thu, Apr 23 2020, Eli Zaretskii wrote:
>> Actually, it's crucial to mention that. You might say it's 
>> Org's 
>> raison d'être. It's what makes integrating all of Org's 
>> functions 
>> so tightly possible.
>
> If features are well integrated and work together well, how is 
> it
> important to know that they do it because of a certain way of
> formatting text?

Because the user has to format that text. :-) Sure, there are 
helper functions for a lot of things, but as a user you do need to 
know the Org format.

>> But at the same time it should be made clear from the outset 
>> that 
>> Org's strength lies in its integration. I mean, I could use 
>> Markdown with Pandoc to write my papers, *cough* Google 
>> Calendar 
>> *cough* to keep track of my appointments, Jupyter for keeping 
>> programming notebooks and *cough* Evernote *cough* to keep 
>> notes, 
>> but there would be no way to link all of that. With Org, there 
>> is.
>
> You are actually describe the strength of Emacs as an integrated
> package whose parts work well with one another.  And yet we have
> separate manuals for major parts: Gnus, Org, Eshell, etc. -- 
> just look
> inside doc/misc/.

Yes, but it's a different level of integration. I need a decent 
working knowledge of Elisp to be able to integrate Gnus and 
Eshell. But I only need to know Org syntax in order to integrate 
my TODO list, task management and writing with my calendar. The 
point is, I need to know Org syntax anyway to do each single thing 
separately. Integrating them doesn't require a deeper level of 
knowledge than I already have.

> IOW, I don't see a contradiction here.

I'm not saying there's a contradiction. If that's how I came 
across, then I didn't make my point very well. Like I said, I 
think the Org documentation would benefit greatly if your 
suggestions were implemented. It's just that the fact that Org's 
different parts are tightly integrated should not be tucked away 
in some "Advanced Use" section of the manual.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Fri, 24 Apr 2020 08:36:49 +0200
> 
> > You are actually describe the strength of Emacs as an integrated
> > package whose parts work well with one another.  And yet we have
> > separate manuals for major parts: Gnus, Org, Eshell, etc. -- 
> > just look
> > inside doc/misc/.
> 
> Yes, but it's a different level of integration. I need a decent 
> working knowledge of Elisp to be able to integrate Gnus and 
> Eshell. But I only need to know Org syntax in order to integrate 
> my TODO list, task management and writing with my calendar. The 
> point is, I need to know Org syntax anyway to do each single thing 
> separately. Integrating them doesn't require a deeper level of 
> knowledge than I already have.

Unless I misunderstand what you mean by "Org syntax", I don't think
users who want to create documents with Org should be required to know
that syntax.  Instead, there should be commands to help them produce
correctly formatted snippets.  Compare that with Texinfo commands
which produce the various syntactic elements of the language.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Unless I misunderstand what you mean by "Org syntax", I don't think
> users who want to create documents with Org should be required to know
> that syntax.  Instead, there should be commands to help them produce
> correctly formatted snippets.

I'm not sure what you mean here.  AFAICT, there are already several
such commands.

- To insert a new headline, type 'M-RET'.
- To insert a source block, type '< s TAB'.
- To insert org export headers, type ''C-c C-e #'.
- To schedule a headline for later, type 'C-c C-s'.
- To insert a link, type 'C-c C-l'.
- etc.

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 24 Apr 2020 12:28:01 +0200
> Cc: Joost Kremers <joostkremers@fastmail.fm>, Emacs developers <emacs-devel@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Unless I misunderstand what you mean by "Org syntax", I don't think
> > users who want to create documents with Org should be required to know
> > that syntax.  Instead, there should be commands to help them produce
> > correctly formatted snippets.
> 
> I'm not sure what you mean here.  AFAICT, there are already several
> such commands.
> 
> - To insert a new headline, type 'M-RET'.
> - To insert a source block, type '< s TAB'.
> - To insert org export headers, type ''C-c C-e #'.
> - To schedule a headline for later, type 'C-c C-s'.
> - To insert a link, type 'C-c C-l'.
> - etc.

Then it seems like I was right: there's no need for users who want to
produce documents with Org to be proficient in the Org syntax.  Right?

Re: "Why is emacs so square?"

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Then it seems like I was right: there's no need for users who want to
> produce documents with Org to be proficient in the Org syntax.  Right?

Yes it's probably sufficient to know the commands and let the text flow
the way it likes.

(I.e. pretty much the way AUCTeX works. I know people back in the 80-ies
and 90-ies who needed to write LaTeX and became emacs users solely
becaause of AUCTeX)

(in both cases, understanding the syntax helps both in understanding
what goes on, and in navigating)

Re: "Why is emacs so square?"

[Joost Kremers]

On Fri, Apr 24 2020, Eli Zaretskii wrote:
> Unless I misunderstand what you mean by "Org syntax", I don't 
> think
> users who want to create documents with Org should be required 
> to know
> that syntax.  Instead, there should be commands to help them 
> produce
> correctly formatted snippets.  Compare that with Texinfo 
> commands
> which produce the various syntactic elements of the language.

Yes, there are usually helper functions to do just that, though 
for some things, it's easier to just type the markup directly. 
(`*bold*` is IMHO quicker than `C-c C-x C-f * bold C-f`.) But once 
I know how to create a heading in a text document I can use the 
same command to create a heading in a notes file or an agenda 
file.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Fri, 24 Apr 2020 12:36:43 +0200
> 
> 
> On Fri, Apr 24 2020, Eli Zaretskii wrote:
> > Unless I misunderstand what you mean by "Org syntax", I don't 
> > think
> > users who want to create documents with Org should be required 
> > to know
> > that syntax.  Instead, there should be commands to help them 
> > produce
> > correctly formatted snippets.  Compare that with Texinfo 
> > commands
> > which produce the various syntactic elements of the language.
> 
> Yes, there are usually helper functions to do just that, though for
> some things, it's easier to just type the markup directly.
> (`*bold*` is IMHO quicker than `C-c C-x C-f * bold C-f`.) But once I
> know how to create a heading in a text document I can use the same
> command to create a heading in a notes file or an agenda file.

Command efficiency aside, if such commands exists, then why would the
user need to know the Org syntax which they produce?

Re: "Why is emacs so square?"

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Date: Fri, 24 Apr 2020 08:36:49 +0200
[…]
>> The 
>> point is, I need to know Org syntax anyway to do each single thing 
>> separately. Integrating them doesn't require a deeper level of 
>> knowledge than I already have.
>
> Unless I misunderstand what you mean by "Org syntax", I don't think
> users who want to create documents with Org should be required to know
> that syntax.  Instead, there should be commands to help them produce
> correctly formatted snippets.  Compare that with Texinfo commands
> which produce the various syntactic elements of the language.

I would like to not have to bother with Org syntax at all, but after
using the commands that produce it I see that syntax.  It can be very
confusing to see an unfamiliar syntax after issuing a command — what
parts of it may I edit?  When I accidentally remove parts of it, how can
I restore the full syntax?

Two things would help here, in my opinion:

* hide the textual representation.

  My Org mode configuration replaces “*”, “**”, “***”, “****” with
  “bullets” like "◉", "○", "◇", and "◇".  I can produce them either by
  tying “*” (if I know that syntax) or by using M-RET and S-right.  Org
  mode hides the syntax for URLs when [[…][…]] is used and displays just
  an underlined and clickable URL.

  For source code blocks I replace “#+begin_src” and “#+end_src” with
  markers like ✎ and □ and set the block visually apart by customizing
  the faces. (See https://pank.eu/blog/pretty-babel-src-blocks.html)

* delete the whole construct instead of deleting characters.  Currently,
  it is easy to end up with invalid syntax by deleting parts of the
  markup text.  Deleting the trailing “c” of “#+end_src” at the end of a
  source code block, for example, breaks that code block but leaves the
  “#+begin_src” and now incomplete “#+end_sr” where they are.  I need to
  know that I have to append a “c” at the end to restore the code
  block.  There is no command I can run to “repair” this code block.
  Maybe it would be good to remove the whole textual markup at once,
  leaving only the user-provided text that was marked up.

By making it impossible or very unlikely to produce incorrect markup and
by hiding the markup syntax itself the user wouldn’t have to learn it
and also wouldn’t be exposed to it accidentally.

At that point the syntax itself becomes secondary; this would then be
similar to how enriched-mode works.

-- 
Ricardo

Re: "Why is emacs so square?"

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Joost Kremers <joostkremers@fastmail.fm>
>>> Date: Fri, 24 Apr 2020 08:36:49 +0200
> […]
>>> The 
>>> point is, I need to know Org syntax anyway to do each single thing 
>>> separately. Integrating them doesn't require a deeper level of 
>>> knowledge than I already have.
>>
>> Unless I misunderstand what you mean by "Org syntax", I don't think
>> users who want to create documents with Org should be required to know
>> that syntax.  Instead, there should be commands to help them produce
>> correctly formatted snippets.  Compare that with Texinfo commands
>> which produce the various syntactic elements of the language.
>
> I would like to not have to bother with Org syntax at all, but after
> using the commands that produce it I see that syntax.  It can be very
> confusing to see an unfamiliar syntax after issuing a command — what
> parts of it may I edit?  When I accidentally remove parts of it, how can
> I restore the full syntax?
>
> Two things would help here, in my opinion:
>
> * hide the textual representation.
>
>   My Org mode configuration replaces “*”, “**”, “***”, “****” with
>   “bullets” like "◉", "○", "◇", and "◇".  I can produce them either by
>   tying “*” (if I know that syntax) or by using M-RET and S-right.  Org
>   mode hides the syntax for URLs when [[…][…]] is used and displays just
>   an underlined and clickable URL.
>
>   For source code blocks I replace “#+begin_src” and “#+end_src” with
>   markers like ✎ and □ and set the block visually apart by customizing
>   the faces. (See https://pank.eu/blog/pretty-babel-src-blocks.html)
>
> * delete the whole construct instead of deleting characters.  Currently,
>   it is easy to end up with invalid syntax by deleting parts of the
>   markup text.  Deleting the trailing “c” of “#+end_src” at the end of a
>   source code block, for example, breaks that code block but leaves the
>   “#+begin_src” and now incomplete “#+end_sr” where they are.  I need to
>   know that I have to append a “c” at the end to restore the code
>   block.  There is no command I can run to “repair” this code block.
>   Maybe it would be good to remove the whole textual markup at once,
>   leaving only the user-provided text that was marked up.
>
> By making it impossible or very unlikely to produce incorrect markup and
> by hiding the markup syntax itself the user wouldn’t have to learn it
> and also wouldn’t be exposed to it accidentally.
>
> At that point the syntax itself becomes secondary; this would then be
> similar to how enriched-mode works.

When I accidentally delete a part of markup, usually '[' or ']' in a
link, it is immidiately reflected visually in the buffer so I just undo
to "restore". For me it is just C-S--.

But I do agree it would be usefull to make some markup "atomic", like
for example "#+BEGIN_SRC", "#+END_SRC". But for some other markup it
might be difficult. For example leading '*': sometimes it might be a
misstake, but sometimes it might be intentionally, for example to change
hte heading from say *** to **. 

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Org's biggest strength 
  > is that the various features are tightly integrated.

You may see that as an advantage, but I consider it a drawback.  The
"tight integration" of these different features is an obstacle to
learning to use one of them, or even finding out about one of them.

*We need to make them separate.*

Separate and integrated are not opposites.
It is possible for several features to be integrated,
in the sense that they work together _when you want that_,
and also separate, in the sense that we describe each one separately
and you can learn about one without paying the slightest attention
to the others.

							 That doesn't 
  > mean you couldn't use Org for just one of its features, you 
  > definitely could, but the beauty of the system is that the 
  > different features aren't strictly separated.

I would say that is the complexity and obscurity of the system.

I think we can make them clearly separate, for purposes
of documenting them, without reducing the ability to integrate them
for users who use more than one.

  > =paper.org=. So far, so uninteresting. But with Org you can put 
  > TODO notes in =paper.org=, add deadlines, date and time stamps, 
  > etc., anything Org supports. Then, when you display your agenda 
  > (i.e., run a function that takes the contents of, in this example, 
  > =agenda.org=, and creates a nice overview of it in an agenda-like 
  > fashion), you can have the TODO items, deadlines etc. from 

I can see that that integration is useful -- but _the fact that it
applies only to "parts of Org mode"_ makes it also a a limitation.
It is a drawback that _only_ the modes that are "part of Org mode" can
integrate with these features -- and the rest of Emacs cannot do so.

Instead of dividing Emacs facilities and modes into the "Org
first-class modes" and the "Org second-class modes", we should make
all modes equally able to integrate in these ways.

  > > It would make more sense to call them various different modes. 
  > > That
  > > they all use a certain way of formatting the text may not be 
  > > important
  > > to mention.

  > Actually, it's crucial to mention that.

People who want to use a specific one of these facilities don't need
to know that.  It is useful for those users who want to use more
than one of these facilities together -- but that should be
an advanced topic.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Joost Kremers]

On Fri, Apr 24 2020, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider 
> ]]]
> [[[ whether defending the US Constitution against all enemies, 
> ]]]
> [[[ foreign or domestic, requires you to follow Snowden's 
> example. ]]]
>
>   > Org's biggest strength 
>   > is that the various features are tightly integrated.
>
> You may see that as an advantage, but I consider it a drawback. 
> The
> "tight integration" of these different features is an obstacle 
> to
> learning to use one of them, or even finding out about one of 
> them.

No, it really isn't. It's just the way the current documentation 
is set up that makes this difficult. (I know, I agree, I've been 
there.)

> Separate and integrated are not opposites.
> It is possible for several features to be integrated,
> in the sense that they work together _when you want that_,
> and also separate, in the sense that we describe each one 
> separately
> and you can learn about one without paying the slightest 
> attention
> to the others.

Again, that's all about documentation.

> I can see that that integration is useful -- but _the fact that 
> it
> applies only to "parts of Org mode"_ makes it also a a 
> limitation.
> It is a drawback that _only_ the modes that are "part of Org 
> mode" can
> integrate with these features -- and the rest of Emacs cannot do 
> so.
> 
> Instead of dividing Emacs facilities and modes into the "Org
> first-class modes" and the "Org second-class modes", we should 
> make
> all modes equally able to integrate in these ways.

That sounds good in theory, but I'm really not sure what that 
would mean in practice. (I'm not entirely sure that you do either. 
;-) The reason Org's facilities can be so tightly integrated is 
because they all use the same Org syntax. Org files are just plain 
text files with a well-defined markup, after all.

As for integrating with the rest of Emacs, any part of Emacs is 
free to make use of this syntax as well, Org in fact provides 
libraries to make this easier. For example, I maintain a package 
for managing .bib files. It integrates with Org in that the user 
can add notes to bib entries, which are kept in Org files, and the 
user can maintain a reading list, also as an Org file, which then 
integrates with the user's TODO list and calendar, if s/he so 
wishes. I started this package long before I ever heard of Org 
mode, but it was easy to add this functionality once I realised it 
would be useful to do so.

So I believe the kind of integration you talk about is already 
possible, you just need to write the Elisp code to do it. In that 
way it doesn't differ from all the other facilities that Emacs 
provides: if I want to integrate Gnus and Eshell (whatever that 
would mean), I need to write Elisp code.

This of course contrasts with the integration of the various 
facilities that Org provides, because that only requires knowledge 
of Org's syntax. But I believe that's OK and fully expected: the 
things Org can do are closely related and many people *need* them 
to integrate well with each other. So integrating them should be 
easy.

On the other hand, what Gnus does has little to do with what 
Eshell does and scenarios where it would be useful to integrate 
them are probably rare. So it's OK that that's not so easy to do, 
as long as it's not impossible.

> > > It would make more sense to call them various different 
> > > modes. That they all use a certain way of formatting the 
> > > text may not be important to mention.
>
>   > Actually, it's crucial to mention that.
>
> People who want to use a specific one of these facilities don't 
> need
> to know that.

Sure, but I don't think it's a big cognitive burden for them to 
know that. Pointing out this fact in a couple of crucial places 
wouldn't take more than a sentence or two, with a reference to a 
section where it's all explained in more detail.

>  It is useful for those users who want to use more
> than one of these facilities together -- but that should be
> an advanced topic.

No, it shouldn't be billed as an advanced topic, for two reasons. 
First, it really isn't advanced at all: like I said, you really 
only need to know Org syntax in order to integrate these 
facilities, and you need to know Org syntax anyway to be able to 
use just one facility. Second, the tight integration is one of the 
reasons people are attracted to Org mode in the first place, so 
it's likely something people will look for in a manual early on.

Anyway, I think this subthread is slowly getting out of hand. :-) 
I don't believe our positions are as far apart as the discussion 
might suggest. I do agree with you and Eli that it would be very 
helpful if the Org manual were structured along the lines Eli 
suggested. I envisage an introductory section that clearly states 
the different use cases of Org and directs the reader to separate 
sections for each of them, which should all be written from the 
point of view of a new user, i.e., they shouldn't assume 
familiarity with any of the other use cases. At the same time, the 
introduction should mention Org's integrative nature and point the 
reader to relevant section(s), without labelling these as 
"advanced".

Whether and to what extent the Org code base should be modified, 
I'm not qualified to say, but given the limited resources, it 
isn't likely to happen anyway. Improving the documentation would 
be a much better investment of time.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 23 Apr 2020 22:37:48 -0400
> Cc: emacs-devel@gnu.org
> 
> Separate and integrated are not opposites.
> It is possible for several features to be integrated,
> in the sense that they work together _when you want that_,
> and also separate, in the sense that we describe each one separately
> and you can learn about one without paying the slightest attention
> to the others.

I think it's more correct to say that Org features are well
integrated, not that they are tightly-coupled in the sense that they
cannot work separately.  I did (and do) successfully use a couple of
Org features although I know and need very little of the rest.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 12:59:06 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Richard Stallman <rms@gnu.org>
    >> Date: Thu, 23 Apr 2020 22:37:48 -0400
    >> Cc: emacs-devel@gnu.org
    >> 
    >> Separate and integrated are not opposites.
    >> It is possible for several features to be integrated,
    >> in the sense that they work together _when you want that_,
    >> and also separate, in the sense that we describe each one separately
    >> and you can learn about one without paying the slightest attention
    >> to the others.

    Eli> I think it's more correct to say that Org features are well
    Eli> integrated, not that they are tightly-coupled in the sense that they
    Eli> cannot work separately.  I did (and do) successfully use a couple of
    Eli> Org features although I know and need very little of the rest.

And that 'little' extends to the Org syntax: there is no need to know
all of it, or even a large part of it, since basic use just requires
something like:

    * Heading level one
      Text

    ** Heading level two
      Text

    * Another heading level one

    ** TODO do some stuff

Itʼs only when you start wanting to change org's default behaviour, or
generate a custom agenda, or schedule TODO items, or track task time
usage etc, that you need to learn more.

Robert

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it's more correct to say that Org features are well
  > integrated, not that they are tightly-coupled in the sense that they
  > cannot work separately.  I did (and do) successfully use a couple of
  > Org features although I know and need very little of the rest.

That is good news.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: mail@nicolasgoaziou.fr, joostkremers@fastmail.fm,
> 	emacs-devel@gnu.org
> Date: Wed, 22 Apr 2020 22:36:55 -0400
> 
> It appears that what people call "Org mode" is a collection of diverse
> features, and what they have in common is use of a certain format of
> the text.  Is that right?

More or less, AFAIK.  The common features are more than just the
format, but the format is AFAIU the most important one.

>   > > As a consequence, it probably makes little sense to separate such
>   > > "facilities"---the term would need to be properly defined in the current
>   > > context, tho---, because each of them implies full support for the whole
>   > > Org syntax.
> 
> Maybe that is how things are now, but is there a reason why things
> SHOULD be done this way?  Does each of these features need to support
> "the whole Org syntax"?
> 
> It could be that the simple way of implementing them is by sharing code
> that implements "the whole Org syntax".  If so, I won't argue against
> sharing that code.  But it may not be useful to TALK about the fact
> that each one implements "the whole Org syntax".  And it is possilble
> that it is better to share only part of that code, not all.
> 
> In other words, if we don't let the concept of "Org mode" shape our thinking,
> we might thing of these features differently.

It may be too late to actually separate the various features,
especially since there doesn't seem to be anyone who'd want to do this
(very complex) job.  I think it would be a very useful step if the
documentations and the general classes of the Org features would
present to the users several disparate sets of capabilities, and would
allow users to learn and use only the set(s) they need.

>   > HTH and TIA
> 
> Hold Turnip Head and Turn It Around?  ;-}

Of course, what else?

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It may be too late to actually separate the various features,

Are you assuming that this means a lot of change in the code?
I have no idea whether it does.  Maybe most of the change needed
is in documentation, and a few little details to go with
the change in documentation.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: joostkremers@fastmail.fm, mail@nicolasgoaziou.fr,
> 	emacs-devel@gnu.org
> Date: Thu, 23 Apr 2020 22:43:05 -0400
> 
>   > It may be too late to actually separate the various features,
> 
> Are you assuming that this means a lot of change in the code?

Yes, I think so.

> I have no idea whether it does.  Maybe most of the change needed
> is in documentation, and a few little details to go with
> the change in documentation.

I think we should try changing the documentation first, as that is a
Good Thing anyway.  When that is done, we could consider whether any
code changes are needed.  (I actually expect that to become evident
while the documentation is re-written in the directions I proposed:
whoever will do that job will discover that, for example, to be able
to produce a stand-alone document with Org, one would need features
that currently belong to some unrelated Org part -- which would mean
some code needs to be added or modified to make that feature
seamlessly available to document-writers.)

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 13:03:52 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> I have no idea whether it does.  Maybe most of the change needed
    >> is in documentation, and a few little details to go with
    >> the change in documentation.

    Eli> I think we should try changing the documentation first, as that is a
    Eli> Good Thing anyway.  When that is done, we could consider whether any
    Eli> code changes are needed.  (I actually expect that to become evident
    Eli> while the documentation is re-written in the directions I proposed:
    Eli> whoever will do that job will discover that, for example, to be able
    Eli> to produce a stand-alone document with Org, one would need features
    Eli> that currently belong to some unrelated Org part -- which would mean
    Eli> some code needs to be added or modified to make that feature
    Eli> seamlessly available to document-writers.)

That depends on what you mean by 'stand-alone'. The built-in Org mode
from 'emacs -Q' can export to at least html, latex, pdf and odt by
default, of which only latex and pdf require the installation of extra
external tools.

Thereʼs a texinfo backend as well that youʼd need to enable, which may
well require external tool support (Iʼve never used it).

Robert

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: rms@gnu.org,  joostkremers@fastmail.fm,  mail@nicolasgoaziou.fr,
>   emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 13:34:13 +0200
> 
>     Eli> I think we should try changing the documentation first, as that is a
>     Eli> Good Thing anyway.  When that is done, we could consider whether any
>     Eli> code changes are needed.  (I actually expect that to become evident
>     Eli> while the documentation is re-written in the directions I proposed:
>     Eli> whoever will do that job will discover that, for example, to be able
>     Eli> to produce a stand-alone document with Org, one would need features
>     Eli> that currently belong to some unrelated Org part -- which would mean
>     Eli> some code needs to be added or modified to make that feature
>     Eli> seamlessly available to document-writers.)
> 
> That depends on what you mean by 'stand-alone'. The built-in Org mode
> from 'emacs -Q' can export to at least html, latex, pdf and odt by
> default, of which only latex and pdf require the installation of extra
> external tools.

That's orthogonal.  By "stand-alone" I meant a document that doesn't
require support from any additional Org features, like TODO notes,
calendar appointments, etc.  Just a document that includes structured
text.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 15:09:26 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: rms@gnu.org,  joostkremers@fastmail.fm,  mail@nicolasgoaziou.fr,
    >> emacs-devel@gnu.org
    >> Date: Fri, 24 Apr 2020 13:34:13 +0200
    >> 
    Eli> I think we should try changing the documentation first, as that is a
    Eli> Good Thing anyway.  When that is done, we could consider whether any
    Eli> code changes are needed.  (I actually expect that to become evident
    Eli> while the documentation is re-written in the directions I proposed:
    Eli> whoever will do that job will discover that, for example, to be able
    Eli> to produce a stand-alone document with Org, one would need features
    Eli> that currently belong to some unrelated Org part -- which would mean
    Eli> some code needs to be added or modified to make that feature
    Eli> seamlessly available to document-writers.)
    >> 
    >> That depends on what you mean by 'stand-alone'. The built-in Org mode
    >> from 'emacs -Q' can export to at least html, latex, pdf and odt by
    >> default, of which only latex and pdf require the installation of extra
    >> external tools.

    Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
    Eli> require support from any additional Org features, like TODO notes,
    Eli> calendar appointments, etc.  Just a document that includes structured
    Eli> text.

None of those additional features are *required* for a document. All
you need to produce a document is org-markup, like

    This is some *bold* text, this is some /italic/ text, and this should
    be =monospace=

You donʼt even have to use headings if you donʼt want to. Or
footnotes. Or links. Or inline latex. But you *can* if you want
to.

Robert

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 24 Apr 2020 14:23:16 +0200
> Cc: joostkremers@fastmail.fm, rms@gnu.org, mail@nicolasgoaziou.fr,
>  emacs-devel@gnu.org
> 
>     Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
>     Eli> require support from any additional Org features, like TODO notes,
>     Eli> calendar appointments, etc.  Just a document that includes structured
>     Eli> text.
> 
> None of those additional features are *required* for a document.

I'm not surprised.  But it could be that some minor feature will still
need something.  Like adding footnotes and links, perhaps?  It's all
should become clear once composing documents with Org is documented.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 15:32:26 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 24 Apr 2020 14:23:16 +0200
    >> Cc: joostkremers@fastmail.fm, rms@gnu.org, mail@nicolasgoaziou.fr,
    >> emacs-devel@gnu.org
    >> 
    Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
    Eli> require support from any additional Org features, like TODO notes,
    Eli> calendar appointments, etc.  Just a document that includes structured
    Eli> text.
    >> 
    >> None of those additional features are *required* for a document.

    Eli> I'm not surprised.  But it could be that some minor feature will still
    Eli> need something.  Like adding footnotes and links, perhaps?  It's all
    Eli> should become clear once composing documents with Org is documented.

Itʼs all text, so you can add those manually if desired. But org by
default has keybindings for both of them :-)

Robert

Re: "Why is emacs so square?"

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Etc., etc.  I invite you to put yourself in the shows of a newcomer to
> Org, and try to imagine how such a newcomer will be able to realize
> that Org can be used as a word-processor...
>
> So please don't be surprised that Richard thinks about this what he
> thinks.

+1.  I used Emacs for a long time, but I didn't adopt Org until a long
time after its release (2013, 14 or so) or so, and even then the manual
was showing its age.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Editing error: I sent

  > I found it impossible to learn what Org mode does.  Its introduction
  > taught how to do outline editing.  It made sense, but outline editing
  > useful for me, so I stopped reading.  I did not want to study use of a
  > mode for outline editing.

but I meant to send:

  > I found it impossible to learn what Org mode does.  Its introduction
  > taught how to do outline editing.  It made sense, but outline editing -
  > is not useful for me, so I stopped reading.  I did not want to study use of a
  > mode for outline editing.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> What I had in mind, regarding variable-pitch text, was word processing.

I was referring to how such features would allow people to potentially
create nicer (well, mostly) graphical interfaces inside Emacs, which
would in turn make Emacs appeal more in the minds of those who judge a
book by its cover.

Word processing in Emacs would also be nice.

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> ndame <ndame@protonmail.com> writes:
>
>> I agree that Emacs is easier to program once you learned it, but
>> other editors, like VSCode, has the advantage that you don't have to
>> learn a quirky and unfamiliar language first.
>
>> Many developers know Javascript and even if one doesn't it's more similar
>> to mainstream languages than lisp, so extension writers mostly has to
>> learn the VSCode API only.
>
> Here's the problem: You have to learn the VS Code API. I'd say learning
> that, and becoming reasonably proficient at it takes longer than
> skimming through the Emacs Lisp intro.

Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
programming Emacs packages though. For one to understand how Emacs works
(with it’s obscure naming scheme like windows), one has to jump a lot of
hoops, and I can guarantee that one who is familiar with Algol-family
languages can pick up the VSCode API much faster than picking up Lisp,
Emacs, and the Emacs API.

>> VScode has a very nice out of the box experience. If you want support
>> for a language then it's one click to install it and it installs the
>> necessary scaffolding too, like a language server for the language.
>
> We have several starter packs, with similarly nice OOTB experiences.

But the default Emacs doesn’t have that, and that’s the problem.
Which means that, for one to have nice OOTB experiences, one has to have
a really good reason to use Emacs (like learning Common Lisp), then google
how to configure Emacs, then encounter Spacemacs without knowing anything
about evil or helm or ivy. And proficient Emacs users usually recommend
not using a starter kit in the internet. (That’s my experience on trying
to use Emacs.)

>> And it has Electron for display support which has a mature browser
>> engine behind it, so it can support advanced graphics features out
>> of the box on all the supported platforms.
>
> Electron is not free software (https://labs.parabola.nu/issues/1167),
> and is definitely not as well suited to providing an integrated
> experience like Emacs.

I don’t think OP was saying that we should use Electron for Emacs, but more
that due to using Electron, it gives the stability that Emacs doesn’t give.
Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs glitches,
locks, and crashes very frequently, and that’s a non-starter for a lot of  
people.

> For instance, even if you render raw HTML inside VS Code, you would not
> be able to grab the region using VSC APIs.  I'm not sure if the VSC API
> allows interacting with the DOM, but from what I can tell, it can't.
>
> There are also various other issues, with relying on a lower-level
> abstraction for "nice graphics features" (the DOM) that is outside the
> editors control.
>
>> Out of the box experience matters. Familiarity matters (e.g supporting
>> standard keys on the platfrom for cut and paste). Nice appearance matters.
>
> We have Cua mode.  No, you don't need to have it enabled by default,
> since it would result in unnecessary breakage for old users.  It would
> be nice if the startup screen informed users of features such as the
> (hypothetical) GTK theme previously mentioned, and Cua.
>
> I personally think that the Emacs bindings are better, and in the end
> work better with Emacs itself, but I do agree that newcomers should be
> allowed to familiarize themselves with Emacs before moving their
> workflow (and habits) to it entirely.
>
>> No wonder lot of developers choose VScode:
>> https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code
>
> We're here to change that :)

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
> programming Emacs packages though. For one to understand how Emacs works
> (with it’s obscure naming scheme like windows), one has to jump a lot of
> hoops, and I can guarantee that one who is familiar with Algol-family
> languages can pick up the VSCode API much faster than picking up Lisp,
> Emacs, and the Emacs API.

This is what gets interesting: Emacs Lisp is a language in it's own
right, and the "Emacs API" is the Emacs Lisp language.  Emacs Lisp is
also a rather small and simple language.

You don't have to pick up "Lisp", or the Emacs "API", you only
pick up Emacs Lisp.

> But the default Emacs doesn’t have that, and that’s the problem.
> Which means that, for one to have nice OOTB experiences, one has to have
> a really good reason to use Emacs (like learning Common Lisp), then google
> how to configure Emacs, then encounter Spacemacs without knowing anything
> about evil or helm or ivy. And proficient Emacs users usually recommend
> not using a starter kit in the internet. (That’s my experience on trying
> to use Emacs.)

We could put a link to them somewhere, but that's something for RMS to decide.

> I don’t think OP was saying that we should use Electron for Emacs, but more
> that due to using Electron, it gives the stability that Emacs doesn’t give.
> Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs glitches,
> locks, and crashes very frequently, and that’s a non-starter for a lot
> of people.

If it "glitches, crashes, locks", that's a bug, and instead of treating
it as a fact, report it.  Plus, I know a lot of people who use Emacs on
macOS, and I even had to use Emacs on Windows a long time back, and
Emacs has always been rather solid.  The starter packs are also supposed
to work well, and it might also be a problem with your own config.

OTOH, Lisp code shouldn't be able to make Emacs crash (unless you're
doing stuff like running invalid bytecode, or overflowing the GC stack),
and if it does, it's also a bug that should be fixed.

Re: "Why is emacs so square?"

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

When I said
> We could put a link to them somewhere, but that's something for RMS to
> decide

I meant
> We could put a link to them somewhere, but that's probably something
> for RMS to decide

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
>> programming Emacs packages though. For one to understand how Emacs works
>> (with it’s obscure naming scheme like windows), one has to jump a lot of
>> hoops, and I can guarantee that one who is familiar with Algol-family
>> languages can pick up the VSCode API much faster than picking up Lisp,
>> Emacs, and the Emacs API.
>
> This is what gets interesting: Emacs Lisp is a language in it's own
> right, and the "Emacs API" is the Emacs Lisp language.  Emacs Lisp is
> also a rather small and simple language.

Emacs Lisp as a language and the standard library (the Emacs API) is
different. For example, the fact that functions and variables have their
own namespaces is a part of the language, and the functions
self-insert-command or bury-buffer are parts of the API.

You can call them as a whole Emacs Lisp, but that doesn’t mean that
it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
language like C++, but for outsiders that have never used Lisp, it’s
hard to approach.

Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
reason for users to use Emacs Lisp, not backwards. And that means that
Emacs should have a great onboarding experience (which is currently not true)
with various packages for so many languages and productivity tools (which is
IMHO true considering all of the packages in GitHub).

> You don't have to pick up "Lisp", or the Emacs "API", you only
> pick up Emacs Lisp.
>
>> But the default Emacs doesn’t have that, and that’s the problem.
>> Which means that, for one to have nice OOTB experiences, one has to have
>> a really good reason to use Emacs (like learning Common Lisp), then google
>> how to configure Emacs, then encounter Spacemacs without knowing anything
>> about evil or helm or ivy. And proficient Emacs users usually recommend
>> not using a starter kit in the internet. (That’s my experience on trying
>> to use Emacs.)
>
> We could put a link to them somewhere, but that's probably something for
> RMS to decide.

Yes, it would be very useful if we can include some links to the starter  
kits.
Also, it would be great if Emacs can have a default init.el that gets  
generated
when there is no one, so that first time users don’t get a bad impression.

>> I don’t think OP was saying that we should use Electron for Emacs, but  
>> more
>> that due to using Electron, it gives the stability that Emacs doesn’t  
>> give.
>> Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs  
>> glitches,
>> locks, and crashes very frequently, and that’s a non-starter for a lot
>> of people.
>
> If it "glitches, crashes, locks", that's a bug, and instead of treating
> it as a fact, report it.

I know, I should report it, but I find that macOS/Windows is considered a
second-platform here, and I didn't want to take my time writing reports just
to get no feedback. I’ll try to report some today.

(TBF, I remember trying to report them, searching for duplicates, and I saw  
some
bug report on the exact same issue I was experiencing. I didn’t know how to
subscribe, so I just thought that it might get fixed.)

> Plus, I know a lot of people who use Emacs on
> macOS, and I even had to use Emacs on Windows a long time back, and
> Emacs has always been rather solid.  The starter packs are also supposed
> to work well, and it might also be a problem with your own config.
>
> OTOH, Lisp code shouldn't be able to make Emacs crash (unless you're
> doing stuff like running invalid bytecode, or overflowing the GC stack),
> and if it does, it's also a bug that should be fixed.

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:


> Emacs Lisp as a language and the standard library (the Emacs API) is
> different. For example, the fact that functions and variables have their
> own namespaces is a part of the language, and the functions
> self-insert-command or bury-buffer are parts of the API.

Do buffer-local variables count as part of the language, or part of the
API? What about text properties in strings? File-local variables?
Primitives like `record_unwind_protect_excursion`? Or how the bytecode
interpreter has a plethora of primitives that only make sense within
Emacs.

And I would consider `self-insert-command' part of Emacs Lisp the
language, since it is implemented as a subr in C code.

> You can call them as a whole Emacs Lisp, but that doesn’t mean that
> it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
> language like C++, but for outsiders that have never used Lisp, it’s
> hard to approach.

It's not hard to approach at all.  The easy trick is to treat it as an
editor macro language, instead of a Lisp dialect.
> Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
> reason for users to use Emacs Lisp, not backwards. And that means that
> Emacs should have a great onboarding experience (which is currently not true)
> with various packages for so many languages and productivity tools (which is
> IMHO true considering all of the packages in GitHub).

Emacs Lisp (more precisely, the first-class extensiblity) is one of the
main reasons to choose Emacs, and the onboarding experience is exactly
what we're talking about.

> I know, I should report it, but I find that macOS/Windows is considered a
> second-platform here, and I didn't want to take my time writing reports just
> to get no feedback. I’ll try to report some today.

macOS/Windows are considered second-class platforms, when it comes to
features: features not available on free operating systems will not be
available on non-free systems.  macOS/Windows are not second-class
platforms, when it comes to fixing bugs not present on free operating
systems.

> (TBF, I remember trying to report them, searching for duplicates, and
> I saw some
> bug report on the exact same issue I was experiencing. I didn’t know how to
> subscribe, so I just thought that it might get fixed.)

Hm, you can always M-x report-emacs-bug

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>
>> Emacs Lisp as a language and the standard library (the Emacs API) is
>> different. For example, the fact that functions and variables have their
>> own namespaces is a part of the language, and the functions
>> self-insert-command or bury-buffer are parts of the API.
>
> Do buffer-local variables count as part of the language, or part of the
> API? What about text properties in strings? File-local variables?
> Primitives like `record_unwind_protect_excursion`? Or how the bytecode
> interpreter has a plethora of primitives that only make sense within
> Emacs.
>
> And I would consider `self-insert-command' part of Emacs Lisp the
> language, since it is implemented as a subr in C code.

I was arguing that the surface area of Emacs is not smaller than VSCode,
which makes the exact classification unnecessary.

(FYI, I count buffer-local vars as a property of the runtime, text
properties are definitely an Emacs API, and `record_unwind_protect_excursion`
or other primitives, subrs like `self-insert-command` written in C are all
Emacs APIs. The language are things like if-expressions, macros, symbols,  
etc…)

>> You can call them as a whole Emacs Lisp, but that doesn’t mean that
>> it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
>> language like C++, but for outsiders that have never used Lisp, it’s
>> hard to approach.
>
> It's not hard to approach at all.  The easy trick is to treat it as an
> editor macro language, instead of a Lisp dialect.

I spread Emacs to my friends. Unless ones who already know Common Lisp,
almost everyone feels that Emacs Lisp is a big hoop.

>> Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
>> reason for users to use Emacs Lisp, not backwards. And that means that
>> Emacs should have a great onboarding experience (which is currently not  
>> true)
>> with various packages for so many languages and productivity tools  
>> (which is
>> IMHO true considering all of the packages in GitHub).
>
> Emacs Lisp (more precisely, the first-class extensiblity) is one of the
> main reasons to choose Emacs, and the onboarding experience is exactly
> what we're talking about.

First class extensibility is probably one of the big reason to use Emacs, but
that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding  
experience
is really about Emacs Lisp - users don’t try to add keybindings or custom
functions on the first day of use.

>> I know, I should report it, but I find that macOS/Windows is considered a
>> second-platform here, and I didn't want to take my time writing reports  
>> just
>> to get no feedback. I’ll try to report some today.
>
> macOS/Windows are considered second-class platforms, when it comes to
> features: features not available on free operating systems will not be
> available on non-free systems.  macOS/Windows are not second-class
> platforms, when it comes to fixing bugs not present on free operating
> systems.
>
>> (TBF, I remember trying to report them, searching for duplicates, and
>> I saw some
>> bug report on the exact same issue I was experiencing. I didn’t know how  
>> to
>> subscribe, so I just thought that it might get fixed.)
>
> Hm, you can always M-x report-emacs-bug

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> (FYI, I count buffer-local vars as a property of the runtime, text
> properties are definitely an Emacs API, and `record_unwind_protect_excursion`
> or other primitives, subrs like `self-insert-command` written in C are all
> Emacs APIs. The language are things like if-expressions, macros,
> symbols, etc…)

Here's the problem: primitives like buffer-local variables, text
properties, and record_unwind_protect_excursion, and self-insert-command
all depend on Emacs concepts such as "buffers", "windows", "frames" and
on and on.  All of these are implemented as language primitives (and in
many cases, 'properties of the runtime', et cetera).  The Lisp
interpreter itself intermingles with "editor" code in a highly haphazard
and ad-hoc way, with many "APIs" being implemented as core language
constructs.

My view is: if the language still makes sense when X construct is
removed, X construct is considered outside the language.  If it doesn't,
X is part of the language.

> I spread Emacs to my friends. Unless ones who already know Common Lisp,
> almost everyone feels that Emacs Lisp is a big hoop.

You're not spreading it right, then :)
The Eintr teaches Emacs Lisp to non-programmers very well.  It also
teaches them how to extend the editor, in a straight-forward and
easy-to-understand way.


> First class extensibility is probably one of the big reason to use Emacs, but
> that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding
> experience
> is really about Emacs Lisp - users don’t try to add keybindings or custom
> functions on the first day of use.

The reason Emacs extensiblity is so first-class is because functionality
for extending Emacs are implemented as primitives in the editor, and are
not "APIs" grafted on top of other languages, such as VS Code or
whatever.

Re: "Why is emacs so square?"

[ndame]

>
> You're not spreading it right, then :)
> The Eintr teaches Emacs Lisp to non-programmers very well. It also
> teaches them how to extend the editor, in a straight-forward and
> easy-to-understand way.

Are these materials available somewhere?

Re: "Why is emacs so square?"

[Po Lu]

ndame <ndame@protonmail.com> writes:

>>
>> You're not spreading it right, then :)
>> The Eintr teaches Emacs Lisp to non-programmers very well. It also
>> teaches them how to extend the editor, in a straight-forward and
>> easy-to-understand way.
>
> Are these materials available somewhere?

C-h i m Emacs Lisp Intro RET

Re: "Why is emacs so square?"

[ndame]

> >
> > Are these materials available somewhere?
>
> C-h i m Emacs Lisp Intro RET

Ah, I didn't get what Eintr refers to. I thought there were some new course
for laypeople to learn emacs.

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> (FYI, I count buffer-local vars as a property of the runtime, text
>> properties are definitely an Emacs API, and  
>> `record_unwind_protect_excursion`
>> or other primitives, subrs like `self-insert-command` written in C are all
>> Emacs APIs. The language are things like if-expressions, macros,
>> symbols, etc…)
>
> Here's the problem: primitives like buffer-local variables, text
> properties, and record_unwind_protect_excursion, and self-insert-command
> all depend on Emacs concepts such as "buffers", "windows", "frames" and
> on and on.  All of these are implemented as language primitives (and in
> many cases, 'properties of the runtime', et cetera).  The Lisp
> interpreter itself intermingles with "editor" code in a highly haphazard
> and ad-hoc way, with many "APIs" being implemented as core language
> constructs.
>
> My view is: if the language still makes sense when X construct is
> removed, X construct is considered outside the language.  If it doesn't,
> X is part of the language.

I personally think that various Emacs APIs regarding buffers, etc… is not
part of the language, but that’s just my opinion.

>> I spread Emacs to my friends. Unless ones who already know Common Lisp,
>> almost everyone feels that Emacs Lisp is a big hoop.
>
> You're not spreading it right, then :)
> The Eintr teaches Emacs Lisp to non-programmers very well.  It also
> teaches them how to extend the editor, in a straight-forward and
> easy-to-understand way.

No, people shouldn't need to learn a new language to use an editor.
In the ideal world, normal people should be able to use package.el and
custom.el to use Emacs without much fuss, and some people that is
interested in can develop packages.

It’s just that Emacs practically needs configuration to be usable - which
means that one must learn Emacs lisp.

Yes, Eintr teaches Emacs Lisp well, but that step should be optional.

>> First class extensibility is probably one of the big reason to use  
>> Emacs, but
>> that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding
>> experience
>> is really about Emacs Lisp - users don’t try to add keybindings or custom
>> functions on the first day of use.
>
> The reason Emacs extensiblity is so first-class is because functionality
> for extending Emacs are implemented as primitives in the editor, and are
> not "APIs" grafted on top of other languages, such as VS Code or
> whatever.

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I personally think that various Emacs APIs regarding buffers, etc… is not
> part of the language, but that’s just my opinion.

They're implemented inside the language runtime, have relavant
primitives inside the bytecode engine, et cetera.  They're also the
primary (I wouldn't go as far as to say only, but it's close) IO
mechanism available in Emacs Lisp.

> No, people shouldn't need to learn a new language to use an editor.
> In the ideal world, normal people should be able to use package.el and
> custom.el to use Emacs without much fuss, and some people that is
> interested in can develop packages.

Indeed, normal people can do exactly that even today.  The point I'm
making here is that learning Emacs Lisp itself will let you extend
Emacs, and that there's no extra "Emacs API" to learn.

> It’s just that Emacs practically needs configuration to be usable - which
> means that one must learn Emacs lisp.
>
> Yes, Eintr teaches Emacs Lisp well, but that step should be optional.

And it is optional; You can go by with package+custom fairly well.  I
know people who do that.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I personally think that various Emacs APIs regarding buffers, etc… is not
  > > part of the language, but that’s just my opinion.

  > They're implemented inside the language runtime, have relavant
  > primitives inside the bytecode engine, et cetera.  They're also the
  > primary (I wouldn't go as far as to say only, but it's close) IO
  > mechanism available in Emacs Lisp.

Those are not part of the Lisp language, so they are not really
part of the mission of the Lisp Reference Manual.
It does document some internal C conventions because they are useful
for people who want to customize at the C level, but we do that
only to the extent that seems worth doing.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Those are not part of the Lisp language, so they are not really
> part of the mission of the Lisp Reference Manual.
> It does document some internal C conventions because they are useful
> for people who want to customize at the C level, but we do that
> only to the extent that seems worth doing.

I'm just saying that I would consider buffers part of Emacs Lisp, and
not a separate "Emacs Lisp standard library".

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm just saying that I would consider buffers part of Emacs Lisp, and
  > not a separate "Emacs Lisp standard library".

The Emacs Lisp Reference Manual documents the use of buffers
from Emacs Lisp.  Operating on them with C code is a different matter.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> The Emacs Lisp Reference Manual documents the use of buffers
> from Emacs Lisp.  Operating on them with C code is a different matter.

I wasn't referring to how buffers can be operated from C code.  I was
referring to how buffers are an integral part of the Emacs Lisp
*language*, and not some hypothetical "standard library".

I was also referring to how the Eintr explains how buffers can be
manipulated from Lisp code quite well.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I wasn't referring to how buffers can be operated from C code.  I was
  > referring to how buffers are an integral part of the Emacs Lisp
  > *language*, and not some hypothetical "standard library".

I don't think the concept of "standard library" makes sense for Emacs
Lisp.  However, I conceptually divide the programming facilities
of Emacs into 

* The Emacs Lisp language

and

* the editing facilities.

I see buffers as part of the editing facilities, not part of the Emacs
Lisp language itself.

  > I was also referring to how the Eintr explains how buffers can be
  > manipulated from Lisp code quite well.

What do you mean by the term "Eintr"?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I don't think the concept of "standard library" makes sense for Emacs
> Lisp.  However, I conceptually divide the programming facilities
> of Emacs into 
>
> * The Emacs Lisp language
>
> and
>
> * the editing facilities.

> I see buffers as part of the editing facilities, not part of the Emacs
> Lisp language itself.

I'm not sure I see that distinction, since Emacs Lisp as a language
doesn't really make sense without the editing facilities.  It would make
sense to classify Emacs Lisp as a whole as a highly domain-centric Lisp dialect.

> What do you mean by the term "Eintr"?

The book "An Introduction to Programming in Emacs Lisp"

Re: "Why is emacs so square?"

[Stefan Monnier]

>> I don't think the concept of "standard library" makes sense for Emacs
>> Lisp.  However, I conceptually divide the programming facilities
>> of Emacs into 
>>
>> * The Emacs Lisp language
>>
>> and
>>
>> * the editing facilities.

Because of how it evolved, there is clear separation.
And it's hard to retro-fit a distinction after-the-fact.
But I personally do think of the Elisp world as split into various "layers":

A- The core language itself.
B- The core standard library.
C- Extra libraries bundled with Emacs.
D- Extra libraries distributed in GNU ELPA.
E- Extra libraries distributed elsewhere.

Yet, I would be hard pressed to draw the separation between some of
those layers (and more so to "define" that separation).

>> I see buffers as part of the editing facilities, not part of the Emacs
>> Lisp language itself.

Great example: putting it in (B) makes sense, yet at the same time I'd
put buffer-local variables in (A), thus breaking the layering.

> I'm not sure I see that distinction, since Emacs Lisp as a language
> doesn't really make sense without the editing facilities.

There are other implementations of Elisp, some of which are not tied to
an editor, so it can make sense (see the paper Mike Sperber and I wrote
for HOPL-2020 for an example).  


        Stefan

Re: "Why is emacs so square?"

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:


> Because of how it evolved, there is clear separation.
> And it's hard to retro-fit a distinction after-the-fact.
> But I personally do think of the Elisp world as split into various "layers":
>
> A- The core language itself.
> B- The core standard library.

Are you referring to `subr.el' and friends, or built-in primitives, or
subrs in *fns.c, or both, or all three?

> Great example: putting it in (B) makes sense, yet at the same time I'd
> put buffer-local variables in (A), thus breaking the layering.

Precisely.

> There are other implementations of Elisp, some of which are not tied to
> an editor, so it can make sense (see the paper Mike Sperber and I wrote
> for HOPL-2020 for an example).  

Of the many implementations that I see listed there, most are from the
"let's rewrite Emacs (in our favorite language / better)" camp, and do
include some (or most of) the editing primitives.  Of the others, I
don't really see Emacs Lisp, but a glorified MacLISP with optional
lexical binding and some Emacs Lisp-ish features.

I suppose we're operating on different definitions of what constitutes
"Emacs Lisp".

Re: "Why is emacs so square?"

[Stefan Monnier]

> Of the many implementations that I see listed there, most are from the
> "let's rewrite Emacs (in our favorite language / better)" camp, and do
> include some (or most of) the editing primitives.  Of the others, I
> don't really see Emacs Lisp, but a glorified MacLISP with optional
> lexical binding and some Emacs Lisp-ish features.

I was thinking mostly of the "elisp.lisp" package by Sam Steingold (and
to a lesser extent librep).

> I suppose we're operating on different definitions of what constitutes
> "Emacs Lisp".

I know for a fact that I operate on several different definitions of
what constitutes "Elisp", yes  ;-)


        Stefan

Re: "Why is emacs so square?"

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I know for a fact that I operate on several different definitions of
> what constitutes "Elisp", yes  ;-)

Fair enough, then.  Thanks for clearing it up.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > What do you mean by the term "Eintr"?

  > The book "An Introduction to Programming in Emacs Lisp"

I was surprised to see that term used in connection with Emacs.
Is that name for the manual used in any part of Emacs?

I recognize EINTR only as an error code for system calls. ;-{.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eduardo Ochs]

Hi Richard,
this sexp
  (info "(eintr)Top")
opens the manual "An Introduction to Programming in Emacs Lisp".

On Fri, 24 Apr 2020 at 03:35, Richard Stallman <rms@gnu.org> wrote:
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?
>
> I recognize EINTR only as an error code for system calls. ;-{.

Re: "Why is emacs so square?"

[Kévin Le Gouguec]

Richard Stallman <rms@gnu.org> writes:

>   > > What do you mean by the term "Eintr"?
>
>   > The book "An Introduction to Programming in Emacs Lisp"
>
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?

This comment in doc/lispintro/Makefile seem to point to hysterical
raisins:

#+begin_src makefile
srcs = ${srcdir}/emacs-lisp-intro.texi ${srcdir}/doclicense.texi \
  ${emacsdir}/docstyle.texi ${emacsdir}/emacsver.texi

# …

# The file name eintr must fit within 5 characters, to allow for
# -NN extensions to fit into DOS 8+3 limits without clashing.
${buildinfodir}/eintr.info: ${srcs} | ${buildinfodir}
	$(AM_V_GEN)$(MAKEINFO) $(MAKEINFO_OPTS) $(INFO_OPTS) -o $@ $<
#+end_src

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > # The file name eintr must fit within 5 characters, to allow for
  > # -NN extensions to fit into DOS 8+3 limits without clashing.

Thanks for finding the reason.

Eli, does this name length matter any more?

Is the Emacs Lisp Intro long enough that it needs to generate subfiles
named with two digits?  Could we make it generate suffixes -N instead?
Then we could call it ELINTR.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: me@enzu.ru, joseph.h.garvin@gmail.com, stefan@marxist.se,
> 	emacs-devel@gnu.org, luangruo@yahoo.com, pcr910303@icloud.com,
> 	eliz@gnu.org, drew.adams@oracle.com, ndame@protonmail.com
> Date: Fri, 24 Apr 2020 23:36:03 -0400
> 
>   > # The file name eintr must fit within 5 characters, to allow for
>   > # -NN extensions to fit into DOS 8+3 limits without clashing.
> 
> Thanks for finding the reason.
> 
> Eli, does this name length matter any more?

No.  Especially since we stopped splitting our manuals into foo-N
parts long ago.

The only issue today is that renaming the Info file will make the
successful update of the system-wide DIR file by install-info at "make
install" time more important, otherwise people might have an old
manual presented to them.  Not sure what this means for the various
binary distros.  Also, we need to rework all the references we have to
that manual in Lisp files (I found only one such reference, FWIW).

> Is the Emacs Lisp Intro long enough that it needs to generate subfiles
> named with two digits?  Could we make it generate suffixes -N instead?

Not an issue anymore, see above.

> Then we could call it ELINTR.

I'd suggest ELINTRO or even LISPINTRO (similar to LISPREF for the
ELisp reference manual).

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'd suggest ELINTRO or even LISPINTRO (similar to LISPREF for the
  > ELisp reference manual).

Given we can use such a long name, I think LISPINTRO is good.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: me@enzu.ru, joseph.h.garvin@gmail.com, stefan@marxist.se,
> 	emacs-devel@gnu.org, pcr910303@icloud.com, eliz@gnu.org,
> 	drew.adams@oracle.com, ndame@protonmail.com
> Date: Thu, 23 Apr 2020 22:34:27 -0400
> 
>   > > What do you mean by the term "Eintr"?
> 
>   > The book "An Introduction to Programming in Emacs Lisp"
> 
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?

It's the name of the Info file we produce from that manual:
eintr.info.

Re: "Why is emacs so square?"

[ndame]

>
> Here's the problem: You have to learn the VS Code API. I'd say learning
> that, and becoming reasonably proficient at it takes longer than
> skimming through the Emacs Lisp intro.

Learning lisp needs a new mindset while the VS Code API is just a bunch
of method calls.

And you don't need to learn the whole API. When I wrote an extension for
a test, to see how hard it is then I just googled things and used those
parts which I needed. I certanly didn't learn the whole vscode API, because
it wasn't necessary.

> > VScode has a very nice out of the box experience. If you want support
> > for a language then it's one click to install it and it installs the
> > necessary scaffolding too, like a language server for the language.
>
> We have several starter packs, with similarly nice OOTB experiences.

But they are not advertised on the emacs homepage, so a new user who just
googles emacs doesn't necessarily know about them.


>
> Electron is not free software (https://labs.parabola.nu/issues/1167),
> and is definitely not as well suited to providing an integrated
> experience like Emacs.

I know it's not free software. I just meant it provided many features
out of the box which has to be implemented separately for emacs.


> For instance, even if you render raw HTML inside VS Code, you would not
> be able to grab the region using VSC APIs. I'm not sure if the VSC API
> allows interacting with the DOM, but from what I can tell, it can't.

Certainly, it's more limited some ways, you don't have the freedom to
access everything like in Emacs.

>
> We have Cua mode. No, you don't need to have it enabled by default,
> since it would result in unnecessary breakage for old users.

Well, I think old users could adapt for the sake of new users. New users
shouldn't encounter lots of strange concepts from the start.

For example, the current tutorial may not be the best
approach. Explaining about cursor movement with C-f and C-b? Windows
and frames?

Why a new user who casually wants to try emacs has to start with this?

A new user can use the cursor keys and the mouse to operate the
menus. Rather than focusing on strange keys for cursor movement a
better approach could be explaining what emacs does better than other
tools and how to use those features.

And users could be informed on the startup screen that they can learn
traditional emacs keys in a separate tutorial if they are interested.

>
> I personally think that the Emacs bindings are better, and in the end
> work better with Emacs itself, but I do agree that newcomers should be
> allowed to familiarize themselves with Emacs before moving their
> workflow (and habits) to it entirely.

Exactly. Users should encounter a familiar environment first, using
the keys they are used to. They can always move on if they decide to
stay with emacs.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Sun, 19 Apr 2020 06:52:03 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Ahmed Khanzada <me@enzu.ru>, Stefan Kangas <stefan@marxist.se>,
>  Joseph Garvin <joseph.h.garvin@gmail.com>, Richard Stallman <rms@gnu.org>,
>  Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
>  Drew Adams <drew.adams@oracle.com>
> 
> For example, the current tutorial may not be the best
> approach. Explaining about cursor movement with C-f and C-b? Windows
> and frames?
> 
> Why a new user who casually wants to try emacs has to start with this?
> 
> A new user can use the cursor keys and the mouse to operate the
> menus. Rather than focusing on strange keys for cursor movement a
> better approach could be explaining what emacs does better than other
> tools and how to use those features.

When did you last look at the tutorial that comes with Emacs?  We
mention the cursor keys there since Emacs 22.1.  We mention
PageUp/PageDown since Emacs 23.1.

> And users could be informed on the startup screen that they can learn
> traditional emacs keys in a separate tutorial if they are interested.

We think using C-f/C-b etc. keys will help users type more
efficiently, and we say so in the tutorial, _after_ saying that the
"normal" cursor motion keys also work.  I see nothing wrong with that.

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think you've stated the arguments very well.  There are a couple of
points where I would say something less strong.

  > 3. If Emacs was to become a "modern" app tomorrow, an editor extended
  > in Lisp still only has appeal for a minority of programmers, much like
  > the Lisp language itself. Most programmers looking for easy and modern
  > experiences will likely stick with Atom and Sublime.

If Emacs were 100% as convenient and attractive as other editors,
it is possible that a lot of users would use it.  30 years ago,
the user profile of Emacs was much broader than it is today.
It would be good to make this happen again.

But that would require a number of changes, and I don't think that
round corners would get us close to there.

Thus, I think your point 3 is not valid in the universal sense that it
is presented in, but it is valid for the this particular issue.

If there are people who want to work on rounded corners, and assuming
they do a good job, I won't argue against it.  But if you want
to attract more users to Emacs, I think there are more important
areas for improvement.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Po Lu]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Richard Stallman <rms@gnu.org> writes:

> If Emacs were 100% as convenient and attractive as other editors,
> it is possible that a lot of users would use it.  30 years ago,
> the user profile of Emacs was much broader than it is today.
> It would be good to make this happen again.

I would personally say that several of the starter packs (Spacemacs and
Doom immediately come to mind) are "attractive" and "modern", and don't
really sacrifice any functionality to achieve that.  Spacemacs is also
very easy to set-up and use.  (Doom's also getting there).
> But that would require a number of changes, and I don't think that
> round corners would get us close to there.

Agreed.

> If there are people who want to work on rounded corners, and assuming
> they do a good job, I won't argue against it.  But if you want
> to attract more users to Emacs, I think there are more important
> areas for improvement.

I'm working on something that uses GTK foreign rendering to draw button
and input field backgrounds as face boxes;  I should be able to get it
in a usable state soon (right now it only works on top of another set of
patches I'm working on that make Emacs a pure GTK app).


[-- Attachment #2: Screenshot --]
[-- Type: image/png, Size: 131103 bytes --]

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 19, 2020, at 11:33, Po Lu <luangruo@yahoo.com> wrote:
> 
>> If there are people who want to work on rounded corners, and assuming
>> they do a good job, I won't argue against it.  But if you want
>> to attract more users to Emacs, I think there are more important
>> areas for improvement.
> 
> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes;  I should be able to get it
> in a usable state soon (right now it only works on top of another set of
> patches I'm working on that make Emacs a pure GTK app).

Maybe it would be nice to have era-based user experiences. Like a 70's UI package, a 80's UI package, etc. That way it is just a matter of selecting a package and every generation will feel that emacs is just what works for them. Just half (maybe quarter) tongue in cheek.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Po Lu]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

> Maybe it would be nice to have era-based user experiences. Like a 70's
> UI package, a 80's UI package, etc. That way it is just a matter of
> selecting a package and every generation will feel that emacs is just
> what works for them. Just half (maybe quarter) tongue in cheek.

I'm not sure that's necessary.  It makes sense to have a set of well
thought-out defaults that work for everyone, or perhaps a few extra
custom themes (ie `gtk') that enable these options and are bundled with
Emacs by default.

Re: "Why is emacs so square?"

[ndame]

>
> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes; I should be able to get it
> in a usable state soon (right now it only works on top of another set of
> patches I'm working on that make Emacs a pure GTK app).

Looks good. These are the changes Emacs needs, so it has a nicer first
impression for users who come from mainstream tools to give it a try.

Emacs shouldn't look old fashioned out of the box. It would be great
if it could use GTK widgets on all major GUI platforms, instead of
text buttons and stuff.

Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[Po Lu]

ndame <ndame@protonmail.com> writes:

> Looks good. These are the changes Emacs needs, so it has a nicer first
> impression for users who come from mainstream tools to give it a try.

I don't think the general goal is for Emacs to imitate popular tools, but
instead to make it a mainstream tool.  To achieve this, we do need to
make Emacs more friendly for newcomers, but we shouldn't erase the
traits that make Emacs unique (such as extreme extensibility and
customizability).

IOW, everything added to make Emacs more friendly should be optional
(but easily discoverable), and should not break backwards-compatiblity with
existing configurations.

Emacs has endured for 40+ years. I doubt that without the Emacsen I
remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
the various improvements they curtailed that Emacs would still be where
it is now.  Let's help Emacs endure another 40 years.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[Eduardo Ochs]

There are several different ways of making Emacs more friendly for
newcomers, and we should take a look at all these different ways and
try to connect them somehow.

I gave a presentation about my way at the last EmacsConf. It's here:

  http://angg.twu.net/emacsconf2019.html

and I mentioned briefly in the presentation - in slides 11-13 - how
I've been using it to teach Emacs to lots of beginners. To make a long
story very short:

  0) install Emacs and eev in their machines,

  1) teach them the basics of Lisp _IN THE FIRST FIVE MINUTES_,

  2) show them how to navigate using the keys M-e, M-j, and M-k,
     and the menu bar and the tool bar.

From the docs:

  M-e   - to follow a hyperlink.  Mnemonic: "(e)valuate"/"(e)xecute".

  M-j   - to jump to certain predefined places. In particular, M-j
          without a numeric argument takes you to a buffer with basic
          help and a list of jump targets. See:

          http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.2

  M-k   - to go back.  Mnemonic: "(k)ill buffer".


Cheers,
  Eduardo Ochs
  http://angg.twu.net/#eev
  http://angg.twu.net/emacsconf2019.html


On Sun, 19 Apr 2020 at 07:16, Po Lu <luangruo@yahoo.com> wrote:
>
> ndame <ndame@protonmail.com> writes:
>
> > Looks good. These are the changes Emacs needs, so it has a nicer first
> > impression for users who come from mainstream tools to give it a try.
>
> I don't think the general goal is for Emacs to imitate popular tools, but
> instead to make it a mainstream tool.  To achieve this, we do need to
> make Emacs more friendly for newcomers, but we shouldn't erase the
> traits that make Emacs unique (such as extreme extensibility and
> customizability).
>
> IOW, everything added to make Emacs more friendly should be optional
> (but easily discoverable), and should not break backwards-compatiblity with
> existing configurations.
>
> Emacs has endured for 40+ years. I doubt that without the Emacsen I
> remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
> the various improvements they curtailed that Emacs would still be where
> it is now.  Let's help Emacs endure another 40 years.
>

Re: Making Emacs more friendly to newcomers

[Po Lu]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> There are several different ways of making Emacs more friendly for
> newcomers, and we should take a look at all these different ways and
> try to connect them somehow.
>
> I gave a presentation about my way at the last EmacsConf. It's here:
>
>   http://angg.twu.net/emacsconf2019.html
>
> and I mentioned briefly in the presentation - in slides 11-13 - how
> I've been using it to teach Emacs to lots of beginners. To make a long
> story very short:
>
>   0) install Emacs and eev in their machines,
>
>   1) teach them the basics of Lisp _IN THE FIRST FIVE MINUTES_,
>
>   2) show them how to navigate using the keys M-e, M-j, and M-k,
>      and the menu bar and the tool bar.
>
> From the docs:
>
>   M-e   - to follow a hyperlink.  Mnemonic: "(e)valuate"/"(e)xecute".
>
>   M-j   - to jump to certain predefined places. In particular, M-j
>           without a numeric argument takes you to a buffer with basic
>           help and a list of jump targets. See:
>
>           http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.2
>
>   M-k   - to go back.  Mnemonic: "(k)ill buffer".
>
>
> Cheers,
>   Eduardo Ochs
>   http://angg.twu.net/#eev
>   http://angg.twu.net/emacsconf2019.html
>
>

Your perspective is interesting.  However, I think new users should be
allowed to slowly adapt to the Emacs way, while being able to utilize their
existing workflow and habits, instead of being fed a new set of habits
and workflows in the first 5 minutes.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> ndame <ndame@protonmail.com> writes:
>
>> Looks good. These are the changes Emacs needs, so it has a nicer first
>> impression for users who come from mainstream tools to give it a try.
>
> I don't think the general goal is for Emacs to imitate popular tools, but
> instead to make it a mainstream tool.  To achieve this, we do need to
> make Emacs more friendly for newcomers, but we shouldn't erase the
> traits that make Emacs unique (such as extreme extensibility and
> customizability).
>
> IOW, everything added to make Emacs more friendly should be optional
> (but easily discoverable), and should not break backwards-compatiblity with
> existing configurations.

I personally find that the stance of trying to not breaking anything is
one of the big reasons that Emacs has a nonusable-without-configuration UX.
Major version numbers are there for a reason… and we can expect for annoyed
people to set some variables to get old behavior.

> Emacs has endured for 40+ years. I doubt that without the Emacsen I
> remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
> the various improvements they curtailed that Emacs would still be where
> it is now.  Let's help Emacs endure another 40 years.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[ndame]

>
> I personally find that the stance of trying to not breaking anything is
> one of the big reasons that Emacs has a nonusable-without-configuration UX.
> Major version numbers are there for a reason… and we can expect for annoyed
> people to set some variables to get old behavior.

Yes, these changes should be clearly marked in NEWS, so those who don't want
them, can revert them.

Out of the box Emacs should be instantly usable for newcomers and older users
could adapt for the sake of Emacs. I wouldn't mind adding a line to my .emacs to
turn something off which I don't need, but which can make the life of new
users easier.

For example, CUA mode could be on by default. I would turn it off, but it could
make the life of new users easier if they didn't have to turn it on explicitly
and they could use their copy/paste keys from the start like they are used it to
in other tools.

Re: Making Emacs more friendly to newcomers

[Po Lu]

ndame <ndame@protonmail.com> writes:

> Yes, these changes should be clearly marked in NEWS, so those who don't want
> them, can revert them.

Massive features that drastically change behaviour should be off by
default.  Stability over users. What's wrong with a button on the fancy
splash screen?

> Out of the box Emacs should be instantly usable for newcomers and older users
> could adapt for the sake of Emacs. I wouldn't mind adding a line to my .emacs to
> turn something off which I don't need, but which can make the life of new
> users easier.

You can't turn massive changes off by adding "one line to my .emacs".
You can however turn them on by adding a button to the splash screen.

Emacs cannot and will never be usable out-of-the-box for 100% of all
usecases.  You can however make it easier for people to start, and again
that's when the "button on splash screen" approach comes in.

> For example, CUA mode could be on by default. I would turn it off, but it could
> make the life of new users easier if they didn't have to turn it on explicitly
> and they could use their copy/paste keys from the start like they are used it to
> in other tools.

That mentality would lead to an unacceptable maintainence burden for a lot of
people.  Again: what's wrong with putting a button on the splash screen?

Re: Making Emacs more friendly to newcomers

[ndame]

>
> > Yes, these changes should be clearly marked in NEWS, so those who don't want
> > them, can revert them.
>
> Massive features that drastically change behaviour should be off by
> default. Stability over users. What's wrong with a button on the fancy
> splash screen?

A button can work too. Or if emacs is started with no config file then it can
ask "Are you using Emacs for the first time?" If the user says yes then it
can offer to set some convenience features like CUA mode.

And if the user says no then everything is as usual.

Re: Making Emacs more friendly to newcomers

[Po Lu]

ndame <ndame@protonmail.com> writes:

> A button can work too. Or if emacs is started with no config file then it can
> ask "Are you using Emacs for the first time?" If the user says yes then it
> can offer to set some convenience features like CUA mode.
>
> And if the user says no then everything is as usual.

The latter now occours to me as being the best solution.  Thanks for
bringing it up.  I believe it would be nice if we had both too.

Re: Making Emacs more friendly to newcomers

[Sébastien Gendre]

# Re: Making Emacs more friendly to newcomers

Based on some suggestions on this topic, and some personal
reflections, I have a suggestion. (Sorry, I didn't read all messages,
maybe someone had already suggest the same thing)

Let's see some use-cases:
- Bob: A newcomer, who just discover Emacs. He search somthing who is
  visually modern, with all features he need to start writing code in
  most popular languages: Code colouration, auto-completion, code
  navigation, code documentation and functions/methods signature
  automatically shown, code errors/warnings signalling, REPL
  integration, snippets, strong GIT integration, etc. He also want to
  use basic features without the need to read a tutorial. Just install
  and go. But he is ok to read some tuto or manuals for advanced
  features. If we ask him question(s) about what to enable or not, he
  probably cannot respond (or thing he cannot). For him, Emacs need to
  be the most out of the box possible.
- Alice: A long time user. She got a personal Emacs configuration she
  had perfected over the years. She chose herself what system is used
  to show function completion, which code parser is used for her daily
  used languages. She add some packages to integrate with special
  tools used at her work. Emacs is her home and office: She use it as
  much for her personal project than for her work. She also made a
  personal workflow with org-mode and write some personal Elisp
  functions and advices. She forge the tools to her need. She do not
  want to have an update of Emacs who break her configuration, her
  workflow or her muscle memory.
- Mei: She simply want to use SpaceEmacs. She need to be sure
  SpaceEmacs would work out of the box and be able to override all
  defaults Emacs configuration. So SpaceEmacs developers need a way to
  doing their work without the need to deactivate a hundred of default
  features one after another and risk to forget one. This possibility
  should be well documented. As the need of Mei is covered by
  SpaceEmacs, she doesn't have special request about Emacs except make
  it easy to use SpaceEmacs.
- Roberto: He work on a pre-configuration of Emacs, similar to
  SpaceEmacs. He need a simple and documented way to deactivate all
  default configurations that would make is work difficult. If
  possible, in one move. And, of course, he need to know what is
  deactivated so he can choose wisely what to enable and what to not.
  
  
For these 4 use-cases, we can simply provide 2 flavors of Emacs:
- Emacs: With all the 2020 features, a modern interface, all needed
  modern features to start coding with most popular languages and easy
  to use for basic usages
- Emacs Vanilla: All the new features are still there, but deactivate
  to not break anything


And these 2 flavors can be in the same text editor: For switch from a
flavor to another, simply enable the global-minor-mode `vanilla-mode`.
And if Emacs detect, after an update or a first start, an already
existing configuration that it could break because of some features:
Emacs simply activate `vanilla-mode` automatically.


For our use-cases, this would be:
- Bob simply download and run Emacs. He got everything he wanted and
  start to code. Emacs can manage Bob projects, show documentation and
  errors, etc. Then, after some times, Bob can read some manuals to
  personalise his installation of Emacs.
- Alice update Emacs. When she restart it, Emacs detect an already
  existing configuration that it could break by enabling some
  features. So, Emacs simply enable `vanilla-mode` and add it to the
  `init.el`. Emacs also show a message to Alice: "Emacs detected that
  you have some personal configuration, so it active Vanilla-mode to
  avoid breaking your configuration. Vanilla-mode deactivate some
  features that you can re-enable manually.". This message is
  accompanied by a clickable link to the documentation about the
  `vanilla-mode` to see what it does in the details and what is
  deactivate.
- Mei simply download Emacs and SpaceEmacs. She follow SpaceEmacs
  instruction and everything work.
- Roberto add `(vanilla-mode)` to his `init.el` file and start writing
  his pre-configuration of Emacs. He is certain that no future version
  of Emacs would break his work and he can share publicly his
  configuration as SpaceEmacs or Doom Emacs do.

  
It's just a starting point, but I think this could be a simple but
very useful solution.

Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

Sébastien Gendre <seb@k-7.ch> writes:

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages
> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything

I'm personally not against the idea of having a separate backwards
compatibility mode.

But I guess we would need to pull in several third-party packages to
have a modern "batteries included" Emacs.  AFAIK, that is
unfortunately not possible given the copyright assignment requirement.
But perhaps a default "modern" mode could be a bit less ambitious.

Best regards,
Stefan Kangas

Re: Making Emacs more friendly to newcomers

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

How will any of this differ from the many existing canned default setups
already available? In fact, given the limitation on only using Emacs
built-in packages, is it even possible to do a setup which is even close to
some of these canned setups, many of which appear to be targeted at new
users (spacemacs, doom, prelude, etc). Are we just talking about a GNU
canned configuration?

On Mon, 20 Apr 2020 at 10:37, Stefan Kangas <stefan@marxist.se> wrote:

> Sébastien Gendre <seb@k-7.ch> writes:
>
> > For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> > - Emacs: With all the 2020 features, a modern interface, all needed
> >   modern features to start coding with most popular languages and easy
> >   to use for basic usages
> > - Emacs Vanilla: All the new features are still there, but deactivate
> >   to not break anything
>
> I'm personally not against the idea of having a separate backwards
> compatibility mode.
>
> But I guess we would need to pull in several third-party packages to
> have a modern "batteries included" Emacs.  AFAIK, that is
> unfortunately not possible given the copyright assignment requirement.
> But perhaps a default "modern" mode could be a bit less ambitious.
>
> Best regards,
> Stefan Kangas
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1897 bytes --]

Re: Making Emacs more friendly to newcomers

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> How will any of this differ from the many existing canned default setups already available? In fact, given the limitation on only using Emacs built-in packages, is it even possible to do a setup which is even close to some of these canned setups, many of which appear to
> be targeted at new users (spacemacs, doom, prelude, etc). Are we just talking about a GNU canned configuration?

More of a few well thought-out tips that are easily discoverable by
users.

>  But I guess we would need to pull in several third-party packages to
>  have a modern "batteries included" Emacs.  AFAIK, that is
>  unfortunately not possible given the copyright assignment requirement.
>  But perhaps a default "modern" mode could be a bit less ambitious.

Agreed, but I believe most package maintainers would be willing to
assign copyright to the FSF.  (For instance Eglot would count as an
important package, and it's in ELPA).

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

For the record, I have a proof-of-concept package for GNU ELPA which
I call `gnu-elpa` and which just adds "most" of the autoloads found in
GNU ELPA packages (along with the corresponding changes to
`auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
will prompt the user if they want to install the corresponding package.

It's not as good as activating `eglot` and `company`, but I think such
a `gnu-elpa` package should ideally be bundled with Emacs-28.


        Stefan

Re: Making Emacs more friendly to newcomers

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> For the record, I have a proof-of-concept package for GNU ELPA which
> I call `gnu-elpa` and which just adds "most" of the autoloads found in
> GNU ELPA packages (along with the corresponding changes to
> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
> will prompt the user if they want to install the corresponding package.

That's interesting.  I remember someone working on something similar,
but would find autoloads inside any package.el repository (it would
download, extract and cache the autoloads from a list of packages
beforehand).

> It's not as good as activating `eglot` and `company`, but I think such
> a `gnu-elpa` package should ideally be bundled with Emacs-28.

Yeah, that would be nice.

Re: Making Emacs more friendly to newcomers

[Simen Heggestøyl]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> For the record, I have a proof-of-concept package for GNU ELPA which
> I call `gnu-elpa` and which just adds "most" of the autoloads found in
> GNU ELPA packages (along with the corresponding changes to
> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
> will prompt the user if they want to install the corresponding package.
>
> It's not as good as activating `eglot` and `company`, but I think such
> a `gnu-elpa` package should ideally be bundled with Emacs-28.

That sounds really nice.

-- Simen

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

> On Apr 21, 2020, at 9:57 AM, Simen Heggestøyl <simenheg@runbox.com> wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>> For the record, I have a proof-of-concept package for GNU ELPA which
>> I call `gnu-elpa` and which just adds "most" of the autoloads found in
>> GNU ELPA packages (along with the corresponding changes to
>> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
>> will prompt the user if they want to install the corresponding package.
>> 
>> It's not as good as activating `eglot` and `company`, but I think such
>> a `gnu-elpa` package should ideally be bundled with Emacs-28.
> 
> That sounds really nice.
> 
> — Simen
> 

I like the idea. If I open a Racket file in VSCode, it show a prompt that asks me if I want to search the “market place” for a racket plugin. If I click yes and click install, everything magically works. Now my racket buffer has completion, highlight, etc. For more popular languages like python, VSCode even auto detects for linters and python executables, etc. And with one click it finds (or downloads) linters and executables and sets them up for me. Maybe it is hard to make Emacs as pretty as VSCode (with all the fancy visual web tech); but making Emacs smarter and more helpful should be a tractable task. We already have Customize, all we need to do next is to add some smart helper functions that install packages and setup stuff. 

Yuan

Re: Making Emacs more friendly to newcomers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> For the record, I have a proof-of-concept package for GNU ELPA which
  > >> I call `gnu-elpa` and which just adds "most" of the autoloads found in
  > >> GNU ELPA packages (along with the corresponding changes to
  > >> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
  > >> will prompt the user if they want to install the corresponding package.

It is ok to do this with GNU ELPA,
because we could move those packages into the Emacs distribution
if that ever seems advantageous for any reason.
We don't have an essential need to make a distinction between
the packages in GNU ELPA and the ones in the Emacs distinction itself.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making Emacs more friendly to newcomers

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> I like the idea. If I open a Racket file in VSCode, it show a prompt
> that asks me if I want to search the “market place” for a racket
> plugin. If I click yes and click install, everything magically
> works. Now my racket buffer has completion, highlight, etc. For more
> popular languages like python, VSCode even auto detects for linters
> and python executables, etc. And with one click it finds (or
> downloads) linters and executables and sets them up for me. Maybe it
> is hard to make Emacs as pretty as VSCode (with all the fancy visual
> web tech); but making Emacs smarter and more helpful should be a
> tractable task. We already have Customize, all we need to do next is
> to add some smart helper functions that install packages and setup
> stuff.

I'd say Emacs can be made to look just as nice as VS Code with some
minor tweaks, and yeah it would be nice if Stefan's package (or
something similar) would be able to suggest Geiser upon opening a Scheme
(or Racket) file.

Re: Making Emacs more friendly to newcomers

[Ahmed Khanzada]

> I'd say Emacs can be made to look just as nice as VS Code with some
> minor tweaks, and yeah it would be nice if Stefan's package (or
> something similar) would be able to suggest Geiser upon opening a Scheme
> (or Racket) file.

I wonder what kind of effect it will have on the community when
packages in the same domain compete to be "anointed" as the package that
Emacs shall recommend for a particular file type or feature.

Or do we approach it like the EU did with web browsers, and when Emacs
boots, we suggest either enabling Ivy, Helm, or Company for text
completion? There are never more than a few packages seriously competing in the
same domain anyway, if one can even call it competition.

Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

Ahmed Khanzada <me@enzu.ru> writes:

> Or do we approach it like the EU did with web browsers, and when Emacs
> boots, we suggest either enabling Ivy, Helm, or Company for text
> completion? There are never more than a few packages seriously competing in the
> same domain anyway, if one can even call it competition.

I think we should offer a multiple choice question, ideally with some
brief explanation of the differences between the packages.

It would also be good if one could easily switch between alternatives.

Best regards,
Stefan Kangas

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 23:33:32 -0700
> From: Ahmed Khanzada <me@enzu.ru>
> Cc: Yuan Fu <casouri@gmail.com>, Tim Cross <theophilusx@gmail.com>,
>  Stefan Kangas <stefan@marxist.se>, Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Sébastien Gendre <seb@k-7.ch>,
>  Simen Heggestøyl <simenheg@runbox.com>
> 
> I wonder what kind of effect it will have on the community when
> packages in the same domain compete to be "anointed" as the package that
> Emacs shall recommend for a particular file type or feature.

We have several of such "competitors" already in core.  Did anything
bad happen?

And it isn't like packages are lining up to be included in Emacs, or
even "anointed" by it, is it?  Boy, I'd like to be there.

Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> And it isn't like packages are lining up to be included in Emacs, or
> even "anointed" by it, is it?  Boy, I'd like to be there.

I strongly agree.  In fact, I would go so far as to say that this is an
important strategic consideration for GNU Emacs.

It's very unfortunate that there are so many great packages that are only
available to a subsection of users willing or able to install third party
packages.

It's too easy for package authors to just throw it up on MELPA and be done with
it, without realizing the many benefits of getting it into GNU Emacs.  There
would be some great benefits to having more deserving packages in core, or even
GNU ELPA:

- They would reach a wider audience.
- We can do more to ensure they integrate well with all other packages.
- We could consider enabling some of them by default.
- We would have a world class team of Emacs Lisp hackers (in other words,
  emacs-devel) reviewing the documentation and code.
- etc., etc.

The reasons why package authors would not want to include it, on the other hand,
could obviously vary.  Some of the reasons I have seen are
unfortunately very shallow:

- Misconceptions about how hard it is to work with emacs-devel.
- An unwillingness to assign copyright to the FSF, seemingly often more due to
  inertia than any principled opposition.
- Strongly ideological anti-FSF sentiments (often disguised as "non-ideological"
  or "practical").

I mean, that's my impression of it, and I'm not pretending that this list is
exhaustive or even generally correct.

But maybe we should think about how we can argue our case more strongly, and
clear up at least some of the misconceptions.  For example, we could make
additions to the Emacs Lisp manual on why one would want to push to have their
package included.  We could also explain that they can have their code in GNU
ELPA, or even GNU Emacs, and host a development repository anywhere
they like, etc.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 24, 2020, at 2:07, Stefan Kangas <stefan@marxist.se> wrote:
> 
> The reasons why package authors would not want to include it, on the other hand,
> could obviously vary.  Some of the reasons I have seen are
> unfortunately very shallow:
> 
> - Misconceptions about how hard it is to work with emacs-devel.

That's something that documentation can fix.

> - An unwillingness to assign copyright to the FSF, seemingly often more due to
>  inertia than any principled opposition.

It has been mentioned a number of times already.

I think that the process could be streamlined (and there is a need to check that with the legal team I guess).

For one, the actually *submission* of the copyright assignment to the FSF could me made to be as easy as a simple code commit, signed with something like a gpg key or something.

Once the developer has simply "pushed that button," the contribution should be considered valid, and then eventually the developer receives a PDF signed by the FSF to confirm the assignment.

And that should be it (or are there cases when the FSF refuses the assignment ?)

> - Strongly ideological anti-FSF sentiments (often disguised as "non-ideological"
>  or "practical").

Hahaha :) I'm not sure a REOPEN YOUR CODE meme would pass muster in our times, but it seems to me that there is some overlap between populations that reject the FSF "because freedom" and those who reject sanitary lockdown "because freedom". But I won't err on that path any further :)

> I mean, that's my impression of it, and I'm not pretending that this list is
> exhaustive or even generally correct.

I think point 1 and 2 are the best the FSF/GNU could do.

> But maybe we should think about how we can argue our case more strongly, and
> clear up at least some of the misconceptions.  For example, we could make
> additions to the Emacs Lisp manual on why one would want to push to have their
> package included.  We could also explain that they can have their code in GNU
> ELPA, or even GNU Emacs, and host a development repository anywhere
> they like, etc.

Excellent !!! Yes, and the emacs site too !



Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[chad]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Thu, Apr 23, 2020 at 4:46 PM Jean-Christophe Helary <
jean.christophe.helary@traduction-libre.org> wrote:

> > On Apr 24, 2020, at 2:07, Stefan Kangas <stefan@marxist.se> wrote:
> > - Misconceptions about how hard it is to work with emacs-devel.
>
> That's something that documentation can fix.
>

 I'm not sure how. I think the widespread conception is that working with
emacs-devel is more difficult than working with many, many other free- and
open-source projects, and I think that conception is correct. Compared to
"fork the project and submit a pull request" or "publish a package on
melpa", following emacs' patch guidelines is harder. Emacs requires
additional paperwork. Updating the documentation (NEWS, Changelog, the info
manuals) is harder and involves tools, tech, and practices that are
unfamiliar to most potential developers. Using debbugs has improved a lot
in the past few years, but is still a pain-point for many. Following the
emacs-devel mailing list is, let's say, not a welcoming experience for
everyone. That doesn't even touch on the difficulties of interacting with
the core.

I think that the end result of emacs' processes is high-quality code that
runs on many more systems than the vast majority of software, but I don't
think most new developers are shying away from working on emacs because of
the lack or quality of the documentation.

~Chad

[-- Attachment #2: Type: text/html, Size: 1902 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 24, 2020, at 9:51, chad <yandros@gmail.com> wrote:
> 
> 
> On Thu, Apr 23, 2020 at 4:46 PM Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> > On Apr 24, 2020, at 2:07, Stefan Kangas <stefan@marxist.se> wrote:
> > - Misconceptions about how hard it is to work with emacs-devel.
> 
> That's something that documentation can fix.
> 
>  I'm not sure how. I think the widespread conception is that working with emacs-devel is more difficult than working with many, many other free- and open-source projects, and I think that conception is correct.

That depends on where you come from. A lot of people have not been contaminated by the entitlement that comes with the "I'm sending a PR, please check it in" generated by the Github culture. I'm not saying that PRs are bad, just that a lot of people think that whatever they do is OK.

Documenting means stating that Emacs is not just another "open source project you can contribute to in the weekends" (although that's also possible). It is Free Software and it is robust and it is here to last. All that comes with requirements and that's fair.

> Compared to "fork the project and submit a pull request" or "publish a package on melpa", following emacs' patch guidelines is harder.

Please. As a totally non-developer I was able, with the guidance of a lot of people here, to follow the rules and get some code in the emacs core code and in package.el. Yes, it is harder because the requirements are different.

> Emacs requires additional paperwork.

I proposed a solution in my suggestions.

> Updating the documentation (NEWS, Changelog, the info manuals) is harder and involves tools, tech, and practices that are unfamiliar to most potential developers.

And if they can learn emacs-lisp enough to contribute something, they can certainly learn a few extra things.

> Using debbugs has improved a lot in the past few years, but is still a pain-point for many. Following the emacs-devel mailing list is, let's say, not a welcoming experience for everyone.

It is an *always* enriching experience.

> That doesn't even touch on the difficulties of interacting with the core.
> 
> I think that the end result of emacs' processes is high-quality code that runs on many more systems than the vast majority of software, but I don't think most new developers are shying away from working on emacs because of the lack or quality of the documentation.

Maybe we're not talking about the same thing ?

When I say document the process, I mean putting it in nice colors on the web site, so as to ease the pain for people who are used to nice colors on web sites but who can still go deeper and commit themselves to serious code.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 24 Apr 2020 08:45:43 +0900
> 
> > - An unwillingness to assign copyright to the FSF, seemingly often more due to
> >  inertia than any principled opposition.
> 
> It has been mentioned a number of times already.
> 
> I think that the process could be streamlined (and there is a need to check that with the legal team I guess).
> 
> For one, the actually *submission* of the copyright assignment to the FSF could me made to be as easy as a simple code commit, signed with something like a gpg key or something.

Commit to what repository?

> Once the developer has simply "pushed that button," the contribution should be considered valid, and then eventually the developer receives a PDF signed by the FSF to confirm the assignment.

The assignment form requires one to file a couple of personal details
that are unlikely to be possible to be gleaned from a commit.  In some
situations, the assignment needs a disclaimer from the person's
employer to go with it, something that again is unlikely to be
triggered by any commit anywhere.

I believe these aspects of the copyright assignment process are the
ones that require a separate communication between humans.  Of course,
if it can somehow be simplified, I'm all for it.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:


> The reasons why package authors would not want to include it, on the other hand,
> could obviously vary.  Some of the reasons I have seen are
> unfortunately very shallow:
>
> (1) - Misconceptions about how hard it is to work with emacs-devel.
> (2) - An unwillingness to assign copyright to the FSF, seemingly often more due to
>       inertia than any principled opposition.
> (3) - Strongly ideological anti-FSF sentiments (often disguised as "non-ideological"
>       or "practical").
>
> I mean, that's my impression of it, and I'm not pretending that this list is
> exhaustive or even generally correct.

With Emacs, my experience has been that (1) and (2) are the most common
reasons, with (1) being slightly more common.  I don't believe I've seen
anyone refuse to assign copyright to the FSF over (3) for Emacs packages
in a long time.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Stefan Kangas <stefan@marxist.se> writes:

> - An unwillingness to assign copyright to the FSF, seemingly often more due to
>   inertia than any principled opposition.

Here's a first proposal to improve the situation: including the "Why
Assign?" text in the manual.  Yes, the manual will be longer, but if
even one more person will read and understand the reasons behind the
FSF's insistence on assignments, I think it will be worth it.  Please
see the attached.

Best regards,
Stefan Kangas

[-- Attachment #2: copyright.diff --]
[-- Type: application/octet-stream, Size: 1915 bytes --]

diff --git a/doc/emacs/trouble.texi b/doc/emacs/trouble.texi
index 33f67f2b44..04bb1bb021 100644
--- a/doc/emacs/trouble.texi
+++ b/doc/emacs/trouble.texi
@@ -1443,8 +1443,32 @@ Copyright Assignment
 
 Generally speaking, for non-trivial contributions to GNU Emacs and
 packages stored in GNU ELPA, we require that the copyright be assigned
-to the FSF@.  For the reasons behind this, see
-@url{https://www.gnu.org/licenses/why-assign.html}.
+to the FSF@.  Professor Eben Moglen, Columbia University Law School,
+has explained the reasons why:
+
+@quotation
+Under US copyright law, which is the law under which most free
+software programs have historically been first published, there are
+very substantial procedural advantages to registration of
+copyright.  And despite the broad right of distribution conveyed by
+the GPL, enforcement of copyright is generally not possible for
+distributors: only the copyright holder or someone having assignment
+of the copyright can enforce the license.  If there are multiple
+authors of a copyrighted work, successful enforcement depends on
+having the cooperation of all authors.
+
+In order to make sure that all of our copyrights can meet the
+recordkeeping and other requirements of registration, and in order to
+be able to enforce the GPL most effectively, FSF requires that each
+author of code incorporated in FSF projects provide a copyright
+assignment, and, where appropriate, a disclaimer of any work-for-hire
+ownership claims by the programmer's employer.  That way we can be sure
+that all the code in FSF projects is free code, whose freedom we can
+most effectively protect, and therefore on which other developers can
+completely rely.
+
+From: @url{https://www.gnu.org/licenses/why-assign.html}
+@end quotation
 
 Copyright assignment is a simple process.  Residents of some countries
 can do it entirely electronically.  We can help you get started,

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 26, 2020, at 0:31, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
>> - An unwillingness to assign copyright to the FSF, seemingly often more due to
>>  inertia than any principled opposition.
> 
> Here's a first proposal to improve the situation: including the "Why
> Assign?" text in the manual.  Yes, the manual will be longer, but if
> even one more person will read and understand the reasons behind the
> FSF's insistence on assignments, I think it will be worth it.  Please
> see the attached.
> 
> Best regards,
> Stefan Kangas
> <copyright.diff>

"each author ... provide+s" ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Stephen Berman]

On Sun, 26 Apr 2020 20:57:17 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:

>> On Apr 26, 2020, at 0:31, Stefan Kangas <stefan@marxist.se> wrote:
>>
>> Stefan Kangas <stefan@marxist.se> writes:
>>
>>> - An unwillingness to assign copyright to the FSF, seemingly often more due to
>>>  inertia than any principled opposition.
>>
>> Here's a first proposal to improve the situation: including the "Why
>> Assign?" text in the manual.  Yes, the manual will be longer, but if
>> even one more person will read and understand the reasons behind the
>> FSF's insistence on assignments, I think it will be worth it.  Please
>> see the attached.
>>
>> Best regards,
>> Stefan Kangas
>> <copyright.diff>
>
> "each author ... provide+s" ?

In this context ("FSF requires that each author of code incorporated in
FSF projects provide a copyright assignment") "provide" is correct (here
corresponding to the subjunctive in French), especially in formal
registers of English, though many people don't use this in everyday
speaking or writing.

Steve Berman

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 26, 2020, at 21:17, Stephen Berman <stephen.berman@gmx.net> wrote:
> 
> On Sun, 26 Apr 2020 20:57:17 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
>>> On Apr 26, 2020, at 0:31, Stefan Kangas <stefan@marxist.se> wrote:
>>> 
>>> Stefan Kangas <stefan@marxist.se> writes:
>>> 
>>>> - An unwillingness to assign copyright to the FSF, seemingly often more due to
>>>> inertia than any principled opposition.
>>> 
>>> Here's a first proposal to improve the situation: including the "Why
>>> Assign?" text in the manual.  Yes, the manual will be longer, but if
>>> even one more person will read and understand the reasons behind the
>>> FSF's insistence on assignments, I think it will be worth it.  Please
>>> see the attached.
>>> 
>>> Best regards,
>>> Stefan Kangas
>>> <copyright.diff>
>> 
>> "each author ... provide+s" ?
> 
> In this context ("FSF requires that each author of code incorporated in
> FSF projects provide a copyright assignment") "provide" is correct (here
> corresponding to the subjunctive in French), especially in formal
> registers of English, though many people don't use this in everyday
> speaking or writing.

Thank you for the reminder !!! Last time I had formal English teaching was 35 years ago... :(


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Thu, 2020-04-23 at 19:07 +0200, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> The reasons why package authors would not want to include it, on the
> other hand,
> could obviously vary.  Some of the reasons I have seen are
> unfortunately very shallow:
>
> - Misconceptions about how hard it is to work with emacs-devel.

Hello! As someone who does not contribute to Emacs for the sole reason
it is *way* harder than in any other project I'm aware of (although
well in line with other GNU projects, but even among them Emacs takes
the lead) I want to emphasize this is not a "shallow reason".

It all comes down to Emacs development not being automated. Which puts
down too much strain on contributors (not mentioning Emacs maintainers
here, because last time this discussion happened (1.5 year ago I
think), Eli ensured me that they are okay. Fair enough: I'm not a Emacs
maintainer, not gonna speak for them).

1. There are many wrong ways to send a patch; and the correct one is
the most non-obvious. Most popular mistakes I think come down to copy-
pasting the patch into email client. Most modern email clients require
lots of tinkering before they work fine with plain text, otherwise
they'll screw patch up in various ways (breaking lines, replacing
whitespace, removing whitespace, you name it).
   Okay, so usually email-based projects recommend using git-send-
email. Recently I sent a patch like this¹ and got a complaint it
doesn't look like what git-format-patch would produce (is that maybe a
hint maintainers are being strained too?). Huh, wrong way again? I'll
give you some examples so you'd see the format looks exactly what other
email-based project use/used: one from Mesa project² (well, before they
moved over to Gitlab-based development) and another one from kernel³.
   What's the correct way? Well, apparently it is either to combine in
some way git-send-email and git-format-patch, or it is to attach a
patch to email. "To attach", who would've thought? Attaching patches
is frowned upon in all other email-based projects because it is hard
to review it, Idk why Emacs even allows that…
   Okay, let's get back to all those "great packages not included in
Emacs": YOU CAN NOT SEND THEM PATCH WRONG. Sorry for caps, I want to
make sure it is visible: there is no way I'll send a patch, say, to
company-mode, and will get a reply "Dude, your patch does not apply
here"! They use either (open-source btw) Gitlab or (proprietary)
Github. You can use command line or web-browser to send patches —
either way, it all becomes a thing called merge/pull request, and
making sure it is correct is all automated. Zero efforts from package
maintainers or contributors.

2. Unusual requirements from commit messages: no other projects require
writing down a list of functions I changed just for the fun of it. This
is what there diff is for! Let me guess where the requirement came
from: I remember seeing that Emacs maintainers accept even patches
with a bunch of unrelated changes, like 1.
renaming a variable, 2. refactoring a code, 3. adding a new feature. No
serious project would accept such patches, but apparently Emacs decided
to hack that around, and are instead requiring that people write
down each function name and its change in commit message.
   Okay, you want this — but could you at least automate it!
And no, some Emacs function does not cut it, people not necessarily use
git from Emacs. I
personally don't. Please, use git hoooks, because this is what everyone
is *forced* to use, you can't possibly miss a git hook. And please,
make sure that when people do git-commit-amend, the function names are
updated accordingly.
   Full automation, to make sure this unusual unique requirement of
Emacs development stays as unobtrusive as possible.

3. FSF assignment: yeah, it is easy to get. But as a package
maintainer, would I want more contributions or only having code from
elite members of FSF? I'd go for the former. If some package user found
some corner case in a function in my package and wants to contribute it
now, and I stop them "go assign some copyright and don't appear at my
project without that", this is a punch into motivation. They may do it
or not, it depends.

4. Patches are discussed on a bugtracker. Good news: contributors
probably won't care. Bad news: as a package maintainer I'd not want to
give up my abilities to 1. Close outdated discussions 2. See the diff
between current and previous patchset version 3. Immediately see which
patchset is the current version. 4. Automatically run CI on the new
uploaded version of the patchset. 5. Immediately merge the patchset
once I'm fine with the changes.

5. As a contributor, when I stumble upon a bug I could fix in
software, first thing I usually do is go check it is not fixed in
latest code and that there's no pending merge/pull requests that seem
to fix that same thing. So, for example, I want to see pending
patchsets to python-mode, can I do that with Emacs
"bug-patch-tracker"? No, with debbugs.gnu.org you can either find
pending patchsets, or you can make a text search, but over everything:
bugs, patchsets, closed or not…

P.S.: I have a feeling, people on Emacs-devel don't consider these to
be anything but nuance. Well, I've got FSF assignment for contributing
to Emacs, and since then I have many times stumbled upon things I
could try to improve. But every time it happens, I remember how hard
it is to contribute here, and dismiss myself with "no, not worth
it". The patch from two weeks ago¹ was the exception just because when
I stumbled upon that problem, I immediately figured it is likely a
one-liner fix.

As it currently stands, I'd strongly recommend against moving packages
from gitlab/github to Emacs upstream.

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41684
2:
https://lists.freedesktop.org/archives/mesa-dev/2018-December/210803.html
3: https://lists.gt.net/linux/kernel/3588040

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sat, 13 Jun 2020 14:59:21 +0300
> 
>    Okay, so usually email-based projects recommend using git-send-
> email. Recently I sent a patch like this¹ and got a complaint it
> doesn't look like what git-format-patch would produce (is that maybe a
> hint maintainers are being strained too?). Huh, wrong way again?

FTR: that wasn't a complaint, it was a gentle request for the future.
Your patch was committed, before I sent that request, even though
committing it required some extra manual work on my part.

We recommend using git-format-patch because it makes applying the
patch easier and less error prone.  It never occurred to me that a
routine recommendation would be interpreted as a "complaint", let
alone trigger a 950-word rant.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 15:50 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Date: Sat, 13 Jun 2020 14:59:21 +0300
> >
> >    Okay, so usually email-based projects recommend using git-send-
> > email. Recently I sent a patch like this¹ and got a complaint it
> > doesn't look like what git-format-patch would produce (is that
> > maybe a
> > hint maintainers are being strained too?). Huh, wrong way again?
>
> FTR: that wasn't a complaint, it was a gentle request for the future.
> Your patch was committed, before I sent that request, even though
> committing it required some extra manual work on my part.
>
> We recommend using git-format-patch because it makes applying the
> patch easier and less error prone.  It never occurred to me that a
> routine recommendation would be interpreted as a "complaint", let
> alone trigger a 950-word rant.

That "rant" is for a reason though? I love Emacs, and it hurts me to
see human resources are being spent in places that other projects
trivially avoid. If you multiply that effort by number of contributors
that made similar mistake and maintainers that wrote to them about it,
I think it would've resulted in time that could've been spent to do
something much more useful.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Alan Third]

On Sat, Jun 13, 2020 at 03:50:05PM +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Date: Sat, 13 Jun 2020 14:59:21 +0300
> > 
> >    Okay, so usually email-based projects recommend using git-send-
> > email. Recently I sent a patch like this¹ and got a complaint it
> > doesn't look like what git-format-patch would produce (is that maybe a
> > hint maintainers are being strained too?). Huh, wrong way again?
> 
> FTR: that wasn't a complaint, it was a gentle request for the future.
> Your patch was committed, before I sent that request, even though
> committing it required some extra manual work on my part.
> 
> We recommend using git-format-patch because it makes applying the
> patch easier and less error prone.  It never occurred to me that a
> routine recommendation would be interpreted as a "complaint", let
> alone trigger a 950-word rant.

I could be wrong but to me that patch looks fine and applies here
without modification.

The only possibly unusual step I took was to save the complete email
to a file, then I applied it using git as normal.

Am I missing something here?
-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Sat, 13 Jun 2020 16:16:55 +0200 (CEST)
> From: Alan Third <alan@idiocy.org>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, stefan@marxist.se,
> 	emacs-devel@gnu.org
> X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED,BAYES_00 device=10.2.0.20
> 
> I could be wrong but to me that patch looks fine and applies here
> without modification.
> 
> The only possibly unusual step I took was to save the complete email
> to a file, then I applied it using git as normal.
> 
> Am I missing something here?

I don't know.  What did you mean by "apply"?

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Alan Third]

On Sat, Jun 13, 2020 at 05:19:09PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 13 Jun 2020 16:16:55 +0200 (CEST)
> > From: Alan Third <alan@idiocy.org>
> > Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, stefan@marxist.se,
> > 	emacs-devel@gnu.org
> > X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED,BAYES_00 device=10.2.0.20
> > 
> > I could be wrong but to me that patch looks fine and applies here
> > without modification.
> > 
> > The only possibly unusual step I took was to save the complete email
> > to a file, then I applied it using git as normal.
> > 
> > Am I missing something here?
> 
> I don't know.  What did you mean by "apply"?

git am ~/Downloads/bug_41684_message_5.mbox

-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Sat, 13 Jun 2020 16:23:31 +0200 (CEST)
> From: Alan Third <alan@idiocy.org>
> Cc: hi-angel@yandex.ru, stefan@marxist.se, emacs-devel@gnu.org
> 
> > > Am I missing something here?
> > 
> > I don't know.  What did you mean by "apply"?
> 
> git am ~/Downloads/bug_41684_message_5.mbox

I didn't have an mbox file, I only had an email message which was not
in git-format-patch format, and whose commit log message needed some
work.

Anyway, I will gladly delegate the job of pushing these forgotten
patches to someone else, if they volunteer (or just do it even without
volunteering).  I only pushed this because no one else did, for more
than a week.  I thought I was doing okay by following up on those
patches.  Or am I missing something?

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 17:33 +0300, Eli Zaretskii wrote:
> > Date: Sat, 13 Jun 2020 16:23:31 +0200 (CEST)
> > From: Alan Third <alan@idiocy.org>
> > Cc: hi-angel@yandex.ru, stefan@marxist.se, emacs-devel@gnu.org
> >
> > > > Am I missing something here?
> > >
> > > I don't know.  What did you mean by "apply"?
> >
> > git am ~/Downloads/bug_41684_message_5.mbox
>
> I didn't have an mbox file, I only had an email message which was not
> in git-format-patch format, and whose commit log message needed some
> work.
>
> Anyway, I will gladly delegate the job of pushing these forgotten
> patches to someone else, if they volunteer (or just do it even without
> volunteering).  I only pushed this because no one else did, for more
> than a week.  I thought I was doing okay by following up on those
> patches.  Or am I missing something?

FTR, I'm really thankful to you for taking a look at the patch, as well as to all
other wonderful people here for maintaining Emacs. My text was just addressing
weak points of current development approach and is an answer to the question "why
don't people upstream their packages to Emacs". There's not much more to this
email, and the patch discussion only really mentioned in the first point by
virtue of being an illustration at hand.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Alan Third]

On Sat, Jun 13, 2020 at 05:33:40PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 13 Jun 2020 16:23:31 +0200 (CEST)
> > From: Alan Third <alan@idiocy.org>
> > Cc: hi-angel@yandex.ru, stefan@marxist.se, emacs-devel@gnu.org
> > 
> > > > Am I missing something here?
> > > 
> > > I don't know.  What did you mean by "apply"?
> > 
> > git am ~/Downloads/bug_41684_message_5.mbox
> 
> I didn't have an mbox file, I only had an email message which was not
> in git-format-patch format, and whose commit log message needed some
> work.
> 
> Anyway, I will gladly delegate the job of pushing these forgotten
> patches to someone else, if they volunteer (or just do it even without
> volunteering).  I only pushed this because no one else did, for more
> than a week.  I thought I was doing okay by following up on those
> patches.  Or am I missing something?

No, I didn't intend to attack you, I was just curious because I would
have thought it should be easy for Emacs to take the email
(git-format-patch format is a plain email, as is the mbox format) and
pipe it straight into git am.

-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Sat, 13 Jun 2020 17:02:33 +0200 (CEST)
> From: Alan Third <alan@idiocy.org>
> Cc: hi-angel@yandex.ru, stefan@marxist.se, emacs-devel@gnu.org
> 
> No, I didn't intend to attack you, I was just curious because I would
> have thought it should be easy for Emacs to take the email
> (git-format-patch format is a plain email, as is the mbox format) and
> pipe it straight into git am.

Of course, that's what I usually do.  But when the email has only a
patch, not a result of git-format-patch, I don't want to try, because
some irregularity of the format could fail the patch and/or the
following commit, and I would then need to recover, fix the patch or
apply it manually, etc.  So I use "git apply" in those cases instead.
Which needs a separate commit step, including specifying the right
author and date.

And the commit log message needs a manual fix in any case.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Andreas Schwab]

On Jun 13 2020, Eli Zaretskii wrote:

>> Date: Sat, 13 Jun 2020 16:23:31 +0200 (CEST)
>> From: Alan Third <alan@idiocy.org>
>> Cc: hi-angel@yandex.ru, stefan@marxist.se, emacs-devel@gnu.org
>> 
>> > > Am I missing something here?
>> > 
>> > I don't know.  What did you mean by "apply"?
>> 
>> git am ~/Downloads/bug_41684_message_5.mbox
>
> I didn't have an mbox file, I only had an email message which was not
> in git-format-patch format, and whose commit log message needed some
> work.

You don't need a file, just pipe it to git am.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Alan Third <alan@idiocy.org>,  emacs-devel@gnu.org,  stefan@marxist.se,
>   hi-angel@yandex.ru
> Date: Sat, 13 Jun 2020 17:05:51 +0200
> 
> >> git am ~/Downloads/bug_41684_message_5.mbox
> >
> > I didn't have an mbox file, I only had an email message which was not
> > in git-format-patch format, and whose commit log message needed some
> > work.
> 
> You don't need a file, just pipe it to git am.

That's what I do, always had.  But I don't even want to try when the
mail message was not formatted with git-format-patch.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Andreas Schwab]

On Jun 13 2020, Eli Zaretskii wrote:

> mail message was not formatted with git-format-patch.

Yes, it was.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

git-send-email (was: Why are so many great packages not trying to get included in GNU Emacs?)

[Kévin Le Gouguec]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Jun 13 2020, Eli Zaretskii wrote:
>
>> mail message was not formatted with git-format-patch.
>
> Yes, it was.

In case that clears up some confusion:

As Konstantin said, the patch[1] was sent with git send-email, which
allows the sender to "annotate" the patch with some text that will be
ignored by git am (IIUC merely by virtue of being stuck between "---\n"
and the actual diff).

In Gnus, piping the whole mail to "cd path/to/emacs && git am" (hitting
"|" in the summary buffer) mostly does TRT: the patch is applied, with
the email's subject as commit summary, and the rest of the message (up
to "---\n") completing the commit message.

The only issue, AFAICT, is that git am fails to strip away the [PATCH]
prefix; IUUC this is because it does not expect debbugs's own "bug#NNN"
prefix.


Feel free to dismiss this as armchair commentary, but I think that we're
likely to see more and more patches sent with git send-email[2], since
it is heavily promoted by other projects privileging mail-based
workflows[3].


[1] <20200603115103.69611-1-Hi-Angel@yandex.ru>
    https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-06/msg00128.html

[2] See e.g. Jonas's patch series back in May:
    <87sgg26zpv.fsf@bernoul.li>
    https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-05/msg00853.html

[3] Sourcehut developers, in particular, have spent a fair amount of
    virtual ink describing how to use it:

    https://drewdevault.com/2018/07/02/Email-driven-git.html    
    https://man.sr.ht/git.sr.ht/send-email.md

    They have even set up a dummy repository for would-be contributors
    to try it out:

    https://git-send-email.io/
    https://lists.sr.ht/~sircmpwn/email-test-drive/

Re: git-send-email (was: Why are so many great packages not trying to get included in GNU Emacs?)

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  alan@idiocy.org,  hi-angel@yandex.ru,
>   stefan@marxist.se,  emacs-devel@gnu.org
> Date: Mon, 15 Jun 2020 00:11:38 +0200
> 
> As Konstantin said, the patch[1] was sent with git send-email, which
> allows the sender to "annotate" the patch with some text that will be
> ignored by git am (IIUC merely by virtue of being stuck between "---\n"
> and the actual diff).
> 
> In Gnus, piping the whole mail to "cd path/to/emacs && git am" (hitting
> "|" in the summary buffer) mostly does TRT: the patch is applied, with
> the email's subject as commit summary, and the rest of the message (up
> to "---\n") completing the commit message.
> 
> The only issue, AFAICT, is that git am fails to strip away the [PATCH]
> prefix; IUUC this is because it does not expect debbugs's own "bug#NNN"
> prefix.
> 
> 
> Feel free to dismiss this as armchair commentary, but I think that we're
> likely to see more and more patches sent with git send-email[2], since
> it is heavily promoted by other projects privileging mail-based
> workflows[3].

We accept and welcome patches in any form and shape.  However, we
recommend to use "git format-patch" (see CONTRIBUTE), and for a good
reason: doing so leaves no doubt regarding the authorship of the
changes.  Whereas just sending email could dupe us in attributing the
change to a different person, something that we try to avoid.  Of
course, with enough manual work and using various Git optional
switches, any problem can be worked around, for the price of more time
invested.

This is why I generally comment on patches sent in forms other than
what is described in CONTRIBUTE.  Eventually, that is our main
contribution document, and we should either stick to what it says or
change the document.

Re: git-send-email

[Andreas Schwab]

On Jun 15 2020, Eli Zaretskii wrote:

> We accept and welcome patches in any form and shape.  However, we
> recommend to use "git format-patch" (see CONTRIBUTE),

Which is exactly what he did.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: git-send-email

[Eli Zaretskii]

On June 15, 2020 9:59:59 AM GMT+03:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jun 15 2020, Eli Zaretskii wrote:
> 
> > We accept and welcome patches in any form and shape.  However, we
> > recommend to use "git format-patch" (see CONTRIBUTE),
> 
> Which is exactly what he did.

No, he did not.  He said that much: he used "git send-email".

You are hinting that "git send-email" runs format-patch internally, for some variants of its command-line arguments.  But that is not what CONTRIBUTE says about using "git send-email", and for a good reason: doing it the CONTRIBUTE way produces email messages that are easily recognizable as being fit for "git am", and don't require tedious and error-prone manual analysis to make sure it is not just diffs pasted into the email body.

We can discuss changes to CONTRIBUTE, but as long as it says something, let's try to act as it says.  We usually have good reasons for what it says.

Re: git-send-email

[Andreas Schwab]

On Jun 15 2020, Eli Zaretskii wrote:

> On June 15, 2020 9:59:59 AM GMT+03:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Jun 15 2020, Eli Zaretskii wrote:
>> 
>> > We accept and welcome patches in any form and shape.  However, we
>> > recommend to use "git format-patch" (see CONTRIBUTE),
>> 
>> Which is exactly what he did.
>
> No, he did not.  He said that much: he used "git send-email".

Exactly, thus git format-patch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: git-send-email

[Alfred M. Szmidt]

   >> > We accept and welcome patches in any form and shape.  However, we
   >> > recommend to use "git format-patch" (see CONTRIBUTE),
   >> 
   >> Which is exactly what he did.
   >
   > No, he did not.  He said that much: he used "git send-email".

   Exactly, thus git format-patch.

No, git send-mail accepts multiple inputs -- and it is not guaranteed
that the input is from format-patch in any shape or form.  From the
man page:

       There are two formats accepted for patch files:

        1. mbox format files

           This is what git-format-patch(1) generates. Most headers and MIME
           formatting are ignored.

        2. The original format used by Greg Kroah-Hartman's
           send_lots_of_email.pl script

           This format expects the first line of the file to contain the "Cc:"
           value and the "Subject:" of the message as the second line.

Re: git-send-email

[Andreas Schwab]

On Jun 15 2020, Alfred M. Szmidt wrote:

>    >> > We accept and welcome patches in any form and shape.  However, we
>    >> > recommend to use "git format-patch" (see CONTRIBUTE),
>    >> 
>    >> Which is exactly what he did.
>    >
>    > No, he did not.  He said that much: he used "git send-email".
>
>    Exactly, thus git format-patch.
>
> No, git send-mail accepts multiple inputs

There is no input.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: git-send-email

[Alfred M. Szmidt]

Computers do not work by osmosis; there is always input.  The input
here is either files, directories, or a rev-list.  The files and
directories can contain either git-am output, or GRH's format.  

	NAME
	       git-send-email - Send a collection of patches as emails
	
	SYNOPSIS
	       git send-email [<options>] <file|directory|rev-list options>...
	       git send-email --dump-aliases
	
	DESCRIPTION
	       Takes the patches given on the command line and emails them out.
	       Patches can be specified as files, directories (which will send all
	       files in the directory), or directly as a revision list. In the last
	       case, any format accepted by git-format-patch(1) can be passed to git
	       send-email.
	
	       The header of the email is configurable via command-line options. If
	       not specified on the command line, the user will be prompted with a
	       ReadLine enabled interface to provide the necessary information.

Re: git-send-email

[Andreas Schwab]

On Jun 15 2020, Alfred M. Szmidt wrote:

> Computers do not work by osmosis; there is always input.  The input
> here is either files, directories, or a rev-list.

Read on.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: git-send-email

[Alfred M. Szmidt]

You clearly seem to know what to "read on" -- I do not since you did
not say, so instead of a nonsensical comment you could explain where
the error is.

Re: git-send-email

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> We accept and welcome patches in any form and shape.  However, we
> recommend to use "git format-patch" (see CONTRIBUTE), and for a good
> reason: doing so leaves no doubt regarding the authorship of the
> changes.  Whereas just sending email could dupe us in attributing the
> change to a different person, something that we try to avoid.

AFAIU, git send-email literally just runs format-patch, and sends the
result (with said optional annotation) over SMTP.  I'm not sure what
difference this makes as far as authorship authenticity is concerned?
The From field used by git send-email is literally the From field set by
git format-patch.

Really, the only differences that I can see between format-patch and
send-email are

- for contributors, no need to whip out a mail client and fiddle with
  attachments,

- for maintainers, no need to scan the mail for attachments; just pipe
  the mail itself to git am.

Apologies if I'm missing anything.

Re: git-send-email

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: stefan@marxist.se,  alan@idiocy.org,  emacs-devel@gnu.org,
>   schwab@linux-m68k.org,  hi-angel@yandex.ru
> Date: Mon, 15 Jun 2020 10:23:16 +0200
> 
> AFAIU, git send-email literally just runs format-patch, and sends the
> result (with said optional annotation) over SMTP.  I'm not sure what
> difference this makes as far as authorship authenticity is concerned?
> The From field used by git send-email is literally the From field set by
> git format-patch.
> 
> Really, the only differences that I can see between format-patch and
> send-email are
> 
> - for contributors, no need to whip out a mail client and fiddle with
>   attachments,
> 
> - for maintainers, no need to scan the mail for attachments; just pipe
>   the mail itself to git am.

You need to look at this from the right vantage point: the POV of me
(or someone else) who needs to install changes in such an email.  I'm
on the receiving end of the email, so I have no idea what command(s)
were used to create and send it.  All I see is a random email message,
not unlike many others, just with diffs in its body.  You suggest to
pipe it into Git, but how do I know it's in a proper format to be
processed correctly by Git?  There's no clue.  I need to read the
relevant parts of the email to verify:

 . that the Subject line is appropriate for the heading of the commit
   log message
 . that the From header names the author, and was not rewritten in
   transit by some mailing-list software or another MTA
 . that the Date makes sense
 . that the diffs weren't wrapped by whatever MUA was used
 . that the diffs and the body are properly encoded

And even after all that, I can never be sure that Git will process the
patch, because my decision that the format is proper is just a guess.
Any single problem I missed, and I get to recover with "am --abort",
clean up my repository, find out what was wrong, etc.

All of this wastes time and energy, which adds up when you need to
process more than just a couple of submissions.

By contrast, when the changes are formatted by "git format-patch" and
included in the body, preferably as an attachment, the patch has a
clear-cut signature, it has its own "From" header that identifies the
author independently of the address from which the email was sent, it
has the commit date independent of the mailing timestamp, and I can
trust its encoding.  In this case, I just pipe into "git am" without
much effort.

Do you see now why we prefer the latter?  And it isn't like Emacs is
the only project; many GNU projects also prefer to have patches
submitted in this format.

Re: git-send-email

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> You need to look at this from the right vantage point: the POV of me
> (or someone else) who needs to install changes in such an email.  I'm
> on the receiving end of the email, so I have no idea what command(s)
> were used to create and send it.  All I see is a random email message,
> not unlike many others, just with diffs in its body.  You suggest to
> pipe it into Git, but how do I know it's in a proper format to be
> processed correctly by Git?  There's no clue.

Thank you for taking the time to spell out how messages produced by
git-send-email can be challenging to distinguish from handcrafted
submissions.

Indeed, I agree that it's not uncommon for contributors to send emails
with "[PATCH]" in the subject and the diff appended at the end; it would
be unreasonable to ask maintainers to be able to guess how the message
was produced just by eyeballing it.

Likewise, it would be unreasonable to ask maintainers to pipe random
messages to git-am to find out if they have been produced by
git-send-email; when I said:

> - for maintainers, no need to scan the mail for attachments; just pipe
>   the mail itself to git am.

I really meant "*when maintainers know the mail has been produced by
git-send-email*, there is no need to scan it for attachments; just pipe
it straight to git-am".

FWIW, git-send-email adds a pretty explicit header[1] to inform
recipients of how the message was produced.

> Do you see now why we prefer the latter?  And it isn't like Emacs is
> the only project; many GNU projects also prefer to have patches
> submitted in this format.

I'm certainly not as well-versed in email mishaps as GNU maintainers, so
I'll trust you when you say that attachments fare better than message
bodies vs. the many transit/encoding problems you've listed.  OTOH I
also see that projects working with git-send-email seem to be none worse
for the wear[2].


[1] X-Mailer: git-send-email [VERSION]

[2] Save for some the occasional "some mail service forbids arbitrary
    header fields" shenanigans:

    https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CCACFas%3DMug5JOOCZJPjucyb+km_21EK2hoxkFCWgLMtu3thztXQ%40mail.gmail.com%3E

Re: git-send-email

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Mon, 15 Jun 2020 17:38:23 +0200
> Cc: schwab@linux-m68k.org, alan@idiocy.org, hi-angel@yandex.ru,
>  stefan@marxist.se, emacs-devel@gnu.org
> 
> FWIW, git-send-email adds a pretty explicit header[1] to inform
> recipients of how the message was produced.

My email setup hides all X-* headers when it displays messages,
because those headers are just noise, and AFAIK are not generally
meant for human consumption.  (There's a command to toggle their
display, but doing that is another nuisance.  Also, a typical message
coming from debbugs has about a dozen X-* headers, so again,
discovering that one header is not easy and calls for careful reading
of boring content, better avoided.)

> OTOH I also see that projects working with git-send-email seem to be
> none worse for the wear[2].

So do we, see CONTRIBUTE.  We just ask that git-send-email be used
after formatting the patch explicitly, so that all its decorations
appear in the email body.  If nothing else, this facilitates including
unrelated discussions with the patch without risking them winding up
in the repository.

Re: git-send-email

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> My email setup hides all X-* headers when it displays messages,
> because those headers are just noise, and AFAIK are not generally
> meant for human consumption.  (There's a command to toggle their
> display, but doing that is another nuisance.  Also, a typical message
> coming from debbugs has about a dozen X-* headers, so again,
> discovering that one header is not easy and calls for careful reading
> of boring content, better avoided.)

Fair enough.  Should the wave of git-send-email contributions turn out
to be unstoppable, at least the existence of this header means it won't
be too hard to write a function to automate this check ;)

>> OTOH I also see that projects working with git-send-email seem to be
>> none worse for the wear[2].
>
> So do we, see CONTRIBUTE.  We just ask that git-send-email be used
> after formatting the patch explicitly, so that all its decorations
> appear in the email body.  If nothing else, this facilitates including
> unrelated discussions with the patch without risking them winding up
> in the repository.

Mmm, now that you mention it, I'm confused.  Here's what we say in
CONTRIBUTE:

> To email a patch you can use a shell command like 'git format-patch -1'
> to create a file, and then attach the file to your email.  This nicely
> packages the patch's commit message and changes.  To send just one
> such patch without additional remarks, you can use a command like
> 'git send-email --to=bug-gnu-emacs@gnu.org 0001-DESCRIPTION.patch'.

I just tried to git-send-email --to=myself a patch file generated from
git-format-patch, and the email I received looks just like what
Konstantin sent to the bug list, i.e.

- the commit's summary line in the Subject field,

- the rest of the commit message at the top of the body,

- some fluff between the "---\n" and "diff --git" lines (a diffstat
  added by git-format-patch; I could have added more comments there,
  like Konstantin did),

- the diff,

- no attachment.

I must be missing something.  How do our instructions differ from what
Konstantin did?  Indeed he ran git-send-email without running
git-format-patch first, but AFAICT this additional step does not change
the end result?

Re: git-send-email

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: schwab@linux-m68k.org,  alan@idiocy.org,  hi-angel@yandex.ru,
>   stefan@marxist.se,  emacs-devel@gnu.org
> Date: Mon, 15 Jun 2020 19:59:37 +0200
> 
> > So do we, see CONTRIBUTE.  We just ask that git-send-email be used
> > after formatting the patch explicitly, so that all its decorations
> > appear in the email body.  If nothing else, this facilitates including
> > unrelated discussions with the patch without risking them winding up
> > in the repository.
> 
> Mmm, now that you mention it, I'm confused.  Here's what we say in
> CONTRIBUTE:
> 
> > To email a patch you can use a shell command like 'git format-patch -1'
> > to create a file, and then attach the file to your email.  This nicely
> > packages the patch's commit message and changes.  To send just one
> > such patch without additional remarks, you can use a command like
> > 'git send-email --to=bug-gnu-emacs@gnu.org 0001-DESCRIPTION.patch'.
> 
> I just tried to git-send-email --to=myself a patch file generated from
> git-format-patch, and the email I received looks just like what
> Konstantin sent to the bug list, i.e.

Then maybe we should remove that sentence.

Re: git-send-email

[Paul Eggert]

I mildly prefer patches sent via 'git send-email' to those sent via attachments,
as I can review the patch directly without having to do any extra manipulation
to see it. When I want to feed the patch to git (which is less common than
reviewing it), I can easily save the message into a file and then run 'git am'.

> how do I know it's in a proper format to be
> processed correctly by Git? 

That problem exists independently of whether the message is sent as-is, or is
put into an attachment. That is, "How does one know whether the attachment is in
the proper format?" is no easier to answer than "How does one know the entire
message is in the proper format?".

There are indeed problems with email-sending agents that munge bytes when
sending patches directly. But 'git send-email' is not one of those agents.

Are you using Gnus to process these messages? Perhaps Gnus could be improved to
make this job easier?

Re: git-send-email

[Eli Zaretskii]

> Cc: stefan@marxist.se, alan@idiocy.org, emacs-devel@gnu.org,
>  schwab@linux-m68k.org, hi-angel@yandex.ru
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 15 Jun 2020 11:51:33 -0700
> 
> I mildly prefer patches sent via 'git send-email' to those sent via attachments,
> as I can review the patch directly without having to do any extra manipulation
> to see it.

With Emacs MUAs I'm familiar with, looking at an attachment is very
easy, almost like looking at the body.  I don't have any problems with
that.

> > how do I know it's in a proper format to be
> > processed correctly by Git? 
> 
> That problem exists independently of whether the message is sent as-is, or is
> put into an attachment.

Not if the body/attachment was formatted by "git format-patch".  Then
the patches have a telltale format and signature that identify the
format unequivocally.

> Are you using Gnus to process these messages?

No.

Re: git-send-email

[Paul Eggert]

On 6/15/20 11:59 AM, Eli Zaretskii wrote:

> With Emacs MUAs I'm familiar with, looking at an attachment is very
> easy, almost like looking at the body.  I don't have any problems with
> that.

Yes, I can also look at an attachment reasonably easily (I'm using Thunderbird
FWIW). Still, it's a bit easier to see email without the attachment. This is
pretty typical among MUAs I've used.

>>> how do I know it's in a proper format to be
>>> processed correctly by Git? 
>>
>> That problem exists independently of whether the message is sent as-is, or is
>> put into an attachment.
> 
> Not if the body/attachment was formatted by "git format-patch".  Then
> the patches have a telltale format and signature that identify the
> format unequivocally.

Yes. Hmm, but I thought that this was the case we were talking about.

Is the problem that people are using 'git send-email' to send patches that were
not formatted via 'git format-patch'? That would indeed be problematic, and if
necessary we can add text to CONTRIBUTE to discourage that.

Re: git-send-email

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> Mmm, now that you mention it, I'm confused.  Here's what we say in
>> CONTRIBUTE:
>> 
>> > To email a patch you can use a shell command like 'git format-patch -1'
>> > to create a file, and then attach the file to your email.  This nicely
>> > packages the patch's commit message and changes.  To send just one
>> > such patch without additional remarks, you can use a command like
>> > 'git send-email --to=bug-gnu-emacs@gnu.org 0001-DESCRIPTION.patch'.
>> 
>> I just tried to git-send-email --to=myself a patch file generated from
>> git-format-patch, and the email I received looks just like what
>> Konstantin sent to the bug list, i.e.
>
> Then maybe we should remove that sentence.

(Re: 2020-06-20T08:42:41Z!eliz@gnu.org)

Thank you for following up on this.  I'm pretty sure just removing the
sentence about git send-email wouldn't have been enough, as I expect
some people could read "use a shell command like 'git format-patch -1'"
and think "oh well, git send-email will work just as well then".

I think your amendments make things a lot clearer.

FWIW, I just fooled around with rmail and mboxes from Debbugs; adding

- "\|^x-mailer: git-send-email" to rmail-nonignored-headers
- "\|^x-mailer:" to rmail-highlighted-headers

makes it slightly easier to spot patches sent by git send-email AFAICT.
Of course, I'm not an rmail guru; there probably are better ways to
solve the recognizability problem.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 13.06.2020 14:59, Konstantin Kharlamov wrote:
> no other projects require
> writing down a list of functions I changed just for the fun of it

As a reviewer, there's something to be said about having an overview of 
the whole diff (which can get long) in a few paragraphs on top of the 
patch. A good commit message like that actually makes a lot of things 
clear in advance.

But yes, that also compensates for otherwise more difficult review 
process, compared to some automated tools other projects use.

> Okay, you want this — but could you at least automate it!
> And no, some Emacs function does not cut it, people not necessarily use
> git from Emacs. I
> personally don't. Please, use git hoooks, because this is what everyone
> is*forced*  to use, you can't possibly miss a git hook.

Someday(tm) we'll migrate to Gitlab, or Gogs, or whatever, and we'll 
have that.

Regarding hooks, we do use them to an extent, but nobody has written a 
checker for commit messages for them yet. And that still wouldn't cover 
people who make patches against released/packaged versions of Emacs, as 
opposed to the Git tree.

The rest of your email, I pretty much agree with. Except, you know, it's 
still quite possible to contribute (pointing to self).

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 17:35 +0300, Dmitry Gutov wrote:
> On 13.06.2020 14:59, Konstantin Kharlamov wrote:
> > no other projects require
> > writing down a list of functions I changed just for the fun of it
> 
> As a reviewer, there's something to be said about having an overview of 
> the whole diff (which can get long) in a few paragraphs on top of the 
> patch. A good commit message like that actually makes a lot of things 
> clear in advance.

FTR, I am all for having good commit messages. It is IMO a must have for any git
project. But having a list of function names with description for each does not
make one. Instead it should be an overview of what is done, why, and how.

Suppose you have a patch that deduplicates the same code pattern across 34
functions by factoring it out to a single short function. Do you really need
that list? I mean, sure it's a fun fact to know, but you'll have to review diff
anyway. If anything, it only burdens you by forcing to check that each function
is on the list. Commit message should reveal the intention of the changes (and
perhaps, if OP thinks changes may raise questions, they should also write the
reasoning). And then a reviewer gotta check (in particular) this intention
matches the actual code.

On that matter I often love to quote a post from 2009 by Peter Hutterer, a
libinput and Linux HID subsystem maintainer. A post that is old but is not
outdated http://who-t.blogspot.com/2009/12/on-commit-messages.html

> But yes, that also compensates for otherwise more difficult review 
> process, compared to some automated tools other projects use.
> 
> > Okay, you want this — but could you at least automate it!
> > And no, some Emacs function does not cut it, people not necessarily use
> > git from Emacs. I
> > personally don't. Please, use git hoooks, because this is what everyone
> > is*forced*  to use, you can't possibly miss a git hook.
> 
> Someday(tm) we'll migrate to Gitlab, or Gogs, or whatever, and we'll 
> have that.
> 
> Regarding hooks, we do use them to an extent, but nobody has written a 
> checker for commit messages for them yet. And that still wouldn't cover 
> people who make patches against released/packaged versions of Emacs, as 
> opposed to the Git tree.
> 
> The rest of your email, I pretty much agree with. Except, you know, it's 
> still quite possible to contribute (pointing to self).

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Basil L. Contovounesios]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> FTR, I am all for having good commit messages. It is IMO a must have for any git
> project. But having a list of function names with description for each does not
> make one.

FWIW, one great benefit of this list for me is that I can quickly
'git log --grep' for all commits that mention a particular definition.
Doing the same with 'git log -G' is painfully slower and with a far
lower signal:noise ratio.

> Instead it should be an overview of what is done, why, and how.

That, or at the very least linking to the relevant bug/thread
discussions, is always a good thing to do and encouraged.

> Suppose you have a patch that deduplicates the same code pattern across 34
> functions by factoring it out to a single short function. Do you really need
> that list?

No, in such cases there are shortcuts you can take, such as "all callers
changed".

> I mean, sure it's a fun fact to know, but you'll have to review diff
> anyway. If anything, it only burdens you by forcing to check that each function
> is on the list. Commit message should reveal the intention of the changes (and
> perhaps, if OP thinks changes may raise questions, they should also write the
> reasoning). And then a reviewer gotta check (in particular) this intention
> matches the actual code.

I doubt anyone disagrees with that.

-- 
Basil

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 20:31 +0100, Basil L. Contovounesios wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > FTR, I am all for having good commit messages. It is IMO a must have for any
> > git
> > project. But having a list of function names with description for each does
> > not
> > make one.
> 
> FWIW, one great benefit of this list for me is that I can quickly
> 'git log --grep' for all commits that mention a particular definition.
> Doing the same with 'git log -G' is painfully slower and with a far
> lower signal:noise ratio.

You can get that purely with git by using option `-L` of gitlong. It has syntax
`-L :<funcname>:<file>`.

To give you example, I just looked at my recent change in python.el, and the
diff says the region belongs to `python-font-lock-keywords-maximum-decoration`.
So I execute:

	git log -L :python-font-lock-keywords-maximum-
decoration:lisp/progmodes/python.el

And I get a log of commits that changed that function. Git version 2.27.0

> > Instead it should be an overview of what is done, why, and how.
> 
> That, or at the very least linking to the relevant bug/thread
> discussions, is always a good thing to do and encouraged.
> 
> > Suppose you have a patch that deduplicates the same code pattern across 34
> > functions by factoring it out to a single short function. Do you really need
> > that list?
> 
> No, in such cases there are shortcuts you can take, such as "all callers
> changed".

Oh, is that something new? I'm just wondering, why when I did the change to
replace hex regexes with xdigit 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36167 I had to write all hundreds
of functions instead of a one liner "all callers are changed"?

> > I mean, sure it's a fun fact to know, but you'll have to review diff
> > anyway. If anything, it only burdens you by forcing to check that each
> > function
> > is on the list. Commit message should reveal the intention of the changes
> > (and
> > perhaps, if OP thinks changes may raise questions, they should also write
> > the
> > reasoning). And then a reviewer gotta check (in particular) this intention
> > matches the actual code.
> 
> I doubt anyone disagrees with that.
> 

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Basil L. Contovounesios]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sat, 2020-06-13 at 20:31 +0100, Basil L. Contovounesios wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>> 
>> > FTR, I am all for having good commit messages. It is IMO a must have for any
>> > git
>> > project. But having a list of function names with description for each does
>> > not
>> > make one.
>> 
>> FWIW, one great benefit of this list for me is that I can quickly
>> 'git log --grep' for all commits that mention a particular definition.
>> Doing the same with 'git log -G' is painfully slower and with a far
>> lower signal:noise ratio.
>
> You can get that purely with git by using option `-L` of gitlong. It has syntax
> `-L :<funcname>:<file>`.
>
> To give you example, I just looked at my recent change in python.el, and the
> diff says the region belongs to `python-font-lock-keywords-maximum-decoration`.
> So I execute:
>
> 	git log -L :python-font-lock-keywords-maximum-
> decoration:lisp/progmodes/python.el
>
> And I get a log of commits that changed that function. Git version 2.27.0

And what if a commit message references a particular variable or
function without touching the file that they're defined in?  I'm talking
about more general xrefing.

>> > Instead it should be an overview of what is done, why, and how.
>> 
>> That, or at the very least linking to the relevant bug/thread
>> discussions, is always a good thing to do and encouraged.
>> 
>> > Suppose you have a patch that deduplicates the same code pattern across 34
>> > functions by factoring it out to a single short function. Do you really need
>> > that list?
>> 
>> No, in such cases there are shortcuts you can take, such as "all callers
>> changed".
>
> Oh, is that something new?

It's older than I've been around these parts (~2016).

> I'm just wondering, why when I did the change to
> replace hex regexes with xdigit 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36167 I had to write all hundreds
> of functions instead of a one liner "all callers are changed"?

You didn't exactly.  It is possible to take shortcuts depending on the
context.  See the file CONTRIBUTE or (info "(standards) Change Logs")
https://www.gnu.org/prep/standards/html_node/Change-Logs.html.

-- 
Basil

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 21:30 +0100, Basil L. Contovounesios wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sat, 2020-06-13 at 20:31 +0100, Basil L. Contovounesios wrote:
> > > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > > 
> > > > FTR, I am all for having good commit messages. It is IMO a must have for
> > > > any
> > > > git
> > > > project. But having a list of function names with description for each
> > > > does
> > > > not
> > > > make one.
> > > 
> > > FWIW, one great benefit of this list for me is that I can quickly
> > > 'git log --grep' for all commits that mention a particular definition.
> > > Doing the same with 'git log -G' is painfully slower and with a far
> > > lower signal:noise ratio.
> > 
> > You can get that purely with git by using option `-L` of gitlong. It has
> > syntax
> > `-L :<funcname>:<file>`.
> > 
> > To give you example, I just looked at my recent change in python.el, and the
> > diff says the region belongs to `python-font-lock-keywords-maximum-
> > decoration`.
> > So I execute:
> > 
> > 	git log -L :python-font-lock-keywords-maximum-
> > decoration:lisp/progmodes/python.el
> > 
> > And I get a log of commits that changed that function. Git version 2.27.0
> 
> And what if a commit message references a particular variable or
> function without touching the file that they're defined in?  I'm talking
> about more general xrefing.

I feel there's some misunderstanding. The list our discussion is about only
mentions changed functions/variables. If the git message references a variable
that is not changed just because it is important to mention, then, well, it
should still be there, in the commit message. That's what good commit messages
are for: you mention things that are important to mention ¯\_(ツ)_/¯

> > > > Instead it should be an overview of what is done, why, and how.
> > > 
> > > That, or at the very least linking to the relevant bug/thread
> > > discussions, is always a good thing to do and encouraged.
> > > 
> > > > Suppose you have a patch that deduplicates the same code pattern across
> > > > 34
> > > > functions by factoring it out to a single short function. Do you really
> > > > need
> > > > that list?
> > > 
> > > No, in such cases there are shortcuts you can take, such as "all callers
> > > changed".
> > 
> > Oh, is that something new?
> 
> It's older than I've been around these parts (~2016).
> 
> > I'm just wondering, why when I did the change to
> > replace hex regexes with xdigit 
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36167 I had to write all
> > hundreds
> > of functions instead of a one liner "all callers are changed"?
> 
> You didn't exactly.  It is possible to take shortcuts depending on the
> context.  See the file CONTRIBUTE or (info "(standards) Change Logs")
> https://www.gnu.org/prep/standards/html_node/Change-Logs.html.

Oh, okay, so I read the docs, and apparently this "all callers are changed" can
only be used when you use a calling convention. In my imaginary example where
you factored out a code from 34 functions it would not be a calling convention,
it would be a piece of code inside those functions. This is actually similar to
the patch that replaces regexes to "xdigit": you have the same pattern *inside*
many functions that you replace. No calling convention changes.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

Sorry, typos

On Sat, 2020-06-13 at 23:52 +0300, Konstantin Kharlamov wrote:
> I feel there's some misunderstanding. The list our discussion is about only
> mentions changed functions/variables.

*"mentions of changed functions/variables"

> > You didn't exactly.  It is possible to take shortcuts depending on the
> > context.  See the file CONTRIBUTE or (info "(standards) Change Logs")
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html.
> 
> Oh, okay, so I read the docs, and apparently this "all callers are changed"
> can
> only be used when you use a calling convention.

*"change a calling convention", sorry

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Basil L. Contovounesios]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sat, 2020-06-13 at 21:30 +0100, Basil L. Contovounesios wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>> 
>> > You can get that purely with git by using option `-L` of gitlong. It has
>> > syntax
>> > `-L :<funcname>:<file>`.
>> > 
>> > To give you example, I just looked at my recent change in python.el, and the
>> > diff says the region belongs to `python-font-lock-keywords-maximum-
>> > decoration`.
>> > So I execute:
>> > 
>> > 	git log -L :python-font-lock-keywords-maximum-
>> > decoration:lisp/progmodes/python.el
>> > 
>> > And I get a log of commits that changed that function. Git version 2.27.0
>> 
>> And what if a commit message references a particular variable or
>> function without touching the file that they're defined in?  I'm talking
>> about more general xrefing.
>
> I feel there's some misunderstanding. The list our discussion is about only
> mentions changed functions/variables. If the git message references a variable
> that is not changed just because it is important to mention, then, well, it
> should still be there, in the commit message. That's what good commit messages
> are for: you mention things that are important to mention ¯\_(ツ)_/¯

Right, I was confused in my last reply.

>> You didn't exactly.  It is possible to take shortcuts depending on the
>> context.  See the file CONTRIBUTE or (info "(standards) Change Logs")
>> https://www.gnu.org/prep/standards/html_node/Change-Logs.html.
>
> Oh, okay, so I read the docs, and apparently this "all callers are changed" can
> only be used when you use a calling convention. In my imaginary example where
> you factored out a code from 34 functions it would not be a calling convention,
> it would be a piece of code inside those functions. This is actually similar to
> the patch that replaces regexes to "xdigit": you have the same pattern *inside*
> many functions that you replace. No calling convention changes.

It doesn't strictly have to be a change in calling convention, you can
use your better judgement.  E.g. you can list only the affected files,
and either way you only need to mention the same message once for all
affected definitions.

-- 
Basil

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sat, 13 Jun 2020 22:23:30 +0300
> 
> having a list of function names with description for each does not
> make one. Instead it should be an overview of what is done, why, and how.

It should be both, actually.

> Suppose you have a patch that deduplicates the same code pattern across 34
> functions by factoring it out to a single short function. Do you really need
> that list?

No, and no one will ever ask you to describe such mechanistic changes
one by one.

It's all in the GNU Coding Standards, btw.  I suggest to read that.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 13.06.2020 22:23, Konstantin Kharlamov wrote:

> FTR, I am all for having good commit messages. It is IMO a must have for any git
> project. But having a list of function names with description for each does not
> make one. Instead it should be an overview of what is done, why, and how.

Having a standard that increases the likelihood of having such a 
description in the commit message without having to ask the contributor 
twice is not a bad thing.

> Suppose you have a patch that deduplicates the same code pattern across 34
> functions by factoring it out to a single short function. Do you really need
> that list? I mean, sure it's a fun fact to know, but you'll have to review diff
> anyway.

Yes and no. If I get the purpose of the diff, I could scan the contents 
more superficially (depending on what kind of changes are proposed, and 
where).

> If anything, it only burdens you by forcing to check that each function
> is on the list.

I usually don't.

> Commit message should reveal the intention of the changes (and
> perhaps, if OP thinks changes may raise questions, they should also write the
> reasoning).

That, too.

In any case, ChangeLog-style commit messages *are* a barrier for 
contributing, and one could argue that in the end they don't bring 
enough benefit to offset that.

But our experience shows that they do bring a certain benefit.

> On that matter I often love to quote a post from 2009 by Peter Hutterer, a
> libinput and Linux HID subsystem maintainer. A post that is old but is not
> outdated http://who-t.blogspot.com/2009/12/on-commit-messages.html

It's a pretty good guideline. But one that's a bit harder to check and 
enforce.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-14 at 01:09 +0300, Dmitry Gutov wrote:
> On 13.06.2020 22:23, Konstantin Kharlamov wrote:
> 
> > FTR, I am all for having good commit messages. It is IMO a must have for any
> > git
> > project. But having a list of function names with description for each does
> > not
> > make one. Instead it should be an overview of what is done, why, and how.
> 
> Having a standard that increases the likelihood of having such a 
> description in the commit message without having to ask the contributor 
> twice is not a bad thing.

I agree, it is always great to formalize things. Okay, let's test it. Imagine a
contributor who are not aware how to write a good commit message, to see how
that guideline would help.

So, they make a non-trivial functional change ("non-trivial" because here we
don't care of trivials like "rename a thing" or "factor out the code". These can
often be described just in the commit title alone), let's say, they replaced a
"list" container in a few functions to a binary tree for whatever reason. Now
we'd like to know why did that happen.

In my case they clearly would not produce anything useful, they'll maybe write
"replace list to a binary tree" and that's it. Why? Who knows.

How will they behave in your case? Well, they'll collect the functions list,
then would scrupulously write an immensely useful information against each one
"Replace list to a binary tree here". You see, it is the same here.

> > Suppose you have a patch that deduplicates the same code pattern across 34
> > functions by factoring it out to a single short function. Do you really need
> > that list? I mean, sure it's a fun fact to know, but you'll have to review
> > diff
> > anyway.
> 
> Yes and no. If I get the purpose of the diff, I could scan the contents 
> more superficially (depending on what kind of changes are proposed, and 
> where).

Sorry if I'm misreading, but given the context of comparing commit-messages with
the list and without, I can only interpret the "yes" as "yes, one sentence that
says the code pattern is factored out from all the functions is not enough, I
need a similar sentence to be repeated 34 times". Is there other interpretation
that I do not see, or do I get it right?

> > If anything, it only burdens you by forcing to check that each function
> > is on the list.
> 
> I usually don't.

This! Strictly speaking, as a reviewer you should check it. If a contributor
forgot to add or remove a function on v2 of patches, and you passed them your
Reviewed-by, wrong commit message would partially be your fault.

You do not usually check it exactly because it is trivially a burden.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 14.06.2020 02:00, Konstantin Kharlamov wrote:

> So, they make a non-trivial functional change ("non-trivial" because here we
> don't care of trivials like "rename a thing" or "factor out the code". These can
> often be described just in the commit title alone), let's say, they replaced a
> "list" container in a few functions to a binary tree for whatever reason. Now
> we'd like to know why did that happen.

We might want to know more things than that, actually.

> In my case they clearly would not produce anything useful, they'll maybe write
> "replace list to a binary tree" and that's it. Why? Who knows.

Then I'll probably ask. If the preceding discussion, or the contents of 
the associated bug report, haven't made the reason clear already.

> How will they behave in your case? Well, they'll collect the functions list,
> then would scrupulously write an immensely useful information against each one
> "Replace list to a binary tree here". You see, it is the same here.

Let's imagine that I know that in the codebase 'list' is used in many 
places, and then in the ChangeLog entry I see that only some of them 
have been replaced.

Then I cut the review short and ask about the rest of the places.

Similarly if they actually described the reason the change, but the 
enumerated changes don't match that goal (e.g. some changes in some 
files are missing).

Another concern that can come up are whether they added 
backward-compatibility aliases (to satisfy our backward compatibility 
policy), which should also be apparent from the ChangeLog style entry. Etc.

> Sorry if I'm misreading, but given the context of comparing commit-messages with
> the list and without, I can only interpret the "yes" as "yes, one sentence that
> says the code pattern is factored out from all the functions is not enough, I
> need a similar sentence to be repeated 34 times". Is there other interpretation
> that I do not see, or do I get it right?

Yes, as in "I'd have to review the diff anyway", and no, as in "I won't 
have to spend as much time doing it as I might have without the 
ChangeLog style summary".

>>> If anything, it only burdens you by forcing to check that each function
>>> is on the list.
>>
>> I usually don't.
> 
> This! Strictly speaking, as a reviewer you should check it. If a contributor
> forgot to add or remove a function on v2 of patches, and you passed them your
> Reviewed-by, wrong commit message would partially be your fault.

I'm all in favor of automated checks. Someone would need to implement 
them, though.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-14 at 02:23 +0300, Dmitry Gutov wrote:
> On 14.06.2020 02:00, Konstantin Kharlamov wrote:
> 
> > So, they make a non-trivial functional change ("non-trivial" because here we
> > don't care of trivials like "rename a thing" or "factor out the code". These
> > can
> > often be described just in the commit title alone), let's say, they replaced
> > a
> > "list" container in a few functions to a binary tree for whatever reason.
> > Now
> > we'd like to know why did that happen.
> 
> We might want to know more things than that, actually.
> 
> > In my case they clearly would not produce anything useful, they'll maybe
> > write
> > "replace list to a binary tree" and that's it. Why? Who knows.
> 
> Then I'll probably ask. If the preceding discussion, or the contents of 
> the associated bug report, haven't made the reason clear already.
> 
> > How will they behave in your case? Well, they'll collect the functions list,
> > then would scrupulously write an immensely useful information against each
> > one
> > "Replace list to a binary tree here". You see, it is the same here.
> 
> Let's imagine that I know that in the codebase 'list' is used in many 
> places, and then in the ChangeLog entry I see that only some of them 
> have been replaced.
> 
> Then I cut the review short and ask about the rest of the places.
> 
> Similarly if they actually described the reason the change, but the 
> enumerated changes don't match that goal (e.g. some changes in some 
> files are missing).
> 
> Another concern that can come up are whether they added 
> backward-compatibility aliases (to satisfy our backward compatibility 
> policy), which should also be apparent from the ChangeLog style entry. Etc.

Sure, all you say sounds reasonable. The point I'm trying to make is that you
have to ask the author for better commit message either way. IOW, you have to
ask that disregarding whether they're obliged to write down the list of
functions changed or not. So having the list didn't help here.

Admittedly, I might be the wrong person to make up an example since I didn't see
the point in this list to begin with. Better examples are certainly welcome.

> > Sorry if I'm misreading, but given the context of comparing commit-messages
> > with
> > the list and without, I can only interpret the "yes" as "yes, one sentence
> > that
> > says the code pattern is factored out from all the functions is not enough,
> > I
> > need a similar sentence to be repeated 34 times". Is there other
> > interpretation
> > that I do not see, or do I get it right?
> 
> Yes, as in "I'd have to review the diff anyway", and no, as in "I won't 
> have to spend as much time doing it as I might have without the 
> ChangeLog style summary".

Please note we're discussing whether having the list of functions changed is
worth it comparing to just the commit message. Having a good commit message is
just as enough, so you "won't have to spend as much time doing it". Like, in the
example with factoring out a code from 34 functions it's enough to just write
"Many functions use same code pattern to do X. Factor it out to a separate
function Y". What changes if instead of this one sentence you have 34 lines with
function names? Besides, as I hopefully showed in my prev. paragraph, if an
author is bad in writing commit messages, having that would hardly change
anything.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Sat, Jun 13, 2020, 15:36 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 13.06.2020 14:59, Konstantin Kharlamov wrote:
> > no other projects require
> > writing down a list of functions I changed just for the fun of it
>
> As a reviewer, there's something to be said about having an overview of
> the whole diff (which can get long) in a few paragraphs on top of the
> patch. A good commit message like that actually makes a lot of things
> clear in advance.
>

+1. I even use this for my own projects or projects where it's not
required. Producing that list is a last self-reviewing step that summarizes
_how_ the change was implemented. The diff itself is the ultimate source,
but a summary is it very welcome.

Of course most good commit messages don't stop there, they also explain the
_why_.

In general, Konstantin. I think your "for fun" exemplifies how you and many
others think of these procedures as spurious, or gratuitous. But they're
not, they exist because she people, whom you may disagree with, find them
useful.

João

João

>

[-- Attachment #2: Type: text/html, Size: 1766 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 20:38 +0100, João Távora wrote:
> On Sat, Jun 13, 2020, 15:36 Dmitry Gutov <dgutov@yandex.ru> wrote:
> > On 13.06.2020 14:59, Konstantin Kharlamov wrote:
> > > no other projects require
> > > writing down a list of functions I changed just for the fun of it
> > 
> > As a reviewer, there's something to be said about having an overview of 
> > the whole diff (which can get long) in a few paragraphs on top of the 
> > patch. A good commit message like that actually makes a lot of things 
> > clear in advance.
> 
> +1. I even use this for my own projects or projects where it's not required.
> Producing that list is a last self-reviewing step that summarizes _how_ the
> change was implemented. The diff itself is the ultimate source, but a summary
> is it very welcome.
> 
> Of course most good commit messages don't stop there, they also explain the
> _why_.
> 
> In general, Konstantin. I think your "for fun" exemplifies how you and many
> others think of these procedures as spurious, or gratuitous. But they're not,
> they exist because she people, whom you may disagree with, find them useful.

Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a follow-
up on it. Does my follow-up mail change your opinion, or perhaps do you have
some example in mind that a good commit message without the list would not
solve?

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[João Távora]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a follow-
> up on it. Does my follow-up mail change your opinion, or perhaps do you have
> some example in mind that a good commit message without the list would not
> solve?

I might have read it.  I'm not saying good commit messages are
impossible without the summarizing list; I'm just saying it's a good
thing to have, something I've grown accustomed to.  When composing them,
they're a good exercise in self-review.  But of course there's more ways
to skin a cat.  This just happens to be the way we use here.

It's not "for fun".  Of course is a mental cost in composing them,
especially if you don't do it often and use the friendly C-x 4 a
shortcut.  But there is a gain, too.

João

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Ricardo Wurmus]

João Távora <joaotavora@gmail.com> writes:

> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>
>> Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a follow-
>> up on it. Does my follow-up mail change your opinion, or perhaps do you have
>> some example in mind that a good commit message without the list would not
>> solve?
>
> I might have read it.  I'm not saying good commit messages are
> impossible without the summarizing list; I'm just saying it's a good
> thing to have, something I've grown accustomed to.  When composing them,
> they're a good exercise in self-review.  But of course there's more ways
> to skin a cat.  This just happens to be the way we use here.
>
> It's not "for fun".  Of course is a mental cost in composing them,
> especially if you don't do it often and use the friendly C-x 4 a
> shortcut.  But there is a gain, too.

I’d also like to note that this list can be invaluable when rebasing
commits and resolving conflicts.  It’s not strictly necessary (just like
other parts of a version control workflow are not strictly necessary),
but it can serve as a sanity check in a time when the diff is not
authoritative as it is in flux.

An explanation as to why things were done is also very useful in those
cases, but an overview on the *conceptual* changes at the procedure
level (rather than the plain diff that’s only concerned with lines and
not with the context in which the changes occurred) provides additional
valuable information that the commit diff itself cannot provide.

You can, of coures, browse the code with the diff applied and without
and see the full context in which those lines were changed, but even
with a nice interface like the one magit provides that’s much more work
than looking at the commit summary.

-- 
Ricardo

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Thu, 2020-06-18 at 19:49 +0200, Ricardo Wurmus wrote:
> João Távora <joaotavora@gmail.com> writes:
> 
> > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > 
> > > Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a
> > > follow-
> > > up on it. Does my follow-up mail change your opinion, or perhaps do you
> > > have
> > > some example in mind that a good commit message without the list would not
> > > solve?
> > 
> > I might have read it.  I'm not saying good commit messages are
> > impossible without the summarizing list; I'm just saying it's a good
> > thing to have, something I've grown accustomed to.  When composing them,
> > they're a good exercise in self-review.  But of course there's more ways
> > to skin a cat.  This just happens to be the way we use here.
> > 
> > It's not "for fun".  Of course is a mental cost in composing them,
> > especially if you don't do it often and use the friendly C-x 4 a
> > shortcut.  But there is a gain, too.
> 
> I’d also like to note that this list can be invaluable when rebasing
> commits and resolving conflicts.  It’s not strictly necessary (just like
> other parts of a version control workflow are not strictly necessary),
> but it can serve as a sanity check in a time when the diff is not
> authoritative as it is in flux.

While it may be useful, but explicit examples may be more interesting. Right now
when I read your text about this list in the context of resolving rebase
conflicts, I only see the downside that if the conflict came up because a
function was renamed, you need to go fix the commit message too.

Even worse: if upon rebasing a function was renamed, you may not get any
conflicts (i.e. because thunk you modified didn't include the beginning of the
function), and now your commit message is broken without you even noticing.

> An explanation as to why things were done is also very useful in those
> cases, but an overview on the *conceptual* changes at the procedure
> level (rather than the plain diff that’s only concerned with lines and
> not with the context in which the changes occurred) provides additional
> valuable information that the commit diff itself cannot provide.

It is possible, it's just that I do not see this. Convincing someone that the
commit message with the list provides more benefit than without it requires
examples that make it explicit. 

So far the whole thread (both this part and the one with Dmitry) had only
negative examples, i.e. why having the list is a burden to anyone.

Let me sum up the positive mentions: so far, you just say it simplifies review
for you, but I don't know your workflow, there may be many factors that make you
assert that, which does not necessarily applies to everyone. Dmitry said the
list makes better commit messages from novices, but again when I tried to dig
deeper, that discussion died.

You see, presence of negative examples and lack of positive ones doesn't make
that look too convincing.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>, Stefan
> 	Kangas <stefan@marxist.se>, emacs-devel@gnu.org
> Date: Fri, 19 Jun 2020 01:34:21 +0300
> 
> > I’d also like to note that this list can be invaluable when rebasing
> > commits and resolving conflicts.  It’s not strictly necessary (just like
> > other parts of a version control workflow are not strictly necessary),
> > but it can serve as a sanity check in a time when the diff is not
> > authoritative as it is in flux.
> 
> While it may be useful, but explicit examples may be more interesting. Right now
> when I read your text about this list in the context of resolving rebase
> conflicts, I only see the downside that if the conflict came up because a
> function was renamed, you need to go fix the commit message too.
> 
> Even worse: if upon rebasing a function was renamed, you may not get any
> conflicts (i.e. because thunk you modified didn't include the beginning of the
> function), and now your commit message is broken without you even noticing.

There's no requirement to retroactively fix commit log messages when
files or functions are renamed.  The renaming is recorded in the
history and can be found when one needs to explore the history of some
code fragment.

What is important is that the log message names the files and
functions/macros/data structures as they are called at the time of the
commit, because the log message is many times read in conjunction with
the diffs.

So I don't think the difficulties you describe are real.

> It is possible, it's just that I do not see this. Convincing someone that the
> commit message with the list provides more benefit than without it requires
> examples that make it explicit. 
> 
> So far the whole thread (both this part and the one with Dmitry) had only
> negative examples, i.e. why having the list is a burden to anyone.

The GNU Coding Standards were recently changed to provide the
rationale for having this information in the log messages.  Since the
official Prep page wasn't updated yet, I show the relevant text below,
in the hope that it will give you enough information to understand why
having that in the log messages could be beneficial.

> Let me sum up the positive mentions: so far, you just say it simplifies review
> for you, but I don't know your workflow, there may be many factors that make you
> assert that, which does not necessarily applies to everyone. Dmitry said the
> list makes better commit messages from novices, but again when I tried to dig
> deeper, that discussion died.

When you contribute changes to a project, you need to satisfy the
workflows of others, even if they differ from yours.  So you need to
respect the opinions of the project developers when they tell you this
information is of help to them.

Here are the excerpts from the latest GNU Coding Standards manual I
mentioned above:

----------------------------------------------------------------------
Therefore, change logs should be detailed enough and accurate enough
to provide the information commonly required for such @dfn{software
forensics}.  Specifically, change logs should make finding answers to
the following questions easy:

@itemize @bullet
@item
What changes affected a particular source file?

@item
Was a particular source file renamed or moved, and if so, as part of
what change?

@item
What changes affected a given function or macro or definition of a
data structure?

@item
Was a function (or a macro or the definition of a data structure)
renamed or moved from another file, and if so, as part of which
change?

@item
What changes deleted a function (or macro or data structure)?

@item
What was the rationale for a given change, and what were its main
ideas?

@item
Is there any additional information regarding the change, and if so,
where can it be found?
@end itemize
[...]
Following the free-text description of the change, it is a good idea
to give a list of names of the entities or definitions that you
changed, according to the files they are in, and what was changed in
each one.  @xref{Style of Change Logs}.  If a project uses a modern
@acronym{VCS} to keep the change log information, as described in
@ref{Change Logs}, explicitly listing the files and functions that
were changed is not strictly necessary, and in some cases (like
identical mechanical changes in many places) even tedious.  It is up
to you to decide whether to allow your project's developers to omit
the list of changed files and functions from the log entries, and
whether to allow such omissions under some specific conditions.
However, while making this decision, please consider the following
benefits of providing the list of changed entities with each change:

@itemize @bullet
@item
Generation of useful @file{ChangeLog} files from @acronym{VCS} logs
becomes more difficult if the change log entries don't list the
modified functions/macros, because @acronym{VCS} commands cannot
reliably reproduce their names from the commit information alone.  For
example, when there is a change in the header part of a function
definition, the heading of the diff hunk as shown in the VCS log
commands will name the wrong function as being modified (usually, the
function defined before the one being modified), so using those diffs
to glean the names of the modified functions will produce inaccurate
results.  You will need to use specialized scripts, such as gnulib's
@file{vcs-to-changelog.py}, mentioned below, to solve these
difficulties, and make sure it supports the source languages used by
your project.

@item
While modern @acronym{VCS} commands, such as Git's @kbd{git log -L}
and @kbd{git log -G}, provide powerful means for finding changes that
affected a certain function or macro or data structure (and thus might
make @file{ChangeLog} files unnecessary if you have the repository
available), they can sometimes fail.  For example, @kbd{git log -L}
doesn't support syntax of some programming languages out of the box.
Mentioning the modified functions/macros explicitly allows finding the
related changes simply and reliably.

@item
Some @acronym{VCS} commands have difficulties or limitations when
tracking changes across file moves or renames.  Again, if the entities
are mentioned explicitly, those difficulties can be overcome.

@item
Users that review changes using the generated @file{ChangeLog} files
may not have the repository and the @acronym{VCS} commands available
to them.  Naming the modified entities alleviates that problem.
@end itemize

@noindent
For these reasons, providing lists of modified files and functions
with each change makes the change logs more useful, and we therefore
recommend to include them whenever possible and practical.

It is also possible to generate the lists naming the modified entities
by running a script.  One such script is @file{mklog.py} (written in
Python 3); it is used by the @code{GCC} project.  Gnulib provides
another variant of such a script, called @file{vcs-to-changelog.py},
part of the @code{vcs-to-changelog} module.  Note that these scripts
currently support fewer programming languages than the manual commands
provided by Emacs (@pxref{Style of Change Logs}).  Therefore, the
above mentioned method of generating the @code{ChangeLog} file from
the @acronym{VCS} commit history, for instance via the
@code{gitlog-to-changelog} script, usually gives better
results---provided that the contributors stick to providing good
commit messages.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Fri, 2020-06-19 at 14:48 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>, Stefan
> > 	Kangas <stefan@marxist.se>, emacs-devel@gnu.org
> > Date: Fri, 19 Jun 2020 01:34:21 +0300
> >
> > > I’d also like to note that this list can be invaluable when rebasing
> > > commits and resolving conflicts.  It’s not strictly necessary (just like
> > > other parts of a version control workflow are not strictly necessary),
> > > but it can serve as a sanity check in a time when the diff is not
> > > authoritative as it is in flux.
> >
> > While it may be useful, but explicit examples may be more interesting. Right
> > now
> > when I read your text about this list in the context of resolving rebase
> > conflicts, I only see the downside that if the conflict came up because a
> > function was renamed, you need to go fix the commit message too.
> >
> > Even worse: if upon rebasing a function was renamed, you may not get any
> > conflicts (i.e. because thunk you modified didn't include the beginning of
> > the
> > function), and now your commit message is broken without you even noticing.
>
> There's no requirement to retroactively fix commit log messages when
> files or functions are renamed.  The renaming is recorded in the
> history and can be found when one needs to explore the history of some
> code fragment.
>
> What is important is that the log message names the files and
> functions/macros/data structures as they are called at the time of the
> commit, because the log message is many times read in conjunction with
> the diffs.
>
> So I don't think the difficulties you describe are real.

Are you saying that wrong commit messages are okay? Will it be okay if I make a
v1 of a patch where just one function is changed, and then in v2 I additionally
modify a dozen of others, and won't add their names to the commit message?

Also, what you say here contradicts to your quote of GNU standard, which says
the list is needed to generate Changelog files. Because not fixing commit
messages retroactively will result in wrong Changelogs.

What's the point in wrong Changelog files and wrong commit messages?

> > Let me sum up the positive mentions: so far, you just say it simplifies
> > review
> > for you, but I don't know your workflow, there may be many factors that make
> > you
> > assert that, which does not necessarily applies to everyone. Dmitry said the
> > list makes better commit messages from novices, but again when I tried to
> > dig
> > deeper, that discussion died.
>
> When you contribute changes to a project, you need to satisfy the
> workflows of others, even if they differ from yours.  So you need to
> respect the opinions of the project developers when they tell you this
> information is of help to them.

Right. Judging by the fact you say this me, I have a feeling you miss the point
why we're even discussing this.

Let me abstract from Emacs a bit. People like different things, which is okay,
everyone has unique life and character. And some like things that would in fact
hurt when applied to others! That's okay too, just don't apply these to
everybody. There're communities for them as well, so it's not like they're
alone.

Now let's get back to Emacs. I hope it's unquestionable that purpose of Emacs
project is prosperity of Emacs project. It doesn't have explicit purpose to
cater to Emacs contributors or developers. But if you ask "how can we make Emacs
evolve and prosper", the "making Emacs contributors, developers and users
comfortable" is hopefully an obvious answer.

Having good developer practices is an implication of "making
developers/contributors comfortable". Which includes, that if some developer
practice (I'm pointing out here to the functions list) 1. carries burden on
everyone, and 2. Makes happy only a few (perhaps, because of their habits or
whatever), we should ditch this practice.

Because Emacs project is not a community of peoples who like a specific thing
that would hurt others when applied to them. Instead it's a community who want
Emacs to evolve and prosper.

> Here are the excerpts from the latest GNU Coding Standards manual I
> mentioned above:
> […snipped…]

Thanks. I should say, it's a big text, half of which basically says "it's cool
to have" which doesn't answer the question "why". So, I'm sorry if I missed some
point while reading this, in this case pointing this out more explicitly might
help.

Regarding the discussion I grasped from it two points:

1. The list is used to generate Changelogs.
2. The standard does not enforce having the list in commit messages if you're
using a decent VCS (which I'd think includes git)

The text then goes into details that generating Changelogs from a VCS alone may
be unreliable. The example it shows can be reproduced on Emacs repo as follows:
if you do `git log -1 -p 50a0126402d`, you'll see some renames, however the
context above the hunk shows not the variable/function being renamed.

I'd argue it would be way more productive to make git produce what Changelog
files need correctly rather than forcing tedious manual work upon everybody. git
already can recognize the context correctly, we just need a specific flag to
only make it show changed functions/variables (ATM it seems not to have it, at
least I didn't find one).

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
>  stefan@marxist.se,  emacs-devel@gnu.org
> Date: Sat, 20 Jun 2020 16:07:54 +0300
> 
> > There's no requirement to retroactively fix commit log messages when
> > files or functions are renamed.  The renaming is recorded in the
> > history and can be found when one needs to explore the history of some
> > code fragment.
> >
> > What is important is that the log message names the files and
> > functions/macros/data structures as they are called at the time of the
> > commit, because the log message is many times read in conjunction with
> > the diffs.
> >
> > So I don't think the difficulties you describe are real.
> 
> Are you saying that wrong commit messages are okay?

Of course not.

> Will it be okay if I make a
> v1 of a patch where just one function is changed, and then in v2 I additionally
> modify a dozen of others, and won't add their names to the commit message?

Of course not.  But you could omit the log messages completely in v1
if it is known in advance that there will be a v2.  IOW, the only log
message that really matters is the last one, the one that is going to
be committed to upstream.

It's similar to documentation: it is perfectly acceptable to initially
post a patch without the documentation bits, saying you will provide
one when the code details are finalized.

> Also, what you say here contradicts to your quote of GNU standard, which says
> the list is needed to generate Changelog files. Because not fixing commit
> messages retroactively will result in wrong Changelogs.
> 
> What's the point in wrong Changelog files and wrong commit messages?

We are miscommunicating.  You have only a very specific scenario in
mind, whereas I was talking about something much more general.  For
the situations you had in mind (IIUC), only the last variant of the
log messages matters.  If you can get those log message right on the
first attempt, you can omit them in intermediate variants, and just
say you will provide them with the last version.  (Of course, if you
don't get them right the first time, you will get review comments for
them, so it's up to you to decide whether indeed you can afford
omitting them from intermediate versions.)

Also, let's face it: changesets where v2 renames many symbols present
in v1's log are rare.  There's no need to make these rare cases sound
as if they were the rule: they are not.

> Now let's get back to Emacs. I hope it's unquestionable that purpose of Emacs
> project is prosperity of Emacs project. It doesn't have explicit purpose to
> cater to Emacs contributors or developers. But if you ask "how can we make Emacs
> evolve and prosper", the "making Emacs contributors, developers and users
> comfortable" is hopefully an obvious answer.
> 
> Having good developer practices is an implication of "making
> developers/contributors comfortable". Which includes, that if some developer
> practice (I'm pointing out here to the functions list) 1. carries burden on
> everyone, and 2. Makes happy only a few (perhaps, because of their habits or
> whatever), we should ditch this practice.

We are not asking contributors to adhere to some arbitrary and
outlandish standards and practices, or something that satisfies only a
small group of people who usurped the power, so to say.  These are
standards common to the GNU Project as a whole (although minor
variations do exist, and when I submit changes to, say, GDB, I need to
do that according to what GDB developers expect and require, not to
what I'm accustomed to in Emacs).  These standards are the result of
quite a few discussions among developers of many GNU projects, where
arguments not unlike those you present are also voiced and considered.
The result is described in the GCS document, and it includes
rationale that also comes out of those discussions.

IOW, it isn't like some band of people conquered the Emacs project and
now dictates its arbitrary demands to the community at large.  These
requirements are the result of many discussions, and include the
summary experience and knowledge of many people who understand very
well that every additional requirement adds to the burden of the
contributors.

Requirements for contributors are always a fine balancing act, whereby
too few or too many requirements will both produce sub-optimal results
for various reasons.  So let's not pretend that dropping important
requirements to make it easy on contributors is the right solution,
because the requirements are there for a reason, and dropping any one
of them brings a disadvantage.  We need to carefully weigh the
advantages and disadvantages of each requirement.

> > Here are the excerpts from the latest GNU Coding Standards manual I
> > mentioned above:
> > […snipped…]
> 
> Thanks. I should say, it's a big text, half of which basically says "it's cool
> to have" which doesn't answer the question "why". So, I'm sorry if I missed some
> point while reading this, in this case pointing this out more explicitly might
> help.

Actually, the reasons (a.k.a. "why") are presented there at least
twice: once indirectly, by explaining the general purpose of good
change log records, and then once more by providing specific
considerations for keeping the information we are talking about (names
of files and functions/macros/data structures that were modified) in
the log.

> 1. The list is used to generate Changelogs.

No.  The text says that it is recommended to have ChangeLog files in
the release tarball, but it doesn't make that mandatory.

> 2. The standard does not enforce having the list in commit messages if you're
> using a decent VCS (which I'd think includes git)

No.  The text leaves this decision to each package maintainer, and
presents important considerations that could and should influence that
decision.

> The text then goes into details that generating Changelogs from a VCS alone may
> be unreliable. The example it shows can be reproduced on Emacs repo as follows:
> if you do `git log -1 -p 50a0126402d`, you'll see some renames, however the
> context above the hunk shows not the variable/function being renamed.
> 
> I'd argue it would be way more productive to make git produce what Changelog
> files need correctly rather than forcing tedious manual work upon everybody. git
> already can recognize the context correctly, we just need a specific flag to
> only make it show changed functions/variables (ATM it seems not to have it, at
> least I didn't find one).

I encourage you to talk to Git developers so that they improve this
capability.  Not sure this is going to happen in practice (knowing how
the diffs are generated, and given that one GNU project using Git
after another sets up alternative tools for overcoming these
problems), but it definitely cannot harm, so by all means go for it.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-20 at 17:02 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
> >  stefan@marxist.se,  emacs-devel@gnu.org
> > Date: Sat, 20 Jun 2020 16:07:54 +0300
> >
> > > There's no requirement to retroactively fix commit log messages when
> > > files or functions are renamed.  The renaming is recorded in the
> > > history and can be found when one needs to explore the history of some
> > > code fragment.
> > >
> > > What is important is that the log message names the files and
> > > functions/macros/data structures as they are called at the time of the
> > > commit, because the log message is many times read in conjunction with
> > > the diffs.
> > >
> > > So I don't think the difficulties you describe are real.
> >
> > Are you saying that wrong commit messages are okay?
>
> Of course not.
>
> > Will it be okay if I make a
> > v1 of a patch where just one function is changed, and then in v2 I
> > additionally
> > modify a dozen of others, and won't add their names to the commit message?
>
> Of course not.  But you could omit the log messages completely in v1
> if it is known in advance that there will be a v2.  IOW, the only log
> message that really matters is the last one, the one that is going to
> be committed to upstream.
>
> It's similar to documentation: it is perfectly acceptable to initially
> post a patch without the documentation bits, saying you will provide
> one when the code details are finalized.
>
> > Also, what you say here contradicts to your quote of GNU standard, which
> > says
> > the list is needed to generate Changelog files. Because not fixing commit
> > messages retroactively will result in wrong Changelogs.
> >
> > What's the point in wrong Changelog files and wrong commit messages?
>
> We are miscommunicating.  You have only a very specific scenario in
> mind, whereas I was talking about something much more general.  For
> the situations you had in mind (IIUC), only the last variant of the
> log messages matters.  If you can get those log message right on the
> first attempt, you can omit them in intermediate variants, and just
> say you will provide them with the last version.  (Of course, if you
> don't get them right the first time, you will get review comments for
> them, so it's up to you to decide whether indeed you can afford
> omitting them from intermediate versions.)
>
> Also, let's face it: changesets where v2 renames many symbols present
> in v1's log are rare.  There's no need to make these rare cases sound
> as if they were the rule: they are not.

Please note that I haven't provided example here. From your text you seem to
think I implied scenario where v1 is an RFC, and later patches are actual
changes.

It's not what I had in mind. I rather was thinking about making some change in
v1, and then as result of code review making more similar changes to other
places. As a real life example, while discussing the patch `Replace manually
crafted hex regexes with [[:xdigit:]]`, more places where similar changes can be
applied were uncovered.

In code-refactoring I think it's pretty common to happen. You can't omit the
list in v1 in these cases because you don't know there will be followups.

> > Now let's get back to Emacs. I hope it's unquestionable that purpose of
> > Emacs
> > project is prosperity of Emacs project. It doesn't have explicit purpose to
> > cater to Emacs contributors or developers. But if you ask "how can we make
> > Emacs
> > evolve and prosper", the "making Emacs contributors, developers and users
> > comfortable" is hopefully an obvious answer.
> >
> > Having good developer practices is an implication of "making
> > developers/contributors comfortable". Which includes, that if some developer
> > practice (I'm pointing out here to the functions list) 1. carries burden on
> > everyone, and 2. Makes happy only a few (perhaps, because of their habits or
> > whatever), we should ditch this practice.
>
> We are not asking contributors to adhere to some arbitrary and
> outlandish standards and practices, or something that satisfies only a
> small group of people who usurped the power, so to say.  These are
> standards common to the GNU Project as a whole (although minor
> variations do exist, and when I submit changes to, say, GDB, I need to
> do that according to what GDB developers expect and require, not to
> what I'm accustomed to in Emacs).  These standards are the result of
> quite a few discussions among developers of many GNU projects, where
> arguments not unlike those you present are also voiced and considered.
> The result is described in the GCS document, and it includes
> rationale that also comes out of those discussions.
>
> IOW, it isn't like some band of people conquered the Emacs project and
> now dictates its arbitrary demands to the community at large.  These
> requirements are the result of many discussions, and include the
> summary experience and knowledge of many people who understand very
> well that every additional requirement adds to the burden of the
> contributors.
>
> Requirements for contributors are always a fine balancing act, whereby
> too few or too many requirements will both produce sub-optimal results
> for various reasons.  So let's not pretend that dropping important
> requirements to make it easy on contributors is the right solution,
> because the requirements are there for a reason, and dropping any one
> of them brings a disadvantage.  We need to carefully weigh the
> advantages and disadvantages of each requirement.

Sounds reasonable. I'd like to see those discussions though to understand the
background, and maybe even participate in them. Do you have any reference?

> > > Here are the excerpts from the latest GNU Coding Standards manual I
> > > mentioned above:
> > > […snipped…]
> >
> > Thanks. I should say, it's a big text, half of which basically says "it's
> > cool
> > to have" which doesn't answer the question "why". So, I'm sorry if I missed
> > some
> > point while reading this, in this case pointing this out more explicitly
> > might
> > help.
>
> Actually, the reasons (a.k.a. "why") are presented there at least
> twice: once indirectly, by explaining the general purpose of good
> change log records,

Err. Okay, I mean, text does explain it. Was I ever opposed to it? Let me
repeat, I'm all for good commit messages. My point is the functions list is not
necessary for having good commit messages.

This whole thread is dedicated to "why having the list is necessary as opposed
to not having it", and while text explains "why having the list is good" in
general, but it does not make comparison to not using it. There's no answer to
that question.

> and then once more by providing specific
> considerations for keeping the information we are talking about (names
> of files and functions/macros/data structures that were modified) in
> the log.

Again, I don't see why just saying in commit message e.g. "Factor out code doing
X out of all functions", is worse than additionally making the list of those
functions (or is it a bad example, and you have a better one in mind? Great, I
want to hear it!).

> > The text then goes into details that generating Changelogs from a VCS alone
> > may
> > be unreliable. The example it shows can be reproduced on Emacs repo as
> > follows:
> > if you do `git log -1 -p 50a0126402d`, you'll see some renames, however the
> > context above the hunk shows not the variable/function being renamed.
> >
> > I'd argue it would be way more productive to make git produce what Changelog
> > files need correctly rather than forcing tedious manual work upon everybody.
> > git
> > already can recognize the context correctly, we just need a specific flag to
> > only make it show changed functions/variables (ATM it seems not to have it,
> > at
> > least I didn't find one).
>
> I encourage you to talk to Git developers so that they improve this
> capability.  Not sure this is going to happen in practice (knowing how
> the diffs are generated, and given that one GNU project using Git
> after another sets up alternative tools for overcoming these
> problems), but it definitely cannot harm, so by all means go for it.

I might do it, but I need motivation. If I knew this is the only reason Emacs
has requirement for the functions list, thus having such ability in git would
allow to drop this requirement, I'd do it. Right now people seem to prefer to
stick to having the list for other reasons (which are being discussed in the
text above), so clearly even if git got such ability, it would be of little use
to Emacs.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
>  stefan@marxist.se,  emacs-devel@gnu.org
> Date: Sat, 20 Jun 2020 18:41:37 +0300
> 
> > Also, let's face it: changesets where v2 renames many symbols present
> > in v1's log are rare.  There's no need to make these rare cases sound
> > as if they were the rule: they are not.
> 
> Please note that I haven't provided example here. From your text you seem to
> think I implied scenario where v1 is an RFC, and later patches are actual
> changes.

Many times the first version of a patch is an implicit RFC, especially
for a rare contributor who cannot be sure his or her ideas will be
accepted by the developers.

As another data point, I frequently post my proposed patches without
log messages, because I believe people generally trust me to produce
the right log messages when the time comes.

> It's not what I had in mind. I rather was thinking about making some change in
> v1, and then as result of code review making more similar changes to other
> places. As a real life example, while discussing the patch `Replace manually
> crafted hex regexes with [[:xdigit:]]`, more places where similar changes can be
> applied were uncovered.
> 
> In code-refactoring I think it's pretty common to happen. You can't omit the
> list in v1 in these cases because you don't know there will be followups.

Fair enough, but massive renames are still rare, IME, and thus the
danger of having to completely rewrite the log messages is also small.

> Sounds reasonable. I'd like to see those discussions though to understand the
> background, and maybe even participate in them. Do you have any reference?

They are scattered across different mailing lists (and across many
months), but you can find many of them on bug-standard@gnu.org and on
gnu-prog-discuss@gnu.org.

> My point is the functions list is not necessary for having good
> commit messages.

Our experiences are different, then.  I find them very important in at
least some cases.

> This whole thread is dedicated to "why having the list is necessary as opposed
> to not having it", and while text explains "why having the list is good" in
> general, but it does not make comparison to not using it. There's no answer to
> that question.

Isn't saying "A is good to have" the same as saying "not having A is
not so good"?

> Again, I don't see why just saying in commit message e.g. "Factor out code doing
> X out of all functions", is worse than additionally making the list of those
> functions (or is it a bad example, and you have a better one in mind? Great, I
> want to hear it!).

For repetitive mechanical changes, it might be okay.  There's no
argument that some changes don't need detailed lists.  The argument is
whether having them in general is helpful.  If you are saying that in
some cases they are redundant, then we agree at least in principle
(though we could disagree in specific cases).  But if you are saying
they are seldom or never needed or useful, then I disagree, based on
my experience.

> > I encourage you to talk to Git developers so that they improve this
> > capability.  Not sure this is going to happen in practice (knowing how
> > the diffs are generated, and given that one GNU project using Git
> > after another sets up alternative tools for overcoming these
> > problems), but it definitely cannot harm, so by all means go for it.
> 
> I might do it, but I need motivation. If I knew this is the only reason Emacs
> has requirement for the functions list, thus having such ability in git would
> allow to drop this requirement, I'd do it. Right now people seem to prefer to
> stick to having the list for other reasons (which are being discussed in the
> text above), so clearly even if git got such ability, it would be of little use
> to Emacs.

It depends how good a job they do.  If they do a perfect job, which
will allow generating accurate ChangeLog-formatted entries without
providing the lists of functions in the log messages, then we might
indeed drop the requirement.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-20 at 19:10 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Sounds reasonable. I'd like to see those discussions though to understand
> > the
> > background, and maybe even participate in them. Do you have any reference?
>
> They are scattered across different mailing lists (and across many
> months), but you can find many of them on bug-standard@gnu.org and on
> gnu-prog-discuss@gnu.org.

Thanks, I'll look at it.

> > My point is the functions list is not necessary for having good
> > commit messages.
>
> Our experiences are different, then.  I find them very important in at
> least some cases.

Right. I should mention though, my experience is not specific to myself. Most
non-GNU projects (actually, all I have seen) don't require having the list, but
do require good commit messages. Peter Hutterer, a libinput and kernel HID
subsystem maintainer wrote a good blog-post in 2009 on commit messages, and this
too did not include having the list 
http://who-t.blogspot.com/2009/12/on-commit-messages.html

I also don't think GNU projects are any good to make examples of. This is my
general experience of seeing how new projects get under GNU umbrella to get
never heard of (which I attribute to points listed in my starting mail, since
most of them are unspecific to Emacs).

But to support this claim regarding GNU, I just did some experiment. I
downloaded git repositories of GNU GCC and Clang, and tried to count
contributors to last 500 commits. I was interested in seeing the number of
occasional contributors. I think that if a project only lives by means of
maintainers and paid people, the project pretty much goes down. Maintainers may
burn out, paid people will move on. Number of occasional contributors shows how
big interest in supporting the development, and they're the ones who at some
point may become maintainers too.

So, I looked at "author email" fields and removed ones with email addresses that
are either clearly corporate or clearly maintainers. Not the most scientific
method, I might have missed a few ones who contributed from their personal
email, but I don't expect the difference to be statistically significant.

So, the command is (I hope my email client won't break it terribly):

    git log -500 --format="%ae" | grep -vP
"@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
five)\.(org|com|de|cz|cn)" | sort -u | wc -l

Results are:
* GCC as of commit 445d8da5fbd: 15
* Clang as of commit 7b201bfcac2: 49

This is some pretty big difference! If I expand the commits range, the
difference increases further.

> > This whole thread is dedicated to "why having the list is necessary as
> > opposed
> > to not having it", and while text explains "why having the list is good" in
> > general, but it does not make comparison to not using it. There's no answer
> > to
> > that question.
>
> Isn't saying "A is good to have" the same as saying "not having A is
> not so good"?

It depends. If A is free, then sure. But if I gotta pay for A, then I'd consider
my options.

> > Again, I don't see why just saying in commit message e.g. "Factor out code
> > doing
> > X out of all functions", is worse than additionally making the list of those
> > functions (or is it a bad example, and you have a better one in mind? Great,
> > I
> > want to hear it!).
>
> For repetitive mechanical changes, it might be okay.  There's no
> argument that some changes don't need detailed lists.  The argument is
> whether having them in general is helpful.  If you are saying that in
> some cases they are redundant, then we agree at least in principle
> (though we could disagree in specific cases).  But if you are saying
> they are seldom or never needed or useful, then I disagree, based on
> my experience.
>
> > > I encourage you to talk to Git developers so that they improve this
> > > capability.  Not sure this is going to happen in practice (knowing how
> > > the diffs are generated, and given that one GNU project using Git
> > > after another sets up alternative tools for overcoming these
> > > problems), but it definitely cannot harm, so by all means go for it.
> >
> > I might do it, but I need motivation. If I knew this is the only reason
> > Emacs
> > has requirement for the functions list, thus having such ability in git
> > would
> > allow to drop this requirement, I'd do it. Right now people seem to prefer
> > to
> > stick to having the list for other reasons (which are being discussed in the
> > text above), so clearly even if git got such ability, it would be of little
> > use
> > to Emacs.
>
> It depends how good a job they do.  If they do a perfect job, which
> will allow generating accurate ChangeLog-formatted entries without
> providing the lists of functions in the log messages, then we might
> indeed drop the requirement.

Okay, I'll ask about it.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
>  stefan@marxist.se,  emacs-devel@gnu.org
> Date: Sat, 20 Jun 2020 21:04:23 +0300
> 
> > Our experiences are different, then.  I find them very important in at
> > least some cases.
> 
> Right. I should mention though, my experience is not specific to myself. Most
> non-GNU projects (actually, all I have seen) don't require having the list, but
> do require good commit messages.

Like I said, latest GCS leave this decision to the project developers'
discretion.

You may also wish to check how long do those projects live, and
compare that with Emacs.  Not every technique that is good for a
5-year project will scale well for a 35-year one.  In my work on Emacs
I quite frequently need to look at changes made 30 years ago, using a
different VCS.

> I also don't think GNU projects are any good to make examples of. This is my
> general experience of seeing how new projects get under GNU umbrella to get
> never heard of (which I attribute to points listed in my starting mail, since
> most of them are unspecific to Emacs).

I hope you realize how saying that makes your opinions matter much
less, do you?

>     git log -500 --format="%ae" | grep -vP
> "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
> odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
> oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
> five)\.(org|com|de|cz|cn)" | sort -u | wc -l
> 
> Results are:
> * GCC as of commit 445d8da5fbd: 15
> * Clang as of commit 7b201bfcac2: 49
> 
> This is some pretty big difference! If I expand the commits range, the
> difference increases further.

GCC is alive for 33 years, so I think your theory eats dust.  Many of
the GCC and GDB developers get paid for their work, but that doesn't
mean the project is less viable, and the long history of both GCC and
GDB is the proof.

> > > This whole thread is dedicated to "why having the list is necessary as
> > > opposed
> > > to not having it", and while text explains "why having the list is good" in
> > > general, but it does not make comparison to not using it. There's no answer
> > > to
> > > that question.
> >
> > Isn't saying "A is good to have" the same as saying "not having A is
> > not so good"?
> 
> It depends. If A is free, then sure. But if I gotta pay for A, then I'd consider
> my options.

That text described the advantages of having the lists precisely so
you could consider your options and make an informed decision.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-20 at 21:43 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
> >  stefan@marxist.se,  emacs-devel@gnu.org
> > Date: Sat, 20 Jun 2020 21:04:23 +0300
> >
> > > Our experiences are different, then.  I find them very important in at
> > > least some cases.
> >
> > Right. I should mention though, my experience is not specific to myself.
> > Most
> > non-GNU projects (actually, all I have seen) don't require having the list,
> > but
> > do require good commit messages.
>
> Like I said, latest GCS leave this decision to the project developers'
> discretion.
>
> You may also wish to check how long do those projects live, and
> compare that with Emacs.  Not every technique that is good for a
> 5-year project will scale well for a 35-year one.  In my work on Emacs
> I quite frequently need to look at changes made 30 years ago, using a
> different VCS.

Right, as well as not every technique that was good 35 years ago is still as
good nowadays.

> > I also don't think GNU projects are any good to make examples of. This is my
> > general experience of seeing how new projects get under GNU umbrella to get
> > never heard of (which I attribute to points listed in my starting mail,
> > since
> > most of them are unspecific to Emacs).
>
> I hope you realize how saying that makes your opinions matter much
> less, do you?

No, I don't. Are you implying that voicing bad opinion regarding GNU on a GNU
mailing list may lead to some people to start ignoring me? If so, I'm fine with
it. You see, my opinions are based on facts. My interpretation of them may be
wrong, but if I expressed them, I am not aware of it. On this mailing list, we
carry technical discussions, which means expressing arguments and counter-
arguments based on facts, and being ready to turn out to be wrong.

Ignoring someone based on their opinion instead of trying to prove them wrong is
not a technical behavior. These are not very technical people, they sometimes go
personal, so if their reaction is a silence, that's fine with me.

FYI, for me even participating in discussions is hard, for personal reasons. But
I am a software engineer, and I get the boundary between personal feelings and
technical discussions, so I get over it.

> >     git log -500 --format="%ae" | grep -vP
> > "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huaw
> > ei|c
> > odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|mi
> > cros
> > oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcprojec
> > t|si
> > five)\.(org|com|de|cz|cn)" | sort -u | wc -l
> >
> > Results are:
> > * GCC as of commit 445d8da5fbd: 15
> > * Clang as of commit 7b201bfcac2: 49
> >
> > This is some pretty big difference! If I expand the commits range, the
> > difference increases further.
>
> GCC is alive for 33 years, so I think your theory eats dust.  Many of
> the GCC and GDB developers get paid for their work, but that doesn't
> mean the project is less viable, and the long history of both GCC and
> GDB is the proof.

Okay, let me say beforehand that both GCC and Clang are very active projects
right now. Just in case, so there's no misunderstanding.

So, times are changing. In older times there were no standard to development,
Git was not as popular, development practices are varied too. So, as long you
could get your patch to a project, any odd contribution requirements were fine,
they hardly would set a barrier.

But these days Git got over all other VCSes (and for a reason), so using SVN or
Perforce, or whatever, is a barrier to contribution. 12 years ago Github was
founded, and then also the open-source clone Gitlab appeared. These two pretty
much set the standard development model nowadays (for a reason too). There still
are projects that use other models, but this is a barrier to contributors.

What I'm getting at is that your reasoning that since GCC is 33 years old it
will live on does not work. For a project to "live on" it needs to be active.
Sure GCC is active! But its activity mainly stems from paid people and
maintainers. Whereas in Clang a large chunk of it stems from contributors. Let
me repeat, paid people come and go, so do maintainers (they may burn out, or
just move on). These contributors are the ones who will become new maintainers
and the ones who advertise the project in their environment.

I hope it makes clear the future of what project looks brighter.

> > > > This whole thread is dedicated to "why having the list is necessary as
> > > > opposed
> > > > to not having it", and while text explains "why having the list is good"
> > > > in
> > > > general, but it does not make comparison to not using it. There's no
> > > > answer
> > > > to
> > > > that question.
> > >
> > > Isn't saying "A is good to have" the same as saying "not having A is
> > > not so good"?
> >
> > It depends. If A is free, then sure. But if I gotta pay for A, then I'd
> > consider
> > my options.
>
> That text described the advantages of having the lists precisely so
> you could consider your options and make an informed decision.

I can't make decision since I am not a Emacs maintainer.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-21 at 00:31 +0300, Konstantin Kharlamov wrote:
> On Sat, 2020-06-20 at 21:43 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
> > >  stefan@marxist.se,  emacs-devel@gnu.org
> > > Date: Sat, 20 Jun 2020 21:04:23 +0300
> > > 
> > > > Our experiences are different, then.  I find them very important in at
> > > > least some cases.
> > > 
> > > Right. I should mention though, my experience is not specific to myself.
> > > Most
> > > non-GNU projects (actually, all I have seen) don't require having the
> > > list,
> > > but
> > > do require good commit messages.
> > 
> > Like I said, latest GCS leave this decision to the project developers'
> > discretion.
> > 
> > You may also wish to check how long do those projects live, and
> > compare that with Emacs.  Not every technique that is good for a
> > 5-year project will scale well for a 35-year one.  In my work on Emacs
> > I quite frequently need to look at changes made 30 years ago, using a
> > different VCS.
> 
> Right, as well as not every technique that was good 35 years ago is still as
> good nowadays.
> 
> > > I also don't think GNU projects are any good to make examples of. This is
> > > my
> > > general experience of seeing how new projects get under GNU umbrella to
> > > get
> > > never heard of (which I attribute to points listed in my starting mail,
> > > since
> > > most of them are unspecific to Emacs).
> > 
> > I hope you realize how saying that makes your opinions matter much
> > less, do you?
> 
> No, I don't. Are you implying that voicing bad opinion regarding GNU on a GNU
> mailing list may lead to some people to start ignoring me? If so, I'm fine
> with
> it. You see, my opinions are based on facts. My interpretation of them may be
> wrong, but if I expressed them, I am not aware of it. On this mailing list, we
> carry technical discussions, which means expressing arguments and counter-
> arguments based on facts, and being ready to turn out to be wrong.
> 
> Ignoring someone based on their opinion instead of trying to prove them wrong
> is
> not a technical behavior. These are not very technical people, they sometimes
> go
> personal, so if their reaction is a silence, that's fine with me.
> 
> FYI, for me even participating in discussions is hard, for personal reasons.
> But
> I am a software engineer, and I get the boundary between personal feelings and
> technical discussions, so I get over it.
> 
> > >     git log -500 --format="%ae" | grep -vP
> > > "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|hu
> > > aw
> > > ei|c
> > > odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|
> > > mi
> > > cros
> > > oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproj
> > > ec
> > > t|si
> > > five)\.(org|com|de|cz|cn)" | sort -u | wc -l
> > > 
> > > Results are:
> > > * GCC as of commit 445d8da5fbd: 15
> > > * Clang as of commit 7b201bfcac2: 49
> > > 
> > > This is some pretty big difference! If I expand the commits range, the
> > > difference increases further.
> > 
> > GCC is alive for 33 years, so I think your theory eats dust.  Many of
> > the GCC and GDB developers get paid for their work, but that doesn't
> > mean the project is less viable, and the long history of both GCC and
> > GDB is the proof.
> 
> Okay, let me say beforehand that both GCC and Clang are very active projects
> right now. Just in case, so there's no misunderstanding.
> 
> So, times are changing. In older times there were no standard to development,
> Git was not as popular, development practices are varied too. So, as long you
> could get your patch to a project, any odd contribution requirements were
> fine,
> they hardly would set a barrier.
> 
> But these days Git got over all other VCSes (and for a reason), so using SVN
> or
> Perforce, or whatever, is a barrier to contribution. 12 years ago Github was
> founded, and then also the open-source clone Gitlab appeared. These two pretty
> much set the standard development model nowadays (for a reason too). There
> still
> are projects that use other models, but this is a barrier to contributors.
> 
> What I'm getting at is that your reasoning that since GCC is 33 years old it
> will live on does not work. For a project to "live on" it needs to be active.
> Sure GCC is active! But its activity mainly stems from paid people and
> maintainers. Whereas in Clang a large chunk of it stems from contributors. Let
> me repeat, paid people come and go, so do maintainers (they may burn out, or
> just move on). These contributors are the ones who will become new maintainers
> and the ones who advertise the project in their environment.
> 
> I hope it makes clear the future of what project looks brighter.

Btw, I figured I botched my calculations by using last 500 commits. If in one
project a few persons posted huge patchsets, but in another nobody, then clearly
the latter gets more mails in last 500 commits, which is wrong.

So, I recalculated by looking at date of the last commit of those "500" in GCC,
and used that date on Clang. I made sure to sort out other corporate mails too.
Command I used is:

	git log --since="Jun 8 21:34:46" --format="%ae" | grep -vP
"@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
five|imagelabs|xilinx|sap|sas|sigmatechnology|sonarsource|ericsson|lowrisc|hight
ec-rt|polymagelabs)\.(org|com|de|cz|cn|ai|se)" | sort -u | wc -l

So, now GCC still gets 15, while for Clang this number gets increased to 89.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rekado@elephly.net, emacs-devel@gnu.org, stefan@marxist.se, 
> 	joaotavora@gmail.com, dgutov@yandex.ru
> Date: Sun, 21 Jun 2020 01:25:15 +0300
> 
> So, I recalculated by looking at date of the last commit of those "500" in GCC,
> and used that date on Clang. I made sure to sort out other corporate mails too.
> Command I used is:
> 
> 	git log --since="Jun 8 21:34:46" --format="%ae" | grep -vP
> "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
> odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
> oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
> five|imagelabs|xilinx|sap|sas|sigmatechnology|sonarsource|ericsson|lowrisc|hight
> ec-rt|polymagelabs)\.(org|com|de|cz|cn|ai|se)" | sort -u | wc -l
> 
> So, now GCC still gets 15, while for Clang this number gets increased to 89.

This metric is irrelevant.  Basically, you removed everyone who was a
prominent developer, so it's little wonder that you are left with a
small number.  Using such arbitrary criteria, one can "prove" anything
for any project.

Once again, the long history and the active development of GCC over
those long years are a clear evidence that your criterion is
completely off the mark.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

I haven't followed this thread very closely, but it seems we've strayed
far enough away from Emacs that it's become quite offtopic.

I may be wrong (since I haven't followed the thread very closely) but my
understanding is that Konstantin would like it for Emacs to accept
submission using a "merge request" model or something like that.

We've discussed this many times in the past.  IIUC, we're slowly going
there (see https://libreplanet.org/wiki/Fsf_2019_forge_evaluation), but
we're an old project, and those people who most contribute to Emacs tend
not to go very much for the shiny new stuff, so if you like the shiny
new stuff I recommend you a healthy dose of patience.


        Stefan


Eli Zaretskii [2020-06-21 05:35:24] wrote:

>> From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> Cc: rekado@elephly.net, emacs-devel@gnu.org, stefan@marxist.se, 
>> 	joaotavora@gmail.com, dgutov@yandex.ru
>> Date: Sun, 21 Jun 2020 01:25:15 +0300
>> 
>> So, I recalculated by looking at date of the last commit of those "500" in GCC,
>> and used that date on Clang. I made sure to sort out other corporate mails too.
>> Command I used is:
>> 
>> 	git log --since="Jun 8 21:34:46" --format="%ae" | grep -vP
>> "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
>> odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
>> oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
>> five|imagelabs|xilinx|sap|sas|sigmatechnology|sonarsource|ericsson|lowrisc|hight
>> ec-rt|polymagelabs)\.(org|com|de|cz|cn|ai|se)" | sort -u | wc -l
>> 
>> So, now GCC still gets 15, while for Clang this number gets increased to 89.
>
> This metric is irrelevant.  Basically, you removed everyone who was a
> prominent developer, so it's little wonder that you are left with a
> small number.  Using such arbitrary criteria, one can "prove" anything
> for any project.
>
> Once again, the long history and the active development of GCC over
> those long years are a clear evidence that your criterion is
> completely off the mark.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-21 at 01:08 -0400, Stefan Monnier wrote:
> I haven't followed this thread very closely, but it seems we've strayed
> far enough away from Emacs that it's become quite offtopic.

Yeah, it probably did.

> I may be wrong (since I haven't followed the thread very closely) but my
> understanding is that Konstantin would like it for Emacs to accept
> submission using a "merge request" model or something like that.
> 
> We've discussed this many times in the past.  IIUC, we're slowly going
> there (see https://libreplanet.org/wiki/Fsf_2019_forge_evaluation), but
> we're an old project, and those people who most contribute to Emacs tend
> not to go very much for the shiny new stuff, so if you like the shiny
> new stuff I recommend you a healthy dose of patience.

Yeah, that was one of points I mentioned in my 1st email. Thanks for the link!

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-21 at 05:35 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: rekado@elephly.net, emacs-devel@gnu.org, stefan@marxist.se, 
> > 	joaotavora@gmail.com, dgutov@yandex.ru
> > Date: Sun, 21 Jun 2020 01:25:15 +0300
> > 
> > So, I recalculated by looking at date of the last commit of those "500" in
> > GCC,
> > and used that date on Clang. I made sure to sort out other corporate mails
> > too.
> > Command I used is:
> > 
> > 	git log --since="Jun 8 21:34:46" --format="%ae" | grep -vP
> > "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huaw
> > ei|c
> > odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|mi
> > cros
> > oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcprojec
> > t|si
> > five|imagelabs|xilinx|sap|sas|sigmatechnology|sonarsource|ericsson|lowrisc|h
> > ight
> > ec-rt|polymagelabs)\.(org|com|de|cz|cn|ai|se)" | sort -u | wc -l
> > 
> > So, now GCC still gets 15, while for Clang this number gets increased to 89.
> 
> This metric is irrelevant.  Basically, you removed everyone who was a
> prominent developer, so it's little wonder that you are left with a
> small number.  Using such arbitrary criteria, one can "prove" anything
> for any project.
> 
> Once again, the long history and the active development of GCC over
> those long years are a clear evidence that your criterion is
> completely off the mark.

I thought I brought counter-arguments to both of your points in my previous email. Anyway, as Stefan mentioned, it is getting offtopic, so maybe let's not continue discussing GCC and Clang.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

> 
>>>    git log -500 --format="%ae" | grep -vP
>>> "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huaw
>>> ei|c
>>> odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|mi
>>> cros
>>> oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcprojec
>>> t|si
>>> five)\.(org|com|de|cz|cn)" | sort -u | wc -l
>>> 
>>> Results are:
>>> * GCC as of commit 445d8da5fbd: 15
>>> * Clang as of commit 7b201bfcac2: 49
>>> 
>>> This is some pretty big difference! If I expand the commits range, the
>>> difference increases further.
>> 
>> GCC is alive for 33 years, so I think your theory eats dust.  Many of
>> the GCC and GDB developers get paid for their work, but that doesn't
>> mean the project is less viable, and the long history of both GCC and
>> GDB is the proof.
> 
> Okay, let me say beforehand that both GCC and Clang are very active projects
> right now. Just in case, so there's no misunderstanding.
> 
> So, times are changing. In older times there were no standard to development,
> Git was not as popular, development practices are varied too. So, as long you
> could get your patch to a project, any odd contribution requirements were fine,
> they hardly would set a barrier.
> 
> But these days Git got over all other VCSes (and for a reason), so using SVN or
> Perforce, or whatever, is a barrier to contribution. 12 years ago Github was
> founded, and then also the open-source clone Gitlab appeared. These two pretty
> much set the standard development model nowadays (for a reason too). There still
> are projects that use other models, but this is a barrier to contributors.
> 
> What I'm getting at is that your reasoning that since GCC is 33 years old it
> will live on does not work. For a project to "live on" it needs to be active.
> Sure GCC is active! But its activity mainly stems from paid people and
> maintainers. Whereas in Clang a large chunk of it stems from contributors. Let
> me repeat, paid people come and go, so do maintainers (they may burn out, or
> just move on). These contributors are the ones who will become new maintainers
> and the ones who advertise the project in their environment.
> 
> I hope it makes clear the future of what project looks brighter.

I think the point is not “this works for a long time and it must be better than new stuff” but rather the current method _can_ live long (proven by gcc & gdb, etc). If in the future people moves to other shiny new SVN’s and github’s, does the git method still work? 

Yuan

[-- Attachment #2: Type: text/html, Size: 19748 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Sat, Jun 20, 2020, 22:31 Konstantin Kharlamov <hi-angel@yandex.ru> wrote:

>
> > > I also don't think GNU projects are any good to make examples of. This
> is my
> > > general experience of seeing how new projects get under GNU umbrella
> to get
> > > never heard of (which I attribute to points listed in my starting mail,
> > > since
> > > most of them are unspecific to Emacs).
> >
> > I hope you realize how saying that makes your opinions matter much
> > less, do you?
>
> No, I don't.


I think what Eli and Ricardo (and now me), are trying to alert you to is
that starting a discussion about working methods of GNU projects from a
position of such a broad disdain of such projects ("not any good to make
examples of") is nonsensical and likely leads to your arguments being
ignored, regardless of how sophisticated they are (even though they aren't).

João

[-- Attachment #2: Type: text/html, Size: 1367 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-21 at 14:49 +0100, João Távora wrote:
> On Sat, Jun 20, 2020, 22:31 Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
> > > > I also don't think GNU projects are any good to make examples of. This
> > is my
> > > > general experience of seeing how new projects get under GNU umbrella to
> > get
> > > > never heard of (which I attribute to points listed in my starting mail,
> > > > since
> > > > most of them are unspecific to Emacs).
> > >
> > > I hope you realize how saying that makes your opinions matter much
> > > less, do you?
> > 
> > No, I don't.
> 
> I think what Eli and Ricardo (and now me), are trying to alert you to is that
> starting a discussion about working methods of GNU projects from a position of
> such a broad disdain of such projects ("not any good to make examples of") is
> nonsensical and likely leads to your arguments being ignored, regardless of
> how sophisticated they are (even though they aren't).

Thank you for elaboration! Well, someone's position per se can not make her/his
arguments more or less valid. They may contradict the position, or they may be
less or more valid… But it is impossible to make correct judgement of arguments
by looking at position alone.

Those (hopefully) hypothetical people basically smugly declare "I am right
because I know I am". Great for them! Bad for others though, because even if
they were right, no one but themselves will know that.

Idk, maybe because I had too wide experience, having contributed to dozens of
unrelated projects, having used a dozen of programming languages in various
paradigms, and having tried to grok various mathematical stuff, but one thing I
used to understand is: "However I am sure I am right, I may turn out to be
wrong". I wish those mentioned people had that understanding.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Ricardo Wurmus]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> I also don't think GNU projects are any good to make examples of. This is my
> general experience of seeing how new projects get under GNU umbrella to get
> never heard of (which I attribute to points listed in my starting mail, since
> most of them are unspecific to Emacs).

This is where I stopped reading and considering your points to be valid.

There are countless things that determine whether a person will
contribute to a project or not — even projects that you “don’t think […]
are any good”.  Pinning a complex behaviour on commit message format is
beyond ludicrous.

-- 
Ricardo

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-20 at 22:57 +0200, Ricardo Wurmus wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > I also don't think GNU projects are any good to make examples of. This is my
> > general experience of seeing how new projects get under GNU umbrella to get
> > never heard of (which I attribute to points listed in my starting mail,
> > since
> > most of them are unspecific to Emacs).
> 
> This is where I stopped reading and considering your points to be valid.

lol. This is a very helpful mail, thanks for contributing to discussion!

> There are countless things that determine whether a person will
> contribute to a project or not — even projects that you “don’t think […]
> are any good”.  Pinning a complex behaviour on commit message format is
> beyond ludicrous.

I didn't.

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Ricardo Wurmus]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> 5. As a contributor, when I stumble upon a bug I could fix in
> software, first thing I usually do is go check it is not fixed in
> latest code and that there's no pending merge/pull requests that seem
> to fix that same thing. So, for example, I want to see pending
> patchsets to python-mode, can I do that with Emacs
> "bug-patch-tracker"? No, with debbugs.gnu.org you can either find
> pending patchsets, or you can make a text search, but over everything:
> bugs, patchsets, closed or not…

For the Guix project I wrote Mumi[1], an alternative web frontend to
Debbugs, which can be seen here:

    https://issues.guix.gnu.org

The idea was to provide something that’s reminiscent of the Github
experience without abandoning what’s great about the mail-based
workflow.

The official Debbugs web interface also allows you to filter by
submissions with patches and by status, though it may not be easily
discoverable how to do that.

-- 
Ricardo

[1]: https://git.elephly.net/software/mumi.git

Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Wed, 2020-06-17 at 05:58 +0200, Ricardo Wurmus wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > 5. As a contributor, when I stumble upon a bug I could fix in
> > software, first thing I usually do is go check it is not fixed in
> > latest code and that there's no pending merge/pull requests that seem
> > to fix that same thing. So, for example, I want to see pending
> > patchsets to python-mode, can I do that with Emacs
> > "bug-patch-tracker"? No, with debbugs.gnu.org you can either find
> > pending patchsets, or you can make a text search, but over everything:
> > bugs, patchsets, closed or not…
> 
> For the Guix project I wrote Mumi[1], an alternative web frontend to
> Debbugs, which can be seen here:
> 
>     https://issues.guix.gnu.org
> 
> The idea was to provide something that’s reminiscent of the Github
> experience without abandoning what’s great about the mail-based
> workflow.

Cool, it looks very nice!

> The official Debbugs web interface also allows you to filter by
> submissions with patches and by status, though it may not be easily
> discoverable how to do that.

Oh, right, I stand corrected: the "advanced text search" has also a button
called "add attribute", where you can type Bug Title → Includes String →
"[PATCH]"

Re: Making Emacs more friendly to newcomers

[Po Lu]

Sébastien Gendre <seb@k-7.ch> writes:


> Let's see some use-cases:
> - Bob: A newcomer, who just discover Emacs. He search somthing who is
>   visually modern, with all features he need to start writing code in
>   most popular languages: Code colouration, auto-completion, code
>   navigation, code documentation and functions/methods signature
>   automatically shown, code errors/warnings signalling, REPL
>   integration, snippets, strong GIT integration, etc. He also want to
>   use basic features without the need to read a tutorial. Just install
>   and go. But he is ok to read some tuto or manuals for advanced
>   features. If we ask him question(s) about what to enable or not, he
>   probably cannot respond (or thing he cannot). For him, Emacs need to
>   be the most out of the box possible.
> - Alice: A long time user. She got a personal Emacs configuration she
>   had perfected over the years. She chose herself what system is used
>   to show function completion, which code parser is used for her daily
>   used languages. She add some packages to integrate with special
>   tools used at her work. Emacs is her home and office: She use it as
>   much for her personal project than for her work. She also made a
>   personal workflow with org-mode and write some personal Elisp
>   functions and advices. She forge the tools to her need. She do not
>   want to have an update of Emacs who break her configuration, her
>   workflow or her muscle memory.
> - Mei: She simply want to use SpaceEmacs. She need to be sure
>   SpaceEmacs would work out of the box and be able to override all
>   defaults Emacs configuration. So SpaceEmacs developers need a way to
>   doing their work without the need to deactivate a hundred of default
>   features one after another and risk to forget one. This possibility
>   should be well documented. As the need of Mei is covered by
>   SpaceEmacs, she doesn't have special request about Emacs except make
>   it easy to use SpaceEmacs.
> - Roberto: He work on a pre-configuration of Emacs, similar to
>   SpaceEmacs. He need a simple and documented way to deactivate all
>   default configurations that would make is work difficult. If
>   possible, in one move. And, of course, he need to know what is
>   deactivated so he can choose wisely what to enable and what to not.

You have summed up the use-cases rather well.  Thanks.

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages
> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything
> And these 2 flavors can be in the same text editor: For switch from a
> flavor to another, simply enable the global-minor-mode `vanilla-mode`.
> And if Emacs detect, after an update or a first start, an already
> existing configuration that it could break because of some features:
> Emacs simply activate `vanilla-mode` automatically.

I'm afraid it's not that simple.  I don't think we need any radical
changes in Emacs to be turned on by default, but maybe something like a
set-up wizard or "New to Emacs? Click here" would be useful.

> - Alice update Emacs. When she restart it, Emacs detect an already
>   existing configuration that it could break by enabling some
>   features. So, Emacs simply enable `vanilla-mode` and add it to the
>   `init.el`. Emacs also show a message to Alice: "Emacs detected that
>   you have some personal configuration, so it active Vanilla-mode to
>   avoid breaking your configuration. Vanilla-mode deactivate some
>   features that you can re-enable manually.". This message is
>   accompanied by a clickable link to the documentation about the
>   `vanilla-mode` to see what it does in the details and what is
>   deactivate.

I'm not sure whether Emacs can reliably detect updates or not.  IIRC,
there was a discussion a while back that said no.  Plus, as I've
previously mentioned, I don't think Emacs should adopt any drastic
changes as the default configuration, but instead make the changes
easily discoverable.  (or at least until all of us old farts have had
another decade or 2 to adjust).

Re: Making Emacs more friendly to newcomers

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> Sébastien Gendre <seb@k-7.ch> writes:
>
>
>> Let's see some use-cases:
>> - Bob: A newcomer, who just discover Emacs. He search somthing who is
>>   visually modern, with all features he need to start writing code in
>>   most popular languages: Code colouration, auto-completion, code
>>   navigation, code documentation and functions/methods signature
>>   automatically shown, code errors/warnings signalling, REPL
>>   integration, snippets, strong GIT integration, etc. He also want to
>>   use basic features without the need to read a tutorial. Just install
>>   and go. But he is ok to read some tuto or manuals for advanced
>>   features. If we ask him question(s) about what to enable or not, he
>>   probably cannot respond (or thing he cannot). For him, Emacs need to
>>   be the most out of the box possible.
>> - Alice: A long time user. She got a personal Emacs configuration she
>>   had perfected over the years. She chose herself what system is used
>>   to show function completion, which code parser is used for her daily
>>   used languages. She add some packages to integrate with special
>>   tools used at her work. Emacs is her home and office: She use it as
>>   much for her personal project than for her work. She also made a
>>   personal workflow with org-mode and write some personal Elisp
>>   functions and advices. She forge the tools to her need. She do not
>>   want to have an update of Emacs who break her configuration, her
>>   workflow or her muscle memory.
>> - Mei: She simply want to use SpaceEmacs. She need to be sure
>>   SpaceEmacs would work out of the box and be able to override all
>>   defaults Emacs configuration. So SpaceEmacs developers need a way to
>>   doing their work without the need to deactivate a hundred of default
>>   features one after another and risk to forget one. This possibility
>>   should be well documented. As the need of Mei is covered by
>>   SpaceEmacs, she doesn't have special request about Emacs except make
>>   it easy to use SpaceEmacs.
>> - Roberto: He work on a pre-configuration of Emacs, similar to
>>   SpaceEmacs. He need a simple and documented way to deactivate all
>>   default configurations that would make is work difficult. If
>>   possible, in one move. And, of course, he need to know what is
>>   deactivated so he can choose wisely what to enable and what to not.
>
> You have summed up the use-cases rather well.  Thanks.
>
>> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
>> - Emacs: With all the 2020 features, a modern interface, all needed
>>   modern features to start coding with most popular languages and easy
>>   to use for basic usages
>> - Emacs Vanilla: All the new features are still there, but deactivate
>>   to not break anything
>> And these 2 flavors can be in the same text editor: For switch from a
>> flavor to another, simply enable the global-minor-mode `vanilla-mode`.
>> And if Emacs detect, after an update or a first start, an already
>> existing configuration that it could break because of some features:
>> Emacs simply activate `vanilla-mode` automatically.
>
> I'm afraid it's not that simple.  I don't think we need any radical
> changes in Emacs to be turned on by default, but maybe something like a
> set-up wizard or "New to Emacs? Click here" would be useful.

I can’t understand why you’re so opposed to changing defaults. Defaults
matter, and I think that users who are already accustomed to Emacs will
have an easier time changing options. (Like adding `(vanilla-mode 1)`
to init.el.)

>> - Alice update Emacs. When she restart it, Emacs detect an already
>>   existing configuration that it could break by enabling some
>>   features. So, Emacs simply enable `vanilla-mode` and add it to the
>>   `init.el`. Emacs also show a message to Alice: "Emacs detected that
>>   you have some personal configuration, so it active Vanilla-mode to
>>   avoid breaking your configuration. Vanilla-mode deactivate some
>>   features that you can re-enable manually.". This message is
>>   accompanied by a clickable link to the documentation about the
>>   `vanilla-mode` to see what it does in the details and what is
>>   deactivate.
>
> I'm not sure whether Emacs can reliably detect updates or not.

Adding a variable that makes Emacs warn if it’s version number is
different from its value might work.

> IIRC,
> there was a discussion a while back that said no.  Plus, as I've
> previously mentioned, I don't think Emacs should adopt any drastic
> changes as the default configuration, but instead make the changes
> easily discoverable.

The features that are best discoverable are the ones that are default.

> (or at least until all of us old farts have had
> another decade or 2 to adjust).

Defaults have to change for experienced users to adjust. And for them,
adjusting is an easy task, not something that takes a decade.

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I can’t understand why you’re so opposed to changing defaults. Defaults
> matter, and I think that users who are already accustomed to Emacs will
> have an easier time changing options. (Like adding `(vanilla-mode 1)`
> to init.el.)

I oppose changing defaults, because I value my tools remaining stable.
Having to frequently adjust my user-emacs-directory to encompass the
latest fancy new idea is an unacceptable maintenance burden to me.  Not
to mention in practice, those changes are going to be far larger than a
hypothetical `vanilla-mode'.

> Adding a variable that makes Emacs warn if it’s version number is
> different from its value might work.

I'm not sure what you're talking about; Variables don't persist across
Emacs sessions.

> The features that are best discoverable are the ones that are default.

And since changing the defaults radically end up hurting existing users,
and also existing packages and potentially the existing ecosystem.  You
have to find a balance between that, and changing the defaults is not
the balance you want.

> Defaults have to change for experienced users to adjust. And for them,
> adjusting is an easy task, not something that takes a decade.

"For existing users to adjust" is not an excuse -- that puts an extra
burden on users.

Re: Making Emacs more friendly to newcomers

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> I can’t understand why you’re so opposed to changing defaults. Defaults
>> matter, and I think that users who are already accustomed to Emacs will
>> have an easier time changing options. (Like adding `(vanilla-mode 1)`
>> to init.el.)
>
> I oppose changing defaults, because I value my tools remaining stable.
> Having to frequently adjust my user-emacs-directory to encompass the
> latest fancy new idea is an unacceptable maintenance burden to me.

Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
‘vanilla-mode’ will be the current situation of Emacs - it will try to
be stable.

> Not
> to mention in practice, those changes are going to be far larger than a
> hypothetical `vanilla-mode'.

Why? If you’re fine with the current level of changes in Emacs, that would
be the level of changes in ‘vanilla-mode’.

>> Adding a variable that makes Emacs warn if it’s version number is
>> different from its value might work.
>
> I'm not sure what you're talking about; Variables don't persist across
> Emacs sessions.

I’m saying that one can add a variable like ‘expected-emacs-version’ and
when Emacs is loading init.el and ‘expected-emacs-version’ is different
from the current version, Emacs can warn you.

>> The features that are best discoverable are the ones that are default.
>
> And since changing the defaults radically end up hurting existing users,

No, it doesn’t. Better defaults help users and allow them to lighten their
configuration.

> and also existing packages and potentially the existing ecosystem.  You
> have to find a balance between that, and changing the defaults is not
> the balance you want.

The balance I’m suggesting (actually ndame) is to add a ‘vanilla-mode’ for
people who value stability over features.

>> Defaults have to change for experienced users to adjust. And for them,
>> adjusting is an easy task, not something that takes a decade.
>
> "For existing users to adjust" is not an excuse -- that puts an extra
> burden on users.

No, it doesn’t - see previous comments.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Mon, 20 Apr 2020 22:07:55 +0900
> Cc: Sébastien Gendre <seb@k-7.ch>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
> ‘vanilla-mode’ will be the current situation of Emacs - it will try to
> be stable.

It's not that simple.  Some features that are turned on cannot be
easily turned off afterwards.

> > And since changing the defaults radically end up hurting existing users,
> 
> No, it doesn’t. Better defaults help users and allow them to lighten their
> configuration.

Experience shows that you are in disagreement with a large bulk of our
users.  They tend to complain loudly when they bump into some changes
of defaults that they dislike, or find that behavior they were
accustomed to changed too radically.

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:


> Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
> ‘vanilla-mode’ will be the current situation of Emacs - it will try to
> be stable.

Experience shows that major changes are not as easy to revert as a
single `(vanilla-mode 1)'.

> Why? If you’re fine with the current level of changes in Emacs, that would
> be the level of changes in ‘vanilla-mode’.

What do you mean?  I haven't seen the default binding for `C-v` changed
in about 25 years.  It would be a shame if it changed now.

> I’m saying that one can add a variable like ‘expected-emacs-version’ and
> when Emacs is loading init.el and ‘expected-emacs-version’ is different
> from the current version, Emacs can warn you.

That assumes the person with the config puts that variable in, and
anyway it makes for more maintenance burden.


> No, it doesn’t. Better defaults help users and allow them to lighten their
> configuration.

There is no "better default".  There's only the default that remains
stable and so far happens to work for everyone.

> The balance I’m suggesting (actually ndame) is to add a ‘vanilla-mode’ for
> people who value stability over features.

You can't stuff major changes in a `vanilla-mode'.

> No, it doesn’t - see previous comments.

Yes it does.  I can't be bothered to put an extra line in my .emacs for
every tiny change users decide they want.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 05:06, Po Lu wrote:
>> No, it doesn’t - see previous comments.
> Yes it does.  I can't be bothered to put an extra line in my .emacs for
> every tiny change users decide they want.

Please keep in mind that if we hope to make Emacs reach, say, 30% share 
among programmers, the extra 25% would be new users.

So for all questions about changing defaults, we should ask ourselves, 
do we prioritize the existing 5% (or 3%, as SO poll says) userbase that 
will naturally continue shrinking over the years, or whether we prefer 
to make life easier and more productive for the users that should come 
later.

And it's not like existing, long-time users can't grow to like the new 
defaults (even after a certain amount of grumbling). I think the Xref 
example shows that.

Re: Making Emacs more friendly to newcomers

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Please keep in mind that if we hope to make Emacs reach, say, 30%
> share among programmers, the extra 25% would be new users.

We should prioritize existing users over hypothetical users that don't
even exist yet.

> So for all questions about changing defaults, we should ask ourselves,
> do we prioritize the existing 5% (or 3%, as SO poll says) userbase
> that will naturally continue shrinking over the years, or whether we
> prefer to make life easier and more productive for the users that
> should come later.

One exists.  The other doesn't.
Which one would you choose?

> And it's not like existing, long-time users can't grow to like the new
> defaults (even after a certain amount of grumbling). I think the Xref 
> example shows that.

Xref was bad enough.  Changing C-a to "select all" would be worse.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 07:42, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Please keep in mind that if we hope to make Emacs reach, say, 30%
>> share among programmers, the extra 25% would be new users.
> 
> We should prioritize existing users over hypothetical users that don't
> even exist yet.

And then, another 20 years pass, the current users get too old/change 
careers/retire/etc, and Emacs's userbase shrinks even more.

I don't want Emacs to die out, and it will if we don't do the work of 
attracting new users.

>> So for all questions about changing defaults, we should ask ourselves,
>> do we prioritize the existing 5% (or 3%, as SO poll says) userbase
>> that will naturally continue shrinking over the years, or whether we
>> prefer to make life easier and more productive for the users that
>> should come later.
> 
> One exists.  The other doesn't.
> Which one would you choose?

Also note that we don't really have the ability to poll even our 
existing users, to find out whether they would like a given change. Even 
disregarding those who would change their mind later.

>> And it's not like existing, long-time users can't grow to like the new
>> defaults (even after a certain amount of grumbling). I think the Xref
>> example shows that.
> 
> Xref was bad enough. 

Give it time.

> Changing C-a to "select all" would be worse.

I didn't talk about that, but...

I think it's possible to support two sets of keybindings. That's 
definitely extra work, though.

Including simply designing a set of bindings that is both compatible 
with CUA and yet retains the current design principles to some extent 
(so far I have no good ideas on that front).

How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Also note that we don't really have the ability to poll even our 
  > existing users,

We have done it many times.  Here's the method I developed for polls
in the past:

* Make a file for the replies to go into.

* Make a mailing address which drops all mail into the file.

* Mail to info-gnu-emacs and help-gnu-emacs, and any other suitable
place, presenting the proposed change in sufficient detail that people
can judge it, and where to email the response, as well as what kind of
information we seek.

What we seek is not "votes", but understanding.  If you are for the
change, please explain why.  Would it help you directly?  If so, in
what scenario, and what would the benefit be?  And how important?

Or is it that you think it will help Emacs development by helping
others?  Please distinguish between what you know and what you guess.

Likewise, if you are against the change, please explain why.  Would it
inconvenience you directly?  If so, in what scenario, and what would
the inconvenience be?  And how important?

Or is it that you think it will harm Emacs development by
inconveniencing others?

We invite you also to propose changes in the proposal that would
improve it, for you -- saying in what scenario, and how.

* We state a deadline some weeks in the future, but since there is no
hurry, we wait some extra time before we look at the responses.

* Ultimately, we do not restrict ourselves to choosing between "make
the change" and "don't make it".  The best outcome is that the
feedback enables us to design a way to please almost everyone.




-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

Hi Richard,

I'd like to reply to that email more thoroughly, but for now:

On 22.04.2020 06:14, Richard Stallman wrote:
> * Mail to info-gnu-emacs and help-gnu-emacs, and any other suitable
> place, presenting the proposed change in sufficient detail that people
> can judge it, and where to email the response, as well as what kind of
> information we seek.

How many subscribers do these mailing lists have?

For comparison, the StackOverflow surveys we've seen mentioned in this 
thread count about 4000 dedicated Emacs users (that filled out the 
survey). The Emacs StackExchange site has around 20'000 registered 
users. The Emacs subreddit has almost 40'000 subscribers.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > * Mail to info-gnu-emacs and help-gnu-emacs, and any other suitable
  > > place, presenting the proposed change in sufficient detail that people
  > > can judge it, and where to email the response, as well as what kind of
  > > information we seek.

  > How many subscribers do these mailing lists have?

I don't know.  Do you?

We could ask the FSF sysadmins.

  > For comparison,

Those two lists are the only ways I know of to reach Emacs users.

I don't know of any other suitable places, but it is good to find
more.

		    the StackOverflow surveys we've seen mentioned in this 
  > thread count about 4000 dedicated Emacs users (that filled out the 
  > survey). The Emacs StackExchange site has around 20'000 registered 
  > users. The Emacs subreddit has almost 40'000 subscribers.

I have never used StackExchange or Reddit, and I don't know how they
are structured.  Are you suggesting them as additional places to send
our polls to?

Have you got any other suggestions of places?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 25.04.2020 06:37, Richard Stallman wrote:

>    > > * Mail to info-gnu-emacs and help-gnu-emacs, and any other suitable
>    > > place, presenting the proposed change in sufficient detail that people
>    > > can judge it, and where to email the response, as well as what kind of
>    > > information we seek.
> 
>    > How many subscribers do these mailing lists have?
> 
> I don't know.  Do you?

I can only guess. I was wondering if my rough intuition was true, 
though. And I think comparing the numbers might give us insight into 
which fraction of our users is really comfortable with email as a 
discussion medium.

> We could ask the FSF sysadmins.

If it's not too much trouble, please do.

> 		    the StackOverflow surveys we've seen mentioned in this
>    > thread count about 4000 dedicated Emacs users (that filled out the
>    > survey). The Emacs StackExchange site has around 20'000 registered
>    > users. The Emacs subreddit has almost 40'000 subscribers.
> 
> I have never used StackExchange or Reddit, and I don't know how they
> are structured.  Are you suggesting them as additional places to send
> our polls to?

Pretty much. Reddit also has a "polls" feature, where it could aggregate 
the answers for us. They also have comments for when someone wants to 
leave an additional explanation.

Because handling thousands of response emails (which is what might 
happen if people are interested enough) by hand is too much, I think. 
Even just a few hundreds.

> Have you got any other suggestions of places?

The ones I mentioned are the biggest ones I know.

Speaking of the default values, what do you think about using your 
scenario to ask the users about their preferred value of 
indent-tabs-mode? I can create a poll with four options: "strong tabs 
preference", "strong spaces preference", "mild tabs preference", "mild 
spaces preference". People can add extra explanations in comments.

This particular subject has endured some heated discussion in the past, 
and we never managed to agree enough to change it. But we never asked 
the users at large either. According to my data, most of them should 
prefer spaces.

If I do create a poll, and the outcome would strongly indicate a change 
of the default, we'd pretty much have to change it then, though.

RE: How to poll the users

[Drew Adams]

> > > Emacs StackExchange site has around 20'000 registered
> > > users. The Emacs subreddit has almost 40'000 subscribers.
> >
> > ... Have you got any other suggestions of places?
> 
> The ones I mentioned are the biggest ones I know.

Also:

https://stackoverflow.com/questions/tagged/emacs

https://superuser.com/questions/tagged/emacs

> ask the users about their preferred value of indent-tabs-mode? ...
> 
> This particular subject has endured some heated discussion in the past,
> and we never managed to agree enough to change it. But we never asked
> the users at large either. According to my data, most of them should
> prefer spaces.

FWIW, there's an Emacs Wiki page for that topic:

https://www.emacswiki.org/emacs/NoTabs

> If I do create a poll, and the outcome would strongly indicate a change
> of the default, we'd pretty much have to change it then, though.

FWIW, I don't agree with that conclusion, in the abstract.

[ But I do prefer spaces-only, personally.  And beyond a
preference for using that within Emacs, when pasting code
copied from Emacs into other apps (e.g. Q&A on the web
sites mentioned), if you have a non-nil value then you
need to first use `M-x untabify', or else manually
reformat everything after pasting. ]

Re: How to poll the users

[Dmitry Gutov]

On 25.04.2020 18:35, Drew Adams wrote:
>>>> Emacs StackExchange site has around 20'000 registered
>>>> users. The Emacs subreddit has almost 40'000 subscribers.
>>>
>>> ... Have you got any other suggestions of places?
>>
>> The ones I mentioned are the biggest ones I know.
> 
> Also:
> 
> https://stackoverflow.com/questions/tagged/emacs
> 
> https://superuser.com/questions/tagged/emacs

Right. But these seem smaller, and I'm not sure we can do any polls on 
stackexchange/stackoverflow anyway.

>> If I do create a poll, and the outcome would strongly indicate a change
>> of the default, we'd pretty much have to change it then, though.
> 
> FWIW, I don't agree with that conclusion, in the abstract.

If the poll doesn't contain an implicit promise (e.g. "we considering a 
change of default"), the turnout is likely to be much lower. Which is 
not what we want, I think.

Re: How to poll the users

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> If the poll doesn't contain an implicit promise (e.g. "we considering a
> change of default"), the turnout is likely to be much lower. Which is
> not what we want, I think.

I agree.  I would add I think this could be an important way for
emacs-devel to interact with regular users, and make them feel more
involved.

I don't want to come across as negative towards your suggestion to
create a poll, which I think is an excellent initiative.  But perhaps
we could consider if there are more pressing or engaging questions to
put before our users.  The tabs vs spaces debate feels a little bit
dated, at least to me, and possibly not even that important since it's
so easy to configure to your liking.

Perhaps we could even consider asking for their input on a number of
important questions (not too many, say 4-5) where it would be
interesting to get feedback.  Ideally we would try to choose questions
strategically to inspire excitement for Emacs development.  (Tabs vs
spaces could of course be one of them.)

Just some food for thought.  Either way you decide, I'm sure I'll be
happy with the outcome.

Best regards,
Stefan Kangas

Re: How to poll the users

[Dmitry Gutov]

On 25.04.2020 19:15, Stefan Kangas wrote:

> I don't want to come across as negative towards your suggestion to
> create a poll, which I think is an excellent initiative.  But perhaps
> we could consider if there are more pressing or engaging questions to
> put before our users.  The tabs vs spaces debate feels a little bit
> dated, at least to me, and possibly not even that important since it's
> so easy to configure to your liking.

I don't know about that. It's definitely not urgent, but it's a fairly 
simple question (unlike some others we might ask), and I think the 
default behavior of mixing tabs with spaces constitutes a point of 
confusion for new Emacs users to this day.

> Perhaps we could even consider asking for their input on a number of
> important questions (not too many, say 4-5) where it would be
> interesting to get feedback.  Ideally we would try to choose questions
> strategically to inspire excitement for Emacs development.  (Tabs vs
> spaces could of course be one of them.)

I think we should only ask one question at a time. Creating multiple 
polls is an option, of course, but we could just as well wait a little 
between them.

And if indent-tabs-mode is not important in your opinion (it's just the 
first thing that came to my mind), do you want to come up with some 
other questions?

Re: How to poll the users

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I don't know about that. It's definitely not urgent, but it's a fairly
> simple question (unlike some others we might ask), and I think the
> default behavior of mixing tabs with spaces constitutes a point of
> confusion for new Emacs users to this day.

OK, you convinced me.

> I think we should only ask one question at a time. Creating multiple
> polls is an option, of course, but we could just as well wait a little
> between them.

Yes, it's not immediately obvious which way is better.  So let's keep
it simple and do what you suggest.

> And if indent-tabs-mode is not important in your opinion (it's just the
> first thing that came to my mind), do you want to come up with some
> other questions?

If I was to design a series of questions, they would probably be about
more "soft" aspects of the project, regarding things we are discussing
in other threads: how to get more people involved in Emacs core
development, contributing to GNU ELPA, etc.  Of course, nothing is
resolved with merely sending out a poll, but I imagine it would help
gauge the situation and make us feel more confident about which
direction to take.

Best regards,
Stefan Kangas

Re: How to poll the users

[Dmitry Gutov]

On 26.04.2020 18:25, Stefan Kangas wrote:
> how to get more people involved in Emacs core
> development, contributing to GNU ELPA, etc.  Of course, nothing is
> resolved with merely sending out a poll, but I imagine it would help
> gauge the situation and make us feel more confident about which
> direction to take

I think we've had those discussion on Reddit many times before already, 
and some of it comes down to doing the work (e.g. setting up GitLab in a 
way to keep both the wolf and the sheep happy, which is a lot of work, 
in this case).

Maybe some more, more specific questions could lead to new insights, though.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > If the poll doesn't contain an implicit promise (e.g. "we considering a
  > > change of default"), the turnout is likely to be much lower. Which is
  > > not what we want, I think.

  > I agree.  I would add I think this could be an important way for
  > emacs-devel to interact with regular users, and make them feel more
  > involved.

A poll of the users is not about counting votes.  The aim is to learn
more about what users find convenient or inconvenient, and especially
how and why it is convenient or inconvenient.

The ideal outcome is NOT that we choose the default that 65% of the
users prefer rather than the one 25% prefer.  Rather, the ideal
outcome is to invent another option that nearly everyone will like.

The only proper "promise" to make is that we will use what we learn
from the poll to make Emacs better.

  > Perhaps we could even consider asking for their input on a number of
  > important questions (not too many, say 4-5) where it would be
  > interesting to get feedback.

Responses of "yes" or "no" are not very helpful, because they give us
little understanding.  We seek responses that tell us more than that.
To encourage users to think about and report why and how certain
behaviors help them or annoy them, we raise one issue at a time.

If there are several issues we want to learn more about, we do
separate polls about them.  We can do as many polls as we like,
subject to the limits on our time to study the results.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: How to poll the users

[Drew Adams]

> >> If I do create a poll, and the outcome would strongly indicate a
> >> change of the default, we'd pretty much have to change it then, though.
> >
> > FWIW, I don't agree with that conclusion, in the abstract.
> 
> If the poll doesn't contain an implicit promise (e.g. "we considering a
> change of default"), the turnout is likely to be much lower. Which is
> not what we want, I think.

tl;dr: Poll results are one, and only one consideration.

---

An implicit promise to consider is not the same thing
as a position that a poll outcome strongly indicates
that the default should be changed.

It may or may not strongly indicate an opinion by the
people who responded, and that may or may not be
strongly relevant to the question.

And just having a poll suggests that there will be
consideration of the poll results, and that such
consideration could include the question of changing
the default.

And if the question of default change is really part
of the question at hand then it should be explicitly
part of the poll.  E.g. not just "What's your use or
preference, personally?" but also "Do you think your
preferred behavior should be the default behavior?

The point is that default-changing is (should be) a
case-by-case decision.  And it can be (and usually
is) based on multiple considerations - not just a
user poll.  One question about polls is their
representation, who the responders are, what their
relation to the question (e.g. their use of Emacs)
is, etc.

I said I didn't agree with your conclusion _in the
abstract_.  That's the problem with it.  It might
be a reasonable conclusion in some particular case
(some particular poll question).  But it's not
reasonable as an abstract proposition.

Re: How to poll the users

[Dmitry Gutov]

On 25.04.2020 19:20, Drew Adams wrote:
> It may or may not strongly indicate an opinion by the
> people who responded, and that may or may not be
> strongly relevant to the question.

Hence the four answer options I suggested.

> And if the question of default change is really part
> of the question at hand then it should be explicitly
> part of the poll.  E.g. not just "What's your use or
> preference, personally?" but also "Do you think your
> preferred behavior should be the default behavior?

Yes, of course.

RE: How to poll the users

[Drew Adams]

> > Also:
> > stackoverflow.com/questions/tagged/emacs
> > superuser.com/questions/tagged/emacs
> 
> Right. But these seem smaller

Super User is limited in the number of Emacs questions, certainly (1,643 questions).

Stack Overflow is NOT limited.  It has 16,700 Emacs questions.  emacs.StackExchange has 18,717 questions.  In other words, they are about the same size.  And there's a fair amount of overlap in the kinds of questions they have.

But the number of questions is only one consideration.  Each of those Stack Exchange sites offers a different mix of users.

In particular, the users of those other sites are programmers of all sorts, people for whom Emacs is not necessarily the be-all and end-all of their lives, people who often primarily want to use Emacs for programming.

That's important, I think.  Emacs questions on Stack Overflow may be less oriented toward things like Org mode, image display, faces, etc., and more oriented toward programming.

We want to reach all kinds of Emacs users.  Programmers are a key user group, and many programmers are more likely to ask an Emacs question, or a question that touches on Emacs, on an SE site other than emacs.SE.

And beyond the sites I mentioned, there are other SE sites that have Emacs Q&A, and still others that have Lisp Q&A that is relevant to Elisp.

An SE poll on a site other than emacs.SE should of course be tagged `emacs`.

Re: How to poll the users

[Dmitry Gutov]

On 25.04.2020 19:54, Drew Adams wrote:
> In particular, the users of those other sites are programmers of all sorts, people for whom Emacs is not necessarily the be-all and end-all of their lives, people who often primarily want to use Emacs for programming.

Fair enough.

> An SE poll on a site other than emacs.SE should of course be tagged `emacs`.

How does one make an SE poll, though?

RE: How to poll the users

[Drew Adams]

> How does one make an SE poll, though?

No idea, sorry.  Sounds like a question to be
posed at https://meta.stackexchange.com/.

Well, maybe not.  Searching there a bit I came
across these, which suggest that SE user polls
are not welcome, in general:

https://meta.stackexchange.com/questions/186530/what-close-reason-for-polling-questions

https://meta.stackexchange.com/questions/233908/are-poll-style-questions-ever-acceptable-on-meta-sites

You had said that Stack Overflow (or Stack
Exchange) does polling, and that's certainly true.

But that's the site itself.  It looks like there
may be no good way for someone outside to post a
poll there.

RE: How to poll the users

[Drew Adams]

> FWIW, there's an Emacs Wiki page for that topic:
> 
> https://www.emacswiki.org/emacs/NoTabs

Oops, sorry, I meant this page:

https://www.emacswiki.org/emacs/TabsAreEvil

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Speaking of the default values, what do you think about using your 
  > scenario to ask the users about their preferred value of 
  > indent-tabs-mode? I can create a poll with four options: "strong tabs 
  > preference", "strong spaces preference", "mild tabs preference", "mild 
  > spaces preference". People can add extra explanations in comments.

The idea of a poll is to understand the effects of the various
choices, and find out the specific reasons for users to prefer this or
that, and evaluate their significance -- NOT to count how many people
prefer each choice.

It is a mistake to count the answers, because a given change can
affect one user very often, and affect another user only rarely, but
they might both state a "strong preference".

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 26.04.2020 06:25, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > Speaking of the default values, what do you think about using your
>    > scenario to ask the users about their preferred value of
>    > indent-tabs-mode? I can create a poll with four options: "strong tabs
>    > preference", "strong spaces preference", "mild tabs preference", "mild
>    > spaces preference". People can add extra explanations in comments.
> 
> The idea of a poll is to understand the effects of the various
> choices, and find out the specific reasons for users to prefer this or
> that, and evaluate their significance -- NOT to count how many people
> prefer each choice.

A numbering poll is still somewhat useful, if only to get the general mood.

But in the description we can ask everybody to actually write a comment. 
*Or* upvote one of the existing comments, if it reflects their 
experience accurately.

Both these options together seem to make responses over email (which 
would otherwise be invisible to the public and thus miss out on the 
chance to spur some discussion) unnecessary. But we could also encourage 
people to write emails, if you so prefer.

> It is a mistake to count the answers, because a given change can
> affect one user very often, and affect another user only rarely, but
> they might both state a "strong preference".

I think the time when it affects the users the most is just after Emacs 
is installed for the first time, before they know about this variable, 
and how to customize its value to nil. So it doesn't affect people 
"often", but it does affect a lot of people.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The ones I mentioned are the biggest ones I know.

I will add StackOverflow and Reddit to the list of places
I suggest posting polls.  Thanks.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 26.04.2020 06:25, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > The ones I mentioned are the biggest ones I know.
> 
> I will add StackOverflow and Reddit to the list of places
> I suggest posting polls.  Thanks.

Like Drew described, StackOverflow discourage polls and will likely 
close them as non-constructive. It's a Q&A website, and they don't want 
Q that can elicit an unbounded number of A's.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Like Drew described, StackOverflow discourage polls and will likely 
  > close them as non-constructive. It's a Q&A website, and they don't want 
  > Q that can elicit an unbounded number of A's.

Would they object to posting a reference to a page with a poll
that asks people to answer by email?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 27.04.2020 05:19, Richard Stallman wrote:
>    > Like Drew described, StackOverflow discourage polls and will likely
>    > close them as non-constructive. It's a Q&A website, and they don't want
>    > Q that can elicit an unbounded number of A's.
> 
> Would they object to posting a reference to a page with a poll
> that asks people to answer by email?

There is no good option for that. The main way to post something there 
is to create a "New Question". Then this question will likely be closed 
by the moderators as "non-constructive" and the vast majority of users 
won't see it.

RE: How to poll the users

[Drew Adams]

tl;dr:

 Announce polls widely, beyond GNU ways.
 Have users participate only through GNU ways.

My suggestion would be to perform polls as
you described in the beginning, i.e., how it's
been done in the past.  (See also below; this
could be enhanced.)

But it would be good to _announce_ a poll in
more places than just the Emacs mailing lists.

A poll can be _announced_, with instructions
for participating and an indication of what
the poll is about, on non-GNU sites such as
those mentioned so far - Reddit and the
various Stack Exchange sites (especially
emacs.StackExchange and StackOverflow).

Plus an announcement by Sasha on her blog and
her Emacs-news mail to emacs-tangents@gnu.org.

Announcing a poll in various places, providing
the same info about it, including how to
participate and what is expected, and then
having all users actually participate in more
or less a single location/way, which is
managed by GNU, would be good, I think.

That way to participate could be just what
has been done in the past - by email.  Or it
could be by way of a GNU Emacs website.  Or
by any combination of GNU-controlled methods,
as long as they all feed into the same poll.

Re: How to poll the users

[Dmitry Gutov]

On 26.04.2020 19:56, Drew Adams wrote:
> My suggestion would be to perform polls as
> you described in the beginning, i.e., how it's
> been done in the past.  (See also below; this
> could be enhanced.)

I've already opined on downsides:

everybody having to write the same thing again and again,
closed-ness to the public (you or I can't read the actual replies),
and in the event that a significant number of our users really choose to 
participate, it will result in a crapload of messages that a single 
person has little hope to sort out.

And if every such poll will requires a special setup (configuration by 
the admins, etcetera), it will limit our ability to do them.

RE: How to poll the users

[Drew Adams]

> I've already opined on downsides:
> 
> everybody having to write the same thing again and again,
> closed-ness to the public (you or I can't read the actual replies),
> and in the event that a significant number of our users really choose
> to participate, it will result in a crapload of messages that a single
> person has little hope to sort out.
> 
> And if every such poll will requires a special setup (configuration by
> the admins, etcetera), it will limit our ability to do them.

I don't see how all of those downsides couldn't be
mitigated, providing a GNU site or other means to
serve as single collection point, echoing point
(echoing current counts, text suggestions, etc.),
and even providing a discussion venue.

Nothing says that we need to prevent the public
from seeing the poll results, including comments,
for example.

The point of my suggestion was to not try to have
such polling (interaction, counting, reporting)
be repeated (and likely in differing, possibly
conflicting ways) on sites outside GNU - and
instead to just _announce_ a poll on such outside
venues.

To be clear, nothing should prevent also discussion
etc. on such non-GNU venues.  The point is for GNU
to count, echo, and provide discussion via a GNU
site/mechanism.

IOW, don't try to reproduce the polling here, there
and everywhere.  Just announce it here, there, and
everywhere.  Anyone who wants to discuss a poll
here, there, and everywhere is welcome to do so,
but that discussion will not automatically be
captured as part of the poll itself.

Just one suggestion.

Re: How to poll the users

[Dmitry Gutov]

On 26.04.2020 20:44, Drew Adams wrote:

>> And if every such poll will requires a special setup (configuration by
>> the admins, etcetera), it will limit our ability to do them.
> 
> I don't see how all of those downsides couldn't be
> mitigated, providing a GNU site or other means to
> serve as single collection point, echoing point
> (echoing current counts, text suggestions, etc.),
> and even providing a discussion venue.

I'm not saying it can't be done. I'm saying it hasn't been done, and in 
all likelihood nobody is going to do it.

> IOW, don't try to reproduce the polling here, there
> and everywhere.  Just announce it here, there, and
> everywhere.  Anyone who wants to discuss a poll
> here, there, and everywhere is welcome to do so,
> but that discussion will not automatically be
> captured as part of the poll itself.

I say just do it on Reddit. Any traffic on the mailing list (which I see 
no reason to discourage) will pale in comparison.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't see how all of those downsides couldn't be
  > mitigated, providing a GNU site or other means to
  > serve as single collection point, echoing point
  > (echoing current counts, text suggestions, etc.),
  > and even providing a discussion venue.

I think we should make sure polls do NOT turn into discussions.
Discussions would multiply the bulk of messages and we would not be
able to digest them.

Most of you are brainstorming about what we could do.
I have actually done polls several times.

Having each poll dump messages into its own file was reliable and easy
to set up.  It takes a few minutes to set that up.  It may take an hour
or two to write the posting.  It may take a few hours to study the
responses.  So let's not worry about the few minutes.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't see how all of those downsides couldn't be
  > mitigated, providing a GNU site or other means to
  > serve as single collection point, echoing point
  > (echoing current counts, text suggestions, etc.),
  > and even providing a discussion venue.

I think we should make sure polls do NOT turn into discussions.
Discussions would multiply the bulk of messages and we would not be
able to digest them.

Most of you are brainstorming about what we could do.
I have actually done polls several times.

Having each poll dump messages into its own file was reliable and easy
to set up.  It takes a few minutes to set that up.  It may take an hour
or two to write the posting.  It may take a few hours to study the
responses.  So let's not worry about the few minutes.

  > IOW, don't try to reproduce the polling here, there
  > and everywhere.  Just announce it here, there, and
  > everywhere.  Anyone who wants to discuss a poll
  > here, there, and everywhere is welcome to do so,
  > but that discussion will not automatically be
  > captured as part of the poll itself.

THose points seem right to me.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 27.04.2020 05:22, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > I don't see how all of those downsides couldn't be
>    > mitigated, providing a GNU site or other means to
>    > serve as single collection point, echoing point
>    > (echoing current counts, text suggestions, etc.),
>    > and even providing a discussion venue.
> 
> I think we should make sure polls do NOT turn into discussions.
> Discussions would multiply the bulk of messages and we would not be
> able to digest them.

Only if we use the mailbox approach. And the downside of disallowing a 
discussion is missing out on valuable insights.

> Most of you are brainstorming about what we could do.
> I have actually done polls several times.

With the tools contemporary websites provide, polling is trivial. Many 
people have done it, myself included.

> Having each poll dump messages into its own file was reliable and easy
> to set up.  It takes a few minutes to set that up.  It may take an hour
> or two to write the posting.  It may take a few hours to study the
> responses.  So let's not worry about the few minutes.

Can you digest, say, 2000 free-form emails in a few hours? And then 
summarize all expressed opinions accurately for the other developers to 
understand the results?

Or if you receive only 20 emails, can you have any confidence that the 
received feedback describes the community with any sort of accuracy?

And in this particular case, numbers are important as well. The 
arguments for and against indent-tabs-mode have been made numerous times 
(including the TabsAreEvil wiki page Drew has linked to). What we don't 
know well, on the other hand, is how many of our users actually use tabs 
for indentation in practice. If the fraction is minuscule, then changing 
the default value really shouldn't hurt.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't see how all of those downsides couldn't be
  > mitigated, providing a GNU site or other means to
  > serve as single collection point, echoing point
  > (echoing current counts, text suggestions, etc.),
  > and even providing a discussion venue.

I think we should make sure polls do NOT turn into discussions.
Discussions would multiply the bulk of messages and we would not be
able to digest them.

Most of you are brainstorming about what we could do.
I have actually done polls.

Dmitry wrote:

  > And if every such poll will requires a special setup (configuration by 
  > the admins, etcetera), it will limit our ability to do them.

Having each poll dump responses into its own file was reliable and
easy.  To set this up takes a few minutes.

It may take an hour or two to write the posting.  It may take hours to
study the responses.  So let's not worry about the extra few minutes.

  > IOW, don't try to reproduce the polling here, there
  > and everywhere.  Just announce it here, there, and
  > everywhere.  Anyone who wants to discuss a poll
  > here, there, and everywhere is welcome to do so,
  > but that discussion will not automatically be
  > captured as part of the poll itself.

THose points seem valid to me.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I've noticed over the years that respondents tend to give simple (thus
not very useful) answers and that it is necessary to urge them to
explain more.

Just now it struck me that the word "poll" might suggest to
respondents that the answer requested is simply "How much do you like
or dislike this", with 5 or 7 possible answers from "Hate it" to "Love
it."  Does this seem likely?  Should we call it something else?  We
could describe it as a "study" or "investigation" instead of a "poll".

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to poll the users

[Dmitry Gutov]

On 28.04.2020 05:44, Richard Stallman wrote:
> I've noticed over the years that respondents tend to give simple (thus
> not very useful) answers and that it is necessary to urge them to
> explain more.
> 
> Just now it struck me that the word "poll" might suggest to
> respondents that the answer requested is simply "How much do you like
> or dislike this", with 5 or 7 possible answers from "Hate it" to "Love
> it."  Does this seem likely?

Polls can have different forms and shapes.

But, of course, most people will find it easier to choose from one of 
the options rather than elaborate in text. Especially when they think 
the answer should be obvious to everybody.

> Should we call it something else?  We
> could describe it as a "study" or "investigation" instead of a "poll".

Since you are dead-set on doing things exactly your way, please go ahead 
and choose the wording, the whole message, and we'll post it in all 
places our users can frequent.

Re: How to poll the users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But it would be good to _announce_ a poll in
  > more places than just the Emacs mailing lists.

  > A poll can be _announced_, with instructions
  > for participating and an indication of what
  > the poll is about, on non-GNU sites such as
  > those mentioned so far - Reddit and the
  > various Stack Exchange sites (especially
  > emacs.StackExchange and StackOverflow).

  > Plus an announcement by Sasha on her blog and
  > her Emacs-news mail to emacs-tangents@gnu.org.

All that sounds good.  The more, the merrier.
(But who is Sasha?)

Nowadays we would want to make a web page with
info about the poll; we could post references to it
everywhere that makes sense.

  > That way to participate could be just what
  > has been done in the past - by email. 

That is the way that makes sense.

					   Or it
  > could be by way of a GNU Emacs website.

That would be possible in principle, but inconvenient to set up and to
use.  We want people to give complete answers, not force their
responses into a form.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: How to poll the users

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

> > Plus an announcement by Sasha on her blog and
> > her Emacs-news mail to emacs-tangents@gnu.org.
> 
> All that sounds good.  The more, the merrier.
> (But who is Sasha?)

Sacha Chua (cc'd - I spelled her first name wrong).

She regularly (e.g. weekly) posts an informal Emacs
News message to emacs-tangents@gnu.org (see attached).  
Those messages are also on her friendly blog page:

https://sachachua.com/blog/

[-- Attachment #2: Type: message/rfc822, Size: 52129 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 19412 bytes --]


2020-04-20 Emacs news


Emacs configuration: 

HYPERLINK "https://urldefense.com/v3/__https://www.youtube.com/watch?v=2P-hEtTlJIA&feature=share__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxQALiI-Z$"Sample Spacemacs Config File for Non-Programmers (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/spacemacs/comments/g1vk0a/sample_spacemacs_config_file_for_nonprogrammers/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbvwtkSL$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://github.com/gexplorer/simple-modeline__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbfyE8Jz$"A simple mode-line configuration for Emacs (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g3k54a/a_simple_modeline_configuration_for_emacs/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxdZwAwnu$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g2fzyr/what_is_your_three_musthave_packages_that_you_can/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxdbFfsUE$"What is your three must-have packages that you can not live without ?
HYPERLINK "https://urldefense.com/v3/__https://monkey.org/*marius/self-contained-emacs.html__;fg!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZdFbThE$"self-contained-emacs (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g148hr/selfcontainedemacs/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxYNOaX7d$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://github.com/wandersoncferreira/dotfiles__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUf5FWrB$"GitHub - wandersoncferreira/dotfiles: Literate Emacs configuration with EXWM

Emacs Lisp: 

HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g13rzo/ann_elispdepmap_a_library_to_generate_a/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxULgu3_1$"{ANN} elisp-depmap - a library to generate a dependency map for elisp projects.
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g0xwjw/ann_new_package_orderless_a_completion_style_that/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxY_mbHHt$"{ANN} New package orderless: a completion style that matches multiple regexps in any order
HYPERLINK "https://urldefense.com/v3/__https://tech.toryanderson.com/2020/04/15/simulating-c-u-args-to-lambda-wrapped-functions/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxfs1ga1r$"Tory Anderson: Simulating `C-u` args to lambda-wrapped functions

Emacs development: 

HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=763ec05cc17973134c440f2d0afb6eb5d095d0d4__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxdAHRbVo$"Bind 'n' and 'p' to move between symbols in apropos
HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=afa542c914379538f986f1428f176ffe42f62609__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxae9VLNn$"Fix small glitches in documenting the native image API feature
HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=e94206aaf608a899c81bb07fe91d26439f51b3f8__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxQGxNc73$"Make use of MS-Windows native image API be selectable at run time
HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=df254a7445a86dc25d133f2d79be8096190a8b96__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxWDGvSAE$"Initial version of native image API support for MS-Windows
HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=fc336a46553919206d9ac621d1ea5e9740477e18__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUnTmXUP$"Document the new 'w32-get/set-ime-open-status' functions

Appearance: 

HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g42pot/new_package_shrface_extensions_to_library/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSG6-idZ$"{New Package} shrface+: extensions to library `shrface.el', apply shrface to non-org buffers, like w3m, info and helpful
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g33rkq/leuventheme/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxavOoGef$"Leuven-theme
HYPERLINK "https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00875.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxQFk6CgC$"Why Emacs is so square (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g22qci/why_emacs_is_so_square/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbdDiFF4$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g1wa51/update_shrface_15_was_released_this_time_you_can/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxdwmD7ox$"{Update} Shrface 1.5 was released. This time, you can use org-cycle iny eww and nov! One more night can not sleep…

Navigation: 

HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g3s0ts/windsel_2dimensional_workspace_switcher/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSDvfZwB$"Winds.el - 2-dimensional workspace switcher
HYPERLINK "https://urldefense.com/v3/__https://www.manueluberti.eu/*emacs/2020/04/13/lockdown-beam-mark-thing-at/__;Lw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxQzx71GX$"Manuel Uberti: Lockdown Beam: mark-thing-at
HYPERLINK "https://urldefense.com/v3/__https://youtu.be/CoWjNatpjuk__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxYjFCS6H$"Watch "Improve project workflow with GNU Global! (Emacs)" on YouTube

Org Mode: 

HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g2ch3i/literate_programming_setup_of_docker_programming/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbhSm6Ll$"Literate programming setup of Docker programming environment with org-mode in Emacs
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g13o5j/ann_orgtreeusage_peek_at_the_usage_of_your_org/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxWNiNzO3$"{ANN} org-treeusage - Peek at the usage of your org headings

Coding: 

HYPERLINK "https://urldefense.com/v3/__https://www.sidraval.com/blog/prettier_ruby_spacemacs.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxb4DND7m$"Using @prettier/plugin-ruby in spacemacs (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/spacemacs/comments/g1jwnr/using_prettierpluginruby_in_spacemacs/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxfhDHQAq$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://github.com/muffinmad/emacs-pdb-capf__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZ8lokT1$"Python debugger (pdb) completion-at-point function
HYPERLINK "https://urldefense.com/v3/__http://blog.binchen.org/posts/use-magit-api-to-rebase-to-closest-branch.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxVT79MiQ$"Chen Bin (redguardtoo): Use Magit API to rebase to closest branch
HYPERLINK "https://urldefense.com/v3/__https://so.nwalsh.com/2020/04/18-dash__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxYFUtNFB$"Norm: Dash docset updates

Mail: 

HYPERLINK "https://urldefense.com/v3/__http://xenodium.com/mumu4e-14-released/index.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxXhtbfRW$"Alvaro Ramirez: mu/mu4e 1.4 released

Community: 

HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g11mp9/weekly_tipstricketc_thread/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZ9cP5o3$"Weekly tips/trick/etc/ thread
HYPERLINK "https://urldefense.com/v3/__https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZr7NH_0$"The most successful malleable system in history | Malleable Systems Collective (HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g0wed7/emacs_the_most_successful_malleable_system_in/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxU57yxTA$"Reddit, HYPERLINK "https://urldefense.com/v3/__https://news.ycombinator.com/item?id=22875106__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxcnTpKDf$"HN - long discussion)
HYPERLINK "https://urldefense.com/v3/__https://i.redd.it/asw2vylm3dt41.png__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSHCyQkb$"Talking to the doctor in Emacs (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g302cw/talking_to_the_doctor_in_emacs/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbh07S7p$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://distinctly.pink/2020-04-17.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxRdtY2ya$"a roundabout path to emacs - distinctly.pink

Other: 

HYPERLINK "https://urldefense.com/v3/__https://news.ycombinator.com/item?id=22881808__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZ22Boav$"Ask HN: Resources to grok Emacs and use it well? | Hacker News
HYPERLINK "https://urldefense.com/v3/__https://youtu.be/ih8FpiK0zck__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxaHMxg9-$"Watch "Emacs Through Macros - 01 - Introduction" on YouTube
HYPERLINK "https://urldefense.com/v3/__https://blog.abrochard.com/melpa-stats.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUJnQyW2$"Some statistics about MELPA (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g1se0q/some_statistics_about_melpa/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSFPVZHk$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://blog.grdryn.me/blog/flatpak-emacs-with-gpg-agent.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxddTTunj$"Using gpg-agent with Emacs flatpak
HYPERLINK "https://urldefense.com/v3/__https://blog.abrochard.com/hyperbole-intro.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbjvsswa$"Adrien Brochard: Quick Introduction to Emacs Hyperbole
HYPERLINK "https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/g3mo8u/a_tiny_tip_for_those_using_elfeed_for_youtube_subs/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxfiGoSAa$"A tiny tip for those using elfeed for youtube subs
HYPERLINK "https://urldefense.com/v3/__http://codingquark.com/emacs/2020/04/19/elfeed-protocol-ttrss.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxTfrU-zC$"codingquark: Elfeed with Tiny Tiny RSS (HYPERLINK "https://urldefense.com/v3/__https://news.ycombinator.com/item?id=22915200__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxTj_Rvaf$"HN)
HYPERLINK "https://urldefense.com/v3/__https://www.manueluberti.eu/*emacs/2020/04/20/lockdown-beam-native-complete/__;Lw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxcG2gKVd$"Manuel Uberti: Lockdown Beam: native-complete
HYPERLINK "https://urldefense.com/v3/__https://i.redd.it/onhkpy3d3qt41.jpg__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxeCJZ81L$"I like the retro vibe of the Keychron K4 paired with Emacs running in terminal :) (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g439dr/i_like_the_retro_vibe_of_the_keychron_k4_paired/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSuopkBb$"Reddit)
HYPERLINK "https://urldefense.com/v3/__https://i.redd.it/kqnjdzlxrmt41.jpg__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbJQPn7R$"(setq handheld-mode nil) (HYPERLINK "https://urldefense.com/v3/__https://reddit.com/r/emacs/comments/g3tvzn/setq_handheldmode_nil/__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxeTfX_lv$"Reddit)

New packages: 

HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/basic-ide__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxRFPNLkW$"basic-ide: BASIC IDE c64
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/bibtex-completion__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxToffwDq$"bibtex-completion: A BibTeX backend for completion frameworks
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/brutal-theme__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUCLjd0Q$"brutal-theme: Brutalist theme
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/completions-frame__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSzMXPhS$"completions-frame: Show completions in child frame
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/elisp-depmap__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxV82aUUx$"elisp-depmap: Generate an elisp dependency map in graphviz
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/flatfluc-theme__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUrhwgCb$"flatfluc-theme: Custom merge of flucui and flatui themes
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/flymake-phpstan__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxfc_Smcg$"flymake-phpstan: Flymake backend for PHP using PHPStan
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/friendly-tramp-path__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZOPITcn$"friendly-tramp-path: Human-friendly TRAMP path construction
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/helm-org-multi-wiki__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxTukpQWr$"helm-org-multi-wiki: Helm interface to org-multi-wiki
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/lambdapi-mode__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxcZp82sw$"lambdapi-mode: A major mode for editing Lambdapi source code
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/leaf-manager__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxW-ACreo$"leaf-manager: Configuration manager for leaf based init.el
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/mc-calc__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSur0q5A$"mc-calc: Combine multiple-cursors and calc
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/meow__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxS6rA6Ta$"meow: Modal Editing On Wheel
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/org-multi-wiki__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUaf9qIi$"org-multi-wiki: Multiple wikis based on Org mode
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/org-noter-pdftools__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxaqXKshd$"org-noter-pdftools: Integration between org-pdftools and org-noter
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/org-treeusage__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZkHevSy$"org-treeusage: Examine the usage of org headings in a tree-like manner
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/owcmd__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbu0LYhh$"owcmd: Run a single command in the other window
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/rego-mode__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxa25WV8h$"rego-mode: A major mode for rego language
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/simple-modeline__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxRCmky3P$"simple-modeline: A simple mode-line configuration for Emacs
HYPERLINK "https://urldefense.com/v3/__https://elpa.gnu.org/packages/sm-c-mode.html__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxZFxyBne$"sm-c-mode: C major mode based on SMIE
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/smart-input-source__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxSRQu0rg$"smart-input-source: Switch OS native input source smartly
HYPERLINK "https://urldefense.com/v3/__http://melpa.org/*/space-theming__;Iw!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxTrSTAZU$"space-theming: Easilly override theme faces

Links from HYPERLINK "https://urldefense.com/v3/__http://reddit.com/r/emacs__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxcCc7-vv$"reddit.com/r/emacs, HYPERLINK "https://urldefense.com/v3/__http://reddit.com/r/orgmode__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxQ08PwAB$"r/orgmode, HYPERLINK "https://urldefense.com/v3/__http://reddit.com/r/spacemacs__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxXzdfqyT$"r/spacemacs, HYPERLINK "https://urldefense.com/v3/__http://reddit.com/r/planetemacs__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUFPREy-$"r/planetemacs, HYPERLINK "https://urldefense.com/v3/__https://hn.algolia.com/?query=emacs&sort=byDate&prefix&page=0&dateRange=all&type=story__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUvzI2Hv$"Hacker News, HYPERLINK "https://urldefense.com/v3/__https://planet.emacslife.com__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxbLc-uN6$"planet.emacslife.com, HYPERLINK "https://urldefense.com/v3/__https://www.youtube.com/results?search_query=emacs&search_sort=video_date_uploaded__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxXMNCVmZ$"YouTube, HYPERLINK "https://urldefense.com/v3/__http://git.savannah.gnu.org/cgit/emacs.git/log/etc/NEWS__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxaKt5pw2$"the Emacs NEWS file and HYPERLINK "https://urldefense.com/v3/__http://lists.gnu.org/archive/html/emacs-devel/2020-04__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxUSYEqWl$"emacs-devel.

You're receiving this message via the Emacs Tangents mailing list.
HYPERLINK "https://urldefense.com/v3/__https://lists.gnu.org/mailman/listinfo/emacs-tangents__;!!GqivPVa7Brio!JDO1PgK0faftCriwmQhzm_PIYslUoLwQ02yXA-6yS5CxV0aF5vVUtMWGxU9TGVYX$"View list info/unsubscribe

[-- Attachment #2.1.1.2: Type: text/html, Size: 21174 bytes --]

[-- Attachment #2.1.2: emacs-news.org --]
[-- Type: text/x-org, Size: 9224 bytes --]

* 2020-04-20 Emacs news
- Emacs configuration:
  - [[https://www.youtube.com/watch?v=2P-hEtTlJIA&feature=share][Sample Spacemacs Config File for Non-Programmers]] ([[https://reddit.com/r/spacemacs/comments/g1vk0a/sample_spacemacs_config_file_for_nonprogrammers/][Reddit]])
  - [[https://github.com/gexplorer/simple-modeline][A simple mode-line configuration for Emacs]] ([[https://reddit.com/r/emacs/comments/g3k54a/a_simple_modeline_configuration_for_emacs/][Reddit]])
  - [[https://www.reddit.com/r/emacs/comments/g2fzyr/what_is_your_three_musthave_packages_that_you_can/][What is your three must-have packages that you can not live without ?]]
  - [[https://monkey.org/~marius/self-contained-emacs.html][self-contained-emacs]] ([[https://reddit.com/r/emacs/comments/g148hr/selfcontainedemacs/][Reddit]])
  - [[https://github.com/wandersoncferreira/dotfiles][GitHub - wandersoncferreira/dotfiles: Literate Emacs configuration with EXWM]]
- Emacs Lisp:
  - [[https://www.reddit.com/r/emacs/comments/g13rzo/ann_elispdepmap_a_library_to_generate_a/][{ANN} elisp-depmap - a library to generate a dependency map for elisp projects.]]
  - [[https://www.reddit.com/r/emacs/comments/g0xwjw/ann_new_package_orderless_a_completion_style_that/][{ANN} New package orderless: a completion style that matches multiple regexps in any order]]
  - [[https://tech.toryanderson.com/2020/04/15/simulating-c-u-args-to-lambda-wrapped-functions/][Tory Anderson: Simulating `C-u` args to lambda-wrapped functions]]
- Emacs development:
  - [[http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=763ec05cc17973134c440f2d0afb6eb5d095d0d4][Bind 'n' and 'p' to move between symbols in apropos]]
  - [[http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=afa542c914379538f986f1428f176ffe42f62609][Fix small glitches in documenting the native image API feature]]
  - [[http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=e94206aaf608a899c81bb07fe91d26439f51b3f8][Make use of MS-Windows native image API be selectable at run time]]
  - [[http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=df254a7445a86dc25d133f2d79be8096190a8b96][Initial version of native image API support for MS-Windows]]
  - [[http://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?id=fc336a46553919206d9ac621d1ea5e9740477e18][Document the new 'w32-get/set-ime-open-status' functions]]
- Appearance:
  - [[https://www.reddit.com/r/emacs/comments/g42pot/new_package_shrface_extensions_to_library/][{New Package} shrface+: extensions to library `shrface.el', apply shrface to non-org buffers, like w3m, info and helpful]]
  - [[https://www.reddit.com/r/emacs/comments/g33rkq/leuventheme/][Leuven-theme]]
  - [[https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00875.html][Why Emacs is so square]] ([[https://reddit.com/r/emacs/comments/g22qci/why_emacs_is_so_square/][Reddit]])
  - [[https://www.reddit.com/r/emacs/comments/g1wa51/update_shrface_15_was_released_this_time_you_can/][{Update} Shrface 1.5 was released. This time, you can use org-cycle iny eww and nov! One more night can not sleep...]]
- Navigation:
  - [[https://www.reddit.com/r/emacs/comments/g3s0ts/windsel_2dimensional_workspace_switcher/][Winds.el - 2-dimensional workspace switcher]]
  - [[https://www.manueluberti.eu//emacs/2020/04/13/lockdown-beam-mark-thing-at/][Manuel Uberti: Lockdown Beam: mark-thing-at]]
  - [[https://youtu.be/CoWjNatpjuk][Watch "Improve project workflow with GNU Global! (Emacs)" on YouTube]]
- Org Mode:
  - [[https://www.reddit.com/r/emacs/comments/g2ch3i/literate_programming_setup_of_docker_programming/][Literate programming setup of Docker programming environment with org-mode in Emacs]]
  - [[https://www.reddit.com/r/emacs/comments/g13o5j/ann_orgtreeusage_peek_at_the_usage_of_your_org/][{ANN} org-treeusage - Peek at the usage of your org headings]]
- Coding:
  - [[https://www.sidraval.com/blog/prettier_ruby_spacemacs.html][Using @prettier/plugin-ruby in spacemacs]] ([[https://reddit.com/r/spacemacs/comments/g1jwnr/using_prettierpluginruby_in_spacemacs/][Reddit]])
  - [[https://github.com/muffinmad/emacs-pdb-capf][Python debugger (pdb) completion-at-point function]]
  - [[http://blog.binchen.org/posts/use-magit-api-to-rebase-to-closest-branch.html][Chen Bin (redguardtoo): Use Magit API to rebase to closest branch]]
  - [[https://so.nwalsh.com/2020/04/18-dash][Norm: Dash docset updates]]
- Mail:
  - [[http://xenodium.com/mumu4e-14-released/index.html][Alvaro Ramirez: mu/mu4e 1.4 released]]
- Community:
  - [[https://www.reddit.com/r/emacs/comments/g11mp9/weekly_tipstricketc_thread/][Weekly tips/trick/etc/ thread]]
  - [[https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/][The most successful malleable system in history | Malleable Systems Collective]] ([[https://www.reddit.com/r/emacs/comments/g0wed7/emacs_the_most_successful_malleable_system_in/][Reddit]], [[https://news.ycombinator.com/item?id=22875106][HN]] - long discussion)
  - [[https://i.redd.it/asw2vylm3dt41.png][Talking to the doctor in Emacs]] ([[https://reddit.com/r/emacs/comments/g302cw/talking_to_the_doctor_in_emacs/][Reddit]])
  - [[https://distinctly.pink/2020-04-17.html][a roundabout path to emacs - distinctly.pink]]
- Other:
  - [[https://news.ycombinator.com/item?id=22881808][Ask HN: Resources to grok Emacs and use it well? | Hacker News]]
  - [[https://youtu.be/ih8FpiK0zck][Watch "Emacs Through Macros - 01 - Introduction" on YouTube]]
  - [[https://blog.abrochard.com/melpa-stats.html][Some statistics about MELPA]] ([[https://reddit.com/r/emacs/comments/g1se0q/some_statistics_about_melpa/][Reddit]])
  - [[https://blog.grdryn.me/blog/flatpak-emacs-with-gpg-agent.html][Using gpg-agent with Emacs flatpak]]
  - [[https://blog.abrochard.com/hyperbole-intro.html][Adrien Brochard: Quick Introduction to Emacs Hyperbole]]
  - [[https://www.reddit.com/r/emacs/comments/g3mo8u/a_tiny_tip_for_those_using_elfeed_for_youtube_subs/][A tiny tip for those using elfeed for youtube subs]]
  - [[http://codingquark.com/emacs/2020/04/19/elfeed-protocol-ttrss.html][codingquark: Elfeed with Tiny Tiny RSS]] ([[https://news.ycombinator.com/item?id=22915200][HN]])
  - [[https://www.manueluberti.eu//emacs/2020/04/20/lockdown-beam-native-complete/][Manuel Uberti: Lockdown Beam: native-complete]]
  - [[https://i.redd.it/onhkpy3d3qt41.jpg][I like the retro vibe of the Keychron K4 paired with Emacs running in terminal :)]] ([[https://reddit.com/r/emacs/comments/g439dr/i_like_the_retro_vibe_of_the_keychron_k4_paired/][Reddit]])
  - [[https://i.redd.it/kqnjdzlxrmt41.jpg][(setq handheld-mode nil)]] ([[https://reddit.com/r/emacs/comments/g3tvzn/setq_handheldmode_nil/][Reddit]])
- New packages:
  - http://melpa.org/#/basic-ide: BASIC IDE c64
  - http://melpa.org/#/bibtex-completion: A BibTeX backend for completion frameworks
  - http://melpa.org/#/brutal-theme: Brutalist theme
  - http://melpa.org/#/completions-frame: Show completions in child frame
  - http://melpa.org/#/elisp-depmap: Generate an elisp dependency map in graphviz
  - http://melpa.org/#/flatfluc-theme: Custom merge of flucui and flatui themes
  - http://melpa.org/#/flymake-phpstan: Flymake backend for PHP using PHPStan
  - http://melpa.org/#/friendly-tramp-path: Human-friendly TRAMP path construction
  - http://melpa.org/#/helm-org-multi-wiki: Helm interface to org-multi-wiki
  - http://melpa.org/#/lambdapi-mode: A major mode for editing Lambdapi source code
  - http://melpa.org/#/leaf-manager: Configuration manager for leaf based init.el
  - http://melpa.org/#/mc-calc: Combine multiple-cursors and calc
  - http://melpa.org/#/meow: Modal Editing On Wheel
  - http://melpa.org/#/org-multi-wiki: Multiple wikis based on Org mode
  - http://melpa.org/#/org-noter-pdftools: Integration between org-pdftools and org-noter
  - http://melpa.org/#/org-treeusage: Examine the usage of org headings in a tree-like manner
  - http://melpa.org/#/owcmd: Run a single command in the other window
  - http://melpa.org/#/rego-mode: A major mode for rego language
  - http://melpa.org/#/simple-modeline: A simple mode-line configuration for Emacs
  - https://elpa.gnu.org/packages/sm-c-mode.html: C major mode based on SMIE
  - http://melpa.org/#/smart-input-source: Switch OS native input source smartly
  - http://melpa.org/#/space-theming: Easilly override theme faces

Links from [[http://reddit.com/r/emacs][reddit.com/r/emacs]], [[http://reddit.com/r/orgmode][r/orgmode]], [[http://reddit.com/r/spacemacs][r/spacemacs]], [[http://reddit.com/r/planetemacs][r/planetemacs]], [[https://hn.algolia.com/?query=emacs&sort=byDate&prefix&page=0&dateRange=all&type=story][Hacker News]], [[https://planet.emacslife.com][planet.emacslife.com]], [[https://www.youtube.com/results?search_query=emacs&search_sort=video_date_uploaded][YouTube]], [[http://git.savannah.gnu.org/cgit/emacs.git/log/etc/NEWS][the Emacs NEWS file]] and [[http://lists.gnu.org/archive/html/emacs-devel/2020-04][emacs-devel]].


You're receiving this message via the Emacs Tangents mailing list.
[[https://lists.gnu.org/mailman/listinfo/emacs-tangents][View list info/unsubscribe]]

Re: How to poll the users

[Sacha Chua]

(resending with proper SPF, I hope)

Drew Adams <drew.adams@oracle.com> writes:

>> > Plus an announcement by Sasha on her blog and
>> > her Emacs-news mail to emacs-tangents@gnu.org.
>> All that sounds good.  The more, the merrier.
>> (But who is Sasha?)
> Sacha Chua (cc'd - I spelled her first name wrong).
> She regularly (e.g. weekly) posts an informal Emacs
> News message to emacs-tangents@gnu.org (see attached).

I'd be happy to link to the poll at the top of Emacs News for several
weeks. If someone posts the poll URL to reddit.com/r/emacs or Cc:s me in
a message to a mailing list, I can pick it up from there.

Sacha Chuac

Re: Making Emacs more friendly to newcomers

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:


> And then, another 20 years pass, the current users get too old/change
> careers/retire/etc, and Emacs's userbase shrinks even more.

I have seen people say Emacs will die by 2000 in the 90s.
I've also seen people say Emacs will die by 2010 in the 2000s.
I've also seen people say Emacs will die by 2020 in the 2010s.

Since all of those predictions of doom have consistently failed, I'm not
inclined to believe any of this either.

> I don't want Emacs to die out, and it will if we don't do the work of
> attracting new users.

And we're attracting a fair amount of new users.  What I would hate to
see is Emacs prioritizing "attracting users" over "being useful".  I'm
sure many in the community agree with me.

> Also note that we don't really have the ability to poll even our
> existing users, to find out whether they would like a given
> change. Even disregarding those who would change their mind later.

The anecdotal experience of many people I know (and I'm sure many people
on this list too) would agree that drastic changes are a bad thing.

> Give it time.

Also, Xref was actually useful in a way.  Drastic redesigning just to
attract new users does not.


> I think it's possible to support two sets of keybindings. That's
> definitely extra work, though.

We already have Cua Mode.  Having a button on the splash screen that
says "enable Cua" should be enough.

> Including simply designing a set of bindings that is both compatible
> with CUA and yet retains the current design principles to some extent 
> (so far I have no good ideas on that front).

I don't think that's possible, at least without 20 years advance notice.

Re: Making Emacs more friendly to newcomers

[Sergey Organov]

Po Lu <luangruo@yahoo.com> writes:

[...]

> And we're attracting a fair amount of new users.  What I would hate to
> see is Emacs prioritizing "attracting users" over "being useful".  I'm
> sure many in the community agree with me.

Indeed! Emacs is the only editor that I grew to like. Other editors and
IDEs I've used I grew to hate.

-- Sergey

Re: Making Emacs more friendly to newcomers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So for all questions about changing defaults, we should ask ourselves, 
  > do we prioritize the existing 5% (or 3%, as SO poll says) userbase that 
  > will naturally continue shrinking over the years, or whether we prefer 
  > to make life easier and more productive for the users that should come 
  > later.

This is entirely logical
if our main priority is how successful Emacs is,
rather than what it does.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 06:19, Richard Stallman wrote:
>    > So for all questions about changing defaults, we should ask ourselves,
>    > do we prioritize the existing 5% (or 3%, as SO poll says) userbase that
>    > will naturally continue shrinking over the years, or whether we prefer
>    > to make life easier and more productive for the users that should come
>    > later.
> 
> This is entirely logical
> if our main priority is how successful Emacs is,
> rather than what it does.

Given that I've had multiple *useful* proposal about changing defaults 
shot down because of the worry that existing users might be 
inconvenienced (having been used to the current behavior), it's a false 
dichotomy.

Re: Making Emacs more friendly to newcomers

[Ahmed Khanzada]

> So for all questions about changing defaults, we should ask ourselves,
> do we prioritize the existing 5% (or 3%, as SO poll says) userbase that
> will naturally continue shrinking over the years, or whether we prefer
> to make life easier and more productive for the users that should come
> later.

Looking at the amount of currently maintained elisp packages online
these days, I suspect Emacs actually has more users than ever, it is
just that our segment of the overall market is smaller.

Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
VM. Is the idea that if we compete in the same modes as the modernist
editors, we can steal enough people from them that we will advance the
cause of free software?

That's not a rhetorical question, I am curious. Right now with the
status quo, we know we are at least satisfying a core audience that has
self-selected themselves as Emacs users through the hazing that is
figuring the damn thing out.

Playing towards your core audience has both benefits and drawbacks.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 23.04.2020 10:04, Ahmed Khanzada wrote:
> Looking at the amount of currently maintained elisp packages online
> these days, I suspect Emacs actually has more users than ever, it is
> just that our segment of the overall market is smaller.

And yet, the number of core contributors stays where it was, at best.

> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
> VM. Is the idea that if we compete in the same modes as the modernist
> editors, we can steal enough people from them that we will advance the
> cause of free software?

Sure. But also how about just "help more people enjoy Emacs's power and 
flexibility"?

We don't really have to compete for the _exact_ same audience. But we 
can expand ours.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 00:04:13 -0700
> From: Ahmed Khanzada <me@enzu.ru>
> Cc: Po Lu <luangruo@yahoo.com>,
>  Sébastien Gendre <seb@k-7.ch>,
>  조성빈 <pcr910303@icloud.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
> VM. Is the idea that if we compete in the same modes as the modernist
> editors, we can steal enough people from them that we will advance the
> cause of free software?

More users generally means more contributors, more future developers,
and better Emacs.  And yes, it advances the cause of Free Software,
like any other free package that attracts users.

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

> On Apr 23, 2020, at 10:56 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>> From: Ahmed Khanzada <me@enzu.ru>
>> Cc: Po Lu <luangruo@yahoo.com>,
>> Sébastien Gendre <seb@k-7.ch>,
>> 조성빈 <pcr910303@icloud.com>,
>> Emacs developers <emacs-devel@gnu.org>
>> 
>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>> VM. Is the idea that if we compete in the same modes as the modernist
>> editors, we can steal enough people from them that we will advance the
>> cause of free software?
> 
> More users generally means more contributors, more future developers,
> and better Emacs.  And yes, it advances the cause of Free Software,
> like any other free package that attracts users.
> 

Exactly. New users today means people fixes bugs and implement cool features tomorrow. A very good deal.

Yuan

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>> From: Ahmed Khanzada <me@enzu.ru>
>> Cc: Po Lu <luangruo@yahoo.com>,
>>  Sébastien Gendre <seb@k-7.ch>,
>>  조성빈 <pcr910303@icloud.com>,
>>  Emacs developers <emacs-devel@gnu.org>
>> 
>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>> VM. Is the idea that if we compete in the same modes as the modernist
>> editors, we can steal enough people from them that we will advance the
>> cause of free software?
>
> More users generally means more contributors, more future developers,
> and better Emacs.  And yes, it advances the cause of Free Software,
> like any other free package that attracts users.
Definitely! Users are important.

There is an interesting interviw/article in Linux Format from January
this year with Ton Roosendaal, the creator of 3D modelling/animation
package Blender. Blender went form relatively non-popular 3D application
on the verge of extinction to become a multimillion industry accepted
application. He touches on tradeoffs Blender made between "old wyas" and
more accepted "modern standards" and importance to appeal to "masses".
In sense it touches on similar questions as Emacs is faced with, so it
might be an interesting read. Just as a side note ... 

Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 28, 2020, at 1:09, Arthur Miller <arthur.miller@live.com> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>>> From: Ahmed Khanzada <me@enzu.ru>
>>> Cc: Po Lu <luangruo@yahoo.com>,
>>> Sébastien Gendre <seb@k-7.ch>,
>>> 조성빈 <pcr910303@icloud.com>,
>>> Emacs developers <emacs-devel@gnu.org>
>>> 
>>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>>> VM. Is the idea that if we compete in the same modes as the modernist
>>> editors, we can steal enough people from them that we will advance the
>>> cause of free software?
>> 
>> More users generally means more contributors, more future developers,
>> and better Emacs.  And yes, it advances the cause of Free Software,
>> like any other free package that attracts users.
> Definitely! Users are important.
> 
> There is an interesting interviw/article in Linux Format from January
> this year with Ton Roosendaal, the creator of 3D modelling/animation
> package Blender. Blender went form relatively non-popular 3D application
> on the verge of extinction to become a multimillion industry accepted
> application. He touches on tradeoffs Blender made between "old wyas" and
> more accepted "modern standards" and importance to appeal to "masses".
> In sense it touches on similar questions as Emacs is faced with, so it
> might be an interesting read. Just as a side note ... 

The article is here:

https://download.blender.org/documentation/pdf/LXF204.feat_3d.5cjt.pdf


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Sébastien Gendre <seb@k-7.ch>
> Date: Mon, 20 Apr 2020 00:44:40 +0200
> 
> - Alice: A long time user. She got a personal Emacs configuration she
>   had perfected over the years. She chose herself what system is used
>   to show function completion, which code parser is used for her daily
>   used languages. She add some packages to integrate with special
>   tools used at her work. Emacs is her home and office: She use it as
>   much for her personal project than for her work. She also made a
>   personal workflow with org-mode and write some personal Elisp
>   functions and advices. She forge the tools to her need. She do not
>   want to have an update of Emacs who break her configuration, her
>   workflow or her muscle memory.

There's a flaw in this description of how long-time Emacs users
concoct their configurations.  What's in their configuration depends
_heavily_ on the defaults: the features whose defaults satisfy such
users are never touched in the init file.  Any "vanilla" Emacs that
turns off many features will run a high risk of breaking such
configurations, because it violates the assumptions on which those
configurations rely.

At least, that's how I maintain my init files.

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages

The first and the most important problem with this is to identify what
you informally call "all the 2020 features, a modern interface, all
needed modern features to start coding with most popular languages and
easy to use for basic usages".  If you review past discussions on this
and related subjects, you will see that opinions on what should be
part of that set of features vary widely, so much so that I don't
believe any significant agreement is practical.  It _might_ be
possible to come up with a relatively short list of features that
could "modernize" Emacs, about which enough people will agree that
they should be part of "2020 features".  However, I'm not sure even
this limited goal is possible, and will continue to be unsure unless
and until someone comes up with such a list, and we see what's in it
and how many people agree on the list.

On top of that, the list (and the dispute to go with it) will need to
be updated with each major release.

Suppose we do have such a list -- will that be enough to make Emacs
sufficiently more attractive to Bob and his friends?  I don't know.
One problem is that we don't have many such Bob's on our team or even
reading this list, and those few who are very quickly become Alice's.
So their voice is never heard.  We don't have any HFE experts on
board, who could pretend to be a Bob.  So who will be able to
represent them and make sure the list of said features will be to
their liking?

> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything

I'm guessing that by "new" you mean all those "modern" features that
we don't currently turn on by default.  Otherwise, I don't see any
useful purpose for such a "vanilla" Emacs.

> And if Emacs detect, after an update or a first start, an already
> existing configuration that it could break because of some features:
> Emacs simply activate `vanilla-mode` automatically.

I don't see how Emacs can do that, when many dozens of optional
features are involved.  How do you write code that detects whether a
given feature can break something?  Ideally, we will have already
considered that, and make every effort not to break any existing
feature or muscle memory.  And who will write and maintain such code,
and update it with each release?  Are you aware of any other project
that does anything similar?

> It's just a starting point, but I think this could be a simple but
> very useful solution.

This assumes that someone does all the research and design and
implementation needed for that, and that we as a project commit to
maintaining these very non-trivial facilities for the years to come.
You may not realize it, but this is a very far cry from what we do
now.  For example, it is a long and frustrating uphill battle just to
make sure that NEWS provides information for how to get back old
behavior, for every one of those new features that do change behavior.
Please try to imagine (and describe to us, if possible) what kind of
development procedures will have to be put in place to support what
you propose, which is much more complex and problematic.

Re: Making Emacs more friendly to newcomers

[Sébastien Gendre]

Having a Vanilla-mode are maybe wore difficult than it seems.

So, let's forget Vanilla-mode and see another solution who can be more
feasible.

Maybe we can take inspiration from the work of Spacemacs and Doom
Emacs: Offer an official pre-configuration of Emacs, on the side of
Emacs itself. This pre-configuration will be more focused on new users
and
new features when Emacs itself would be more focused on stability.

Here is, in more detail, what I have in mind.

On one side, continue to develop Emacs as today :
- Keep same defaults
- If a new features is proposed, check if it break any compatibility
  or defaults
- If no, include it in Emacs
- If yes, try to modify this feature to not break any compatibility or
  defaults and if its a success, include this feature in Emacs
- If it's not possible, include the feature but deactivate it by
  default or make a package on ELPA
  
  
I don't think this side is different from what development on Emacs is
today. We can call this side Emacs vanilla, or Emacs core, or Emacs
base. Anything that reflect that this is the common base for everyone.


On another side, we can create a pre-configuration (like what
Spacemacs or Doom Emacs do) :
- All this pre-configuration is a set of files to be put inside the
  .emacs.d to start using it (like Spacemacs)
- Main goal is to have a pre-configuration that provide what is
  commonly expected from a modern text editor [1], out of the box
- Easy to use for the common tasks
- Enable some features that are not enabled by default
- Modify some defaults behaviours of Emacs to reflect more what new
  users search in a text editor
- Can include some packages from ELPA (if no legal or licence issue)
- This pre-configuration can be done by a dedicated team who
  collaborate with who work directly on Emacs
- The structure of this pre-configuration need to be made to not
  conflict with user personal configuration (ex: avoid to put anything
  in the init.el, use separate sub-directory inside .emacs.d, etc)
  
  
The actual Emacs show that the first side is possible. And projects
like Spacemacs and Doom Emacs show that the second side is also
possible. So I think this solution is feasible. And a direct
collaboration of the both side can make the process more easy.

A remaining problem is: How provide the pre-configuration easily and
out of the box for new users, without breaking long time Emacs users
configuration?

A possibility would be:
- When Emacs start, it check if a configuration already exist on the
  user directory (~/.emacs.d or ~/.emacs)
- If yes, Emacs start
- If no, Emacs restore the pre-configuration inside ~/.emacs.d then
  start

With this, new user can use the "modern, shiny, OOTB Emacs", out of
the box, by simply download and run it. And the long time user can
have a stable Emacs who don't break their configuration. For someone
who want to use Spacemacs, simply extract it as ~/.emacs.d before
start Emacs. And for someone who want to start Emacs without a
pre-configuration, simply create an empty directory for ~/.emacs.d.

Of course, the pre-configuration can be updated automatically with
Emacs. As the files of this pre-configuration are separated from user
specific configuration.

Open questions remain:
- Does the pre-configuration release cycle are synchronised with Emacs
or
  completely independent?
- Does the user can block the pre-configuration update, to avoid
  breaking its configuration based on a specific version of the
  pre-configuration?

But I think this can be a realisable solution. 

[1] List of features to be defined, but I imagine some out of the box
auto-completion, code navigation, functions documentation + functions
signatures + errors showing automatically, strong integration with git
(Magit?) and debuger, major containers engines (docker, kubernetes)
integration, etc. With a great support of the most populare
programming languages. And maybe have a special attention to integrate
with web technologies and tools for web developer.



PS: Or maybe we think to much about this problem. And making an LTS
versions of Emacs, like Ubuntu does, is the solution.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Sébastien Gendre <seb@k-7.ch>
> Date: Tue, 21 Apr 2020 14:43:47 +0200
> 
> On another side, we can create a pre-configuration (like what
> Spacemacs or Doom Emacs do) :
> - All this pre-configuration is a set of files to be put inside the
>   .emacs.d to start using it (like Spacemacs)
> - Main goal is to have a pre-configuration that provide what is
>   commonly expected from a modern text editor [1], out of the box
> - Easy to use for the common tasks
> - Enable some features that are not enabled by default
> - Modify some defaults behaviours of Emacs to reflect more what new
>   users search in a text editor
> - Can include some packages from ELPA (if no legal or licence issue)
> - This pre-configuration can be done by a dedicated team who
>   collaborate with who work directly on Emacs
> - The structure of this pre-configuration need to be made to not
>   conflict with user personal configuration (ex: avoid to put anything
>   in the init.el, use separate sub-directory inside .emacs.d, etc)

As was already said in this thread, the main problem with this is to
come up with the list of features to turn on.  Did you ask yourself
why there's Spacemacs and Doom Emacs (and a few more variants), and
not just one?  It tells us something about the commonality of
preferences.

> A remaining problem is: How provide the pre-configuration easily and
> out of the box for new users, without breaking long time Emacs users
> configuration?
> 
> A possibility would be:
> - When Emacs start, it check if a configuration already exist on the
>   user directory (~/.emacs.d or ~/.emacs)
> - If yes, Emacs start
> - If no, Emacs restore the pre-configuration inside ~/.emacs.d then
>   start

Does this mean users who download this "shiny Emacs" will be unable to
upgrade to a newer version?

> Of course, the pre-configuration can be updated automatically with
> Emacs. As the files of this pre-configuration are separated from user
> specific configuration.

So you propose to have config files that users shall never touch?  How
likely is this going to hold, what with Emacs users being very
inquisitive folks?

> [1] List of features to be defined, but I imagine some out of the box
> auto-completion, code navigation, functions documentation + functions
> signatures + errors showing automatically, strong integration with git
> (Magit?) and debuger, major containers engines (docker, kubernetes)
> integration, etc. With a great support of the most populare
> programming languages. And maybe have a special attention to integrate
> with web technologies and tools for web developer.

This is the main problem to solve, so its place is hardly in the
footnotes ;-)

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 17:38, Eli Zaretskii wrote:
>> A remaining problem is: How provide the pre-configuration easily and
>> out of the box for new users, without breaking long time Emacs users
>> configuration?
>>
>> A possibility would be:
>> - When Emacs start, it check if a configuration already exist on the
>>    user directory (~/.emacs.d or ~/.emacs)
>> - If yes, Emacs start
>> - If no, Emacs restore the pre-configuration inside ~/.emacs.d then
>>    start
> Does this mean users who download this "shiny Emacs" will be unable to
> upgrade to a newer version?

The pre-configuration could contain just one line:

   (require 'shiny-settings)

where shiny-settings.el is distributed with Emacs and is updated 
together with new releases.

Although, after 5-10 years pass, we'll surely encounter users of 
previous versions unhappy with changes to their shiny-settings too. :-)

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

> The pre-configuration could contain just one line:
>
>   (require 'shiny-settings)

Nitpick: `require` is *really* not the right job since just loading
a file should not change Emacs's behavior substantially.

Ideally, it should be a custom-theme, but second best could be
a minor-mode.


        Stefan

"Themes" shipping configuration - an unusual convention

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > The pre-configuration could contain just one line:
> >
> >   (require 'shiny-settings)
>
> Nitpick: `require` is *really* not the right job since just loading
> a file should not change Emacs's behavior substantially.
>
> Ideally, it should be a custom-theme, but second best could be
> a minor-mode.

So a theme can be used to change configuration, and indeed this is the
recommended way to do it.  Interesting, and news to me.  But is this a
good convention?  I'm not so sure.

AFAIK, all other applications I have used understand "theme" to mean a
"package containing graphical appearance details".  This definition
from Wikipedia: https://en.wikipedia.org/wiki/Theme_(computing)

I don't think users will expect a "theme" to modify the behavior of
Emacs.  There are usually things called "profiles" where one would
save or load settings from.  This means that if M-x load-theme changes
the behavior of Emacs (significantly or otherwise), they are in for a
surprise.

I would propose to change the convention such that a "theme" is only
meant to modify "graphical appearance details".   Not behavior.  (From
what I can tell, all themes currently shipped with Emacs follow this
convention.[1])

We could introduce a *separate* convention, called e.g. "custom
profiles", which are understood to also change settings.  They could
have their own directory in our tree called "etc/profiles", and
separate commands to load them (say, M-x load-profile).

Of course, a "custom profile" could technically do anything a "theme"
does and vice versa.  Just as a 'require'd package can technically
override any face, enable viper-mode or whatever.  But we should
discourage that.

Best regards,
Stefan Kangas

PS. If anyone can point to an example of a "custom theme" that ships
settings, it would be interesting to see it.

Footnotes:
1. The exception is some variables related to graphical display, which
is not unusual or surprising to my mind.

Re: "Themes" shipping configuration - an unusual convention

[Stefan Monnier]

> So a theme can be used to change configuration, and indeed this is the
> recommended way to do it.  Interesting, and news to me.

A custom-theme is a set of custom settings, yes.

> AFAIK, all other applications I have used understand "theme" to mean a
> "package containing graphical appearance details".  This definition
> from Wikipedia: https://en.wikipedia.org/wiki/Theme_(computing)

Yes, but at the same time, it's hard to draw the line: if a theme
controls the shape of menus (e.g. chooses between scroll-down menus and
pie-menus), is it "graphical appareance"?
What about the structure of a menu?  What about the place where
completions are displayed (a popup child frame vs the *Completions*
buffer)?

In any case, I'm not sure we want to start adding an artificial barrier:
the underlying technique conflates the two and I don't think it's
a problem, even if it doesn't correspond to what some other applications
offer (FWIW, I believe some application's themes are also able to change
pretty much any aspect of the behavior.  IIRC that's the case for
Enlightenment, for example).

> I don't think users will expect a "theme" to modify the behavior
> of Emacs.

It wouldn't be the first time that Emacs goes beyond users expectations ;-)

> We could introduce a *separate* convention, called e.g. "custom
> profiles", which are understood to also change settings.  They could
> have their own directory in our tree called "etc/profiles", and
> separate commands to load them (say, M-x load-profile).

I'm fine with using a different naming convention for the actual
behavior-oriented themes, but I see no need to hide the fact that the
implementation is the same.


        Stefan

RE: "Themes" shipping configuration - an unusual convention

[Drew Adams]

> So a theme can be used to change configuration, and indeed this is the
> recommended way to do it.  Interesting, and news to me.  But is this a
> good convention?  I'm not so sure.
> 
> AFAIK, all other applications I have used understand "theme" to mean a
> "package containing graphical appearance details"...
> 
> I don't think users will expect a "theme" to modify the behavior of
> Emacs.  There are usually things called "profiles" where one would
> save or load settings from.  This means that if M-x load-theme changes
> the behavior of Emacs (significantly or otherwise), they are in for a
> surprise.
> 
> I would propose to change the convention such that a "theme" is only
> meant to modify "graphical appearance details".   Not behavior.  (From
> what I can tell, all themes currently shipped with Emacs follow this
> convention.[1])
> 
> We could introduce a *separate* convention, called e.g. "custom
> profiles", which are understood to also change settings.  They could
> have their own directory in our tree called "etc/profiles", and
> separate commands to load them (say, M-x load-profile).
> 
> Of course, a "custom profile" could technically do anything a "theme"
> does and vice versa.  Just as a 'require'd package can technically
> override any face, enable viper-mode or whatever.  But we should
> discourage that.
...
> Footnotes:
> 1. The exception is some variables related to
>    graphical display, which is not unusual or
>    surprising to my mind.

I believe this is a principal difference between
custom themes and color themes.

Custom themes are essentially part of Customize,
and from the outset they were about customizing
options.  Only later were they extended to do
some (most) of what color themes do: define a
color scheme by setting a bunch of faces, frame
parameters etc.

(That's my recollection anyway.  Chong Yidong
extended custom themes to implement some of
what color themes provide.)

Nowadays, the distinction has mostly been lost,
unfortunately, and many people speak of "color
themes" when they really mean vanilla Emacs
custom themes.

https://www.emacswiki.org/emacs/ColorThemes

https://www.emacswiki.org/emacs/CustomThemes

Your proposal seems to be to more or less limit
Emacs custom themes to defining color schemes,
or perhaps color schemes plus some other display
properties.

Re: "Themes" shipping configuration - an unusual convention

[Basil L. Contovounesios]

Stefan Kangas <stefan@marxist.se> writes:

> PS. If anyone can point to an example of a "custom theme" that ships
> settings, it would be interesting to see it.

Searching for custom-theme-set-variables under etc/themes gives:

- etc/themes/dichromacy-theme.el
- etc/themes/leuven-theme.el
- etc/themes/misterioso-theme.el
- etc/themes/tango-dark-theme.el
- etc/themes/tango-theme.el
- etc/themes/wombat-theme.el

Under GNU ELPA:

- modus-operandi-theme.el
- modus-vivendi-theme.el
- tramp-theme.el

Under the top 5 most downloaded themes on MELPA:

- zenburn
- solarized
- sanityinc-tomorrow
- spacemacs

Most of which also come with their own defcustoms, etc.

Did I misunderstand what you were asking for?

-- 
Basil

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 04:35:48 +0300
> 
> > Does this mean users who download this "shiny Emacs" will be unable to
> > upgrade to a newer version?
> 
> The pre-configuration could contain just one line:
> 
>    (require 'shiny-settings)
> 
> where shiny-settings.el is distributed with Emacs and is updated 
> together with new releases.

So we expect users not to customize their Emacs, as long as they use
the "shiny Emacs"?  What are the chances of that to work?

Re: Making Emacs more friendly to newcomers

[chad]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Wed, Apr 22, 2020 at 6:27 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Wed, 22 Apr 2020 04:35:48 +0300
> >
> > > Does this mean users who download this "shiny Emacs" will be unable to
> > > upgrade to a newer version?
> >
> > The pre-configuration could contain just one line:
> >
> >    (require 'shiny-settings)
> >
> > where shiny-settings.el is distributed with Emacs and is updated
> > together with new releases.
>
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?
>

Spacemacs, Doom, and Prelude (to name just three of the more popular
options) all make this work out-of-tree, so it certainly seems possible.
From my reading, the first two (at least) are strongly expected to be
customized after installation, and to have those customizations survive
updates of the "kit".

Spacemacs in particular adds a "layer" concept to emacs customization so
that bundles of related options/code/packages/config can be turned on or
off as a group.  Details can be found at:
https://www.spacemacs.org/doc/LAYERS.html. I would personally hope that we
could streamline this process, which seems pretty bulky from the outside.
Maybe inviting the Spacemacs people to share their experience that led to
creating their layers system would be helpful to us both. (I would have
CC'd them onthis message, but their team seems to be heavily based around
github (pull requests, gitter sharing, etc.), so it's not obvious to me
whom to contact. I can look into finding a contact if people think it's
worthwhile.

~Chad

[-- Attachment #2: Type: text/html, Size: 2327 bytes --]

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]



> On Apr 22, 2020, at 1:46 PM, chad <yandros@gmail.com> wrote:
> 
> On Wed, Apr 22, 2020 at 6:27 AM Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> wrote:
> > Cc: emacs-devel@gnu.org <mailto:emacs-devel@gnu.org>
> > From: Dmitry Gutov <dgutov@yandex.ru <mailto:dgutov@yandex.ru>>
> > Date: Wed, 22 Apr 2020 04:35:48 +0300
> > 
> > > Does this mean users who download this "shiny Emacs" will be unable to
> > > upgrade to a newer version?
> > 
> > The pre-configuration could contain just one line:
> > 
> >    (require 'shiny-settings)
> > 
> > where shiny-settings.el is distributed with Emacs and is updated 
> > together with new releases.
> 
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?
> 
> Spacemacs, Doom, and Prelude (to name just three of the more popular options) all make this work out-of-tree, so it certainly seems possible. From my reading, the first two (at least) are strongly expected to be customized after installation, and to have those customizations survive updates of the "kit".
> 
> Spacemacs in particular adds a "layer" concept to emacs customization so that bundles of related options/code/packages/config can be turned on or off as a group.  Details can be found at: https://www.spacemacs.org/doc/LAYERS.html <https://www.spacemacs.org/doc/LAYERS.html>. I would personally hope that we could streamline this process, which seems pretty bulky from the outside. Maybe inviting the Spacemacs people to share their experience that led to creating their layers system would be helpful to us both. (I would have CC'd them onthis message, but their team seems to be heavily based around github (pull requests, gitter sharing, etc.), so it's not obvious to me whom to contact. I can look into finding a contact if people think it's worthwhile.
> 
> ~Chad
> 

I’ve used Spacemacs for quite a while back in 2017 when I just started using Emacs. It’s more of a gigantic community-driven config than an out-of-box for-dummy kit. What I envisioned is more like what VSCode does: automatically installing appropriate packages and downloading and setting up external programs. I would use it if there is such feature - many of my configs are just (use-package package) with some code adding hooks and auto-mode-alist.

Some ideas: 
1. Is it ok to include MELPA (opt-in) as one of the mirrors? Say a newbie type M-x auto-package-mode, and boom, all the auto installing package features are on, and MELPA is added to package-archives. 
2. Could Emacs downloads some external programs (like LSP servers) for users? I would definitely let Emacs do the dirty work if it works reliably. But maybe there are security/maintenance concerns.
3. It would be cool if Customize can customize mode hooks and auto-mode-alist and other usual stuff.

Yuan



[-- Attachment #2: Type: text/html, Size: 4324 bytes --]

Re: Making Emacs more friendly to newcomers

[chad]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Wed, Apr 22, 2020 at 3:52 PM Yuan Fu <casouri@gmail.com> wrote:

>
> Some ideas:
> 3. It would be cool if Customize can customize mode hooks and
> auto-mode-alist and other usual stuff.
>

It seems like most elisp packages could come with a standardized "Here's
the normal setup for this mode/package; would you like to run it now, have
it run on each startup, or see a new buffer where you can examine it now?",
analogous to how customize-theme prompts to
disallow/allow-once/allow-always code upon loading the theme. (Honestly, I
assume this never happened because most emacs devs seem to prefer
managing snippets of elisp over using customize.) Use-package gets part of
the way there; seems like it could easily get the typical setup hooks for a
package from the package itself.

~Chad

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]



> On Apr 22, 2020, at 8:12 PM, chad <yandros@gmail.com> wrote:
> 
> 
> On Wed, Apr 22, 2020 at 3:52 PM Yuan Fu <casouri@gmail.com <mailto:casouri@gmail.com>> wrote:
> 
> Some ideas: 
> 3. It would be cool if Customize can customize mode hooks and auto-mode-alist and other usual stuff.
> 
> It seems like most elisp packages could come with a standardized "Here's the normal setup for this mode/package; would you like to run it now, have it run on each startup, or see a new buffer where you can examine it now?", analogous to how customize-theme prompts to disallow/allow-once/allow-always code upon loading the theme.

If Customize can provide a interface, I’m sure packages will (slowly) adapt to it, just as they adapt to defcustom.

> (Honestly, I assume this never happened because most emacs devs seem to prefer managing snippets of elisp over using customize.)

Mainly for maintenance reasons, I guess. Custom file is usually not version-controlled. That’s not necessarily a bad thing, I find Customize useful for storing local configurations that could differ between machines (executable paths, etc). Maybe Customize could separate into two files, one version controlled, one local. And I can put many of my random setq’s into Customize. 




[-- Attachment #2: Type: text/html, Size: 2528 bytes --]

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 16:22, Eli Zaretskii wrote:
>> The pre-configuration could contain just one line:
>>
>>     (require 'shiny-settings)
>>
>> where shiny-settings.el is distributed with Emacs and is updated
>> together with new releases.
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?

Just make sure the custom file is loaded after.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 조성빈 <pcr910303@icloud.com>,  Richard Stallman
>  <rms@gnu.org>,  Ahmed Khanzada <me@enzu.ru>,  "joseph.h.garvin@gmail.com"
>  <joseph.h.garvin@gmail.com>,  "stefan@marxist.se" <stefan@marxist.se>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>,  "eliz@gnu.org"
>  <eliz@gnu.org>,  "drew.adams@oracle.com" <drew.adams@oracle.com>
> Date: Sun, 19 Apr 2020 16:21:40 +0800
> 
> Again: what's wrong with putting a button on the splash screen?

Nothing.  The only problem is to decide what will that button
activate.  I think you will find that opinions vary widely about that.

P.S. And why does every message from you get sent twice to each
addressee?

RE: Making Emacs more friendly to newcomers

[Drew Adams]

> P.S. And why does every message from you get sent twice to each
> addressee?

+1

Re: Making Emacs more friendly to newcomers

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Nothing.  The only problem is to decide what will that button
> activate.  I think you will find that opinions vary widely about that.

Well, for starters things like CUA mode, maybe a hypothetical `gtk'
theme, and other things like that.  But that will likely require a lot
of debate yes.

> P.S. And why does every message from you get sent twice to each
> addressee?

I'm not sure, I'll look into it.  Sorry!

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I personally find that the stance of trying to not breaking anything is
> one of the big reasons that Emacs has a nonusable-without-configuration UX.
> Major version numbers are there for a reason… and we can expect for annoyed
> people to set some variables to get old behavior.

Major version numbers are there to announce new features.  With massive
changes (such as the ones that are being proposed here), you can't just
"flip a variable to get the old behaviour".  Especially people with 20
years of muscle memory and 200,000+ line configs.

Again: what's wrong with the "if you're new to Emacs, click here" button?

Re: "Why is emacs so square?"

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes;  I should be able to get it
> in a usable state soon

Interesting.  Can you use all the normal editing commands inside the
text field widget?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > * A UI that doesn't look or behave like any other application
  > * Keyboard shortcuts inconsistent with every other application
  > * A bizarre ancient vocabulary inconsistent with every other application.

A new user might well think of Emacs keyboard commands as "shortcuts",
carrying over the concepts that perse has learned in using other
programs.  When it comes to understanding what new users think,
we need to know what concepts they use.

But those characters are not really "shortcuts".

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 16, 2020, at 23:58, Drew Adams <drew.adams@oracle.com> wrote:
> 
> And count me as one vote for the menu-bar being
> important, especially for discoverability.  The
> tool-bar is less important, IMO, but I'd still
> vote to keep it.

The tool bar especially would work better if it looked/acted like it were native.



Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

RE: "Why is emacs so square?"

[Drew Adams]

> The tool bar especially would work better if it
> looked/acted like it were native.

I suppose I can guess what you mean by "looking"
native, but not what "acting" native means.

My impression is that different apps outside Emacs
can have radically different kinds of tool bars,
both wrt action and look & feel.  And this is so,
even for apps on the same platform, where they are
perhaps all "native".

IMHO, the Emacs tool-bar is something that it makes
sense - at least optionally - to pop up on demand,
rather than take up a fair amount of screen real
estate.

My library tool-bar+.el implements one way of doing
this - by having a menu-bar pseudo-menu `Buttons',
which, when clicked, shows the tool-bar only for one
operation.  Other ways of doing this or something
similar are possible, of course.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

(That library also gives you the possibility of
showing the tool-bar only on particular frames,
rather than showing it on all frames or not showing
it on any frame.)

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The tool bar especially would work better if it looked/acted like it were native.

Can you explain how that change in appearance would make it _work_ better?

I can understand claiming that people would feel more comfortable with it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "Why is emacs so square?"

[ndame]

> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.

If the cursor keys work out of the box then the tutorial should
begin with features which can be used without learning new cursor keys,
demonstrating something which emacs does well or better than other
tools. Is there such a thing? Or does learning emacs mostly pay off
for the advanced user? I can't think of a feature right know where
emacs shines for the casual user.

C-v and stuff are advanced topics IMO which pay off mostly in the long
run, not at the beginning, they could be shown in an advanced section
of the tutorial later.

And for keybindings there is no real need to switch to emacs, because,
for example, vscode can also have emacs keys:

https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx


So some feature should be found which can be shown for the casual user at the beginning
of the tutorial which may convince the user that emacs is worth the effort.

IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[조성빈]

2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:

>> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> 
> If the cursor keys work out of the box then the tutorial should
> begin with features which can be used without learning new cursor keys,
> demonstrating something which emacs does well or better than other
> tools.

Yeah, Emacs should not position it as an obscure editor that only gurus use. 

> Is there such a thing? Or does learning emacs mostly pay off
> for the advanced user? I can't think of a feature right know where
> emacs shines for the casual user.

Org mode, magit, helm comes to my mind.
Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

> C-v and stuff are advanced topics IMO which pay off mostly in the long
> run, not at the beginning, they could be shown in an advanced section
> of the tutorial later.
> 
> And for keybindings there is no real need to switch to emacs, because,
> for example, vscode can also have emacs keys:
> 
> https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx
> 
> 
> So some feature should be found which can be shown for the casual user at the beginning
> of the tutorial which may convince the user that emacs is worth the effort.
> 
> IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 20:57, 조성빈 wrote:
> Programmability should also be mentioned

As well as, specifically, that you can easily change Emacs's looks and 
behavior at runtime by evaluating code in *scratch*. Which allows for 
quick iterative development.

I know of no other mainstream editors that support this.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Sat, 25 Apr 2020 02:57:17 +0900
> 
> 2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:
> 
> >> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> > 
> > If the cursor keys work out of the box then the tutorial should
> > begin with features which can be used without learning new cursor keys,
> > demonstrating something which emacs does well or better than other
> > tools.
> 
> Yeah, Emacs should not position it as an obscure editor that only gurus use. 
> 
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
> 
> Org mode, magit, helm comes to my mind.
> Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

A tutorial is not for "selling" Emacs.  It's a good idea to write such
a "sales" document, but it would be a separate document.

A tutorial is supposed to teach the users how to use Emacs, so it
should indeed start from the basics.  Whether those basics should or
shouldn't begin with cursor motion is a matter of opinion, but it
would be strange to see an Emacs tutorial that would begin by showing
how to enter and use Org, Magit, Helm, and other similar packages.  I
challenge you to even write about these features without mentioning
"buffer", "window", "mode line", and other basics of the Emacs UI.
How can you talk about these without first saying something about what
they are, what they show, how they can be used, etc.?

RE: "Why is emacs so square?"

[Drew Adams]

> A tutorial is not for "selling" Emacs.  It's a good
> idea to write such a "sales" document, but it would
> be a separate document.

+1

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

Several years ago, someone put together "A guided tour of Emacs":

  https://www.gnu.org/software/emacs/tour/

I suspect what is being discussed here is a new version of that document,
possibly included directly in the build and/or linked from the default
startup screen.

~Chad

[-- Attachment #2: Type: text/html, Size: 465 bytes --]

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>
> I suspect what is being discussed here is a new version of that document, possibly included directly in the build and/or linked from the default startup screen.
>

Pretty nice and well put together. It really should be linked from
the startup screen.

For the record, here's a page with similar purpose for vscode.
It's useful to see what the competition offers. Just scroll
down and read the titles:

https://vscodecandothat.com/

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 18:53:56 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
>  조성빈 <pcr910303@icloud.com>,
>  EMACS development team <emacs-devel@gnu.org>
> 
> Pretty nice and well put together. It really should be linked from
> the startup screen.

It's already there.

Re: "Why is emacs so square?"

[chad]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Fri, Apr 24, 2020 at 12:25 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 24 Apr 2020 18:53:56 +0000
> > From: ndame <ndame@protonmail.com>
> > Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
> >  조성빈 <pcr910303@icloud.com>,
> >  EMACS development team <emacs-devel@gnu.org>
> >
> > Pretty nice and well put together. It really should be linked from
> > the startup screen.
>
> It's already there.
>

I checked again with emacs -q on a fresh build from this morning. The
default starting text is below, but it doesn't seem to include it. I also
checked the default Help menu, where I thought that it had once been
included, but didn't find it there, either. Maybe I got removed at some
point?

Welcome to GNU Emacs, one component of the GNU/Linux operating system.
> To follow a link, click Mouse-1 on it, or move to it and type RET.
> To quit a partially entered command, type Control-g.
>


Important Help menu items:
> Emacs Tutorial Learn basic Emacs keystroke commands
> Read the Emacs Manual View the Emacs manual using Info
> (Non)Warranty GNU Emacs comes with ABSOLUTELY NO WARRANTY
> Copying Conditions Conditions for redistributing and changing Emacs
> More Manuals / Ordering Manuals  How to order printed manuals from the FSF
>


Useful tasks:
> Visit New File Specify a new file’s name, to edit the file
> Open Home Directory Open your home directory, to operate on its files
> Customize Startup Change initialization settings including this screen
>


GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo
> version 1.16.0)
>  of 2020-04-24
> Copyright (C) 2020 Free Software Foundation, Inc.
>

[-- Attachment #2: Type: text/html, Size: 3341 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Fri, 24 Apr 2020 15:52:04 -0700
> Cc: ndame <ndame@protonmail.com>, Drew Adams <drew.adams@oracle.com>, 
> 	조성빈 <pcr910303@icloud.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
>  > Pretty nice and well put together. It really should be linked from
>  > the startup screen.
> 
>  It's already there.
> 
> I checked again with emacs -q on a fresh build from this morning. The default starting text is below, but it
> doesn't seem to include it. I also checked the default Help menu, where I thought that it had once been
> included, but didn't find it there, either. Maybe I got removed at some point?

No, it was not removed.  It's still there, both in Emacs 27 and on
master.  But we have several different variants of the startup screen,
and what gets actually displayed depends on how you invoke Emacs and
on Emacs's capabilities in the session you started.  So how did you
start Emacs (from the shell prompt, from some icon, from some
service), and what kind of features do you have in that build?

Alternatively, just read the code in startup.el and try to figure out
why you don't have that displayed in your case.  It usually means you
lack some capability, but of course there could be some bug as well.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:42, chad wrote:
> Several years ago, someone put together "A guided tour of Emacs":
> 
> https://www.gnu.org/software/emacs/tour/
> 
> I suspect what is being discussed here is a new version of that 
> document, possibly included directly in the build and/or linked from the 
> default startup screen.

Thanks for the link! Probably, yes.

A heavily updated and reorganized new version.

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>

Also, it's much more pleasant looking than the built-in tutorial
which is plain text. I wonder why the tutorial looks so barebones.
Why doesn't it use colors, fonts, formatting?

There should be some tutorial-presentation-mode which is turned on
in the tutorial buffer by default and spices up it a bit by adding
text properties.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 19:22:39 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>, 조성빈 <pcr910303@icloud.com>, EMACS development team <emacs-devel@gnu.org>
> 
> Also, it's much more pleasant looking than the built-in tutorial
> which is plain text. I wonder why the tutorial looks so barebones.
> Why doesn't it use colors, fonts, formatting?
> 
> There should be some tutorial-presentation-mode which is turned on
> in the tutorial buffer by default and spices up it a bit by adding
> text properties.

We have enriched-mode, if someone wants to add colors to the tutorial.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:10, Eli Zaretskii wrote:
> A tutorial is not for "selling" Emacs.

We should probably call it the "movement tutorial", or something like 
that. And make it come later in the introduction.

> how to enter and use Org, Magit, Helm, and other similar packages.  I
> challenge you to even write about these features without mentioning
> "buffer", "window", "mode line", and other basics of the Emacs UI.

All of these can be introduced much quicker than a 12-page document. And 
the user doesn't need to know *how* to do stuff before they can learn 
about the things Emacs can do.

And at least for Magit and Helm, it's perfectly possible to describe 
their selling points without first introducing what "buffers" and "mode 
line" are. Maybe even windows.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 24 Apr 2020 21:40:55 +0300
> 
> > how to enter and use Org, Magit, Helm, and other similar packages.  I
> > challenge you to even write about these features without mentioning
> > "buffer", "window", "mode line", and other basics of the Emacs UI.
> 
> All of these can be introduced much quicker than a 12-page document.

Maybe it can, maybe it can't.  I encourage you (or someone else) to
show such a variant of the introductory text, then we'd have something
to talk about, including comparing it with what we have now.

> And at least for Magit and Helm, it's perfectly possible to describe 
> their selling points without first introducing what "buffers" and "mode 
> line" are. Maybe even windows.

Once again, "selling" is a different document.  Describing how to use
these feature without the basics could work for those who already know
the basics, but not for those who don't.  Maybe you assume that people
who read the tutorial already know the basics.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 22:22, Eli Zaretskii wrote:

>> All of these can be introduced much quicker than a 12-page document.
> 
> Maybe it can, maybe it can't.  I encourage you (or someone else) to
> show such a variant of the introductory text, then we'd have something
> to talk about, including comparing it with what we have now.

Guess it's going on my list. But if anyone starts working on the new 
version, I have a few suggestions, please hit me up.

>> And at least for Magit and Helm, it's perfectly possible to describe
>> their selling points without first introducing what "buffers" and "mode
>> line" are. Maybe even windows.
> 
> Once again, "selling" is a different document.  Describing how to use
> these feature without the basics could work for those who already know
> the basics, but not for those who don't.  Maybe you assume that people
> who read the tutorial already know the basics.

"Selling" happens first. Then the new user has more motivation to 
actually learn stuff in detail.

Re: "Why is emacs so square?"

[ndame]

>
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
>
> Org mode, magit, helm comes to my mind.


Orgmode is included, but helm and magit are in melpa. Emacs should feature
packages which are accessible for the new user without tinkering. Though,
if the newbie.el which can setup a beginner friendly environment if emacs
is started without config is allowed to add melpa to the package list and
install helm/magit automatically then it's ok, because then it is instantly
available  for the new user.

BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
is extremely clunky, especially if one comes from other modern tools.

A user accustomed to modern tools expects something like this:

https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png

A vertical list which is instantly filtered as you type.

Compared to this the default completion is hoplessly old fashioned with its
multicolumn text display and having to press for TAB for the results.

Icomplete is a step in the right direction. The above mentioned newbie.el
should set it up instead of the default completion.

Though, it's a single line displaying completions, a vertical display
could be better, especially if the entries are longer.

And someone did it already:

https://github.com/oantolin/icomplete-vertical

Icomplete-vertical should be adopted into the core as an option and this
is how completion should be set up for newbies.

It's still not as good looking as the one on my first link, but it's
almost there. It's vertical, it gives you instant results, so it's much
closer to completion provided by modern tools (Idea, VsCode, etc.) than
the default one.

Re: "Why is emacs so square?"

[Yuan Fu]

> On Apr 25, 2020, at 12:28 PM, ndame <ndame@protonmail.com> wrote:
> 
>> 
>>> Is there such a thing? Or does learning emacs mostly pay off
>>> for the advanced user? I can't think of a feature right know where
>>> emacs shines for the casual user.
>> 
>> Org mode, magit, helm comes to my mind.
> 
> 
> Orgmode is included, but helm and magit are in melpa. Emacs should feature
> packages which are accessible for the new user without tinkering. Though,
> if the newbie.el which can setup a beginner friendly environment if emacs
> is started without config is allowed to add melpa to the package list and
> install helm/magit automatically then it's ok, because then it is instantly
> available  for the new user.
> 
> BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
> is extremely clunky, especially if one comes from other modern tools.
> 
> A user accustomed to modern tools expects something like this:
> 
> https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png
> 
> A vertical list which is instantly filtered as you type.
> 
> Compared to this the default completion is hoplessly old fashioned with its
> multicolumn text display and having to press for TAB for the results.
> 
> Icomplete is a step in the right direction. The above mentioned newbie.el
> should set it up instead of the default completion.
> 
> Though, it's a single line displaying completions, a vertical display
> could be better, especially if the entries are longer.
> 
> And someone did it already:
> 
> https://github.com/oantolin/icomplete-vertical
> 
> Icomplete-vertical should be adopted into the core as an option and this
> is how completion should be set up for newbies.
> 
> It's still not as good looking as the one on my first link, but it's
> almost there. It's vertical, it gives you instant results, so it's much
> closer to completion provided by modern tools (Idea, VsCode, etc.) than
> the default one.
> 


Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

Yuan

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 25.04.2020 23:45, Yuan Fu wrote:

>> Though, it's a single line displaying completions, a vertical display
>> could be better, especially if the entries are longer.
>>
>> And someone did it already:
>>
>> https://github.com/oantolin/icomplete-vertical
>>
>> Icomplete-vertical should be adopted into the core as an option and this
>> is how completion should be set up for newbies.
>>
>> It's still not as good looking as the one on my first link, but it's
>> almost there. It's vertical, it gives you instant results, so it's much
>> closer to completion provided by modern tools (Idea, VsCode, etc.) than
>> the default one.
>>
> 
> 
> Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

And it's definitely a very good step.

It would be even better if it could work with any of the packages that 
move minibuffer into a childframe. Unfortunately, the combination seems 
broken one way or another, probably because icomplete-vertical has to 
rely on a hack to get the right behavior.

E.g. with https://github.com/honmaple/emacs-maple-minibuffer I get:

Debugger entered--Lisp error: (error "Cannot resize a minibuffer-only 
frame")
   resize-mini-window-internal(#<window 6 on  *Minibuf-1*>)
   window--resize-mini-window(#<window 6 on  *Minibuf-1*> 36)
   enlarge-window(1)
   icomplete-vertical-minibuffer-setup()
   run-hooks(icomplete-minibuffer-setup-hook)
   icomplete-minibuffer-setup()

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > If the cursor keys work out of the box then the tutorial should
  > > begin with features which can be used without learning new cursor keys,
  > > demonstrating something which emacs does well or better than other
  > > tools.

I used to think it was important to teach Emacs cursor motion
character because they are needed to edit efficiently.  But if that
is a big discouragement to using the tutorial, let's try it another way.

  > Org mode, magit, helm comes to my mind.

"Org mode", as currently conceptualized (a single thing), is not
suitable to teach to beginners.  If we reconceptualize it as several
task-specific features, some of them may be useful to teach to
beginners.

Magit is not part of Emacs.  I would like to include it in Emacs.  A
year ago, its developer agreed to cooperate with getting the copyright
assignments; but last January, after I found a volunteer to do the
work of arranging this with contributors, the developer did not
respond.

Has anyone been in touch with him since then?  It would be very good
to get this moving.

I don't know what Helm's situation is (or what it does), but whether
describing it in Emacs is an option to consider depends on that
situation.

As a general matter, it is a lot more work to describe something with
a learn-by-doing tutorial than to describe it in a manual.  The number
of topics we can teach in the tutorial is thus limited.  The existing
tutorial does not talk about _any_ special purpose subsystems, not
even Dired, and I think it how it should be.

I think that people who reach the stage of starting using Dired
already know enough that they don't need a learn-by-doing tutorial to
learn it, and they might on the contrary find it annoyingly slow as a
way to learn.  That must go double for Magit.  The best way to tell
people how to use features like that is with ordinary manuals.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: "Why is emacs so square?"

[Drew Adams]

> > Eli, does this name length matter any more?
> 
> No.  Especially since we stopped splitting our manuals into foo-N
> parts long ago.
> 
> The only issue today is that renaming the Info file will make the
> successful update of the system-wide DIR file by install-info at "make
> install" time more important, otherwise people might have an old
> manual presented to them.  Not sure what this means for the various
> binary distros.  Also, we need to rework all the references we have to
> that manual in Lisp files (I found only one such reference, FWIW).

Maybe another, minor, consideration: There are
likely many references to parts of the manual
out there, beyond Emacs (e.g. on web sites).

In some cases a reference might be just textual,
e.g., "(eintr) Yanking".

In other cases it might be a URL to the manual
on line, e.g.:

https://www.gnu.org/software/emacs/manual/html_node/eintr/Yanking.html

(URLs can be redirected, of course.)

Re: "Why is emacs so square?"

[Jeff Norden]

Copied below is what I've posted to lwn.net in response to the article "Making
Emacs popular again" (https://lwn.net/Articles/819452/) about this thread.
Some of it, particularly the last part, is in response to that article rather
than anything that anyone has or would say on the emacs-devel list.
------------------------------
I'm late to this party, but as a longtime user of Gnu emacs, I feel obligated
to weigh in.  I've been using emacs on an almost daily basis for 30+ years.  I
use rmail for about 90% of my email.  I use a customized version of TeX mode
for composing documents, which include exams/quizzes/handout for the classes I
teach, research-related work, as well as mundane letters, memos, notes, etc.
I use emacs for all of the software that I write and/or dabble with, mostly
Perl and C.  I use shell-mode about as often as I use a terminal window
(currently mate-terminal, a fork of the pre-gnome-3 gnome-terminal).

To start with, the idea that emacs "needs" to have more users to prevent it
from becoming "extinct" is basically absurd.  Free software, by its very
nature, *can't* become extinct.  Even if current trends/fads mean that there
is a lull in the number of people using Gnu emacs today, the source code will
still be available for future generations to discover and use.  It's about
like saying that we must find a way to make the "Early New English" language
of the 17th century more appealing and widely spoken in order to prevent the
works of Shakespeare from becoming extinct.  Even if, for some reason, people
stopped reading and producing Shakespeare's plays for a number of years, they
would undoubtedly be re-discovered and become popular again.

This all seems to be part of the current insane attitude that software, and
technology in general, is some sort of perishable commodity with the shelf
life of milk.  Somehow, if it isn't updated every month or so, it just isn't
any good any more, even though it still does what it used to and your needs
for it haven't changed.

Emacs has never been an editor for "casual" user.  It doesn't compete with
notepad, any of the various "office" editors (open source or not), or even
vi/vim.  Gnu emacs is for people that want an extensible editor that gives
them complete control over how it operates, and can be easily and freely
customized to accomplish any sort of task that they want it to.  This sort of
freedom comes with a price - you need to invest some time and effort in order
to learn how to use it effectively.  But for many of us, it is an effort that
has been more than worthwhile.

In my opinion, it would be incredibly counterproductive to try to attract
people who don't need the functionality that emacs provides, or who aren't
willing to put forth the effort required to learn how to effectively use that
functionality.  I believe this means that any person who's decision on whether
or not to use an editor is swayed by the appearance of buttons or rounded
corners is someone who should *not* be encouraged to start using emacs.  If
you are not attracted to emacs by the features it provides and the tasks it
can accomplish, then please find an editor that will better suit your needs.

On the other hand, if someone wants to add such features for their own
benefit, perhaps because they feel it will enhance their own aesthetic
experience while using emacs, then by all means do so.  That is the whole
point of free software, after all.  But adding these in an attempt to attract
more users is a bad idea.

My *fear* is that a major effort to increase the "user base" will lead to the
transformation of emacs into something that doesn't serve anybody's needs very
well.  This is happening in many open source projects, where all sorts of
functionality has been deprecated and then removed because of the perception
that it isn't needed or being used by a large enough fraction of users.  The
recent loss of malloc_get_state() and malloc_set_state() are examples that are
particularly relevant to emacs.

Even in emacs, I personally found it a bit annoying to type "M-x count lines
region" only to be told in the mini-buffer that:
  ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
But this was easily fixed by adding a single line to my .emacs file.  However,
if large blocks of code start disappearing from the source, or changes are
made that render existing elisp files unusable, then emacs really will run the
risk of becoming extinct.

For example, a package of elisp functions that I wrote 30 years ago for
emacs-18, which I use to record and average student grades, still works just
fine with emacs-26.  TeX is the only other software that I know of with this
level of stability.  It seems that there are very few people today who, like
Knuth and Stallman, take a long-term view of what they are trying to
accomplish.  I could go on along these lines, but this is probably sufficient.

----

However, I feel that I must respond directly to some of the comments about RMS
that have been made, along the lines of "emacs would be better without him" or
his "signature tantrums."  I'll respond in a way that RMS never would, because
he is far too polite:

   Do you have any idea who the f*** you are talking about!!?

When Richard founded the FSF, which basically started the free software
movement, people tried to write him off as some sort of extremest nutcase.
"Nobody will write software and just give it away" was a common criticism.
Well, history has shown that Stallman was correct, and his critics were the
nutcases.  It's quite possible that there would be almost no free software, no
linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
unfailing efforts and unwavering belief in free software though the years.  My
own opinion is that, if anything, Richard's opinions and views are a bit too
mild and conservative.

The arrogance of youth is natural.  I was certainly guilty of it when I was
young.  But there is no excuse for disrespecting the people who basically
built the universe that you currently enjoy inhabiting.

-Jeff

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 26.05.2020 20:09, Jeff Norden wrote:
> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.

By that logic, you shouldn't worry too much about what happens to its 
development either: after all, you could continue to use one of the 
versions already released for 10 or 20 or however more years.

Re: "Why is emacs so square?"

[Arthur Miller]

Jeff Norden <jnorden@math.tntech.edu> writes:

Interesting read, but there are some fallacies, or maybe not a fallacies
but implicit assumptions that maybe are not justified:


>   Free software, by its very
> nature, *can't* become extinct.  Even if current trends/fads mean that there
> is a lull in the number of people using Gnu emacs today, the source code will
> still be available for future generations to discover and use.  It's about
> like saying that we must find a way to make the "Early New English" language
> of the 17th century more appealing and widely spoken in order to prevent the
> works of Shakespeare from becoming extinct.  Even if, for some reason, people
> stopped reading and producing Shakespeare's plays for a number of years, they
> would undoubtedly be re-discovered and become popular again.
Njah, but software is not a literar work. I don't think that people are
even reading Shakespeare with same enthusiasm and appreciation as they
did back in his own time. I don't think they appreciate him less today,
but they probably appreciate him in a different way. I don't think this
analogy works for software though, since software is written to be used,
practially.

> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.
As a continuation of above, the software is not written to be just
appreciated.

If it ain't developed it will stop to work when the machine it works on
stops to exist, or the OS, or the ABIs changes etc. So to be continually
used software has to be continually updated as the system below it
updates. If we got stabile systems that will continues to work unchanged
then maybe the above would hold. I don't think though that current
hardware/OS/lib eco system is there yet. Also software is hard to write
have I heard somewhere and there will be bugs. Butgs needs to be fixed!
A bug fix means update. As we use software more and discover and fix
more bugs, updates will be needed. One can maybe stop adding features,
sure, but somehow people come with more desires and feature requests all
the time, so yet again, more updates, more bugs, more updates ... ehh. I
don't know, I don't see really analogy with literal work here. Evergreen
software has developed as an answer to certain human patterns, it ain't
come out from thin air, so I don't think it is really insane attitude as
the professor, with all the respect, writes.

> Emacs has never been an editor for "casual" user.  It doesn't compete with
> notepad, any of the various "office" editors (open source or not), or even
> vi/vim.  Gnu emacs is for people that want an extensible editor that gives
> them complete control over how it operates, and can be easily and freely
> customized to accomplish any sort of task that they want it to.
Sure, but what says that one does have to exclude the other?

> This sort of
> freedom comes with a price - you need to invest some time and effort in order
> to learn how to use it effectively.  But for many of us, it is an effort that
> has been more than worthwhile.
Why? What says price is mandated? Why can't easy things be easy,
no-effort, and complicated things left for people who wish to dive in? I
feel there is some prejudice and assumption there simply based on how
computer usage looks today. But what says things have to be as they are?
Can't we change the world? :-)

> In my opinion, it would be incredibly counterproductive to try to attract
> people who don't need the functionality that emacs provides, or who aren't
> willing to put forth the effort required to learn how to effectively use that
> functionality.  I believe this means that any person who's decision on whether
> or not to use an editor is swayed by the appearance of buttons or rounded
> corners is someone who should *not* be encouraged to start using emacs.  If
> you are not attracted to emacs by the features it provides and the tasks it
> can accomplish, then please find an editor that will better suit your needs.
I think rounded buttons were more of a joke, but anyway, I don't
understand why it would be counterproductive to attract people who are
not willing to become finger octopusses just to use Emacs? More people
means more eyes, more usage scenarios, more bugs descovered, more users
becomming with time power users, more functionality added, better
software in the long term and maybe more momentum to free world. I don't
understand how someone can see bigger grass roots as a diminutive. 

> Even in emacs, I personally found it a bit annoying to type "M-x count lines
> region" only to be told in the mini-buffer that:
>   ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
> But this was easily fixed by adding a single line to my .emacs file.
Poor you, I really feel your pain.

> However,
> if large blocks of code start disappearing from the source, or changes are
> made that render existing elisp files unusable, then emacs really will run the
> risk of becoming extinct.
Why would large blocks of code disappear? Nobody said Emacs should go
rewritten from scratch, stuff should get thrown away etc.

> For example, a package of elisp functions that I wrote 30 years ago for
> emacs-18, which I use to record and average student grades, still works just
> fine with emacs-26.  TeX is the only other software that I know of with this
> level of stability.  It seems that there are very few people today who, like
> Knuth and Stallman, take a long-term view of what they are trying to
> accomplish.  I could go on along these lines, but this is probably sufficient.
I don't know, I think we have never before had so many textbooks on how
to design and write software, especially libraries and APIs so they are
easy to change and modify withouth affecting existing adopters? Isn't
entire OOP an answer to that? Are you really sure there are so few
people today who takes long term stability that lightly? 

> ----
>
> However, I feel that I must respond directly to some of the comments about RMS
> that have been made, along the lines of "emacs would be better without him" or
> his "signature tantrums."  I'll respond in a way that RMS never would, because
> he is far too polite:
>
>    Do you have any idea who the f*** you are talking about!!?
>
> When Richard founded the FSF, which basically started the free software
> movement, people tried to write him off as some sort of extremest nutcase.
> "Nobody will write software and just give it away" was a common criticism.
> Well, history has shown that Stallman was correct, and his critics were the
> nutcases.  It's quite possible that there would be almost no free software, no
> linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
> unfailing efforts and unwavering belief in free software though the years.  My
> own opinion is that, if anything, Richard's opinions and views are a bit too
> mild and conservative.
>
> The arrogance of youth is natural.  I was certainly guilty of it when I was
> young.  But there is no excuse for disrespecting the people who basically
> built the universe that you currently enjoy inhabiting.
>
> -Jeff
I completely agree here. I don't know though if it is relevant, since
making Emacs more of a in-time player in 21st century is by no mean a
dissrespect to RMS or anyone else.

Re: "Why is emacs so square?"

[Jeff Norden]

This is a follow-up to may post from May, plus a concrete suggestion.

Of course, my Shakespere analogy was a bit tongue-in-cheek.  But software
and literature are both artistic human activities, and have more
similarities than you might think.  This would be more apparent if Knuth's
concept of Literate Programming were used more widely.

Of course, software *must* be updated regularly.  But I still contend that
the current pace borders on insanity.  Updates often seem to be done merely
to satisfy some current "ui" or "ux" trends.  In other projects, including
GPL ones, this has resulted in removing functionality and stripping out
large swaths of source code.  I would hate to see that happen to emacs.
There is a Doonsbury cartoon that I like, even though it refers to the most
un-free software platform in existence:
  https://www.gocomics.com/doonesbury/2014/03/16

I think the risk of emacs becoming extinct because of a lack of users is
overblown.  But, I probably overstepped in arguing for some sort of elitist
attitude.  I still think it would be counterproductive to concentrate on
superficial changes, like button shapes, just to attract more "warm
bodies."  On the other hand, anything that makes it easier for a person to
reach the point where they say:

   Hey, I never realized that you could do *that* with an editor!

is absolutely worth pursuing.  This would, hopefully, help convince them of
the value of not just emacs, but free software more generally.

----------
In this last regard, it occurs to me that a small defun from my personal
dot-emacs might help.  Everyone starting out with emacs eventually finds
themselves in some sort of state that they need to get out of.  Often a
recursive edit, sometimes several level deep.  I've never been a big fan of
ESC ESC ESC. For a while, I got in the habit of typing "M-X top-level" a
lot.  Then I added the following to my dot-emacs, and have been quite happy
with it:

    (defun keyboard-quit-strong ()
      "Run `keyboard-quit' to return emacs to a more responsive state.
    If repeated twice in a row, run `top-level' instead, to also exit
    any recursive editing levels."
      (interactive)
      (when (eq last-command 'keyboard-quit-strong)
	(setq this-command 'top-level) ;dis-arm a 3rd C-g
	(ding)
	(top-level))
      ;; Not reached after `top-level'. (A rare behavior in lisp.)
      (keyboard-quit))

    (global-set-key "\C-g" 'keyboard-quit-strong)

Here are my reasons for preferring this over ESC ESC ESC:

1) Everyone using emacs has to learn C-g, since it is the only way to
interrupt the interpreter.  One less thing to remember is always good.

2) If you manage to get yourself 10-levels deep in recursive edits somehow,
ESC ESC ESC ESC... is pretty tedious, since it only exits one level for each
three ESC's.

3) When the first ESC ESC ESC doesn't work for some reason, and you try more,
it's easy to lose count and wind up with an extra ESC.  You might type another
key before 'ESC-' appears in the echo area, with some unintended (albeit
usually benign) consequence.

4) Some of the ESC ESC ESC actions, especially delete-other-windows, seem
unexpected to me.  Isn't it more confusing, rather than helpful, to have the
window configuration you've carefully set up suddenly disappear?  I suppose it
might make sense after *Help* pops up, unless you've moved the point into the
*Help* buffer.  It seems to me that 'C-x 1' and 'C-x 2' are bindings that just
about everyone learns early on anyway, but I could be wrong.

A few other points:

If you repeatedly type C-g, the echo area toggles between "Quit" and
"Back to top level."  This nicely indicates what is going on.

If emacs is stuck in the interpreter, it takes at least three C-g's, to get
top-level to run.  Despite this, I have yet to break the 'G' key on any of my
keyboards, no matter how frustrated I've gotten :-).

I don't think I have ever accidentally exited from a recursive edit that I
wanted to keep using, such as a backtrace, by unintentionally typing C-g too
many times.  But this it is something to be considered.  On the other hand,
I've recently used this binding *a lot* along with debug-on-entry.

----------
Hope this helps, and that anyone reading this is healthy and staying safe.

-Jeff Norden

Re: "Why is emacs so square?"

[Jeff Norden]

Oops, that first line should read "...my post from May,"
Also, it looks like the list-archive software didn't pick this up as
continuing that thread, so here is a link:
  https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03191.html

-Jeff