Making Emacs popular again with a video

Making Emacs popular again with a video

[Nathan Colinet]

Hello,

I read on the mailing list that you're looking for a way to make Emacs 
popular again. I thought I could share my idea.

I started using emacs a year ago and when I started everything was 
really confusing, what is a frame, what is a buffer, how to install 
packages, what are major and minor modes, etc.. I wanted to give up but 
then I saw a 1 hour talk about Emacs that shows how powerful it is. Then 
I was hooked. Unfortunately the sound was no good at all and it was way 
too long. I think it could be really benefic for emacs to have a 5-10 
minutes video that would present Emacs not as an old obscure porgram but 
as an amazing fresh looking tool that drastically improves efficiency. I 
think people nowadays need an out-of-the-box experience, that's why 
promoting doom-emacs or spacemacs might be better than the default Emacs.

I think if the video is well realised it could really be a huge win.

Stay safe and well,

Nathan Colinet

Re: Making Emacs popular again with a video

[Arthur Miller]

Nathan Colinet <colinetnathan98@gmail.com> writes:

> Hello,
>
> I read on the mailing list that you're looking for a way to make Emacs popular
> again. I thought I could share my idea.
>
> I started using emacs a year ago and when I started everything was really
> confusing, what is a frame, what is a buffer, how to install packages, what are
> major and minor modes, etc.. I wanted to give up but then I saw a 1 hour talk
> about Emacs that shows how powerful it is. Then I was hooked. Unfortunately the
> sound was no good at all and it was way too long. I think it could be really
> benefic for emacs to have a 5-10 minutes video that would present Emacs not as
> an old obscure porgram but as an amazing fresh looking tool that drastically
> improves efficiency. I think people nowadays need an out-of-the-box experience,
> that's why promoting doom-emacs or spacemacs might be better than the default
> Emacs.
>
> I think if the video is well realised it could really be a huge win.
>
> Stay safe and well,
>
> Nathan Colinet
There are already such videos. Check out emacs rocks on YT.
https://www.youtube.com/user/emacsrocks

Those are even linked to on Emacs webpage, ir you open emacs.org and
scroll down, you will find the links.

But surely Emacs could have used more of such short feature showing-off
videos/tutorials. 

Re: Making Emacs popular again with a video

[Nathan Colinet]

> There are already such videos. Check out emacs rocks on YT.
> https://www.youtube.com/user/emacsrocks
>
> Those are even linked to on Emacs webpage, ir you open emacs.org and
> scroll down, you will find the links.
I don't think any brand new user will bother watching something like 
"episode 15 restclient-mode". I think they need "How Emacs makes you 
efficient" or "Emacs makes everything easier" on emacs.org.

> But surely Emacs could have used more of such short feature showing-off
> videos/tutorials.
Maybe Emacs doesn't need more of them but only a good one IMHO.

Regards,

Nathan

On 2020-05-08 12:39, Arthur Miller wrote:
> Nathan Colinet <colinetnathan98@gmail.com> writes:
>
>> Hello,
>>
>> I read on the mailing list that you're looking for a way to make Emacs popular
>> again. I thought I could share my idea.
>>
>> I started using emacs a year ago and when I started everything was really
>> confusing, what is a frame, what is a buffer, how to install packages, what are
>> major and minor modes, etc.. I wanted to give up but then I saw a 1 hour talk
>> about Emacs that shows how powerful it is. Then I was hooked. Unfortunately the
>> sound was no good at all and it was way too long. I think it could be really
>> benefic for emacs to have a 5-10 minutes video that would present Emacs not as
>> an old obscure porgram but as an amazing fresh looking tool that drastically
>> improves efficiency. I think people nowadays need an out-of-the-box experience,
>> that's why promoting doom-emacs or spacemacs might be better than the default
>> Emacs.
>>
>> I think if the video is well realised it could really be a huge win.
>>
>> Stay safe and well,
>>
>> Nathan Colinet
> There are already such videos. Check out emacs rocks on YT.
> https://www.youtube.com/user/emacsrocks
>
> Those are even linked to on Emacs webpage, ir you open emacs.org and
> scroll down, you will find the links.
>
> But surely Emacs could have used more of such short feature showing-off
> videos/tutorials.

Re: Making Emacs popular again with a video

[Stefan Kangas]

Nathan Colinet <colinetnathan98@gmail.com> writes:

> I started using emacs a year ago and when I started everything was
> really confusing, what is a frame, what is a buffer, how to install
> packages, what are major and minor modes, etc.. I wanted to give up but

Welcome to Emacs!  You made the right choice.

> then I saw a 1 hour talk about Emacs that shows how powerful it is. Then
> I was hooked. Unfortunately the sound was no good at all and it was way
> too long. I think it could be really benefic for emacs to have a 5-10
> minutes video that would present Emacs not as an old obscure porgram but
> as an amazing fresh looking tool that drastically improves efficiency.

This is a very good idea.  The only problem is that someone has to do
it.  :-)

Would you be prepared to volunteer for working on that?

> I think people nowadays need an out-of-the-box experience, that's why
> promoting doom-emacs or spacemacs might be better than the default
> Emacs.

This is valuable input, I think.

Best regards,
Stefan Kangas

Re: Making Emacs popular again with a video

[Nathan Colinet]

Thank you for your reply.

I would happily help on that video (for the content) but I'm definitely 
not qualified to shoot/realise it, I don't even have a decent micro. I 
think if we want this video to have the desired effect the FSF or GNU 
(don't know who's in charge) might need to pay someone to realise it.

Regards,

Nathan

On 2020-05-08 12:41, Stefan Kangas wrote:
> Nathan Colinet <colinetnathan98@gmail.com> writes:
>
>> I started using emacs a year ago and when I started everything was
>> really confusing, what is a frame, what is a buffer, how to install
>> packages, what are major and minor modes, etc.. I wanted to give up but
> Welcome to Emacs!  You made the right choice.
>
>> then I saw a 1 hour talk about Emacs that shows how powerful it is. Then
>> I was hooked. Unfortunately the sound was no good at all and it was way
>> too long. I think it could be really benefic for emacs to have a 5-10
>> minutes video that would present Emacs not as an old obscure porgram but
>> as an amazing fresh looking tool that drastically improves efficiency.
> This is a very good idea.  The only problem is that someone has to do
> it.  :-)
>
> Would you be prepared to volunteer for working on that?
>
>> I think people nowadays need an out-of-the-box experience, that's why
>> promoting doom-emacs or spacemacs might be better than the default
>> Emacs.
> This is valuable input, I think.
>
> Best regards,
> Stefan Kangas

Re: Making Emacs popular again with a video

[Eli Zaretskii]

> From: Nathan Colinet <colinetnathan98@gmail.com>
> Date: Fri, 8 May 2020 10:26:19 +0200
> 
> I started using emacs a year ago and when I started everything was 
> really confusing, what is a frame, what is a buffer, how to install 
> packages, what are major and minor modes, etc.. I wanted to give up but 
> then I saw a 1 hour talk about Emacs that shows how powerful it is. Then 
> I was hooked. Unfortunately the sound was no good at all and it was way 
> too long. I think it could be really benefic for emacs to have a 5-10 
> minutes video that would present Emacs not as an old obscure porgram but 
> as an amazing fresh looking tool that drastically improves efficiency. I 
> think people nowadays need an out-of-the-box experience, that's why 
> promoting doom-emacs or spacemacs might be better than the default Emacs.
> 
> I think if the video is well realised it could really be a huge win.

I think it's a very good idea.  Would someone want to produce such a
video?

Re: Making Emacs popular again with a video

[Nathan Colinet]

We could find someone on reddit, I think a lot of YouTubers are 
following r/linux. To ensure the video quality GNU or FSF might need to 
pay someone to produce it. I have some ideas about the features of emacs 
the video could highlight.

Regards,

Nathan

On 2020-05-08 13:33, Eli Zaretskii wrote:
>> From: Nathan Colinet <colinetnathan98@gmail.com>
>> Date: Fri, 8 May 2020 10:26:19 +0200
>>
>> I started using emacs a year ago and when I started everything was
>> really confusing, what is a frame, what is a buffer, how to install
>> packages, what are major and minor modes, etc.. I wanted to give up but
>> then I saw a 1 hour talk about Emacs that shows how powerful it is. Then
>> I was hooked. Unfortunately the sound was no good at all and it was way
>> too long. I think it could be really benefic for emacs to have a 5-10
>> minutes video that would present Emacs not as an old obscure porgram but
>> as an amazing fresh looking tool that drastically improves efficiency. I
>> think people nowadays need an out-of-the-box experience, that's why
>> promoting doom-emacs or spacemacs might be better than the default Emacs.
>>
>> I think if the video is well realised it could really be a huge win.
> I think it's a very good idea.  Would someone want to produce such a
> video?

Re: Making Emacs popular again with a video

[Stefan Kangas]

Nathan Colinet <colinetnathan98@gmail.com> writes:

> We could find someone on reddit, I think a lot of YouTubers are
> following r/linux. To ensure the video quality GNU or FSF might need to
> pay someone to produce it. I have some ideas about the features of emacs
> the video could highlight.

As far as I know, the FSF doesn't have any money set aside for
advertising Emacs.

We are a volunteer run project, so the way these things happen is
generally that someone just takes it upon themselves to do it.

IMHO, a very well thought out screencast could do the job just as well
as a professionally produced video.  All that is required is a bit of
initiative and creativity, I think, perhaps by asking around for
volunteers to help with certain tasks (for example voice recording of a
manuscript).

Best regards,
Stefan Kangas

Re: Making Emacs popular again with a video

[Andreas Röhler]

Am 08.05.20 um 10:26 schrieb Nathan Colinet:
> Hello,
> 
> I read on the mailing list that you're looking for a way to make Emacs 
> popular again. I thought I could share my idea.
> 
> I started using emacs a year ago and when I started everything was 
> really confusing, what is a frame, what is a buffer, how to install 
> packages, what are major and minor modes, etc.. I wanted to give up but 
> then I saw a 1 hour talk about Emacs that shows how powerful it is. Then 
> I was hooked. Unfortunately the sound was no good at all and it was way 
> too long. I think it could be really benefic for emacs to have a 5-10 
> minutes video that would present Emacs not as an old obscure porgram but 
> as an amazing fresh looking tool that drastically improves efficiency. I 
> think people nowadays need an out-of-the-box experience, that's why 
> promoting doom-emacs or spacemacs might be better than the default Emacs.
> 
> I think if the video is well realised it could really be a huge win.
> 
> Stay safe and well,
> 
> Nathan Colinet
> 
> 
> 

Hi,

thanks bringing that up. Agree such a video might be helpful. The 
reasons however, why Emacs is a kind of niche nowadays are multiple and 
complex. Leaving apart all items Emacs itself can't change, there is 
something which can be done IMO: making Emacs ready for a beginner in 
programming resp. for non-programmers. Make Emacs appear mannerly as 
just an editor first. Which also means: at the beginning leave apart all 
complex stuff useful for advanced programmers only.

For instance at "Introduction" fairly everything in first paragraphs 
IMHO may be dropped resp. should be moved at later sections. Copy stuff 
below for the convenience of the reader here.

All the day enjoying Emacs,
Andreas

Copy:

Introduction
************

You are reading about GNU Emacs, the GNU incarnation of the advanced,
self-documenting, customizable, extensible editor Emacs.  (The ‘G’ in
GNU (GNU’s Not Unix) is not silent.)

    We call Emacs “advanced” because it can do much more than simple
insertion and deletion of text.  It can control subprocesses, indent
programs automatically, show multiple files at once, edit remote files
like they were local files, and more.  Emacs editing commands operate in
terms of characters, words, lines, sentences, paragraphs, and pages, as
well as expressions and comments in various programming languages.

    “Self-documenting” means that at any time you can use special
commands, known as “help commands”, to find out what your options are,
or to find out what any command does, or to find all the commands that
pertain to a given topic.  *Note Help::.

    “Customizable” means that you can easily alter the behavior of Emacs
commands in simple ways.  For instance, if you use a programming
language in which comments start with ‘<**’ and end with ‘**>’, you can
tell the Emacs comment manipulation commands to use those strings (*note
Comments::).  To take another example, you can rebind the basic cursor
motion commands (up, down, left and right) to any keys on the keyboard
that you find comfortable.  *Note Customization::.

Re: Making Emacs popular again with a video

[Nathan Colinet]

Hi,

I agree that's too advanced for a beginner user.

On 2020-05-09 09:50, Andreas Röhler wrote:
>
>
> Am 08.05.20 um 10:26 schrieb Nathan Colinet:
>> Hello,
>>
>> I read on the mailing list that you're looking for a way to make 
>> Emacs popular again. I thought I could share my idea.
>>
>> I started using emacs a year ago and when I started everything was 
>> really confusing, what is a frame, what is a buffer, how to install 
>> packages, what are major and minor modes, etc.. I wanted to give up 
>> but then I saw a 1 hour talk about Emacs that shows how powerful it 
>> is. Then I was hooked. Unfortunately the sound was no good at all and 
>> it was way too long. I think it could be really benefic for emacs to 
>> have a 5-10 minutes video that would present Emacs not as an old 
>> obscure porgram but as an amazing fresh looking tool that drastically 
>> improves efficiency. I think people nowadays need an out-of-the-box 
>> experience, that's why promoting doom-emacs or spacemacs might be 
>> better than the default Emacs.
>>
>> I think if the video is well realised it could really be a huge win.
>>
>> Stay safe and well,
>>
>> Nathan Colinet
>>
>>
>>
>
> Hi,
>
> thanks bringing that up. Agree such a video might be helpful. The 
> reasons however, why Emacs is a kind of niche nowadays are multiple 
> and complex. Leaving apart all items Emacs itself can't change, there 
> is something which can be done IMO: making Emacs ready for a beginner 
> in programming resp. for non-programmers. Make Emacs appear mannerly 
> as just an editor first. Which also means: at the beginning leave 
> apart all complex stuff useful for advanced programmers only.
>
> For instance at "Introduction" fairly everything in first paragraphs 
> IMHO may be dropped resp. should be moved at later sections. Copy 
> stuff below for the convenience of the reader here.
>
> All the day enjoying Emacs,
> Andreas
>
> Copy:
>
> Introduction
> ************
>
> You are reading about GNU Emacs, the GNU incarnation of the advanced,
> self-documenting, customizable, extensible editor Emacs.  (The ‘G’ in
> GNU (GNU’s Not Unix) is not silent.)
>
>    We call Emacs “advanced” because it can do much more than simple
> insertion and deletion of text.  It can control subprocesses, indent
> programs automatically, show multiple files at once, edit remote files
> like they were local files, and more.  Emacs editing commands operate in
> terms of characters, words, lines, sentences, paragraphs, and pages, as
> well as expressions and comments in various programming languages.
>
>    “Self-documenting” means that at any time you can use special
> commands, known as “help commands”, to find out what your options are,
> or to find out what any command does, or to find all the commands that
> pertain to a given topic.  *Note Help::.
>
>    “Customizable” means that you can easily alter the behavior of Emacs
> commands in simple ways.  For instance, if you use a programming
> language in which comments start with ‘<**’ and end with ‘**>’, you can
> tell the Emacs comment manipulation commands to use those strings (*note
> Comments::).  To take another example, you can rebind the basic cursor
> motion commands (up, down, left and right) to any keys on the keyboard
> that you find comfortable.  *Note Customization::.
>

Re: Making Emacs popular again with a video

[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 instance at "Introduction" fairly everything in first paragraphs 
  > > IMHO may be dropped resp. should be moved at later sections. Copy 
  > > stuff below for the convenience of the reader here.

Perhaps there is no longer a need to inform the public of those
three basic capabilities of Emacs.

Do Emacs's current competitors have the same capabilities?

    > You are reading about GNU Emacs, the GNU incarnation of the advanced,
    > self-documenting, customizable, extensible editor Emacs. 
-- 
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 popular again with a video

[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. ]]]
>
>   > > For instance at "Introduction" fairly everything in first paragraphs 
>   > > IMHO may be dropped resp. should be moved at later sections. Copy 
>   > > stuff below for the convenience of the reader here.
>
> Perhaps there is no longer a need to inform the public of those
> three basic capabilities of Emacs.
>
> Do Emacs's current competitors have the same capabilities?
They have pretty much everything but "self-documenting", which should
maybe be referred as "self-retrospecting" feature. They usually rely on
external documentation. For the rest, they have it. Some of them are
created with goal to be like Emacs, just to use more familiar scripting
language then Lisp (i.e. Javascript) (VS Code, Brackets, Atom, etc).

Re: Making Emacs popular again with a video

[Dmitry Gutov]

On 12.05.2020 10:04, Arthur Miller wrote:
> They have pretty much everything but "self-documenting", which should
> maybe be referred as "self-retrospecting" feature

Self-introspecting?

Re: Making Emacs popular again with a video

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12.05.2020 10:04, Arthur Miller wrote:
>> They have pretty much everything but "self-documenting", which should
>> maybe be referred as "self-retrospecting" feature
>
> Self-introspecting?
Haha, probably :-)

Sorry I am not native english speaker, so I sometimes "guess" some
"international" words, 'coz I am lazy to look 'em up.

RE: Making Emacs popular again with a video

[Drew Adams]

> > They have pretty much everything but "self-documenting", which should
> > maybe be referred as "self-retrospecting" feature
> 
> Self-introspecting?

self introspecting = introspecting

introspect: "Reflect on one's own thoughts and feelings"

https://www.wordwebonline.com/search.pl?w=introspect

Re: Making Emacs popular again with a video

[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. ]]]

  > > Do Emacs's current competitors have the same capabilities?
  > They have pretty much everything but "self-documenting", which should
  > maybe be referred as "self-retrospecting" feature.

Do people think it is desirable to delete most of that intro text?
It is uder 15 lines; perhaps it is harmless to keep 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: Making Emacs popular again with a video

[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. ]]]
>
>   > > Do Emacs's current competitors have the same capabilities?
>   > They have pretty much everything but "self-documenting", which should
>   > maybe be referred as "self-retrospecting" feature.
>
> Do people think it is desirable to delete most of that intro text?
> It is uder 15 lines; perhaps it is harmless to keep it.

I don't think it is very important issue. It is normal to have a bit
longer introductorty text/description about application. It just does
not need to take screen estate on the welcome screen maybe?

By the way, I probably wouldn't try to identify Emacs as just a text
editor longer. Personally I see Emacs as en extensible platform, or
system (not in a sense of that joke of operating system), a tool, or
whatever one might wish to call it. I think it has developed and become
usefull much more then just as a text editor. Also I think it might help
if Emacs developed even further in that direction, as a
"multi-tool/swiss army knife" of human-computer interaction?

I don't use other text editors, so I really don't know how good they are
at other tasks then just text editing. I usually just take a look for
the curiosity sake when a new editor/IDE becomes popular, and then I
usually realize Emacs already has everything I need and just uninstall
the new thing. 

Re: Making Emacs popular again with a video

[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. ]]]

  > By the way, I probably wouldn't try to identify Emacs as just a text
  > editor longer. Personally I see Emacs as en extensible platform,

I designed Emacs to be a text editor.

I am disappointed that people extend Emacs ONLY to do other unrelated
jobs while NOT extending the kinds of text editing it will do.

-- 
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 popular again with a video

[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. ]]]
>
>   > By the way, I probably wouldn't try to identify Emacs as just a text
>   > editor longer. Personally I see Emacs as en extensible platform,
>
> I designed Emacs to be a text editor.
>
> I am disappointed that people extend Emacs ONLY to do other unrelated
> jobs while NOT extending the kinds of text editing it will do.
Why would you be dissapointed by that? Isn't it great that people make
stuff you haven't thought of with it?

People are extending Emacs for text editing as well, but it already is
quite competent as a text editor. Good job!

Re: Making Emacs popular again with a video

[Robert Pluim]

>>>>> On Thu, 14 May 2020 01:14:36 -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. ]]]

    >> By the way, I probably wouldn't try to identify Emacs as just a text
    >> editor longer. Personally I see Emacs as en extensible platform,

    Richard> I designed Emacs to be a text editor.

    Richard> I am disappointed that people extend Emacs ONLY to do other unrelated
    Richard> jobs while NOT extending the kinds of text editing it will do.

What, specifically, is missing in that area? If youʼre talking about
WYSIWYG-related features, I have free programs that can do that, and I
donʼt use them much directly: I use emacs to generate their format,
then touch up the results afterwards.

Robert

Re: Making Emacs popular again with a video

[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 like Emacs to have the features of LibreOffice -- at least for
word processing and slides.

It would take years to get there, but I hope to see it during my lifetime.

-- 
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 popular again with a video

[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 would like Emacs to have the features of LibreOffice -- at least for
> word processing and slides.
>
> It would take years to get there, but I hope to see it during my lifetime.
What do you mean with slides? Presentations? You can already do
slides-like stuff in org-mode, not as advanced as in Impress, but enough
for many situations. Some presentations are done via pdf-files which you
can show from Emacs. You could even use images to create a slide-show
mimicking a presentation. Or what features do you have in mind?

For some more advanced graphical features Emacs would need better
renderer, ability to display (and script) some graphics, layouting etc.

Why is that important for Emacs? I haven't personally opened an "office"
app for years, unless I had to do something for a customer. I think good
text editor like Emacs is more then fine for most needs. I think people
"need" office apps mostly because of marketing not because they really
need it, especially nowdays when we don't print so much like we did 20
years ago or so. I might be biased here though, it is just my reflection.

Re: Making Emacs popular again with a video

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 15 May 2020 09:55:16 +0200
> Cc: Robert Pluim <rpluim@gmail.com>, colinetnathan98@gmail.com,
>  andreas.roehler@online.de, emacs-devel@gnu.org
> 
> > I would like Emacs to have the features of LibreOffice -- at least for
> > word processing and slides.
> >
> > It would take years to get there, but I hope to see it during my lifetime.
> What do you mean with slides? Presentations? You can already do
> slides-like stuff in org-mode, not as advanced as in Impress, but enough
> for many situations. Some presentations are done via pdf-files which you
> can show from Emacs. You could even use images to create a slide-show
> mimicking a presentation. Or what features do you have in mind?

So maybe what is missing is a manual or a tutorial describing to users
how to create presentations using Org?

> For some more advanced graphical features Emacs would need better
> renderer, ability to display (and script) some graphics, layouting etc.

What is missing for displaying slides?  AFAIK, the current Emacs
display engine is perfectly capable of displaying text with images.

Besides, I'm not sure the produced slides should be displayed in Emacs
in the first place, they can be displayed by some image viewer, of
which I'm sure there are quite a few on any given system.

> Why is that important for Emacs?

IMO, that's not a valid question to ask about Emacs.  We could ask the
same about reading and sending email, displaying calendar and managing
appointments, many Org features, etc. etc.  Emacs users want to do
many jobs in Emacs, and editing documents is a job that's actually
closer to the original Emacs purpose than many others.

> I haven't personally opened an "office" app for years, unless I had
> to do something for a customer. I think good text editor like Emacs
> is more then fine for most needs. I think people "need" office apps
> mostly because of marketing not because they really need it,
> especially nowdays when we don't print so much like we did 20 years
> ago or so. I might be biased here though, it is just my reflection.

Careful: your personal perspective on this stuff is probably heavily
biased by your line of work and your experience.  There are people out
there who write documents of various kinds all day every day.

Re: Making Emacs popular again with a video

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Fri, 15 May 2020 09:55:16 +0200
>> Cc: Robert Pluim <rpluim@gmail.com>, colinetnathan98@gmail.com,
>>  andreas.roehler@online.de, emacs-devel@gnu.org
>> 
>> > I would like Emacs to have the features of LibreOffice -- at least for
>> > word processing and slides.
>> >
>> > It would take years to get there, but I hope to see it during my lifetime.
>> What do you mean with slides? Presentations? You can already do
>> slides-like stuff in org-mode, not as advanced as in Impress, but enough
>> for many situations. Some presentations are done via pdf-files which you
>> can show from Emacs. You could even use images to create a slide-show
>> mimicking a presentation. Or what features do you have in mind?
>
> So maybe what is missing is a manual or a tutorial describing to users
> how to create presentations using Org?
Could be. There are some tutorials/show-offs on youtube, and some
personal blogs, but maybe some more thought and put toghether manual
could help.

>> For some more advanced graphical features Emacs would need better
>> renderer, ability to display (and script) some graphics, layouting etc.
>
> What is missing for displaying slides?  AFAIK, the current Emacs
> display engine is perfectly capable of displaying text with images.
Slides as images (or pdfs), or even just plain text as some org :slide:
does work just fine as currently is in Emacs. I ment more that people
like to have some more elemnts, like lines, arrows, and
other graphical elements in office applications as well as laying out
those elements and text in a bit more advanced way. For example
text boxes in office apps. I am not sure how easy it is to layout images
and have text wrap around it in Emacs and similar. Maybe latex as a
document format could be fine, if Emacs can render final result as a buffer
view without going to file export/import and displaying back image or
pdf. Same for say html. I think, I am not sure. If Emacs could render
render those directly as buffer view while editing it, I think it would
be the word processor a lá "office".

> Besides, I'm not sure the produced slides should be displayed in Emacs
> in the first place, they can be displayed by some image viewer, of
> which I'm sure there are quite a few on any given system.
>
>> Why is that important for Emacs?
>
> IMO, that's not a valid question to ask about Emacs.  We could ask the
> same about reading and sending email, displaying calendar and managing
> appointments, many Org features, etc. etc.  Emacs users want to do
> many jobs in Emacs, and editing documents is a job that's actually
> closer to the original Emacs purpose than many others.
Fair enough, indeed :-).

>> I haven't personally opened an "office" app for years, unless I had
>> to do something for a customer. I think good text editor like Emacs
>> is more then fine for most needs. I think people "need" office apps
>> mostly because of marketing not because they really need it,
>> especially nowdays when we don't print so much like we did 20 years
>> ago or so. I might be biased here though, it is just my reflection.
>
> Careful: your personal perspective on this stuff is probably heavily
> biased by your line of work and your experience.  There are people out
> there who write documents of various kinds all day every day.
Yeah, I know, I am aware of my modest personal needs. It is just a
reflection on what I see over and over again: when my friends
ask me which office to get, I tell them they good enough with
included WordPad that comes with Windows, or to download Libre/Open
Office if they need more. Most of them bought anyway MS Office, because
it is "the best", even though they will use just like 1% of feature in
it.

Re: Making Emacs popular again with a video

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 15 May 2020 12:43:13 +0200
> Cc: rpluim@gmail.com, colinetnathan98@gmail.com, andreas.roehler@online.de,
>  rms@gnu.org, emacs-devel@gnu.org
> 
> > What is missing for displaying slides?  AFAIK, the current Emacs
> > display engine is perfectly capable of displaying text with images.
> Slides as images (or pdfs), or even just plain text as some org :slide:
> does work just fine as currently is in Emacs. I ment more that people
> like to have some more elemnts, like lines, arrows, and
> other graphical elements in office applications as well as laying out
> those elements and text in a bit more advanced way.

We have svg.el for that, can't it be utilized?

> For example text boxes in office apps. I am not sure how easy it is
> to layout images and have text wrap around it in Emacs and
> similar.

Shouldn't be a problem, we have image slices since Emacs 21.

Re: Making Emacs popular again with a video

[H. Dieter Wilhelm]

Arthur Miller <arthur.miller@live.com> writes:

> What do you mean with slides? Presentations? You can already do
> slides-like stuff in org-mode, not as advanced as in Impress, but enough
> for many situations. Some presentations are done via pdf-files which you
> can show from Emacs. You could even use images to create a slide-show
> mimicking a presentation. Or what features do you have in mind?

FYI: Nowadays you are able to accomplish more refined presentations with
LaTeX and the presentation package Beamer (among others) than all the
Office Applications.

You can do all the modern, fancy presentation stuff and moreover
including animations, videos and 3D objects (OK only Adobe Reader
supports 3D at the moment).

> For some more advanced graphical features Emacs would need better
> renderer, ability to display (and script) some graphics, layouting etc.

I suggest to use the LaTeX Tikz package for doing the graphics.  It has
also the advantage that the graphical fonts are consistent with the text
and mathematics.

  http://www.texample.net/tikz/examples/

> Why is that important for Emacs? I haven't personally opened an "office"
> app for years, unless I had to do something for a customer. I think
> good

The same here, even in my company I'm using org-mode LaTeX exports for
reports and presentations.

> text editor like Emacs is more then fine for most needs. I think people
> "need" office apps mostly because of marketing not because they really
> need it, especially nowdays when we don't print so much like we did 20
> years ago or so. I might be biased here though, it is just my reflection.

I'm not sure.  Could it be that the majority of people are not really
capable to work in abstract ways (like programming)?  I observe that
most of my colleagues and acquaintances are not willing or are hardly
able to operate programs without "visual guidance".  For example our
designers are rather using the mouse cascading into menus instead of
memorising and applying predefined keyboard shortcuts!

     Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Making Emacs popular again with a video

[H. Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:

> I would like Emacs to have the features of LibreOffice -- at least for
> word processing and slides.

I assume you mean WYSIWYG abilities, like dropping images and moving
them around or drawing over them.  Do you then also want a "visually"
guided graphical interface like in the LibreOffice components?

     Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Making Emacs popular again with a video

[Ben McGinnes]

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

On Thu, May 14, 2020 at 11:25:31PM -0400, Richard Stallman wrote:
> 
> I would like Emacs to have the features of LibreOffice -- at least
> for word processing and slides.

That's ambitious ...

Would you intend that to produce existing open standard formats
(i.e. mainly OpenDocument Format files, but someone will inevitably
include DOCX and PPTX out of necessity)?

> It would take years to get there, but I hope to see it during my
> lifetime.

Perhaps.  It depends on how much your vision actually requires native
support and how much can be done by utilising existing technology
which GNU Emacs already understands to produce that end result.

Both of those open formats[1] are based on XML.  So there's already
plenty of avenues for generating those more complicated formats from
something more readily edited by Emacs now.

OTOH, there are reasons I almost never use Emacs to write fiction and,
though I do use it in some aspects of preparing or making minor edits
of the pre-publication source files (which are in another XML format),
it's not really the primary tool there either.  Still, my use case is
fairly niche because most word processor users (and *all* slide
presentation users) don't need to care about traditional publishing
standards.

So, edge cases like mine aside, you can probably do a lot of what you
want now.  Though I suspect the org-mode project is in a better
position to make that a reality right now.


Regards,
Ben

 1. Including MS's formats out of practicality; let's skip the quirks
    of their license since people on this list either are, or should
    already be, aware of all that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Making Emacs popular again with a video

[Ben McGinnes]

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

On Sat, May 23, 2020 at 12:11:27AM -0400, Richard Stallman wrote:
> 
>> Would you intend that to produce existing open standard formats
>> (i.e. mainly OpenDocument Format files, but someone will inevitably
>> include DOCX and PPTX out of necessity)?
> 
> Sure, ideally.

Well, ODF does have a flat file format which can make it a little
easier to work with, though it's been a few years since I last did
anything like that.  Actually, maybe more than a few.  IIRC, though,
DOCX is far less painful under the hood (which is annoying, but not
much we can do about that now).

>> Perhaps.  It depends on how much your vision actually requires
>> native support and how much can be done by utilising existing
>> technology which GNU Emacs already understands to produce that end
>> result.
> 
> It is fine to make use of external free programs to do the job,
> provided that gives good practical results.

Then that opens up a lot of options, especially for intermediate
solutions to produce the desired output prior to achieving WYSIWYG
functionality in Emacs.  You should certainly be able to achieve
WYSIWYM right now.  Org-mode effectively already does.

Mainly, though, I was thinking of taking advantage of the fact that
the existing document formats already used are XML formats then you
could just utlise that and XSLT to go from some simpler format and
interface to produce whatever you want.  There's already plenty of
existing support within the GNU project, so why not use it?

> Perhaps I didn't make this clear, but the goal I have in mind
> includes WYSIWYG display of formatted text.

Yeah, I thought so, hence the "ambitious" comment.

>> OTOH, there are reasons I almost never use Emacs to write fiction 
> 
> Would you like to explain why?  We might learn something from seeing
> your reasons.

Fair enough.  For me it's a combination of function and state of mind;
Emacs can only really affect the former, of course.

I suspect much of the functionality issues could probably be gotten
around with some custom major and/or minor modes.  There are certain
things which are generally just done with styles or templates that
most purely text based editors would address by inserting additional
content (e.g. extra blank lines, special characters, etc.).  Ligatures
would be very nice, but are less of a concern when the publishing
software[1] will take care of that properly later.

Smart quotation marks for either single or double quotes are pretty
much essential for anything dialogue related (so ‘ or ’ instead of ',
except when the latter is just an apostrophe - though that does get a
little more finicky sometimes, and “ or ” instead of ").  As well as
"smart typing" like always capitalising the lone "i" or fixing
capitalisation on a new sentence is frequently exploited when writing
a lot.  There's almost certainly several other things which aren't
coming to mind because normally I don't need to think about them.

To put into perspective how much a difference these little things can
make:  I think my record in one writing session was a chapter of about
20,800 words in around 21 hours.  Doing that without all those little
features would either take far longer (and risk interrupting the
writing flow), or significantly increase the amount of manual editing
required later.

The state of mind thing is more a matter of encouraging the creative
flow and sometimes that means manipulating the way I see the text as I
write it (the nature of which generally varies according to the
subject matter).  Usually, though it just comes down to never having
to really think about doing something with the software other than
just write.

At the moment LibreOffice does all that and more, which makes it ideal
for fiction and longer political work.  With the added bonus of not
generally making my mind follow more technical paths when I look at
it.  Which is something Emacs does with me to a large extent, since
it's so integral to many of my more geeky pursuits.  I've certainly
quite happily used it to write technical documentation[2] and code,
and no doubt will continue to do so.  It's even helped with part of my
little Unicode cheat sheet,[3] even though that's still mostly done in
LibreOffice.[4]


Regards,
Ben

 1. My publishing platform is rather more technical than the scope of
    this thread, so I'm leaving that part out.

 2. Like this (using Org-mode and its XHTML export):
    http://files.au.adversary.org/crypto/gpgme-python-howto.html

 3. http://files.east1.us.adversary.org/files/UnicodeNotes.pdf

 4. Because Emacs still beats everything else for inserting code
    points from plane 1 or above.  The relevant part of my ~/.emacs
    file for displaying most of the current Unicode spec is at the end
    of the PDF linked above.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Making Emacs popular again with a video

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 14 May 2020 01:14:36 -0400
> Cc: colinetnathan98@gmail.com, andreas.roehler@online.de, emacs-devel@gnu.org
> 
> I designed Emacs to be a text editor.
> 
> I am disappointed that people extend Emacs ONLY to do other unrelated
> jobs while NOT extending the kinds of text editing it will do.

If you mean "text" literally, then you may be right.  But if you
include in that editing of program sources, then I'd say we are
definitely making progress in that area, albeit slower than we would
want to.

Re: Making Emacs popular again with a video

[Tim Cross]

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

On Wed, 13 May 2020 at 18:50, Arthur Miller <arthur.miller@live.com> wrote:

> 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. ]]]
> >
> >   > > Do Emacs's current competitors have the same capabilities?
> >   > They have pretty much everything but "self-documenting", which should
> >   > maybe be referred as "self-retrospecting" feature.
> >
> > Do people think it is desirable to delete most of that intro text?
> > It is uder 15 lines; perhaps it is harmless to keep it.
>
> I don't think it is very important issue. It is normal to have a bit
> longer introductorty text/description about application. It just does
> not need to take screen estate on the welcome screen maybe?
>
> By the way, I probably wouldn't try to identify Emacs as just a text
> editor longer. Personally I see Emacs as en extensible platform, or
> system (not in a sense of that joke of operating system), a tool, or
> whatever one might wish to call it. I think it has developed and become
> usefull much more then just as a text editor. Also I think it might help
> if Emacs developed even further in that direction, as a
> "multi-tool/swiss army knife" of human-computer interaction?
>
> I don't use other text editors, so I really don't know how good they are
> at other tasks then just text editing. I usually just take a look for
> the curiosity sake when a new editor/IDE becomes popular, and then I
> usually realize Emacs already has everything I need and just uninstall
> the new thing.
>
>
I think this touches on an important point. Emacs is more than an editor.
To an extent, the editing aspects of Emacs are not particularly interesting
and most of the really great editing features of Emacs have been
incorporated into other editors anyway - it is not really a distinguishing
features. The key to what makes Emacs is a combination of extensibility and
self-documenting. For me, what makes Emacs different from nearly all the
alternatives is the ability to create the work environment and work flows I
want rather than conforming to the environment and workflows someone else
has defined. With a little effort, I can have my projects setup so that all
those boring and repetitive tasks are automated using a common framework,
language and interface. plus I get a whole lot of unified and consistent
tools/commands with that same interface, which makes dealing with the ad
hoc stuff faster/easier as well.

Unfortunately, this benefit is not going to be universal for all users. If
you don't have a need for workflows or if your requirement is just for
simple editing of text or if your simply not that interested or are happy
to use separate tools and environments etc, your really not going to see a
lot of benefit from Emacs over other editors. This makes me think that
aiming to make Emacs more popular may be a too generic objective. Perhaps
we need to consider who or what group of users we want Emacs to be popular
with. Should we be trying to identifyt which 'market' Emacs is going to be
most beneficial for and then target that group rather than just tyring to
be 'popular' in the more generic sense?

-- 
regards,

Tim

--
Tim Cross

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

Re: Making Emacs popular again with a video

[Andreas Röhler]

Am 14.05.2020 um 09:38 schrieb Tim Cross:
> On Wed, 13 May 2020 at 18:50, Arthur Miller <arthur.miller@live.com> wrote:
>
>> 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. ]]]
>>>
>>>    > > Do Emacs's current competitors have the same capabilities?
>>>    > They have pretty much everything but "self-documenting", which should
>>>    > maybe be referred as "self-retrospecting" feature.
>>>
>>> Do people think it is desirable to delete most of that intro text?
>>> It is uder 15 lines; perhaps it is harmless to keep it.
>> I don't think it is very important issue. It is normal to have a bit
>> longer introductorty text/description about application. It just does
>> not need to take screen estate on the welcome screen maybe?
>>
>> By the way, I probably wouldn't try to identify Emacs as just a text
>> editor longer. Personally I see Emacs as en extensible platform, or
>> system (not in a sense of that joke of operating system), a tool, or
>> whatever one might wish to call it. I think it has developed and become
>> usefull much more then just as a text editor. Also I think it might help
>> if Emacs developed even further in that direction, as a
>> "multi-tool/swiss army knife" of human-computer interaction?
>>
>> I don't use other text editors, so I really don't know how good they are
>> at other tasks then just text editing. I usually just take a look for
>> the curiosity sake when a new editor/IDE becomes popular, and then I
>> usually realize Emacs already has everything I need and just uninstall
>> the new thing.
>>
>>
> I think this touches on an important point. Emacs is more than an editor.
> To an extent, the editing aspects of Emacs are not particularly interesting
> and most of the really great editing features of Emacs have been
> incorporated into other editors anyway - it is not really a distinguishing
> features. The key to what makes Emacs is a combination of extensibility and
> self-documenting. For me, what makes Emacs different from nearly all the
> alternatives is the ability to create the work environment and work flows I
> want rather than conforming to the environment and workflows someone else
> has defined. With a little effort, I can have my projects setup so that all
> those boring and repetitive tasks are automated using a common framework,
> language and interface. plus I get a whole lot of unified and consistent
> tools/commands with that same interface, which makes dealing with the ad
> hoc stuff faster/easier as well.
>
> Unfortunately, this benefit is not going to be universal for all users. If
> you don't have a need for workflows or if your requirement is just for
> simple editing of text or if your simply not that interested or are happy
> to use separate tools and environments etc, your really not going to see a
> lot of benefit from Emacs over other editors. This makes me think that
> aiming to make Emacs more popular may be a too generic objective. Perhaps
> we need to consider who or what group of users we want Emacs to be popular
> with. Should we be trying to identifyt which 'market' Emacs is going to be
> most beneficial for and then target that group rather than just tyring to
> be 'popular' in the more generic sense?


A good example how complex stuff might be accessible delivers the 
success of the Python language.  Just watched a video called "Python 
Steering Council Community Address" where some roots of this popularity 
are delivered. For example they have an own section discussing 
user-experience of beginners:

https://www.youtube.com/watch?v=xX8fGuh4T_o&feature=youtu.be

Re: Making Emacs popular again with a video

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Thu, 14 May 2020 17:38:15 +1000
> Cc: colinetnathan98@gmail.com,
>  Andreas Röhler <andreas.roehler@online.de>,
>  Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> To an extent, the editing aspects of Emacs are not particularly
> interesting and most of the really great editing features of Emacs
> have been incorporated into other editors anyway

I would disagree, at least to some extent.  It is true that many Emacs
features are available today elsewhere, but some surprisingly still
aren't.  For example, what about transposing words or lines with one
or 2 keystrokes?

Re: Making Emacs popular again with a video

[Tim Cross]

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

On Fri, 15 May 2020 at 00:19, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Thu, 14 May 2020 17:38:15 +1000
> > Cc: colinetnathan98@gmail.com,
> >  Andreas Röhler <andreas.roehler@online.de>,
> >  Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> >
> > To an extent, the editing aspects of Emacs are not particularly
> > interesting and most of the really great editing features of Emacs
> > have been incorporated into other editors anyway
>
> I would disagree, at least to some extent.  It is true that many Emacs
> features are available today elsewhere, but some surprisingly still
> aren't.  For example, what about transposing words or lines with one
> or 2 keystrokes?
>

I'm sure we will find some examples, though the ones you cited are
available in a number of editors (for example VS Code C-t = letter,
Shift-Ctl-t = word and Alt-Ctl-T for line transposing Many editors have
been inspired by and have borrowed/copied from Emacs. Features which use to
be only seen in Emacs are now seen in many other editors (column editing,
rectangle cut and paste, transposing letters, words and lines, multiple
cursors, etc. Most editors have some form of plugin or extention mechanism
and people have ported most of the useful features from Emacs. (though
their extension/plugin mechanism is typically much less flexible than
Emacs).

There are certainly some things Emacs still does better with respect to
editing, like editing of binary data or even ascii art etc. It is rare when
I've used another editor and missed a feature that I've not found the
feature is available - I may need to add a plugin or define a key binding
or define a macro (as in keyboard macros not lisp macro). However, in
general, I find these things which Emacs still does better to be really
fringe areas which I rarely use or need. The majority of advanced editing
features provided by emacs are available in most editors with a programming
orientation. In many of these editors, other things which are slightly
difficult to get working consistently in Emacs are available 'out of the
box'. For example, getting font ligatures and colour emojii working in VS
Code is trivial. In Emacs, it is harder and varies depending on which
platform you are on.

VS Code is probably a good example. While I still prefer Emacs, if I'm
really honest, from a purely editing perspective, VS Code is as good and
feature rich. Where it fails is in the ease of extensibility and ability to
customize to fit how I like to work - with VS Code, I need to adjust more
to how VS Code wants to work, but when it comes to just writing source
code, they are both pretty equivalent.


-- 
regards,

Tim

--
Tim Cross

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

Re: Making Emacs popular again with a video

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Do people think it is desirable to delete most of that intro text?
> It is uder 15 lines; perhaps it is harmless to keep it.

I think so, FWIW.

Best regards,
Stefan Kangas

Re: Making Emacs popular again with a video

[Andreas Röhler]

On 12.05.20 05:12, 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. ]]]
>
>    > > For instance at "Introduction" fairly everything in first paragraphs
>    > > IMHO may be dropped resp. should be moved at later sections. Copy
>    > > stuff below for the convenience of the reader here.
>
> Perhaps there is no longer a need to inform the public of those
> three basic capabilities of Emacs.
>
> Do Emacs's current competitors have the same capabilities?
>
>      > You are reading about GNU Emacs, the GNU incarnation of the advanced,
>      > self-documenting, customizable, extensible editor Emacs.

When looking into the net in order to make my point more obvious came 
about this:

The power of Emacs comes from being able to write new commands a [...], 
read and modify commands that are already in Emacs.

Re: Making Emacs popular again with a video

[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 power of Emacs comes from being able to write new commands a [...], 
  > read and modify commands that are already in Emacs.

That is true.  That's what "extensible" refers to.

The question is, is it worth spending a few paragraphs on those points:

    > You are reading about GNU Emacs, the GNU incarnation of the advanced,
    > self-documenting, customizable, extensible editor Emacs.

When I wrote the first Emacs in 1976, these were exciting new advances.
Most users had never imagined such features in an editor.

Maybe today every programmer has seen such features elsewhere, and
responds to that statement with, "ho hum."  If so, maybe we should
delete those paragraphs.

On the other hand, maybe the standard of comparison today is something
hardly extensible at all.  ISTR that Microsoft Turd has macros; can they
support nontrivial extensions?  What about Google Crocks in a browser,
can that support nontrivial extensions?


-- 
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 popular again with a video

[Andreas Röhler]

On 13.05.20 05:55, 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 power of Emacs comes from being able to write new commands a [...],
>    > read and modify commands that are already in Emacs.
>
> That is true.  That's what "extensible" refers to.
>
> The question is, is it worth spending a few paragraphs on those points:
>
>      > You are reading about GNU Emacs,
>
> When I wrote the first Emacs in 1976, these were exciting new advances.
> Most users had never imagined such features in an editor.
>
> Maybe today every programmer has seen such features elsewhere, and
> responds to that statement with, "ho hum."  If so, maybe we should
> delete those paragraphs.
>
> On the other hand, maybe the standard of comparison today is something
> hardly extensible at all.  ISTR that Microsoft Turd has macros; can they
> support nontrivial extensions?  What about Google Crocks in a browser,
> can that support nontrivial extensions?
>
>
Assume understand your point. But the question was about didactics. What 
a beginner, starting to write a letter, needs to know? Why Emacs is 
censored having a steep learning curve? All things mentioned in this 
first sentence are probably true. However must admit even after years 
not being sure what "GNU incarnation of the advanced, self-documenting, 
customizable, extensible editor Emacs" should mean. Are there other 
incarnations than GNU incarnation of Emacs thinkable? Instead "GNU 
incarnation of ...Emacs" would understand "Emacs, an incarnation of GNU" 
- whatever GNU means...

Re: Making Emacs popular again with a video

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> The question is, is it worth spending a few paragraphs on those points:
>
>     > You are reading about GNU Emacs, the GNU incarnation of the advanced,
>     > self-documenting, customizable, extensible editor Emacs.
>
> When I wrote the first Emacs in 1976, these were exciting new advances.
> Most users had never imagined such features in an editor.
>
> Maybe today every programmer has seen such features elsewhere, and
> responds to that statement with, "ho hum."  If so, maybe we should
> delete those paragraphs.

I do think most of that introduction comes off as somewhat uninspired
and mundane if you don't know that backstory, such as:

    you can rebind the basic cursor motion commands (up, down, left and
    right) to any keys on the keyboard that you find comfortable

While some parts are more exciting:

    New commands are simply programs written in the Lisp language, which are
    run by Emacs’s own Lisp interpreter.  Existing commands can even be
    redefined in the middle of an editing session, without having to restart
    Emacs.

I think a rewrite would be in order.  But it's hard to write such a text
well.

Best regards,
Stefan Kangas

RE: Making Emacs popular again with a video

[Drew Adams]

> some parts are more exciting:
> 
>  New commands are simply programs written in the Lisp language,
>  which are run by Emacs’s own Lisp interpreter.  Existing
>  commands can even be redefined in the middle of an editing
>  session, without having to restart Emacs.

Along with the fact that commands can be redefined
and keys can be rebound to different commands, it
might be worth mentioning that (pretty much) _every_
user action/input involves invoking a command.

That's not obvious.  In particular, it's not obvious
that when you insert text by typing you're invoking
`self-insert-command' for each character-key you type.

I say it "might" be worth mentioning.  No, I don't
think this is super important.  But it gives an idea
how extensible Emacs really is - every interaction
involves customizable commands/keys.  Users control
Emacs behavior ubiquitously.

(emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

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

May 13, 2020, 06:53 by stefankangas@gmail.com:

> Richard Stallman <rms@gnu.org> writes:
>
>> The question is, is it worth spending a few paragraphs on those points:
>>
>> > You are reading about GNU Emacs, the GNU incarnation of the advanced,
>> > self-documenting, customizable, extensible editor Emacs.
>>
>> When I wrote the first Emacs in 1976, these were exciting new advances.
>> Most users had never imagined such features in an editor.
>>
>> Maybe today every programmer has seen such features elsewhere, and
>> responds to that statement with, "ho hum."  If so, maybe we should
>> delete those paragraphs.
>>
>
> I do think most of that introduction comes off as somewhat uninspired
> and mundane if you don't know that backstory, such as:
>
> you can rebind the basic cursor motion commands (up, down, left and
> right) to any keys on the keyboard that you find comfortable
>
> While some parts are more exciting:
>
> New commands are simply programs written in the Lisp language, which are
> run by Emacs’s own Lisp interpreter.  Existing commands can even be
> redefined in the middle of an editing session, without having to restart
> Emacs.
>
> I think a rewrite would be in order.  But it's hard to write such a text
> well.
>
> Best regards,
> Stefan Kangas
>
How's this for a start?

+ Welcome to GNU Emacs!
+
+ An Emacs, short for "Editor MACroS", is a kind of text editor built
+ from the idea that each key calls a tiny program (or macro). This idea
+ proves powerful in practice, enabling far more than simple insertion
+ and deletion of characters.  With it, you can operate on words or
+ lines, sentences or paragraphs, even whole pages.  You can navigate
+ within or between documents, automate tasks, and control subprocesses;
+ all with the press of a key!  GNU Emacs is the GNU project's
+ incarnation of the Emacs idea.
+
+ GNU Emacs is built for introspection and extensibility.
+
+ "Introspection" means GNU Emacs has self-knowledge.  Every aspect of
+ the system is documented and, because of the Emacs idea, that
+ information is easy to access.  The documentation may be general, like
+ this introduction.  It may be instructive, like the tutorials that
+ are included.  The documentation even reaches down to the source code
+ itself!  All of this is right at your fingertips.  See Help.
+
+ "Extensibility" means behavior can be altered and improved.  Users can
+ customize their environment, from keyboard shortcuts to color themes
+ and most everything in-between.  See Customization.  The extensibility
+ goes beyond simple customization: new commands can be created and
+ applied in real-time.  New commands can be bundled in packages and
+ shared with the diverse Emacs community. Most of the commands in Emacs
+ are written in Lisp, with a few exceptions in C.  See Emacs Lisp
+ Intro(eintr) if you want to learn Emacs Lisp programming.
+
+ GNU Emacs is used by authors and researchers, as well as programmers.
+ It has seen active development for more than 30 years; it is a
+ heritage as much as a community project.  We love GNU Emacs because we
+ feel that no other editing environment rewards sustained user
+ investment quite like it.  We hope that will be your experience, too.

A few thoughts:
- The introduction in Emacs 26.3 is 306 words.  This is also 306 words.  I propose any rewrite should also be ~306 words.
- Extensible is more specific than customizable; if you're extensible, you're necessarily customizable, right?
- As brought up in the "GNU Emacs Raison d'etre" thread, it appears "We love GNU Emacs because we feel that no other editing environment rewards sustained user investment quite like it."  I buried this in the last paragraph because it flowed.  It's an audacious claim; one I think GNU Emacs upholds and a standard I think the community may implicitly support.  If so, it might be helpful to make it explicit.  Maybe that sentiment should be front and center?
- Aside from memory, these were my sources:
https://web.archive.org/web/20000819071104/http://www.multicians.org:80/mepap.html#seciii
https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
- Real-time editor is used differently here than it appears to have meant in 1976.  I have used it here as shorthand for "without having to restart Emacs".

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

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Dmitry Gutov]

On 14.05.2020 05:18, excalamus--- via Emacs development discussions. wrote:
> How's this for a start?

I like it.

I'd retouch a few phrases, but overall seems like a solid improvement.

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

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


May 14, 2020, 08:04 by dgutov@yandex.ru:

> On 14.05.2020 05:18, excalamus--- via Emacs development discussions. wrote:
>
>> How's this for a start?
>>
>
> I like it.
>
> I'd retouch a few phrases, but overall seems like a solid improvement.
>
Please share!

I wrote this:

to volunteer for the task, if people agree it needs doing
to demonstrate how we can reassess our raison d'etre and scaffold newcomers by presenting it to them explicitly
If this draft, or a revision of it, gets the thumbs up, I will need assistance in submitting it officially.

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

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Dmitry Gutov]

On 15.05.2020 00:31, excalamus--- via Emacs development discussions. wrote:
> 
> May 14, 2020, 08:04 by dgutov@yandex.ru:
> 
>     On 14.05.2020 05:18, excalamus--- via Emacs development discussions.
>     wrote:
> 
>         How's this for a start?
> 
> 
>     I like it.
> 
>     I'd retouch a few phrases, but overall seems like a solid improvement.
> 
> Please share!

OK. See below.

> I wrote this:
> 
>  1. to volunteer for the task, if people agree it needs doing
>  2. to demonstrate how we can reassess our raison d'etre and scaffold
>     newcomers by presenting it to them explicitly
> 
> If this draft, or a revision of it, gets the thumbs up, I will need 
> assistance in submitting it officially.

We could make a new topic for it then. But the maintainer reads these 
threads, too.

On your proposed text:

   built
   from the idea that each key calls a tiny program (or macro)

Keys don't call macros anymore (all commands must be functions, not 
macros). Seems like the meaning of the word "macro" has changed over the 
years.

   GNU Emacs is the GNU project's
   incarnation of the Emacs idea.

...I'm not 100% sure what the idea is. Keys having bindings? I'll admit 
I might have missed that in the original text.

   The documentation even reaches down to the source code
   itself!

What does this mean? Functions having docstrings? Which they do everywhere.

   We love GNU Emacs because we
   feel that no other editing environment rewards sustained user
   investment quite like it.

Personally, I don't love this sentiment. It implies that one must invest 
a lot of time to get something good out of it. I'd rather emphasize 
power, flexibility and interactivity rather than paint a picture of the 
user polishing his Emacs for decades. Which we do, but, well, a lot of 
professionals in different industries do this too with their 
industry-specific tools.

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

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


May 14, 2020, 20:46 by dgutov@yandex.ru:

> On your proposed text:
>
>  built from the idea that each key calls a tiny program (or macro)
> Keys don't call macros anymore (all commands must be functions, not macros). Seems like the meaning of the word "macro" has changed over the years.
>
My intent with this paragraph is to explain what "Emacs" is and what defines an "Emacs", at a high level.  Emacs stands for  "Editor MACroS" and the idea of explicitly associating a function with each key, as I see it, is the defining aspect of an Emacs.  I think the etymology is an appropriate starting place for explaining what "Emacs" is, especially since it is an unusual word, potentially confused with something like "email" or Apple's "mac" computer.  However, starting with the etymology restricts the author to using the term "macro" somewhere.  I agree that "function" is a better word.  But to Andreas Röhler's point, I'm trying to strike a balance between programmer and non-programmer.  I used "tiny program" instead of "function" for this reason.  I think a programmer is likely to get the gist of "tiny program" whereas a non-programmer would be confused by jargon like "function"  (Based on my convos with non-programmers, aka., my girlfriend). "macro" is bad, maybe worse, but etymologically unavoidable. I think the manual should cater to the non-programmer; let the Emacs Lisp reference cater to programmers.
So much for what Emacs is.  

What *defines* an Emacs? Is it "the Emacs idea", as I've called it, that each key press is transparently associated with a function?  Word or Gmail probably call a function on a keypress, but that's not exposed to the user like it is with Emacs.  (This is partly what I was asking about when I asked for Emacs' raison d'etre.)  Thoughts?

>  GNU Emacs is the GNU project's
>  incarnation of the Emacs idea.
>
> ...I'm not 100% sure what the idea is. Keys having bindings? I'll admit I might have missed that in the original text.
>
You're right that it's confusing; it's not well expressed and not a complete thought.  Here's what I'm trying to get at: there is *an* Emacs, a piece of software characterized by *something*, and there is *the* GNU Emacs.  Is Word an Emacs? No. Is Epoch an Emacs? Yes. Why is that? Further, there is Lucid Emacs, DrRacket, Multics Emacs, Gosling Emacs, etc.  GNU Emacs is only one *instance* of an Emacs.  What sets GNU Emacs apart, specifically? Is it just that it's currently the most active in development? Or, is there something more underpinning GNU Emacs' existence? Why is it we're talking about GNU Emacs and not any of the others? 

>  The documentation even reaches down to the source code
>  itself!
>
> What does this mean? Functions having docstrings? Which they do everywhere.
>
I mean the source code itself is documentation and that the user has easy acess to it.  Word has documentation, but no access to source code. Notepad++ is free sotware, but the source code is not easily accessed (relative to Emacs).  The immediate access to the source is, I feel, a key compenent of the self-documentation of Emacs and what puts it in that unique space between user and developer.
>  We love GNU Emacs because we
>  feel that no other editing environment rewards sustained user
>  investment quite like it.
>
> Personally, I don't love this sentiment. It implies that one must invest a lot of time to get something good out of it. I'd rather emphasize power, flexibility and interactivity rather than paint a picture of the user polishing his Emacs for decades. Which we do, but, well, a lot of professionals in different industries do this too with their industry-specific tools.
>
This is a good point. I think Karl Fogel nailed it when he said, "Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment."  I think the only people who will make it far enough to read the manual are the sort of people who are willing to invest in their time *and* have decided to investigate.  It's important to let them know they will be rewarded for that and how.  The manual intro, I feel, is an appropriate place to do that.  I agree we should emphasize power, flexibility, and interactivity as a selling point, but that will/should have happened well before a user gets to the manual.  

Thank you for sharing your thoughts! I am interesting in hearing more of them!

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

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

Is this something I should continue investing time in?  

Before posting a revision, I've been awaiting feedback on:

* What *defines* an Emacs? Is it "the Emacs idea", as I've called it, that each key press is transparently associated with a function?

* What sets GNU Emacs apart, specifically, from other Emacs?

* Did I clarify the reasoning behind the sections that caused confusion?  I intend to revise those sections and want to be sure that their focus is correct and that it is the merely the wording, and not the purpose of the section, which needs revision.

First draft copied below for your convenience:

> Welcome to GNU Emacs!
>
> An Emacs, short for "Editor MACroS", is a kind of text editor built
> from the idea that each key calls a tiny program (or macro). This idea
> proves powerful in practice, enabling far more than simple insertion
> and deletion of characters.  With it, you can operate on words or
> lines, sentences or paragraphs, even whole pages.  You can navigate
> within or between documents, automate tasks, and control subprocesses;
> all with the press of a key!  GNU Emacs is the GNU project's
> incarnation of the Emacs idea.
>
> GNU Emacs is built for introspection and extensibility.
>
> "Introspection" means GNU Emacs has self-knowledge.  Every aspect of
> the system is documented and, because of the Emacs idea, that
> information is easy to access.  The documentation may be general, like
> this introduction.  It may be instructive, like the tutorials that
> are included.  The documentation even reaches down to the source code
> itself!  All of this is right at your fingertips.  See Help.
>
> "Extensibility" means behavior can be altered and improved.  Users can
> customize their environment, from keyboard shortcuts to color themes
> and most everything in-between.  See Customization.  The extensibility
> goes beyond simple customization: new commands can be created and
> applied in real-time.  New commands can be bundled in packages and
> shared with the diverse Emacs community. Most of the commands in Emacs
> are written in Lisp, with a few exceptions in C.  See Emacs Lisp
> Intro(eintr) if you want to learn Emacs Lisp programming.
>
> GNU Emacs is used by authors and researchers, as well as programmers.
> It has seen active development for more than 30 years; it is a
> heritage as much as a community project.  We love GNU Emacs because we
> feel that no other editing environment rewards sustained user
> investment quite like it.  We hope that will be your experience, too.

RE: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

Resending in order to add to the public archives.  Apologies for the extra messages!


May 20, 2020, 12:58 by excalamus@tutanota.com:

>
> May 19, 2020, 13:26 by drew.adams@oracle.com:
>
>>> Is this something I should continue investing time in?
>>>
>>
>> IMO, yes, please do.  Why not?  It will be fun for
>> you (and us) anyway, regardless of the outcome.
>>
> I agree it's fun and I'm glad you've joined in!  I meant as opposed to pursuing something like this: > https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00206.html
>
>
>> 1. Command, not just function.
>>
> Thank you for this!  The difficulty with this section is separating the jargon from the expression of the idea.  (The idea being, "each key calls a tiny program (or macro)".  Macro is clearly jargon and extremely ambiguous at that (e.g. lisp macro, Excel VBA macro, C macro, keyboard macro, etc.).  "Function" is more accurate, but also jargon.  "Command" is a term I had not considered.  
>
>
>> > What *defines* an Emacs? Is it "the Emacs idea", as I've called it, that each key press is 
>> > transparently associated with a function?
>>
>> 2. Why do you say "transparently" here?
>>
> By transparent, I mean that it is easy for a user to see "the Emacs idea" (i.e. "each key calls a tiny program (or macro)").  The Idea is made transparent through C-h k:
>
> 1. C-h k <up> opens *Help* which states, "<up> runs a command which is a function"
> 2. There is a link to the function definition, previous-line
>
> That's what I mean by "transparent".  
>
> The more it's discussed, I think it's the functionality of C-h is specifically what *defines*, in practical terms, an "Emacs".  I think it would be helpful to explain this to non-programmers along with *why the Idea is important and powerful*.  Other editors undoubtedly call a function when "<up>", or a button on the UI, is pressed; it's software, so it has to work that way at some level.  However, an "Emacs" grants users visibility and access behind the curtains.  Aside from this transparency existing,  I don't think it's necessarily seen as a virtue.  On the contrary, I think it's viewed as irrelevant; the sentiment is "I don't care if I can disassemble my John Deere engine, I have seeds to plant right now.  How does this help me do that?"
>
>
>

RE: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

Updated the proposed intro based on everyone's excellent feedback!

> (nil)Top
>
> Welcome to the Exciting World of GNU Emacs!
> *******************************************
>
> GNU Emacs is born of two ideas, the GNU project and Emacs editors.  The
> goal of the GNU project is to provide a complete, free software system.
> This means GNU Emacs respects you. It can adapt to how you work, not the
> other way around![1] An "Emacs" is a command oriented text editor
> designed for introspection and extensibility.  These qualities enable
> far more than basic word processing, as this manual describes.
>
> "Introspection" means GNU Emacs has self-knowledge.  Every aspect of the
> system is documented and accessible.  Each level of inquiry has
> tutorials, guides, and references.  It can answer questions like, "What
> commands might help me?", "What does this do?", and, "How does this
> work?"  The documentation extends from general concepts to the source
> code itself!  GNU Emacs has everything conveniently in-house, at your
> fingertips.  See Help.
>
> "Extensibility" means that you can alter GNU Emacs itself.  You can
> customize the environment, from keyboard shortcuts to color themes, and
> most everything in-between.  See Customization.  Moreover, you can
> create and apply new commands in real-time. These can be packaged and
> shared with the diverse Emacs community.  Most of GNU Emacs is written
> in Lisp.  See Emacs Lisp Intro(eintr) if you want to learn how to extend
> GNU Emacs.
>
> Authors and researchers, as well as programmers, use GNU Emacs.  It has
> seen active development for more than 40 years and includes innumerable
> features; it is a heritage as much as a tool.  We love GNU Emacs because
> we find its editing environment a rewarding experience like no other.
> We hope you'll feel that way, too.
>
>    ---------- Footnotes ----------
>
>    [1] GNU is a recursive acronym for GNU's Not Unix.  The 'G' in GNU
>    is not silent.  To learn more about the GNU project and how it can
>    benefit you, see Philosophy (<https://www.gnu.org/philosophy/>)

I like this revision, though I have two reservations:

First, I think it oversells the accessibility of the documentation.
The Emacs documentation is extensive and well written.  However, I
find it quite difficult to navigate to a concept if that thing isn't a
function or variable.  I have been a beginner and asked myself, "What
is a cons cell?".  I found then, as I often still do, that leaving
Emacs (to use a web browser) yields results fast enough to not use
Emacs itself.  Ironically, I most often wind up at the gnu.org html
documentation.

Second, the menu description is "Intro::An introduction to Emacs
concepts" which is no longer true in this version.  I have updated it
to be an intro to *GNU* Emacs, which includes reference to the GNU
project.  I consider being a component of the GNU system a feature and
something integral to distinguishing GNU Emacs from other Emacsen.  It
feels right to talk about it in the manual introduction.  However,
this implies structural, if not intention, changes to the overall
manual.  I feel those are over my head at this point.  There are less
dramatic doc tasks to assist with.

Thoughts?

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Eli Zaretskii]

> Date: Thu, 28 May 2020 03:21:34 +0200 (CEST)
> Cc: Drew Adams <drew.adams@oracle.com>, Emacs Devel <emacs-devel@gnu.org>
> From: excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> First, I think it oversells the accessibility of the documentation.
> The Emacs documentation is extensive and well written.  However, I
> find it quite difficult to navigate to a concept if that thing isn't a
> function or variable.  I have been a beginner and asked myself, "What
> is a cons cell?".  I found then, as I often still do, that leaving
> Emacs (to use a web browser) yields results fast enough to not use
> Emacs itself.  Ironically, I most often wind up at the gnu.org html
> documentation.

Are you aware of the 'i' command in Info, and using it?  Because its
purpose is precisely to help in the situations like you describe.  For
example, "what is a cons cell?" is immediately answered by typing this
in Info:

  i cons cell RET

or even

  i cons RET

Maybe we should have an interactive command that would let users type
the likes of "what is a cons cell" and translate that to the
appropriate Info-index command?  Because this extremely useful command
seems to be unknown and under-used.

> I consider being a component of the GNU system a feature and
> something integral to distinguishing GNU Emacs from other Emacsen.

I think at this time and place, there's only one Emacs.  What
"non-GNU" Emacsen are there that still need to be kept in mind?

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Andreas Röhler]

On 28.05.20 09:08, Eli Zaretskii wrote:
>> Date: Thu, 28 May 2020 03:21:34 +0200 (CEST)
>> Cc: Drew Adams <drew.adams@oracle.com>, Emacs Devel <emacs-devel@gnu.org>
>> From: excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> First, I think it oversells the accessibility of the documentation.
>> The Emacs documentation is extensive and well written.  However, I
>> find it quite difficult to navigate to a concept if that thing isn't a
>> function or variable.  I have been a beginner and asked myself, "What
>> is a cons cell?".  I found then, as I often still do, that leaving
>> Emacs (to use a web browser) yields results fast enough to not use
>> Emacs itself.  Ironically, I most often wind up at the gnu.org html
>> documentation.
> Are you aware of the 'i' command in Info, and using it?

Get an error at the top of Info - works only inside Elisp


>    Because its
> purpose is precisely to help in the situations like you describe.  For
> example, "what is a cons cell?" is immediately answered by typing this
> in Info:
>
>    i cons cell RET
>
> or even
>
>    i cons RET
>
> Maybe we should have an interactive command that would let users type
> the likes of "what is a cons cell" and translate that to the
> appropriate Info-index command?  Because this extremely useful command
> seems to be unknown and under-used.

Think that would be helpful.

RE: (emacs) Intro [was: Making Emacs popular again with a video]

[Stefan Kangas]

Hi,

My day-job involves copy-editing among other things.  I like this
revision overall, but hope you find the below observations useful.

First, it doesn't push the point that this is an editor for "power
users".  In my opinion, we should emphasize that point, as others have
suggested.

excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Updated the proposed intro based on everyone's excellent feedback!
>
>> (nil)Top
>>
>> Welcome to the Exciting World of GNU Emacs!
>> *******************************************
>>
>> GNU Emacs is born of two ideas, the GNU project and Emacs editors.  The

"Emacs editors" here is confusing.  I'm not sure how to reformulate it,
but see the below point.

>> goal of the GNU project is to provide a complete, free software system.
>> This means GNU Emacs respects you. It can adapt to how you work, not the
>> other way around![1] An "Emacs" is a command oriented text editor

Better: "Emacs is a command oriented text editor".  I understand what
you're going for (there are other Emacs editors) but frankly it's not
really a key point in an introduction and it is not easy understand this
subtle point for readers.

>> designed for introspection and extensibility.  These qualities enable
>> far more than basic word processing, as this manual describes.

Scratch "as this manual describes", it is superfluous.

>> "Introspection" means GNU Emacs has self-knowledge.  Every aspect of the

I'm not sure about replacing "self-documenting" with "introspection",
but whatever word we use I think it reads better if it starts
"Introspection means that every aspect of the system...".

>> system is documented and accessible.  Each level of inquiry has
>> tutorials, guides, and references.  It can answer questions like, "What
>> commands might help me?", "What does this do?", and, "How does this
>> work?"  The documentation extends from general concepts to the source
>> code itself!  GNU Emacs has everything conveniently in-house, at your

I would avoid using an exclamation mark here.

I would also scratch the word "in-house".  Perhaps add something that
you don't need to fire up a web browser to read documentation, but can
do it directly in Emacs itself.

>> fingertips.  See Help.
>>
>> "Extensibility" means that you can alter GNU Emacs itself.  You can
>> customize the environment, from keyboard shortcuts to color themes, and

"Color themes" is mostly an assumed feature in text editors and not
terribly exciting.  Could we find a better example?

>> most everything in-between.  See Customization.  Moreover, you can
>> create and apply new commands in real-time. These can be packaged and
>> shared with the diverse Emacs community.  Most of GNU Emacs is written
>> in Lisp.  See Emacs Lisp Intro(eintr) if you want to learn how to extend
>> GNU Emacs.
>>
>> Authors and researchers, as well as programmers, use GNU Emacs.  It has

Better: "Authors, researchers and programmers all use GNU Emacs."

>> seen active development for more than 40 years and includes innumerable
>> features; it is a heritage as much as a tool.  We love GNU Emacs because
>> we find its editing environment a rewarding experience like no other.
>> We hope you'll feel that way, too.

This paragraph is excellent.  Possibly you could try something like:

"We love GNU Emacs because we find its editing environment a rewarding
experience like no other.  It can adapt to your needs and grows with
you.  We hope you'll love using it, too."

(Just a rough draft, but something along those lines maybe.)

> First, I think it oversells the accessibility of the documentation.
> The Emacs documentation is extensive and well written.  However, I
> find it quite difficult to navigate to a concept if that thing isn't a
> function or variable.  I have been a beginner and asked myself, "What
> is a cons cell?".  I found then, as I often still do, that leaving
> Emacs (to use a web browser) yields results fast enough to not use
> Emacs itself.  Ironically, I most often wind up at the gnu.org html
> documentation.

The problem is not necessarily with your text.  It could just be that we
should should identify the problematic areas and improve our
documentation, the tutorial, etc.

> Second, the menu description is "Intro::An introduction to Emacs
> concepts" which is no longer true in this version.

I propose to rename it to "An introduction to GNU Emacs".

> However, this implies structural, if not intention, changes to the
> overall manual.

What do you have in mind more exactly?

Best regards,
Stefan Kangas

RE: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via Emacs development discussions.]

>> May 28, 2020, 03:08 by >> eliz@gnu.org>> :
>>
>> Are you aware of the 'i' command in Info, and using it?   Because its purpose is precisely to help in the situations like you describe.
>>
Yes and no.  Thank you for reminding me and for bringing this up.  I find I run into problems  similar to those Andreas points out.  

> May 28, 2020, 03:08 by > eliz@gnu.org> :
>
> I think at this time and place, there's only one Emacs.  What
> "non-GNU" Emacsen are there that still need to be kept in mind?
>
GNU Emacs definitely dominates now.  Yet, GNU Emacs is not the only Emacs.  I'm not sure how to account for that when revising the manual.  

For instance, the first line of the current version is nonsense if GNU Emacs and Emacs are conflated:

> You are reading about GNU Emacs, the GNU incarnation of the advanced, self-documenting, 
> customizable, extensible editor Emacs.

The node link description for the intro is "An introduction to Emacs concepts."  I took that to mean Emacsen, as that's primarily what (emacs) Intro describes.  Is it describing something else?  If it *is* describing Emacsen and we don't want it to be, what direction should it go?

Other thoughts:

- Strictly speaking GNU Emacs and Emacs are distinct.  What recommendations do you have for navigating the distinction?  Or should we *not* make a distinction?  Maybe I'm just being pedantic.
- Part of understanding GNU Emacs as a program is understanding its history.  It's easier for me to comprehend aspects of Emacs (e.g. window/frame) when I realize it's been in existence longer than I have.  Maybe we should gloss over the distinction in the manual text and include a separate history node?   There are places, like (emacs) User Input, that reference "historical reasons" that might benefit from that.
- Terminology, like "Emacsen", exists within the community (EmacsWiki, etc.) which is confusing if you conflate GNU Emacs with Emacs.  I was certainly confused by this.  Maybe add such terminology to the glossary?
- Other Emacs are referenced within GNU Emacs's code-base.  Running grep on my Emacs install turns up 281 matches for "xemacs".  I doubt that's going to trip many people up, but who knows.


> May 28, 2020, 06:23 by > stefankangas@gmail.com> :
>
> Hi,
>
> My day-job involves copy-editing among other things.  I like this
> revision overall, but hope you find the below observations useful.
>
Absolutely!  I'm so stinkin' excited to be working with you (all) on this.  Thank you for taking the time to share your perspective and experience!

> First, it doesn't push the point that this is an editor for "power
> users".  In my opinion, we should emphasize that point, as others have
> suggested.
>
I'm not sure how to do this.  How do you define a power user?

Other discussions make it seem like a focus on power users is a focus on features.  I opted to avoid that here.  A person will have already been sold on trying Emacs, likely based on features, well in advance to reading the manual.  Focusing on features also opens the impossible question of "Which features should I highlight?"  I tried to provide context instead.  


> excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Updated the proposed intro based on everyone's excellent feedback!
>>
>>> (nil)Top
>>>
>>> Welcome to the Exciting World of GNU Emacs!
>>> *******************************************
>>>
>>> GNU Emacs is born of two ideas, the GNU project and Emacs editors.  The
>>>
>
> "Emacs editors" here is confusing.  I'm not sure how to reformulate it,
> but see the below point.
>
>>> goal of the GNU project is to provide a complete, free software system.
>>> This means GNU Emacs respects you. It can adapt to how you work, not the
>>> other way around![1] An "Emacs" is a command oriented text editor
>>>
>
> Better: "Emacs is a command oriented text editor".  I understand what
> you're going for (there are other Emacs editors) but frankly it's not
> really a key point in an introduction and it is not easy understand this
> subtle point for readers.
>
Yeah, I grappled quite a bit with explaining what an Emacs is.  It's awkward.   I think my comments to Eli above cover the main obstacles.

>>> "Introspection" means GNU Emacs has self-knowledge.  Every aspect of the
>>>
>
> I'm not sure about replacing "self-documenting" with "introspection",
> but whatever word we use I think it reads better if it starts
> "Introspection means that every aspect of the system...".
>
>>> system is documented and accessible.  Each level of inquiry has
>>> tutorials, guides, and references.  It can answer questions like, "What
>>> commands might help me?", "What does this do?", and, "How does this
>>> work?"  The documentation extends from general concepts to the source
>>> code itself!  GNU Emacs has everything conveniently in-house, at your
>>>
I'm beginning to doubt using "introspection", too.  RMS gives a good description of "self-documenting" on page 18 of "EMACS: The Extensible, Customizable, Self-Documenting Display Editor" (https://dspace.mit.edu/handle/1721.1/5736) <https://dspace.mit.edu/handle/1721.1/5736>. I tried to reuse the ideas.  The term "self-documenting" is undoubtedly correct, especially in the technical "search the dispatch table" sense.  Yet I find it doesn't encompass, at least immediately, the other aspects of the documentation: tutorials, references, and the source code, as well as ease of navigation. I feel introspection  gets at those more easily at the expense of being less precise.  Maybe "self-knowledge" and the line about the source code is enough?

> I would also scratch the word "in-house".  Perhaps add something that
> you don't need to fire up a web browser to read documentation, but can
> do it directly in Emacs itself.
>
Interesting.  I was going for brevity and trying to emphasize the ease of navigating the Emacs documentation.  I see your point.  Precise is probably better than general.   Actually, (navigates to Gutenberg), that's Strunk's Rule 12: Use definite, specific, concrete language.

>>> fingertips.  See Help.
>>>
>>> "Extensibility" means that you can alter GNU Emacs itself.  You can
>>> customize the environment, from keyboard shortcuts to color themes, and
>>>
>
> "Color themes" is mostly an assumed feature in text editors and not
> terribly exciting.  Could we find a better example?
>
I wish... It's the riddle of what features to mention.  I don't have an answer for it.  I went with themes because even though it's common, people love messing with them.  At least it's beloved if not exciting.  Suggestions?

>>> most everything in-between.  See Customization.  Moreover, you can
>>> create and apply new commands in real-time. These can be packaged and
>>> shared with the diverse Emacs community.  Most of GNU Emacs is written
>>> in Lisp.  See Emacs Lisp Intro(eintr) if you want to learn how to extend
>>> GNU Emacs.
>>>
>>> Authors and researchers, as well as programmers, use GNU Emacs.  It has
>>>
>
> Better: "Authors, researchers and programmers all use GNU Emacs."
>
Agreed.

>>> seen active development for more than 40 years and includes innumerable
>>> features; it is a heritage as much as a tool.  We love GNU Emacs because
>>> we find its editing environment a rewarding experience like no other.
>>> We hope you'll feel that way, too.
>>>
>
> This paragraph is excellent.  Possibly you could try something like:
>
> "We love GNU Emacs because we find its editing environment a rewarding
> experience like no other.  It can adapt to your needs and grows with
> you.  We hope you'll love using it, too."
>
Thank you! I worked hard to come up with a variant to Karl's (?) "no other editing environment rewards sustained user investment quite like it" that didn't imply a steep learning curve*.  I hope this strikes the right balance.  I like your suggestion, too, of moving the adapt+grow from P1 to here.  

*I am a SLC denier.

> (Just a rough draft, but something along those lines maybe.)
>
>> First, I think it oversells the accessibility of the documentation.
>> The Emacs documentation is extensive and well written.  However, I
>> find it quite difficult to navigate to a concept if that thing isn't a
>> function or variable.  I have been a beginner and asked myself, "What
>> is a cons cell?".  I found then, as I often still do, that leaving
>> Emacs (to use a web browser) yields results fast enough to not use
>> Emacs itself.  Ironically, I most often wind up at the gnu.org html
>> documentation.
>>
>
> The problem is not necessarily with your text.  It could just be that we
> should should identify the problematic areas and improve our
> documentation, the tutorial, etc.
>
Agreed.  I would like to talk about C-h discoverability and navigation when I have time.  I think there are taters there.

>> Second, the menu description is "Intro::An introduction to Emacs
>> concepts" which is no longer true in this version.
>>
>
> I propose to rename it to "An introduction to GNU Emacs".
>
Agreed.

>> However, this implies structural, if not intention, changes to the
>> overall manual.
>>
>
> What do you have in mind more exactly?
>
I mentioned some in my reply to Eli above.  Basically, I think "An Introduction to Emacs[en]" is addressed differently than "An Introduction to GNU Emacs".  The intro sets the user up for what's to come.  Part of me wants to say the manual should guide end users to being hackers (power users?).  I have a hard time separating hackability from the other features listed.  I'm probably losing sight of the intent/purpose of the manual/introduction.

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Eli Zaretskii]

> Date: Fri, 29 May 2020 04:39:03 +0200 (CEST)
> Cc: "excalamus--- via Emacs development discussions." <emacs-devel@gnu.org>,
>  Drew Adams <drew.adams@oracle.com>
> From: excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > May 28, 2020, 03:08 by > eliz@gnu.org> :
> >
> > I think at this time and place, there's only one Emacs.  What
> > "non-GNU" Emacsen are there that still need to be kept in mind?
> >
> GNU Emacs definitely dominates now.  Yet, GNU Emacs is not the only Emacs.

Again, what other Emacsen still need to be kept in mind?  They are all
dead, AFAIK.  Why allude to them in a document that will see light in
a year or two at the earliest?  It will just confuse people.

RE: (emacs) Intro [was: Making Emacs popular again with a video]

[Stefan Kangas]

excalamus@tutanota.com writes:

> - Strictly speaking GNU Emacs and Emacs are distinct.  What
> recommendations do you have for navigating the distinction?  Or should
> we *not* make a distinction?  Maybe I'm just being pedantic.

There is an interesting history here, and I'm as fascinated by this as
the next guy.  But in this day and age, GNU Emacs has completely
eclipsed all other versions of Emacs.

I'm not sure the benefit of bringing up that history here, especially
since there are many good articles and resources that discuss this
elsewhere.  It risks confusing or even sending users looking for other
Emacsen (likely a dead-end).

My conclusion is that we should avoid discussing other versions of Emacs
in this introduction.

> Maybe we should gloss over the distinction in the manual text
> and include a separate history node?

I don't see why not.  The only problem I know of is that the manual is
already very long in printed form.

> - Terminology, like "Emacsen", exists within the community (EmacsWiki,
> etc.) which is confusing if you conflate GNU Emacs with Emacs.  I was
> certainly confused by this.  Maybe add such terminology to the
> glossary?

Maybe EmacsWiki should just be refocused on GNU Emacs, instead.

> - Other Emacs are referenced within GNU Emacs's code-base.  Running
> grep on my Emacs install turns up 281 matches for "xemacs".  I doubt
> that's going to trip many people up, but who knows.

We have been working on reducing the number of such instances.  I think
some things just needs work, and in some cases (e.g. cc-mode) it's not
clear to me if the maintainer wants to drop XEmacs support just yet.

> Absolutely!  I'm so stinkin' excited to be working with you (all) on
> this.  Thank you for taking the time to share your perspective and
> experience!

Happy to help, thanks for working on this.  You had some specific
questions but I couldn't think of a good answer, so I'll leave that in
the hope that someone else will.

Best regards,
Stefan Kangas

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[Stefan Monnier]

>> - Strictly speaking GNU Emacs and Emacs are distinct.  What
>> recommendations do you have for navigating the distinction?  Or should
>> we *not* make a distinction?  Maybe I'm just being pedantic.
> There is an interesting history here, and I'm as fascinated by this as
> the next guy.  But in this day and age, GNU Emacs has completely
> eclipsed all other versions of Emacs.

That is true.  The editor we're all working on right now is called
"Emacs", and the reason why we sometimes refer to it as "GNU Emacs" is
to remind people that is part of the GNU project, not to distinguish it
from other Emacsen such as "Lucid Emacs".

Notice that all other Emacsen out there use another name: e.g. "XEmacs"
is not called "X Emacs", "Zile" is not called "Zile Emacs", ...


        Stefan

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[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. ]]]

  > > Maybe we should gloss over the distinction in the manual text
  > > and include a separate history node?

  > I don't see why not.  The only problem I know of is that the manual is
  > already very long in printed form.

Keeping the manual shorter (and thus cheaper) is of practical importance.
We can publish articles about history and other interesting side points
in gnu.org or along with the distribution.

We need to keep the manual short.
-- 
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: (emacs) Intro [was: Making Emacs popular again with a video]

[Karl Fogel]

On 14 May 2020, Dmitry Gutov wrote:
>On 14.05.2020 05:18, excalamus--- via Emacs development discussions. wrote:
>> How's this for a start?
>
>I like it.
>
>I'd retouch a few phrases, but overall seems like a solid improvement.

+1 to what Dmitry said.  Editing quibbles aside, this is on the right track.  It presents the important things a new user should understand when she first enters the Emacs universe.  

Thanks!

Re: (emacs) Intro [was: Making Emacs popular again with a video]

[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 is a good start.  Overall, I like it.

I would suggest systematically changing the passive voice to active,
except where there is some specific reason to use passive.  We try to
avoid making a habit of passive voice.

  >  enabling far more than simple insertion
  > + and deletion of characters.  With it, you can operate on words or
  > + lines, sentences or paragraphs, even whole pages. 

These particular feaures may not be worth mentioning nowadays.  Some
other editors can operate on words and lines.

  > - As brought up in the "GNU Emacs Raison d'etre" thread, it
  > - appears "We love GNU Emacs because we feel that no other editing
  > - environment rewards sustained user investment quite like it."  I
  > - buried this in the last paragraph because it flowed. 

I like the way you mentioned it.  I don't agree that this is Emacs's
"raison d'etre", but saying that we love Emacs because of this is
valid.

  > https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
  > - Real-time editor is used differently here than it appears to have meant in 1976.  I have used it here as shorthand for "without having to restart Emacs".

In regard to Emacs, "real-time editor" means that the text changes
immediately as you type characters.  This contrasts with line-based editors
such as Basic's editor, and command-string input editors such as TECO.

Nowadays this is the usual way, so I agree it is not worth mentioning
here.


-- 
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: (emacs) Intro [was: Making Emacs popular again with a video]

[Andreas Röhler]

Appreciating your effort. However, being afraid the task is still more 
complicated. In fact, no one here on this list -- me inclusive -- will 
be able to say what needs to be written in that intro. Because all know 
Emacs. It needs the questions and comments of the unexperienced user.

At least if thinking of an intro for the non-programmer. It probably 
makes sense keeping also an intro for programmers.

GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

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

May 11, 2020, 23:12 by rms@gnu.org:

> Perhaps there is no longer a need to inform the public of those
> three basic capabilities of Emacs.
>
> Do Emacs's current competitors have the same capabilities?
>
> > You are reading about GNU Emacs, the GNU incarnation of the advanced,
> > self-documenting, customizable, extensible editor Emacs. 
>
What are we competing for?  I feel that while other threads are examining "missing features", it would be helpful to examine what GNU Emacs does offer.  Not only in software features, but maybe also in philosophy, community, or tradition.

What is it about GNU Emacs that makes this mailing list bustle with enthusiasm?  Other editors use GPL, provide source code, have documentation, are customizable, and extendable.  There's something in how GNU Emacs implements these that is different.  I feel like there are taters to find if we dig a little.

Is it because Emacs Lisp is unique to Emacs that Emacs teaches as well as documents?
Is it that by being a pseudo-Lisp machine, Emacs puts users in the zone of proximal development?
Is GNU Emacs the best embodiment of the GNU philosophy?  


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

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 12 May 2020, excalamus--- via "Emacs development discussions." wrote:
>May 11, 2020, 23:12 by rms@gnu.org:
>What are we competing for?  I feel that while other threads are
>examining "missing features", it would be helpful to examine what GNU
>Emacs does offer.  Not only in software features, but maybe also in
>philosophy, community, or tradition.
>
>What is it about GNU Emacs that makes this mailing list bustle with
>enthusiasm?  Other editors use GPL, provide source code, have
>documentation, are customizable, and extendable.  There's something
>in how GNU Emacs implements these that is different.  I feel like
>there are taters to find if we dig a little.
>
>Is it because Emacs Lisp is unique to Emacs that Emacs teaches as
>well as documents?
>Is it that by being a pseudo-Lisp machine, Emacs puts users in the
>zone of proximal development?
>Is GNU Emacs the best embodiment of the GNU philosophy? 

Sure, I'll take the bait:

To the best of my knowledge, no other editing environment rewards sustained user investment so well.

With Emacs, if you keep investing -- i.e., acquiring knowledge and skill by reading documentation, writing customizations, and exploring others' customizations -- Emacs keeps rewarding you with a better and better editing experience.  The degree to which it does this seems normal to many of us here, because we've been used to it for many years.  I think we sometimes fail to appreciate the degree to which non-users, potential ("Emacs-curious") users, and even many actual new users are *not* aware of it: they don't realize how enormous the reward can be, and how broad its scope.

This should probably affect how we think about promoting Emacs.  Emacs shouldn't necessarily try to attract everyone who needs to edit text [1].  Many people who edit text nonetheless don't view text editing as a primary activity worthy of investment.  Those users are not good candidates for Emacs.

Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment.  There's a loose correlation in which good programmers tend to be those sorts of people, because good programmers are usually willing to invest in learning their tools in general.  E.g., they'll learn their text editor the same way they'll learn their debugger, their programming framework, etc.  But the set isn't limited to just programmers.  For example, scientists and other academics who edit LaTeX documents are often good candidates for Emacs usage, because by both temperament and life situation they are well-positioned to understand how sustained investment in learning their editing environment could pay off in the long term.

So I suggest that GNU Emacs's raison d'être is to be the text editor that best rewards sustained user investment.

I think Emacs actually does so right now, too, and that we just haven't always communicated this fact clearly enough.

Thus, instead of focusing on making Emacs easier for new users, it would be better to focus on smoothing out discontinuities in Emacs' investment-reward curve.  The long-term health of Emacs as a project will not come from a large number of lightly committed users who don't appreciate what makes Emacs unique, but rather from a smaller number of users for whom Emacs is important and irreplaceable.

I'm not suggesting that we shouldn't improve the new-user experience in Emacs, of course.  We should make it as easy as possible for newcomers *while still prioritizing invested users*.   In user experience design, there are frequently tradeoffs between making things easy for newcomers and making them rewarding for experts.  Unfortunately, too often in design discussions, the new user experience automatically wins out -- it's like some kind of magic card that people play (even sometimes unconsciously) in UI/UX discussions.  For Emacs, this would be a mistake.  Emacs's great strength will never be in its new-user experience, and this is in some ways a necessary consequence of Emacs being so great for highly invested long-term users.

This also suggests that the sorts of features that highly-invested users tend to want -- for example, LSP-based features -- should be more important to us than how square the menus are or what menu items are shown in a default startup configuration.  When we make decisions that disappoint the core user base, we endanger the project much more than when we make decisions that disappoint users (or potential users) who weren't likely to become highly invested anyway.

(The fact that Emacs promotes free software by being a good GPL'd program is nice too, and is important to many of us, but it's not unique to Emacs.)

Best regards,
-Karl

RE: GNU Emacs raison d'etre

[Drew Adams]

+1 to everything Karl said.  Worth rereading.

Re: GNU Emacs raison d'etre

[Andreas Röhler]

On 13.05.20 18:18, Karl Fogel wrote:
> On 12 May 2020, excalamus--- via "Emacs development discussions." wrote:
>> May 11, 2020, 23:12 by rms@gnu.org:
>> What are we competing for?  I feel that while other threads are
>> examining "missing features", it would be helpful to examine what GNU
>> Emacs does offer.  Not only in software features, but maybe also in
>> philosophy, community, or tradition.
>>
>> What is it about GNU Emacs that makes this mailing list bustle with
>> enthusiasm?  Other editors use GPL, provide source code, have
>> documentation, are customizable, and extendable.  There's something
>> in how GNU Emacs implements these that is different.  I feel like
>> there are taters to find if we dig a little.
>>
>> Is it because Emacs Lisp is unique to Emacs that Emacs teaches as
>> well as documents?
>> Is it that by being a pseudo-Lisp machine, Emacs puts users in the
>> zone of proximal development?
>> Is GNU Emacs the best embodiment of the GNU philosophy?
> Sure, I'll take the bait:
>
> To the best of my knowledge, no other editing environment rewards sustained user investment so well.
>
> With Emacs, if you keep investing -- i.e., acquiring knowledge and skill by reading documentation, writing customizations, and exploring others' customizations -- Emacs keeps rewarding you with a better and better editing experience.  The degree to which it does this seems normal to many of us here, because we've been used to it for many years.  I think we sometimes fail to appreciate the degree to which non-users, potential ("Emacs-curious") users, and even many actual new users are *not* aware of it: they don't realize how enormous the reward can be, and how broad its scope.
>
> This should probably affect how we think about promoting Emacs.  Emacs shouldn't necessarily try to attract everyone who needs to edit text [1].  Many people who edit text nonetheless don't view text editing as a primary activity worthy of investment.  Those users are not good candidates for Emacs.
>
> Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment.  There's a loose correlation in which good programmers tend to be those sorts of people, because good programmers are usually willing to invest in learning their tools in general.  E.g., they'll learn their text editor the same way they'll learn their debugger, their programming framework, etc.  But the set isn't limited to just programmers.  For example, scientists and other academics who edit LaTeX documents are often good candidates for Emacs usage, because by both temperament and life situation they are well-positioned to understand how sustained investment in learning their editing environment could pay off in the long term.
>
> So I suggest that GNU Emacs's raison d'être is to be the text editor that best rewards sustained user investment.
>
> I think Emacs actually does so right now, too, and that we just haven't always communicated this fact clearly enough.
>
> Thus, instead of focusing on making Emacs easier for new users, it would be better to focus on smoothing out discontinuities in Emacs' investment-reward curve.  The long-term health of Emacs as a project will not come from a large number of lightly committed users who don't appreciate what makes Emacs unique, but rather from a smaller number of users for whom Emacs is important and irreplaceable.
>
> I'm not suggesting that we shouldn't improve the new-user experience in Emacs, of course.  We should make it as easy as possible for newcomers *while still prioritizing invested users*.   In user experience design, there are frequently tradeoffs between making things easy for newcomers and making them rewarding for experts.  Unfortunately, too often in design discussions, the new user experience automatically wins out -- it's like some kind of magic card that people play (even sometimes unconsciously) in UI/UX discussions.  For Emacs, this would be a mistake.  Emacs's great strength will never be in its new-user experience, and this is in some ways a necessary consequence of Emacs being so great for highly invested long-term users.

Agree with everything beside two last paragraphs. Enjoying the 
possibilities to extend and assisting new users being productive seems 
no contradiction. May you give an example where an smooth entrance 
hinders the power of more complex functionality?

Sure, as it was mentioned in other post, writing an introduction for 
beginners is difficult, it is an art of its own.


>
> This also suggests that the sorts of features that highly-invested users tend to want -- for example, LSP-based features -- should be more important to us than how square the menus are or what menu items are shown in a default startup configuration.  When we make decisions that disappoint the core user base, we endanger the project much more than when we make decisions that disappoint users (or potential users) who weren't likely to become highly invested anyway.
>
> (The fact that Emacs promotes free software by being a good GPL'd program is nice too, and is important to many of us, but it's not unique to Emacs.)
>
> Best regards,
> -Karl
>

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 13 May 2020, Andreas Röhler wrote:
>Agree with everything beside two last paragraphs. Enjoying the
>possibilities to extend and assisting new users being productive seems 
>no contradiction. May you give an example where an smooth entrance
>hinders the power of more complex functionality?

The newcomer-vs-expert tradeoff is real, and it's pervasive throughout UI and UX design.

One example is button-based functionality.  For both experts and newcomers, those buttons/icons take away screen real estate -- but for newcomers they make features easier to find, so it's worth it.  For experts, they *just* take away screen real estate, while providing little or no benefit.

Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.

Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is *good* for experts, as we know from personal experience.

I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are *good* for the experienced user.

These design tradeoffs cannot be avoided.  It would be a fallacy to think that it's always possible to be *both* maximally newcomer-friendly and investor-friendly.  

(The term "user-friendly" is itself misleading.  There is no such thing as "a user" in a way that makes the term "user-friendly" meaningful.  Better terms would at least attempt to make important distinctions -- "newcomer-friendly", "expert-friendly", "ADHD-friendly", "limited-movement-friendly", "visually-impaired-friendly", etc -- and would encourage designers to understand that being good in some categories means being bad in others.)

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 13.05.2020 23:05, Karl Fogel wrote:
> Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.
> 
> Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is*good*  for experts, as we know from personal experience.

I might with agree with you principle, but both examples seem suspect.

First, the "low investment" editors frequently have higher density of 
information in the UI elements that correspond to our mode-line and 
fringe, margins, etc. Largely thanks to their technical capabilities 
(various-sized fonts, graphics, being able to fit different kinds of 
indicators together on a "fringe"). So it appears at least in this area 
Emacs has been overtaken purely on technical grounds.

Regarding the key combinations and the minibuffer, there is no hard 
evidence that our current behavior is supremely optimal. In fact, I'm 
fairly sure that by being risk-averse and resistant to change, and by 
having no UX experts around, Emacs loses out on some possible 
advancements in usability. Even expert-friendly ones.

So I would recommend not becoming complacent, or becoming assured that 
workflows you have spent some time getting accustomed to, can't be improved.

> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
> 
> These design tradeoffs cannot be avoided.  It would be a fallacy to think that it's always possible to be*both*  maximally newcomer-friendly and investor-friendly.

The last sentence is sensible, but it's generally beside the point: I'm 
sure we still have a long way to go in both directions.

And unfortunately, in practice around here "prioritizing invested users" 
somehow turns out to mean "let's not make existing users uncomfortable". 
By changing defaults, introducing new workflows, or changing old ones. 
Which, in the long run, serves neither crowd.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 13 May 2020, Dmitry Gutov wrote:
>I might with agree with you principle, but both examples seem suspect.
>
>First, the "low investment" editors frequently have higher density of
>information in the UI elements that correspond to our mode-line and 
>fringe, margins, etc. Largely thanks to their technical capabilities
>(various-sized fonts, graphics, being able to fit different kinds of 
>indicators together on a "fringe"). So it appears at least in this
>area Emacs has been overtaken purely on technical grounds.

*nod*.  There might be room for improvement in how Emacs uses various visual areas, though, having watched many different programmers using many different kinds of editors, I think Emacs's mode line actually scores pretty well on the indicator front (once one learns how to interpret it).

But in any case, note that these other editors also face this same tradeoff.  You can see it in Microsoft Word, for example: in recent versions, its default startup control panel looks like the cockpit of Boeing 747.  Experienced users complain noisily about it (you can find various blog posts and other chatter about this on the Net), but this UI change was made so that *new* users could find a visual path to anything they might be looking for.

The tradeoff will always be there, even if sometimes there is room for Emacs to improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak.

>Regarding the key combinations and the minibuffer, there is no hard
>evidence that our current behavior is supremely optimal. In fact, I'm 
>fairly sure that by being risk-averse and resistant to change, and by
>having no UX experts around, Emacs loses out on some possible 
>advancements in usability. Even expert-friendly ones.
>
>So I would recommend not becoming complacent, or becoming assured that
>workflows you have spent some time getting accustomed to, can't be
>improved.

Absolutely.

But the particular *way* in which we've crowded the keybinding space is independent of the fact that the space is crowded, and necessarily must be crowded if it is to offer experts the quick access to functionality that they want.  Crowding the keybinding space is good for high-investment users and bad for newcomers (that's why newcomers to Emacs so often trip accidentally over unexpectedly combustible key sequences).  That tradeoff will always be there, no matter what the particular mapping of key sequences to functionality is.

So I think my example there holds up pretty well.

>> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
>> These design tradeoffs cannot be avoided.  It would be a fallacy to
>> think that it's always possible to be*both*  maximally
>> newcomer-friendly and investor-friendly.
>
>The last sentence is sensible, but it's generally beside the point:
>I'm sure we still have a long way to go in both directions.

Very good point: there are some things we could that would get us closer to the point where tradeoff decisions are necessary.  But not everything we contemplate doing will be in that category.  Some of the things we want to do will already *be* at the tradeoff point, and then we will have a decision to make.

>> This also suggests that the sorts of features that highly-invested
>> users tend to want -- for example, LSP-based features
>
>LSP is a high-investment feature?
>
>Reminder: it came to us from VS Code, Microsoft's text editor for
>programmers.

Not quite.  What I wrote, exactly, is that it is the sort of feature that highly-invested users tend to want.  That is different in a subtle way.  By not supplying the sorts of things that LSP would enable, we signal to high-investment users that there is an entire area of improvement that Emacs is not going to explore.  So while lack of LSP hurts both newcomers and experts, it discourages the experts more, because they are looking for signals that continued investment will lead to increased reward.

Put another way: LSP is the sort of thing that enables highly-invested users -- the kinds of people who write or would consider writing Elisp -- to build new functionality into Emacs, perhaps even functionality we cannot predict today.  While LSP is a good thing for all users, newcomers and experts alike, it specifically *rewards* further investment by users who are motivated to make (and capable of making) investments based on LSP's availability.  It is an expertise amplifier.  When we fail to include an expertise amplifier like that, we "bend the curve" -- in the wrong direction.

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 01:04, Karl Fogel wrote:
> On 13 May 2020, Dmitry Gutov wrote:
>> I might with agree with you principle, but both examples seem suspect.
>>
>> First, the "low investment" editors frequently have higher density of
>> information in the UI elements that correspond to our mode-line and
>> fringe, margins, etc. Largely thanks to their technical capabilities
>> (various-sized fonts, graphics, being able to fit different kinds of
>> indicators together on a "fringe"). So it appears at least in this
>> area Emacs has been overtaken purely on technical grounds.
> 
> *nod*.  There might be room for improvement in how Emacs uses various visual areas, though, having watched many different programmers using many different kinds of editors, I think Emacs's mode line actually scores pretty well on the indicator front (once one learns how to interpret it).

I think the mode-line is more or less average by today's standards. But 
of course it wins on customizability. The fringes a significantly less 
functional, though. :-(

> But in any case, note that these other editors also face this same tradeoff.  You can see it in Microsoft Word, for example: in recent versions, its default startup control panel looks like the cockpit of Boeing 747.  Experienced users complain noisily about it (you can find various blog posts and other chatter about this on the Net), but this UI change was made so that *new* users could find a visual path to anything they might be looking for.
> 
> The tradeoff will always be there, even if sometimes there is room for Emacs to improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak.

Yes, the tradeoff is somewhere in there, but my problem with the 
conclusion is that it would be really easy to misapply your principle 
(e.g. by saying we don't need fancier buttons, even though we probably 
do, or that the Getting Started guide is good enough and doesn't need 
improvement, and someone should go work on specialized Org-mode docs 
instead).

Making good use of it seems difficult.

The kind of person who *could* make a better judgment in this area is 
someone who specializes on UX. And they are rare guests around here.

> But the particular *way* in which we've crowded the keybinding space is independent of the fact that the space is crowded, and necessarily must be crowded if it is to offer experts the quick access to functionality that they want.  Crowding the keybinding space is good for high-investment users and bad for newcomers (that's why newcomers to Emacs so often trip accidentally over unexpectedly combustible key sequences).  That tradeoff will always be there, no matter what the particular mapping of key sequences to functionality is.

Are you sure that this particular aspect is _bad_ for new users, though? 
Nobody likes to stretch they hand too far. But I'll grant you this 
point, that Emacs is *somewhat* on the side of high-investment here.

This part is expected of a professional tool, however, and the 
experience for newcomers could be improved without taking away much from 
the "oldies". See the 'transient' package, for example, recently 
proposed for inclusion on emacs-devel.

>>> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good*  for the experienced user.
>>> These design tradeoffs cannot be avoided.  It would be a fallacy to
>>> think that it's always possible to be*both*  maximally
>>> newcomer-friendly and investor-friendly.
>>
>> The last sentence is sensible, but it's generally beside the point:
>> I'm sure we still have a long way to go in both directions.
> 
> Very good point: there are some things we could that would get us closer to the point where tradeoff decisions are necessary.  But not everything we contemplate doing will be in that category.  Some of the things we want to do will already *be* at the tradeoff point, and then we will have a decision to make.

Some of them, probably. At this point, I think, there are still a lot of 
decisions that would bring us closer to newcomer-friendliness while 
keeping no worse high-investment compatibility.

>>> This also suggests that the sorts of features that highly-invested
>>> users tend to want -- for example, LSP-based features
>>
>> LSP is a high-investment feature?
>>
>> Reminder: it came to us from VS Code, Microsoft's text editor for
>> programmers.
> 
> Not quite.  What I wrote, exactly, is that it is the sort of feature that highly-invested users tend to want.  That is different in a subtle way.  By not supplying the sorts of things that LSP would enable, we signal to high-investment users that there is an entire area of improvement that Emacs is not going to explore.  So while lack of LSP hurts both newcomers and experts, it discourages the experts more, because they are looking for signals that continued investment will lead to increased reward.

I'm glad that we both like LSP, or at least the idea of it.

But it seems these days almost everybody wants it, except for MS Word 
and Notepad users.

> Put another way: LSP is the sort of thing that enables highly-invested users -- the kinds of people who write or would consider writing Elisp -- to build new functionality into Emacs, perhaps even functionality we cannot predict today.  While LSP is a good thing for all users, newcomers and experts alike, it specifically *rewards* further investment by users who are motivated to make (and capable of making) investments based on LSP's availability.  It is an expertise amplifier.  When we fail to include an expertise amplifier like that, we "bend the curve" -- in the wrong direction.

There are certain aspects where LSP is not exactly perfect: the 
functionality it allows is limited by the protocol, and by LSP servers 
available currently. It's an "ecosystem amplifier", or maybe an 
equalizer even.

I mean, it for sure is great, not to be lagging in language support for 
a whole number of languages where we did before. But there are different 
protocols that allow more powerful extensibility. nREPL, for example.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Dmitry Gutov wrote:
>Yes, the tradeoff is somewhere in there, but my problem with the
>conclusion is that it would be really easy to misapply your principle 
>(e.g. by saying we don't need fancier buttons, even though we probably
>do, or that the Getting Started guide is good enough and doesn't need 
>improvement, and someone should go work on specialized Org-mode docs
>instead).
>
>Making good use of it seems difficult.

Any guiding principle can be misused, but that doesn't make it useless.

The particular misuses you cite above are speculative -- no one's actually saying those things, as far as I'm aware.

In a reply to Christopher Lemmer Webber just now [1], I got a little bit more specific:

  > If we just say "Emacs should be easier for newcomers to learn",
  > that's not a useful rallying cry IMHO.  If we say instead "Emacs
  > should try to attract newcomers who have a higher-than-average
  > probability of becoming high-investment users, and should explain
  > early on to those newcomers what the road ahead looks like", *then*
  > we have a high-level guiding principle we can actually use.

So there's some concrete guidance about *how* we might seek to improve the Getting Started guide (and other things like the Emacs web site, starter videos, etc):

* Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks.  Set expectations right from the start.

* Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment.

* Also tell them about the ways in which Emacs may frustrate them along the way, and explain that those frustrations are common and are sometimes inevitably entangled with the same things that make Emacs winning in the long term.

I find it fairly easy to come up with ways in which this principle would provide guidance in certain decisions.  I could try to list more of those ways, if it would be helpful, but I just don't want to get into a sub-discussion about each such example.  It's meant to be a high-level principle, after all.

Ultimately, I personally find it helpful in thinking about how to teach Emacs and how to write packages.  Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm:

"GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."

Apparently some other people here find it useful as well.   You might or might not be one of them, but I can at least promise you that I'll never use this principle to make bad suggestions about ways in which Emacs should be made unfriendly to newcomers :-).

>The kind of person who *could* make a better judgment in this area is
>someone who specializes on UX. And they are rare guests around here.

More UX expertise would always help, naturally, but those of us who are here are not wholly ignorant of the field either, nor of the questions and tradeoffs that need to be dealt with.

>Are you sure that this particular aspect is _bad_ for new users, though?

Yes.  I am sure.

I've taught Emacs to a lot of people -- scores of them, at least; I don't keep track, but the sample size is large enough to be beyond merely anecdotal at this point.  I've watched newcomers run into the same obstacles over and over, and this particular obstacle is always one of the first they encounter.

>Nobody likes to stretch they hand too far. But I'll grant you
>this point, that Emacs is *somewhat* on the side of high-investment
>here.
>
>This part is expected of a professional tool, however, and the
>experience for newcomers could be improved without taking away much
>from the "oldies". See the 'transient' package, for example, recently 
>proposed for inclusion on emacs-devel.

I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)

However, your assertion that "the experience for newcomers could be improved without taking away much from the 'oldies'" is exactly what I'm arguing is not true.  I actually think we can't (much) improve this particular part of the experience for newcomers without taking away one of the things about Emacs that most rewards investment.

The newcomers who eventually *do* become experts do so in part by first stumbling across new commands accidentally (in that crowded keybinding space) and then using help tools like `C-h l' to see what they just did.  So one of the things we should prioritize is teaching newcomers how important those help facilities are and how to use them in a smart way.  I'm specifically saying that this is *more important for Emacs than it is for other editors*.  Sure, users of (say) the Atom editor should eventually know how to use the built-in help there too.  But it's a difference in prioritization: for Emacs users, using that built-in help is more important than it would be in other editors, and the methods and circumstances of using the help are different too.  So we should incorporate that fact into how we present Emacs to new users.

(Again, this is from at least some experience.  The users I've taught who have gone on to become proficient Emacs users are ones who invested very early in learning the various help facilities and when to use them.)

>Some of them, probably. At this point, I think, there are still a lot
>of decisions that would bring us closer to newcomer-friendliness while 
>keeping no worse high-investment compatibility.

That could be true, though I'm a bit more skeptical than you are.  In any case, it does not make the principle inoperative; it is consistent with the principle.

I believe we'll make better decisions if we keep in mind that "friendly to newcomers" is not, in itself, the primary goal.

>I'm glad that we both like LSP, or at least the idea of it.
>
>But it seems these days almost everybody wants it, except for MS Word
>and Notepad users.

Yes.  High-investment users, however, see more possibilities from LSP than low-investment users do -- they'll go farther with it.

>There are certain aspects where LSP is not exactly perfect: the
>functionality it allows is limited by the protocol, and by LSP servers 
>available currently. It's an "ecosystem amplifier", or maybe an
>equalizer even.
>
>I mean, it for sure is great, not to be lagging in language support
>for a whole number of languages where we did before. But there are
>different protocols that allow more powerful extensibility. nREPL, for
>example.

Ah, that's a technical question about the suitability of LSP for a particular problem space, and I'm not well-informed enough to have a useful opinion there.  If you say nREPL, I'm not going to argue! :-)

Best regards,
-Karl

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01893.html

    From: Karl Fogel <kfogel@red-bean.com>
    To: Christopher Lemmer Webber <cwebber@dustycloud.org>
    Cc: ndame <ndame@protonmail.com>,  Emacs developers <emacs-devel@gnu.org>
    Subject: Re: What is the most useful potential feature which Emacs lacks?
    Date: Wed, 13 May 2020 23:08:04 -0500
    Message-ID: <87y2pvqhuj.fsf@red-bean.com>

[2] https://github.com/magit/transient/blob/master/lisp/transient.el

[3] https://emacsair.me/2019/02/14/transient-0.1/

RE: GNU Emacs raison d'etre

[Drew Adams]

> one of the things we should prioritize is teaching newcomers
> how important those help facilities are and how to use them
> in a smart way.  

This is something I've long tried to promote.

The first thing (one of them), to get new users
to learn (by tutorial, video, or otherwise) is
how to "Ask Emacs".  That starts with the help
commands, but it can go as deep as one wants,
including how to ask Emacs in its source code.

And of the help commands, the first and most
important to learn are those that let you know
what just happened, what you did, where you are
now, and what you can do.

That includes `C-g' (yes, it can also be a help
command - get me out of here!), and `C-h l'
(which should be enhanced, IMO), `C-]', and
`M-x top-level' (or `M-: (top-level)', or bind
it to a key).

In my library `menu-bar+.el', I even add, as the
first item in menu-bar menu `Help', this submenu:

 Whoops!?
   Cancel Current Action  C-g
   Back to Top Level
   What did I do!?        C-h l

And in submenu `Describe' of menu `Help', I add
item `This...' (i.e., describe this).  It gives
you help about a key/menu sequence or a display
object you click with the mouse (e.g., part of a
window or a name somewhere as buffer text).  You
can do any of these things at its prompt:

    type a key sequence
    choose a menu item
    click on a scroll bar
    click on the mode line
    click in the minibuffer
    click on an Emacs-related name in a buffer
    click anywhere else in a buffer

For the last two: clicking on a name invokes
`apropos'.  Clicking elsewhere describes the
buffer's modes.

Most such help is from `describe-key' or the
manual (`Info-goto-emacs-key-command-node').
(My version of that Info command searches for
the key name with `Info-search' if it can't
find it in the usual ways.)

Dunno whether anyone uses such things, but I
thought they might help.

Beyond that, being able to tell what keys are
usable in the current context (any context),
and what they do, is super-important for both
learning and orienting yourself when you think
you're lost.

In that regard, my main offer is Icicles key
completion.  An alternative which is popular
is `which-key'.

On one of the wiki pages describing Icicles,
there are sections that cover the following
"Ask Emacs" topics, all of which I think are
important for newbies (independently of how
Icicles can help with them):

 * See what you can do at any moment:

   . See which possible inputs are expected by a
     command that reads input → PossibleInputs

   . See which key sequences are currently
     available, which of them are general vs
     which are local, and what each of them does
     → PossibleKeyBindings

 * See individual descriptions of the possible
   inputs, that is, help on completion candidates
   → CandidateHelp

 * Find menu items more easily → FindMenuItems

 * Find commands more easily → FindCommands

 * Find help in the doc → FindStuffInManuals

 * Learn how to use regexps → LearnAboutRegexps

https://www.emacswiki.org/emacs/EmacsNewbieWithIcicles

> I'm specifically saying that this is *more
> important for Emacs than it is for other editors*.

100% agreement.

1. It's more important for Emacs (using, learning).
2. Emacs has more to offer in this regard.

> for Emacs users, using that built-in help is more
> important than it would be in other editors, and the
> methods and circumstances of using the help are
> different too.  So we should incorporate that fact
> into how we present Emacs to new users.

This.

Re: GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

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

May 14, 2020, 00:56 by kfogel@red-bean.com:

> So there's some concrete guidance about *how* we might seek to improve the Getting Started guide (and other things like the Emacs web site, starter videos, etc):
>
> * Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks.  Set expectations right from the start.
>
> * Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment.
>
> * Also tell them about the ways in which Emacs may frustrate them along the way, and explain that those frustrations are common and are sometimes inevitably entangled with the same things that make Emacs winning in the long term.
>
>  I could try to list more of those ways, if it would be helpful
>
Yes!  Please do!  I would like to contribute toward improving the internal guide(s).

I am very much interested in figuring out:
what expectations we should set from the start
what abilities users will learn, precisely
what frustrations they will encounter and how to overcome them
Basically, I think Emacs could benefit from an explicit path to learning (i.e. a built in path).  

On StackExchange, I authored a popular response to "How to start learning Emacs Lisp" (https://emacs.stackexchange.com/questions/47318/how-can-i-start-learning-emacs-lisp/47320#47320) <https://emacs.stackexchange.com/questions/47318/how-can-i-start-learning-emacs-lisp/47320#47320>.  That response garners votes regularly; it's information people want.  I think learning Emacs leads naturally to learning Emacs Lisp.

Since I update that response occasionally (and have written several unpublished updates to it), I feel I should just contribute officially.  If you can continue to share your experience, I think that would help me.

> Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm:
>
> "GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."
>
Having these kinds of characterizations, I think, helps "sell" Emacs' virtues. I have rewritten the intro (emacs) to try demonstrating this.  See https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01889.html

I am interested, what other virtues do people feel GNU Emacs has?




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

Re: GNU Emacs raison d'etre

[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. ]]]

  > * Tell newcomers up front that Emacs really starts to be worth it
  > * after a few years, not a few weeks.

I don't believe that is true.  It is an exaggeration.

  > * Show them some of the abilities they will eventually have, so
  > * that they can see why it's worth it to make the investment.

That is useful.

  > * Also tell them about the ways in which Emacs may frustrate them
  > * along the way, and explain that those frustrations are common
  > * and are sometimes inevitably entangled with the same things that
  > * make Emacs winning in the long term.

This sounds like a recipe for discouraging people from starting.

    > I've watched newcomers run into the same obstacles over and
    > over, and this particular obstacle is always one of the first
    > they encounter.

Which obstacle is that?  If we can identify specific things that are
likely to frustrate users, we can work on improving them.  But I can't
see in your message what that refers to.

-- 
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: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Richard Stallman wrote:
>  > * Tell newcomers up front that Emacs really starts to be worth it
>  > * after a few years, not a few weeks.
>
>I don't believe that is true.  It is an exaggeration.

Well, it's not a rhetorical exaggeration, in any case.  That is, it is my actual belief, based on observation.  (It could be wrong, of course, but just to be clear, it wasn't an exaggeration for the sake of effect.)

Different people will naturally learn at different rates, depending on their aptitude and environment.  The best environment is to have an Emacs expert nearby in person, who can occasionally watch the newcomer edit and point out faster ways to do things, point out ways to ask Emacs for help, etc.  But even in that kind of environment, with a talented newcomer, I don't think I've seen it take less than approximately a year to get to the point where they are doing better with Emacs than they would have done with some less extensible, less capable text editor.

>  > * Also tell them about the ways in which Emacs may frustrate them
>  > * along the way, and explain that those frustrations are common
>  > * and are sometimes inevitably entangled with the same things that
>  > * make Emacs winning in the long term.
>
>This sounds like a recipe for discouraging people from starting.

To me it is just realistic, and if I were a newcomer I'd want to be informed of it.

>    > I've watched newcomers run into the same obstacles over and
>    > over, and this particular obstacle is always one of the first
>    > they encounter.
>
>Which obstacle is that?  If we can identify specific things that are
>likely to frustrate users, we can work on improving them.  But I can't
>see in your message what that refers to.

It was earlier in the thread:

> One thing that I recall every newcomer experiencing is, at least
> initially, the feeling that Emacs was constantly biting them --
> constantly surprising them with unexpected and confusing behaviors
> that jump out from accidental keystrokes.  Two of the first things I
> always have to teach newcomers are `C-g' and `C-h l' :-).

This property results from the keybinding space being tightly packed, of course -- which is good for experts but rocky for newcomers.

Teaching newcomers how to use these accidental stumbles to their advantage is important, and I always try to do so.  But I find it helps to let them know that it's going to happen often -- that Emacs will react in unexpected ways and surprise them, and that persisting through that initial fog of unexpected reactions is worth the effort.

A perfect analogy is manual ("stick") transmission cars versus automatic transmission cars.  A stick car is harder for a newcomer to drive, but gives an experienced user more control than she would otherwise have.  An automatic transmission car is easier for a newcomer, but frustrating for the expert because it limits (a bit) what she can do.

Does this mean that no one learns to drive stick?  Of course not.  Some people do so by choice -- they make a conscious investment, made with the understanding that driving will be *harder* for a while before there is any discernable payoff.  But they are willing to make that choice because others told them how it would be worth it.  It's not something the user would find out from reading the manual for the car, though.

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Arthur Miller]

Karl Fogel <kfogel@red-bean.com> writes:

> On 14 May 2020, Richard Stallman wrote:
>>  > * Tell newcomers up front that Emacs really starts to be worth it
>>  > * after a few years, not a few weeks.
>>
>>I don't believe that is true.  It is an exaggeration.
>
> Well, it's not a rhetorical exaggeration, in any case. That is, it is my actual
> belief, based on observation. (It could be wrong, of course, but just to be
> clear, it wasn't an exaggeration for the sake of effect.)
>
> Different people will naturally learn at different rates, depending on their
> aptitude and environment. The best environment is to have an Emacs expert nearby
> in person, who can occasionally watch the newcomer edit and point out faster
> ways to do things, point out ways to ask Emacs for help, etc. But even in that
> kind of environment, with a talented newcomer, I don't think I've seen it take
> less than approximately a year to get to the point where they are doing better
> with Emacs than they would have done with some less extensible, less capable
> text editor.

To me it took about 15 years to realize full potential of Emacs. I am
using Emacs since around year '99, 2000, since university. The first few
months were a sincere frustration, but Emacs, was the most powerful
editor installed on university server (Sun ray with Solaris at time) so
I opted for it. The alternative was Nedit, or something that was
included in CDE and OpenDesktop (or what was the name of Suns OpenLook
thing). My compiler course teacher used the editor included with
OpenDesktop. I used Emacs in OpenDesktop environment since CDE was
crawlingly slow as soon as there were more then five persons logged into
server. Most of people on our course were using Nedit since it was most
similar to what they had at home on Windows, some of us used Emacs. I
went through the frustration, learned Emacs shortcuts and so on, just
because one teacher told us on Java course, that Emacs is recommended
since it is most advanced editor we had on servers. It was funny to see
people identing their code, we were everybody sitting and tabbing through
each line of the file because nobody knew how to mark entire file and
ident it at once. I think it wasn't on refcard or something. You would
hear people clicking and tabbing (and annoying others) all the time.

Anyway, for longest years I was using Emacs just as-is, and just for
text editing. Only when I was really annoyed by something were I
looking on the internet how to change it and fix it. But then after
digging around for fixes i realized how Emacs can be used when I saw
configs of other people and what other people do with emacs and so on.

Now it is my main tool for the most stuff. I don't know if I am just not
talented, but I know I am extremelly pragmatic. I just want to do what I
feel is my current goal or task, I don't care for exploring stuff just
for exploration. I think doing work with a tool is more worth then
tinkering with the tool, so I was never really deeply interested to go
into Emacs in the beginning. I never really red the welcome screen in the
beginning, it was just an annoyance untill I learned how to turn it off
in my init file. Maybe some other people are more clever then I and read
that stuff, I was too lazy for it, I had stuff to do.

I dont' know if others are like me and just want to do their typing, or
if Emacs is nowdays better at introducing itself, but I remember my
first time with it, and it was annoying.

I agree, with everything you said, and I think how fast people will
learn depends probably on how they are exposed to Emacs. If one is on
his own, like we were, then one might miss lots of good stuff with Emacs
because it is hidden quite deeply and need quite some scratching under
the surface. Maybe the inital approach to Emacs just as a text editor
like any other was the biggest problem, since Emacs isn't just a text
editor like any other :-). I don't know. Blame me, but for me it took
quite some time to realize power of Emacs.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 16.05.2020 01:14, Arthur Miller wrote:
> I dont' know if others are like me and just want to do their typing, or
> if Emacs is nowdays better at introducing itself, but I remember my
> first time with it, and it was annoying.

It's probably better "at introducing itself" too, but not by orders of 
magnitude. But it for sure can do more, both with advancements in the 
core and with considerable help from the third-party community and the 
overall language support ecosystem (LSP, for example).

So it's quite powerful from the outset. And okay, maybe it will take 
some users a few months to start writing their own commands (and some 
will simply never do it), but it all depends on how they were introduced 
to Emacs, and what their immediate needs are.

RE: GNU Emacs raison d'etre

[Drew Adams]

> >  > * Tell newcomers up front that Emacs really starts to be worth it
> >  > * after a few years, not a few weeks.
> >
> >I don't believe that is true.  It is an exaggeration.
> 
> Well, it's not a rhetorical exaggeration, in any case.  That is, it is
> my actual belief, based on observation.  (It could be wrong, of course,
> but just to be clear, it wasn't an exaggeration for the sake of
> effect.)

It all depends on what one interprets "really" as.

I agree with you, for "_REALLY!_".  I agree with RMS
for "really", as in you get some real worth immediately.

But overall, I agree with the point you were making,
which I think is that the more you invest with Emacs
the more it's worth it, and if you invest only a tiny
amount (e.g. you just started using it) then you might
not see much of what it really has to offer.

Trying to pack such a message into just "really"
doesn't work, in general.

> Different people will naturally learn at different rates, depending on
> their aptitude and environment.  The best environment is to have an
> Emacs expert nearby in person, who can occasionally watch the newcomer
> edit and point out faster ways to do things, point out ways to ask
> Emacs for help, etc.  But even in that kind of environment, with a
> talented newcomer, I don't think I've seen it take less than
> approximately a year to get to the point where they are doing better
> with Emacs than they would have done with some less extensible, less
> capable text editor.
> 
> >  > * Also tell them about the ways in which Emacs may frustrate them
> >  > * along the way, and explain that those frustrations are common
> >  > * and are sometimes inevitably entangled with the same things that
> >  > * make Emacs winning in the long term.
> >
> >This sounds like a recipe for discouraging people from starting.
> 
> To me it is just realistic, and if I were a newcomer I'd want to be
> informed of it.

I agree, but I'm not sure how best to pass that message.

There are surely _some_ newcomers who might not get
that Emacs is a fine instrument.  There _is_ a lot to
learn, to make fine music.  But yes, you can get some
melody out of it without much practice.

I do think that newbies should be encouraged, not
discouraged.  But they should also know that Emacs is
like a piano or a lathe - there's more to it than meets
the eye.

> Teaching newcomers how to use these accidental stumbles to their
> advantage is important, and I always try to do so.  But I find it helps
> to let them know that it's going to happen often -- that Emacs will
> react in unexpected ways and surprise them, and that persisting through
> that initial fog of unexpected reactions is worth the effort.

Unexpected in terms of naive, uninformed expectations.
Which is why any intro/tutorial needs to stress the
importance of Emacs help/doc.

There is little that is unexpected in the sense of
unpredictable or undocumented.

> A perfect analogy is manual ("stick") transmission cars versus
> automatic transmission cars.  A stick car is harder for a newcomer to
> drive, but gives an experienced user more control than she would
> otherwise have.  An automatic transmission car is easier for a
> newcomer, but frustrating for the expert because it limits (a bit) what
> she can do.
> 
> Does this mean that no one learns to drive stick?  Of course not.  Some
> people do so by choice -- they make a conscious investment, made with
> the understanding that driving will be *harder* for a while before
> there is any discernable payoff.  But they are willing to make that
> choice because others told them how it would be worth it.  It's not
> something the user would find out from reading the manual for the car,
> though.

The analogy is pretty good (not perfect).  The last
sentence doesn't correspond to Emacs, though, I think.

You _can_ learn Emacs by reading its manuals and its
help (`C-h').  Asking Emacs is a good way to learn.
Maybe not as good as the expert-over-your-shoulder
method you cited, but pretty good.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 15 May 2020, Drew Adams wrote:
>> A perfect analogy is manual ("stick") transmission cars versus
>> automatic transmission cars.  A stick car is harder for a newcomer to
>> drive, but gives an experienced user more control than she would
>> otherwise have.  An automatic transmission car is easier for a
>> newcomer, but frustrating for the expert because it limits (a bit) what
>> she can do.
>> 
>> Does this mean that no one learns to drive stick?  Of course not.  Some
>> people do so by choice -- they make a conscious investment, made with
>> the understanding that driving will be *harder* for a while before
>> there is any discernable payoff.  But they are willing to make that
>> choice because others told them how it would be worth it.  It's not
>> something the user would find out from reading the manual for the car,
>> though.
>
>The analogy is pretty good (not perfect).  The last
>sentence doesn't correspond to Emacs, though, I think.
>
>You _can_ learn Emacs by reading its manuals and its
>help (`C-h').  Asking Emacs is a good way to learn.
>Maybe not as good as the expert-over-your-shoulder
>method you cited, but pretty good.

Ah, you seem to think I was saying "no one learns how to drive stick by reading the manual".

But that's not what I was saying.  I was saying that you don't find out from the manual *why* driving stick might be worth it for you -- why it might be worth the investment.

Even if the manual were to talk about that, the manual is still not where most people would actually *learn* it from.  They would learn it from talking to someone who already drives stick, or from reading an article that discusses the benefits of driving stick and how it takes some investment to do so, or some other source like that.

Learning *the fact that Emacs expects & rewards sustained investment* is different from *learning Emacs*.  Learning that you need to make an investment is different from making the investment.  I was talking about the former, so I think the analogy holds.

Now, the Emacs manual (and web site) can & should talk about how Emacs requires some investment, and about how it then rewards that investment.  But we shouldn't expect those places to be where most people learn this fact.  It's a message that has to be spread via other channels.

Best regards,
-Karl

RE: GNU Emacs raison d'etre

[Drew Adams]

> >> Does this mean that no one learns to drive stick?  Of course not.
> >> Some people do so by choice -- they make a conscious investment,
> >> made with the understanding that driving will be *harder* for a
> >> while before there is any discernable payoff.  But they are
> >> willing to make that choice because others told them how it would
> >> be worth it.  It's not something the user would find out from
> >> reading the manual for the car, though.
> >
> >The analogy is pretty good (not perfect).  The last
> >sentence doesn't correspond to Emacs, though, I think.
> >
> >You _can_ learn Emacs by reading its manuals and its
> >help (`C-h').  Asking Emacs is a good way to learn.
> >Maybe not as good as the expert-over-your-shoulder
> >method you cited, but pretty good.
> 
> Ah, you seem to think I was saying "no one learns how to drive stick by
> reading the manual".
> 
> But that's not what I was saying.  I was saying that you don't find out
> from the manual *why* driving stick might be worth it for you -- why it
> might be worth the investment.

Yes, I see now that you more likely meant that by "it".
(It could have meant learning stick or learning that
driving stick will ultimately pay off.)

I'd say that many who end up being Emacs users (in the
sense you intend) were _not_ convinced by others ahead
of time as you suggest - though many others were, no
doubt.

And I'd say that some of those who weren't thus
convinced have likely gotten their "Emacs user" bona
fides at least partly thanks to the manuals and the
help UI ("ask Emacs").

IOW, I agree with your characterization of most Emacs
users (i.e., other than any drive-by tasters who don't
stay).  And I agree with your claim that having a
mentor over the shoulder can be very helpful.  And I
agree with your guess that many who do stay become
convinced to try it and stick with it because of a
payoff promised from outside Emacs itself (manuals).
I disagree, if you also claim that _only_ those with
mentors, or those convinced by others to stick it out,
end up as users.

The point that users who stick around and really use
Emacs are the prime target of its "user friendliness"
is one I agree with.  (Not the only target, but the
main one.)  And the things you say help create Emacs
users do in fact help, and they can even sometimes be
determinant.  But it's not the case, IMO, that those
things are required, to become an Emacs user (again,
in your sense).

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 20 May 2020, Drew Adams wrote:
>Yes, I see now that you more likely meant that by "it".
>(It could have meant learning stick or learning that
>driving stick will ultimately pay off.)
>
>I'd say that many who end up being Emacs users (in the
>sense you intend) were _not_ convinced by others ahead
>of time as you suggest - though many others were, no
>doubt.
>
>And I'd say that some of those who weren't thus
>convinced have likely gotten their "Emacs user" bona
>fides at least partly thanks to the manuals and the
>help UI ("ask Emacs").
>
>IOW, I agree with your characterization of most Emacs
>users (i.e., other than any drive-by tasters who don't
>stay).  And I agree with your claim that having a
>mentor over the shoulder can be very helpful.  And I
>agree with your guess that many who do stay become
>convinced to try it and stick with it because of a
>payoff promised from outside Emacs itself (manuals).
>I disagree, if you also claim that _only_ those with
>mentors, or those convinced by others to stick it out,
>end up as users.
>
>The point that users who stick around and really use
>Emacs are the prime target of its "user friendliness"
>is one I agree with.  (Not the only target, but the
>main one.)  And the things you say help create Emacs
>users do in fact help, and they can even sometimes be
>determinant.  But it's not the case, IMO, that those
>things are required, to become an Emacs user (again,
>in your sense).

Agreed -- I don't think that's absolutely required.  I do think that a new user stands a much greater chance of becoming a long-term, invested user when persuaded (and ideally helped) by others who have already made that investment successfully.  But it's not required.  

Most of the long-term Emacs users I know personally seem to have been socialized into it, but it could be the case that there's some selection bias among the Emacs users I know!

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Eduardo Ochs]

On Fri, 15 May 2020 at 18:43, Karl Fogel <kfogel@red-bean.com> wrote:
>
> Different people will naturally learn at different rates, depending
> on their aptitude and environment. The best environment is to have
> an Emacs expert nearby in person, who can occasionally watch the
> newcomer edit and point out faster ways to do things, point out ways
> to ask Emacs for help, etc. But even in that kind of environment,
> with a talented newcomer, I don't think I've seen it take less than
> approximately a year to get to the point where they are doing better
> with Emacs than they would have done with some less extensible, less
> capable text editor.


The fun factor is getting absent from the discussion. Let me bring it
back in.

1.
==

When I started using using Solaris in a laboratory in the university
in the mid-90s I tried to learn vi - and for me that was torture.
After some time I bought a 386 and a CD with one of the first
GNU/Linux distributions, and I tried Emacs. No computers in the
university had Emacs - all the sysadmins were against it.

After a few hours playing with Emacs I found how to write my own .el
files and execute them. After a few days I found C-x C-e and I was
mind-blown by it. That was in the beginning of my holidays, and after
that during two months I spent practically all my time awake playing
with Emacs and using it to learn how use the GNU/Linux system that
came with it. Why? Because it was fun.

2.
==

In 2019 I had two opportunities to teach Emacs to friends who are
professional programmers (note: I don't interact much with
professional programmers in real life). It wouldn't work to show to
them what Emacs is capable of doing, to tell them that they would be
able to use Emacs for everything if they would invest 2000 hours in
that, or to show them that Emacs is a better _editor_ than their
favorite editors, that were vim and VSCode - especially because I am
not a very proficient user of Emacs-the-editor myself...

...so I helped them install Emacs in their machines, showed them the
basic ideas of Lisp, showed them how to open tutorials that were 80%
about Emacs-the-Lisp-environment and only 20% about Emacs-the-editor,
and helped them to follow the explanations, instructions, and
exercises. They loved it.

3.
==

A few days ago I discovered, reading discussions in this mailing list,
that I am not the only old-timer who has found Org difficult to learn,
and who has learned only tiny bits of it even after struggling with it
a lot.

I think that I found Org hard because learning it was not fun in the
same sense as learning Emacs was... I found the examples in the manual
very hard to run, and the feature of Org in which I was most
interested - code blocks - depended on many concepts that were treated
as black boxes.

We are trying to discuss what could make Emacs more appealing, easier
to learn, etc, etc, and how answers to these questions could become
features, videos, and tutorials.

There are several very different ways to make features, videos, and
tutorials that are "good". Some of these ways are very common now -
powerful features, very smart "Do what I mean" buttons, well-produced
videos with smiling presenters, with promises of productivity, fame,
and fortune... but there are some ways of making "good" things that
were very common some decades ago, but now are less so: the main key
terms are "elegance" and "hackeability".

I have even tried to make an experimental/prototype-ish tutorial for
Org following these ideas, but I didn't get very far. I even asked
some questions in the Org mailing list in nov/2019 and got answers for
them, but my original plan was to write a handful of new functions for
Org that would show the sub-actions of running `C-c C-c' on a code
block - see:

  (info "(org)Evaluating code blocks")

but I found the source code too hard to understand, and gave up after
some days.

There are also other parts of Emacs that I tried to understand but
gave up - for example, I've never been able to understand how to use
edebug, and I've only been able to learn the most basic things about
eshell, but a few days ago Sacha Chua posted this video in her Emacs
News, and this gave new hopes...

  http://www.youtube.com/watch?v=L1f2tulD9N8

Maybe we can try to coordinate people who have similar notions of
"good", "fun", "elegant", and "hackable", and try to form groups to
discuss and write tutorials?... I have the impression that these
tutorials can yield good material for discussion with people outside
the groups of writers - including package authors...

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/emacsconf2019.html
    http://angg.twu.net/emacs.html

Re: GNU Emacs raison d'etre

[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. ]]]

Your message suggests another way of stating Emacs's special virtue:
     
Emacs is the editor that encourages you to hack it to make it better.

-- 
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: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 06:46, Richard Stallman wrote:
> Your message suggests another way of stating Emacs's special virtue:
>       
> Emacs is the editor that encourages you to hack it to make it better.

That sounds more fun than "sustained investment". :-)

Re: GNU Emacs raison d'etre

[Yuri Khan]

On Sat, 16 May 2020 at 04:43, Karl Fogel <kfogel@red-bean.com> wrote:
> > Two of the first things I
> > always have to teach newcomers are `C-g' and `C-h l' :-).
>
> This property results from the keybinding space being tightly packed, of course -- which is good for experts but rocky for newcomers.

It results from the fact that ‘keyboard-quit’ is on an obscure[^1] C-g
key rather than the intuitive[^1] Esc. And that results from Esc being
used in most terminals to mean Meta.

[^1]: from a novice’s point of view

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sat, 16 May 2020 15:05:54 +0700
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>  Andreas Röhler <andreas.roehler@online.de>,
>  Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> It results from the fact that ‘keyboard-quit’ is on an obscure[^1] C-g
> key rather than the intuitive[^1] Esc.

We also have "ESC ESC ESC".

Re: GNU Emacs raison d'etre

[Yuri Khan]

On Sat, 16 May 2020 at 17:37, Eli Zaretskii <eliz@gnu.org> wrote:

> We also have "ESC ESC ESC".

Yes. It takes a greater degree of impatience to discover, and it is
somewhat more aggressive in its effect than C-g.

We also have ‘q’ in any modes derived from special-mode.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 07:56, Karl Fogel wrote:

 > Any guiding principle can be misused, but that doesn't make it useless.

 > The particular misuses you cite above are speculative -- no one's
 > actually saying those things, as far as I'm aware.

Actually, those examples are closer to the discussions I have taken 
part in (let's not change xxx because existing users will complain; and 
the newbies will just have to get in line, the entry barrier is high 
anyway, who cares if they have to learn one more thing to get started).

On the flip side, I don't remember anybody propose to make key bindings 
less "staggered".

> In a reply to Christopher Lemmer Webber just now [1], I got a little bit more specific:
> 
>    > If we just say "Emacs should be easier for newcomers to learn",
>    > that's not a useful rallying cry IMHO.  If we say instead "Emacs
>    > should try to attract newcomers who have a higher-than-average
>    > probability of becoming high-investment users, and should explain
>    > early on to those newcomers what the road ahead looks like", *then*
>    > we have a high-level guiding principle we can actually use.

I think we already do (the rest flocks to #1, #2 and #4 popular 
options). No need to try harder in that direction.

> So there's some concrete guidance about *how* we might seek to improve the Getting Started guide (and other things like the Emacs web site, starter videos, etc):
> 
> * Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks.  Set expectations right from the start.

That feels like giving up. And "worth it" depends on personal 
expectations. From reading comments on Reddit, converts from Vim, for 
instance, try Spacemacs or Doom Emacs, and seemingly become satisfied in 
a matter of days.

> * Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment.

Not sure what you have in mind here. If it's a "here's not an Emacs 
would solve a problem", this could turn into a useful tutorial for 
journeyman emacsers.

> * Also tell them about the ways in which Emacs may frustrate them along the way, and explain that those frustrations are common and are sometimes inevitably entangled with the same things that make Emacs winning in the long term.

Not a bad advice, but deciding on such a list in official documentation 
might not be easy (people have opinions). Once we do decide, it would be 
better to try to improve these things first.

> Ultimately, I personally find it helpful in thinking about how to teach Emacs and how to write packages.  Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm:
> 
> "GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."

I still don't like it. It either means "you don't get much until you 
struggle for a while" (which just sounds discouraging) and/or "no other 
program comes even close at text manipulation", which is... pretty 
conceited and kind of limited at the same time. I mean, Emacs is great 
and all, but I don't have "text manipulation" as the #1 goal in my life. 
Or even among top 10 goals.

The higher-level things one can implement with Emacs Lisp are a lot more 
interesting.

>> Are you sure that this particular aspect is _bad_ for new users, though?
> 
> Yes.  I am sure.
> 
> I've taught Emacs to a lot of people -- scores of them, at least; I don't keep track, but the sample size is large enough to be beyond merely anecdotal at this point.  I've watched newcomers run into the same obstacles over and over, and this particular obstacle is always one of the first they encounter.

Okay, but is it still a problem after they've tried Emacs for a day, for 
instance? For a week?

These periods of time would of course suggest Emacs is not ideal for 
total newbies, but they're not the kind of "sustained investment" you 
described either.

>> This part is expected of a professional tool, however, and the
>> experience for newcomers could be improved without taking away much
>>from the "oldies". See the 'transient' package, for example, recently 
>> proposed for inclusion on emacs-devel.
> 
> I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)

You press 'C-x', wait a while - and it pops up a window with the 
descriptions of all commands whose bindings start with 'C-x'. Same for 
all other "incomplete" key sequences. Looks pretty handy for beginners.

> However, your assertion that "the experience for newcomers could be improved without taking away much from the 'oldies'" is exactly what I'm arguing is not true.  I actually think we can't (much) improve this particular part of the experience for newcomers without taking away one of the things about Emacs that most rewards investment.
> 
> The newcomers who eventually *do* become experts do so in part by first stumbling across new commands accidentally (in that crowded keybinding space) and then using help tools like `C-h l' to see what they just did.  So one of the things we should prioritize is teaching newcomers how important those help facilities are and how to use them in a smart way.  I'm specifically saying that this is *more important for Emacs than it is for other editors*.  Sure, users of (say) the Atom editor should eventually know how to use the built-in help there too.  But it's a difference in prioritization: for Emacs users, using that built-in help is more important than it would be in other editors, and the methods and circumstances of using the help are different too.  So we should incorporate that fact i
 nto how we present Emacs to new users.

Yes, ok. Maybe this one is harder to improve that some others.

>> Some of them, probably. At this point, I think, there are still a lot
>> of decisions that would bring us closer to newcomer-friendliness while
>> keeping no worse high-investment compatibility.
> 
> That could be true, though I'm a bit more skeptical than you are.  In any case, it does not make the principle inoperative; it is consistent with the principle.
> 
> I believe we'll make better decisions if we keep in mind that "friendly to newcomers" is not, in itself, the primary goal.

It's not like extreme user-friendliness was ever a guiding principle 
here. :-)

In this we're, again, similar to other professional software.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

Sorry,

On 17.05.2020 04:28, Dmitry Gutov wrote:
> I think we already do (the rest flocks to #1, #2 and #4 popular
                                                        ^ #3
> options). No need to try harder in that direction.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

Sorry again,

On 17.05.2020 04:28, Dmitry Gutov wrote:
> Not sure what you have in mind here. If it's a "here's not an Emacs 
> would solve a problem", this could turn into a useful tutorial for 
> journeyman emacsers.

^ "here's how an Emacs user would solve a problem"

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 17, 2020, at 10:28, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>>> This part is expected of a professional tool, however, and the
>>> experience for newcomers could be improved without taking away much
>>> from the "oldies". See the 'transient' package, for example, recently proposed for inclusion on emacs-devel.
>> I don't have any experience using 'transient', so I'd need more explanation from you to understand what you meant by that part.  (I tried to understand 'transient' from reading [2] and [3], but unfortunately -- and somewhat surprisingly! -- the documentation at those pages does not give a single concrete example of transient's use.)
> 
> You press 'C-x', wait a while - and it pops up a window with the descriptions of all commands whose bindings start with 'C-x'. Same for all other "incomplete" key sequences. Looks pretty handy for beginners.

which-key seems to do something similar. I like it very much because it helps see the rationale behind keybinding. After a while you get to learn the bindings for the commands you use the most and you can easily explore new commands.


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

Re: GNU Emacs raison d'etre

[Stefan Kangas]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

> which-key seems to do something similar. I like it very much because
> it helps see the rationale behind keybinding. After a while you get to
> learn the bindings for the commands you use the most and you can
> easily explore new commands.

I've used which-key for a couple of years by now.  It has turned out to
be a huge time-saver and great for discovering new commands (or to
remind myself of some less frequently used ones).

I believe that we would have much to gain in terms of being new-user
friendly by having something like this in core, enabled by default.

The package is installable from MELPA, and screenshots are at:
https://github.com/justbur/emacs-which-key

Best regards,
Stefan Kangas

Re: GNU Emacs raison d'etre

[Joost Kremers]

On Sun, May 17 2020, Stefan Kangas wrote:
[which-key]
> I believe that we would have much to gain in terms of being 
> new-user
> friendly by having something like this in core, enabled by 
> default.

I also find which-key extremely helpful and because it is only 
triggered after a short delay, it stays out of my way when I don't 
need it.

The question might as well be, why isn't in it core already? The 
file `which-key.el` actually says "Copyright (C) 2017  Free 
Software Foundation, Inc."

I course there are things that would need to be cleared first, but 
it does seem the author would be willing to make it happen.

-- 
Joost Kremers
Life has its moments

Re: GNU Emacs raison d'etre

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> writes:
>
>> which-key seems to do something similar. I like it very much because
>> it helps see the rationale behind keybinding. After a while you get to
>> learn the bindings for the commands you use the most and you can
>> easily explore new commands.
>
> I've used which-key for a couple of years by now.  It has turned out to
> be a huge time-saver and great for discovering new commands (or to
> remind myself of some less frequently used ones).
>
> I believe that we would have much to gain in terms of being new-user
> friendly by having something like this in core, enabled by default.
>
> The package is installable from MELPA, and screenshots are at:
> https://github.com/justbur/emacs-which-key
>
> Best regards,
> Stefan Kangas
I also think you could have something like which-key on by default. I
have also used which-key at least a year or two, and I have just one
small issue with it: sometimes, when there are lots of options, it
renders botom line only partially. It renders it little behind the
minibuffer, I see only half the height of the bottom line. For me it is
not a major issue, and is probably not hard to fix, I just didn't bother
myself, but if you would have it in Emacs then it might need fix.

transient

[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 like it very much because it helps see the rationale behind
  > keybinding. After a while you get to learn the bindings for the
  > commands you use the most and you can easily explore new commands.

For those that know Transient -- do you think it would provide that
benefit too?

-- 
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: transient

[Joost Kremers]

On Mon, May 18 2020, Richard Stallman wrote:
>   > I like it very much because it helps see the rationale 
>   > behind
>   > keybinding. After a while you get to learn the bindings for 
>   > the
>   > commands you use the most and you can easily explore new 
>   > commands.
>
> For those that know Transient -- do you think it would provide 
> that
> benefit too?

Well, which-key simply displays existing keybindings. A package 
author doesn't have to do anything, which-key just works.

Transient OTOH defines its own key sequences, so you can't use it 
to show users existing keybindings. If a package author wants 
their package to work with transient, they have to define 
transient menus for all functionality they want to expose.

Transient key bindings also work differently from standard Emacs 
key bindings. That's not a bad thing, because transient's main 
purpose is to provide an interface to external command line 
programs (such as git, as it was originally developed as part of 
magit) and it's well-suited for that.

It would be possible to use transient to provide an interface to 
Emacs packages, but the interface would be different from what is 
standard, so it's not a which-key replacement.


-- 
Joost Kremers
Life has its moments

Re: transient

[Dmitry Gutov]

On 18.05.2020 09:58, Joost Kremers wrote:
> 
> On Mon, May 18 2020, Richard Stallman wrote:
>>   > I like it very much because it helps see the rationale   > behind
>>   > keybinding. After a while you get to learn the bindings for   > the
>>   > commands you use the most and you can easily explore new   > 
>> commands.
>>
>> For those that know Transient -- do you think it would provide that
>> benefit too?
> 
> Well, which-key simply displays existing keybindings. A package author 
> doesn't have to do anything, which-key just works.

Perhaps I was wrong (sorry, not actively using either of the packages), 
and it's the which-key package that I was thinking about after all.

Re: transient

[Howard Melman]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Mon, May 18 2020, Richard Stallman wrote:
>>   > I like it very much because it helps see the rationale behind
>>   > keybinding. After a while you get to learn the bindings for the
>>   > commands you use the most and you can easily explore
>>   > new commands.
>>
>> For those that know Transient -- do you think it would provide that
>> benefit too?
>
> Well, which-key simply displays existing keybindings. A package author
> doesn't have to do anything, which-key just works.
>
> Transient OTOH defines its own key sequences, so you can't use it to
> show users existing keybindings. If a package author wants their
> package to work with transient, they have to define transient menus
> for all functionality they want to expose.

Agreed. I've used both. which-key let's me explore existing
bindings with no effort.  Type C-x r and wait a second and
see all the rectangle and register commands. It was great
for learning the M-s and M-g keymaps when they were added.

which-key has been very helpful for learning bindings and I
think it would be great addition to core. Though for a busy
keymap it can take a second to read it to find what you
want. The C-h map is a perfect example. 

I've written a few transients that I've found useful,
including one for help and others for customize, ediff,
frame commands and one that toggles a ton of different minor
modes and visual features. Unlike which-key, transient
allows you to specify the order and groupings of bindings
when activated which can make scaning and learning them much
easier

hydra is a similar package to transient in that you can
define such temporary keymaps and customize a help display
that's shown while using it.  It has advantages and
disadvantages but so far I've prefered transient.

-- 

Howard

Re: transient

[John Yates]

On Mon, May 18, 2020 at 2:41 PM Howard Melman <hmelman@gmail.com> wrote:
> I've written a few transients that I've found useful,
> including one for help and others for customize, ediff,
> frame commands and one that toggles a ton of different minor
> modes and visual features.

Are these available anywhere?

/john

Re: transient

[Howard Melman]

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

John Yates <john@yates-sheets.org> writes:

> On Mon, May 18, 2020 at 2:41 PM Howard Melman <hmelman@gmail.com> wrote:
>> I've written a few transients that I've found useful,
>> including one for help and others for customize, ediff,
>> frame commands and one that toggles a ton of different minor
>> modes and visual features.
>
> Are these available anywhere?

Not as a package as they are just my own personal config. I
did post a few here:
https://www.reddit.com/r/emacs/comments/f3o0v8/anyone_have_good_examples_for_transient/fhq1lky/?context=3

Here's a screenshot of my help one:


[-- Attachment #2: Help Transient Window --]
[-- Type: image/png, Size: 61561 bytes --]

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]



-- 

Howard

RE: transient

[Drew Adams]

> >>> I like it very much because it helps see the rationale behind
> >>> keybinding. After a while you get to learn the bindings for the
> >>> commands you use the most and you can easily explore
> >>> new commands.
> 
> ... which-key let's me explore existing bindings with
> no effort.  Type C-x r and wait a second and see all
> the rectangle and register commands. It was great for
> learning the M-s and M-g keymaps when they were added.
> which-key has been very helpful for learning bindings...

FWIW -

Icicles key completion is similar, but there are
notable differences:

1. You can use it on-demand (as well as just
   automatically) - complete only when you want
   to, and without a delay.

2. Because of that you can also use it at top
   level, not just after hitting a prefix key.
   Use it to see what key bindings are available
   in the current context (e.g. active modes).

3. Completion candidates have 2 parts: key and
   command name: `KEY  =  COMMAND'.  You can
   match either or both.  Prefix keys have `...'
   instead of `COMMAND: `PREFIX-KEY  =  ...'.

4. Choosing a candidate with a COMMAND invokes
   it.  Choosing a prefix-key candidate changes
   the set of candidates to its completions.
   E.g., choosing `C-h  =  ...' shows candidates
   such as `f  =  describe-function'.

5. You can filter the current matches, by typing
   input that matches key or command names, or
   both.  You can filter multiple times (multiple
   patterns).  Remove your current pattern from
   the minibuffer and type another one to see a
   different set of matches at the same level
   (same prefix key or top level).

6. When completing a prefix key, the first
   candidate shown is `..', which you can choose
   to go back up a level (completions above that
   prefix key).  Then you can go down another
   prefix key - explore the entire key-sequence
   forest.

7. That forest includes menus, as prefix-key
   candidates (`menu-bar  = ...').  So you can
   explore menus in the same way. [*]

8. You can sort candidates in these ways:

    * local bindings first, then non-local, each
      group in alphabetic order by key name
    * prefix keys first, then non-prefix, again,
      in key-name alphabetic order
    * alphabetic order by command name

   You can cycle among those sort orders anytime,
   using `C-,'.

9. Local bindings are highlighted differently
   from non-local - two faces.  Menus get two
   other faces (local, non-local).

10. You can show full help (`C-h f' help) for
    any candidate, anytime, without ending
    completion.  (Use `C-M-RET' on it.)

11. Being able to match minibuffer input against
   key and command names means that, unlike the
   approach of `which-key' and similar, when
   completing a prefix key you don't just hit
   keys that complete the key sequence, to
   invoke its command.  A workaround for that is
   to hit `M-q' and then hit a key, to insert
   its name in the minibuffer and then choose it.
   E.g., `M-q C-M-f' inserts the text `C-M-f' in
   the minibuffer.
_____

[*] Exploring menu-bar menus this way is one
    step (menu level) at a time, the same as
    exploring other key sequences.  A better way
    to explore menu-bar menus is to use library
    La Carte.  Then you can match menu items or
    submenus directly, at any level.  I.e., you
    can type a single pattern that dives down
    into the menu hierarchy - like file-name
    completion.  (But you can also navigate
    stepwise.)

Re: transient

[Arthur Miller]

Drew Adams <drew.adams@oracle.com> writes:

>> >>> I like it very much because it helps see the rationale behind
>> >>> keybinding. After a while you get to learn the bindings for the
>> >>> commands you use the most and you can easily explore
>> >>> new commands.
>> 
>> ... which-key let's me explore existing bindings with
>> no effort.  Type C-x r and wait a second and see all
>> the rectangle and register commands. It was great for
>> learning the M-s and M-g keymaps when they were added.
>> which-key has been very helpful for learning bindings...
>
> FWIW -
>
> Icicles key completion is similar, but there are
> notable differences:
>
> 1. You can use it on-demand (as well as just
>    automatically) - complete only when you want
>    to, and without a delay.
>
> 2. Because of that you can also use it at top
>    level, not just after hitting a prefix key.
>    Use it to see what key bindings are available
>    in the current context (e.g. active modes).
>
> 3. Completion candidates have 2 parts: key and
>    command name: `KEY  =  COMMAND'.  You can
>    match either or both.  Prefix keys have `...'
>    instead of `COMMAND: `PREFIX-KEY  =  ...'.
>
> 4. Choosing a candidate with a COMMAND invokes
>    it.  Choosing a prefix-key candidate changes
>    the set of candidates to its completions.
>    E.g., choosing `C-h  =  ...' shows candidates
>    such as `f  =  describe-function'.
>
> 5. You can filter the current matches, by typing
>    input that matches key or command names, or
>    both.  You can filter multiple times (multiple
>    patterns).  Remove your current pattern from
>    the minibuffer and type another one to see a
>    different set of matches at the same level
>    (same prefix key or top level).
>
> 6. When completing a prefix key, the first
>    candidate shown is `..', which you can choose
>    to go back up a level (completions above that
>    prefix key).  Then you can go down another
>    prefix key - explore the entire key-sequence
>    forest.
>
> 7. That forest includes menus, as prefix-key
>    candidates (`menu-bar  = ...').  So you can
>    explore menus in the same way. [*]
>
> 8. You can sort candidates in these ways:
>
>     * local bindings first, then non-local, each
>       group in alphabetic order by key name
>     * prefix keys first, then non-prefix, again,
>       in key-name alphabetic order
>     * alphabetic order by command name
>
>    You can cycle among those sort orders anytime,
>    using `C-,'.
>
> 9. Local bindings are highlighted differently
>    from non-local - two faces.  Menus get two
>    other faces (local, non-local).
>
> 10. You can show full help (`C-h f' help) for
>     any candidate, anytime, without ending
>     completion.  (Use `C-M-RET' on it.)
>
> 11. Being able to match minibuffer input against
>    key and command names means that, unlike the
>    approach of `which-key' and similar, when
>    completing a prefix key you don't just hit
>    keys that complete the key sequence, to
>    invoke its command.  A workaround for that is
>    to hit `M-q' and then hit a key, to insert
>    its name in the minibuffer and then choose it.
>    E.g., `M-q C-M-f' inserts the text `C-M-f' in
>    the minibuffer.
> _____
>
> [*] Exploring menu-bar menus this way is one
>     step (menu level) at a time, the same as
>     exploring other key sequences.  A better way
>     to explore menu-bar menus is to use library
>     La Carte.  Then you can match menu items or
>     submenus directly, at any level.  I.e., you
>     can type a single pattern that dives down
>     into the menu hierarchy - like file-name
>     completion.  (But you can also navigate
>     stepwise.)
I haven't used Icicles yet, but seen this list, maybe I
should give it a try and see if I can use it instead of which-key. Can
Icicles be used without any additional learning and as easy as
which-key? Which-key is kind-of "just works", one installs it and it does
what it does without additional effort on user side. Is "automatic"
feature of Icicles in same manner?

Regression, but I have to say, I am impressed Drew. With how much you
have written. I went yesterday through your changelog for Dired+. Just
reading the changelog and thinking though the extra features you have
there took quite some time I have to say. What spontaneously to look
usefull is marking/toggeling/untoggling files per region only. That
seems like a usefull feature. Maybe you should try to get that part into
standard Dired?

Re: transient

[Michael Heerdegen]

Arthur Miller <arthur.miller@live.com> writes:

> usefull is marking/toggeling/untoggling files per region only. That
> seems like a usefull feature. Maybe you should try to get that part into
> standard Dired?

After Bug#39902 had been treated this has improved in vanilla Emacs.
Toggling was not changed, however.

Michael.

bug#39902: transient

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Thanks for mentioning it.  Now toggling per region is implemented
> here:

Thanks.

Patch looks reasonable.  I tried it quickly.  It works - but the last
line covered by the region is never included in toggling, even when it
is completely inside the region.  I'm using dired-mark-region ->
inclusive.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Thanks for mentioning it.  Now toggling per region is implemented
>> here:
>
> Thanks.
>
> Patch looks reasonable.  I tried it quickly.  It works - but the last
> line covered by the region is never included in toggling, even when it
> is completely inside the region.  I'm using dired-mark-region ->
> inclusive.

Maybe it doesn't work because after Drew asked me to use better names,
I changed the option values from 'exclusive/inclusive' to 'file/line'.
So maybe the patch will work when using dired-mark-region -> line.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> So maybe the patch will work when using dired-mark-region -> line.

Yes, that was it, now it works as expected :-)

Thanks,

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> So maybe the patch will work when using dired-mark-region -> line.
>
> Yes, that was it, now it works as expected :-)

Thanks for checking, now pushed to master in commit 25390b28c4.

It seems there are no more Dired commands that could depend on region :-)

RE: transient

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> Icicles key completion is similar, but there are
> notable differences:
>
> 1. You can use it on-demand (as well as just
>    automatically) - complete only when you want
>    to, and without a delay.

What binding do you use here?  Won't it conflict with other keybindings?

Best regards,
Stefan Kangas

RE: transient

[Drew Adams]

> > Icicles key completion is similar, but there are
> > notable differences:
> >
> > 1. You can use it on-demand (as well as just
> >    automatically) - complete only when you want
> >    to, and without a delay.
> 
> What binding do you use here?  Won't it conflict with
> other keybindings?

Are you sure you really want to know? ;-)

tl;dr:

By default, the key (`S-TAB' by default) doesn't
get bound in any keymaps where it's already bound.

___

Option:

 `icicle-key-complete-keys' is a variable defined in `icicles-opt.el'.
 Its value is ([backtab])

 Documentation:
 Key sequences to use for `icicle-complete-keys'.
 A list of values that each has the same form as a key-sequence
 argument to `define-key'.  It is a list mainly in order to accommodate
 different keyboards - for example, `S-tab' and `S-iso-lefttab'.

(IOW the key to complete keys is `S-TAB' only by default.)
___

These options are also relevant here:

1.
 `icicle-key-complete-keys-for-minibuffer' is a variable defined in `icicles-opt.el'.
 Its value is ([M-backtab] [ESC backtab])

 Documentation:
 Key sequences to use for `icicle-complete-keys' in the minibuffer.
 A list of values that each has the same form as a key-sequence
 argument to `define-key'.

 Note: Some operating systems intercept `M-S-TAB' for their own use.
 For some versions of MS Windows, you can use
 (w32-register-hot-key [M-S-tab]) to allow Emacs to use `M-S-TAB'.

[The reason for this is that by default `S-TAB' is also used
in Icicles in the minibuffer completion maps, to complete
minibuffer input.  So by default, _key_ completion in the
minibuffer itself (yes, it's possible) uses `M-S-TAB'.]

2.
 `icicle-keymaps-for-key-completion' is a variable defined in `icicles-opt.el'.
 Its value is (...)

 Documentation:
 List of keymaps in which to bind `S-TAB' to `icicle-complete-keys'.
 List elements are symbols that are bound to keymaps.

 Each keymap should have at least one prefix key.  `S-TAB' is bound in
 each keymap, so that you can use it to complete the prefix keys.

 If one of the keymaps is not defined when Icicle mode is entered, then
 it is ignored.  If you later define it, then just exit and reenter
 Icicle mode, to bind `S-TAB' in the newly defined map.  For example,
 use `M-x icy-mode' twice after entering Calendar mode, to be able to
 complete `calendar-mode' prefix keys such as `A'.

 Do not add `global-map' or any keymaps, such as `ctl-x-map', that are
 accessible from the global keymap to the list - they are already
 treated, by default.

 Do not add any of the translation keymaps, `function-key-map',
 `key-translation-map', or `iso-transl-ctl-x-8-map' to the list - that
 will not work.

[These are keymaps inaccessible from `global-map',
as maps accessible from it are already included.]

3.
 `icicle-complete-key-anyway-flag' is a variable defined in `icicles-opt.el'.
 Its value is nil

 Documentation:
 Non-nil means bind `S-TAB' for key completion even if already
 bound.  If nil, then each of the keys in `icicle-key-complete-keys' is
 bound to `icicle-complete-keys' in each keymap of
 `icicle-keymaps-for-key-completion' only if `S-TAB' is not already
 bound in the keymap.

 Note: the keys in `icicle-key-complete-keys' are always bound to
 `icicle-complete-keys' in `icicle-mode-map'.  This option affects only
 the binding of those keys in `icicle-keymaps-for-key-completion'.

[Besides the keymaps defined by that option, keymaps
reachable from `global-map' with this function get the
`S-TAB' binding, IF either they don't already have
`S-TAB' bound OR option `icicle-complete-key-anyway-flag'
is non-nil.
This is the reason behind the "Do not add `global-map'..."
part of the `icicle-keymaps-for-key-completion' doc string.]

(defun icicle-bind-key-completion-keys-in-keymaps-from (map &optional keys)
  "Bind keys in `icicle-key-complete-keys' to `icicle-complete-keys'.
Each key in `icicle-complete-keys' (or optional arg KEYS, if non-nil)
is bound in all keymaps accessible from keymap MAP."
  (dolist (key+map  (accessible-keymaps map))
    (let ((map  (cdr key+map)))
      (when (keymapp map)
        (dolist (key  (or keys  icicle-key-complete-keys))
          (when (or icicle-complete-key-anyway-flag
                    (not (lookup-key map key)))
            (condition-case nil
               (define-key map key 'icicle-complete-keys)
             (error nil))))))))

The same kind of treatment happens in reverse when
you turn `icy-mode' off: key-completion keys are
unbound.  (Yes, it can't be perfect.  For example,
the set of keymaps accessible from the then current
global map might be different, or their keys might
be different.)

See this part of the doc:

https://www.emacswiki.org/emacs/Icicles_-_Key_Completion#KeymapsInaccessibleFromGlobalMap

Search that same page for "option" to see the above
options and others having to do with key completion
described in context.

which-key

[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. ]]]

  > Well, which-key simply displays existing keybindings. A package 
  > author doesn't have to do anything, which-key just works.

I see.  That sounds useful.  Does anyone disagree?

-- 
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: GNU Emacs raison d'etre

[Drew Adams]

> > I don't have any experience using 'transient', so
> > I'd need more explanation from you to understand
> > what you meant by that part.  (I tried to understand
> > 'transient' from reading [2] and [3], but unfortunately
> > -- and somewhat surprisingly! -- the documentation at
> > those pages does not give a single concrete example
> > of transient's use.)
> 
> You press 'C-x', wait a while - and it pops up a
> window with the descriptions of all commands whose
> bindings start with 'C-x'. Same for all other
> "incomplete" key sequences. Looks pretty handy for
> beginners.

https://www.emacswiki.org/emacs/Icicles_-_Key_Completion#AutomaticKeyCompletion

FWIW.  Key completion since 2007.

> > one of the things we should prioritize is teaching
> > newcomers how important those help facilities are
> > and how to use them in a smart way.  I'm specifically
> > saying that this is *more important for Emacs than
> > it is for other editors*.  ... it's a difference in 
> > prioritization: for Emacs users, using that
> > built-in help is more important than it would be in
> > other editors, and the methods and circumstances of
> > using the help are different too.  So we should
> > incorporate that fact into how we present Emacs to
> > new users.
> >
> > I believe we'll make better decisions if we keep in
> > mind that "friendly to newcomers" is not, in itself,
> > the primary goal.
> 
> It's not like extreme user-friendliness was ever a
> guiding principle here. :-)

I disagree.  There is a difference between "extreme
user-friendliness" - which I think is, and should be,
a guiding principle here, and prioritizing "friendly
to newcomers".

Just because something (a great book, a great work of
art or science or craft) doesn't immediately reflect
the preconceptions and baked-in expectations of a
newbie to it, that doesn't mean it's not rewarding
and "friendly" to its "users".  Not at all.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 17 May 2020, Drew Adams wrote:
>> > I believe we'll make better decisions if we keep in
>> > mind that "friendly to newcomers" is not, in itself,
>> > the primary goal.
>> 
>> It's not like extreme user-friendliness was ever a
>> guiding principle here. :-)
>
>I disagree.  There is a difference between "extreme
>user-friendliness" - which I think is, and should be,
>a guiding principle here, and prioritizing "friendly
>to newcomers".

While "friendly to newcomers" means something on its own, "user-friendliness" only means something after one has characterized the users in question.  That's the main point I've been trying to make: that there is no such thing as a generic user, so we have to make decisions about which kinds of users to optimize for.

In most UI/UX conversations (not necessarily here, but on the Net in general), most of the time people unconsciously say "user-friendly" as a synonym for "easy for newcomers to pick up quickly" -- without realizing that it also implies "tends not to reward sustained investment", since these two qualities inevitably trade off.

So if we characterize our users as "those who see, or who have the potential to see, the value of making a sustained investment in their text manipulation environment", *then* yes, by all means Emacs should be user-friendly.  But if we're saying "user-friendly" in the colloquial sense that most people use the term in, then no, I think it would be a mistake for Emacs to aim for that.

Best regards,
-Karl

RE: GNU Emacs raison d'etre

[Drew Adams]

> >> It's not like extreme user-friendliness was ever a
> >> guiding principle here. :-)
> >
> >I disagree.  There is a difference between "extreme
> >user-friendliness" - which I think is, and should be,
> >a guiding principle here, and prioritizing "friendly
> >to newcomers".
> 
> While "friendly to newcomers" means something on its own, "user-
> friendliness" only means something after one has characterized the
> users in question.  That's the main point I've been trying to make:
> that there is no such thing as a generic user, so we have to make
> decisions about which kinds of users to optimize for.
> 
> In most UI/UX conversations (not necessarily here, but on the Net in
> general), most of the time people unconsciously say "user-friendly" as
> a synonym for "easy for newcomers to pick up quickly" -- without
> realizing that it also implies "tends not to reward sustained
> investment", since these two qualities inevitably trade off.
> 
> So if we characterize our users as "those who see, or who have the
> potential to see, the value of making a sustained investment in their
> text manipulation environment", *then* yes, by all means Emacs should
> be user-friendly.  But if we're saying "user-friendly" in the
> colloquial sense that most people use the term in, then no, I think it
> would be a mistake for Emacs to aim for that.

I agreed with that point when you made it earlier.

My point was that Emacs does have the quoted
"extreme user-friendliness" as a guiding principle,
even if it does not treat the quoted "friendly to
newcomers" as the highest priority.

And the difference involves just what you said:
Emacs users are not only, or even particularly,
newcomers.  Emacs tries hard to be friendly to its
users, and you've described its main users well.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 17 May 2020, Dmitry Gutov wrote:
>>> Are you sure that this particular aspect is _bad_ for new users, though?
>> Yes.  I am sure.
>> I've taught Emacs to a lot of people -- scores of them, at least; I
>> don't keep track, but the sample size is large enough to be beyond
>> merely anecdotal at this point.  I've watched newcomers run into the
>> same obstacles over and over, and this particular obstacle is always
>> one of the first they encounter.
>
>Okay, but is it still a problem after they've tried Emacs for a day,
>for instance? For a week?
>
>These periods of time would of course suggest Emacs is not ideal for
>total newbies, but they're not the kind of "sustained investment" you 
>described either.

The nature and variety of a newcomer's problems with Emacs depends a lot on how much coaching the newcomer is getting from someone with more experience.

But even with good coaching, it takes a long time for Emacs to become "worth it", by which I mean "better for that user than the J. Random Popular Text Editor they might have gone with instead".

>>> This part is expected of a professional tool, however, and the
>>> experience for newcomers could be improved without taking away much
>>> from the "oldies". See the 'transient' package, for example,
>>> recently proposed for inclusion on emacs-devel.
>> I don't have any experience using 'transient', so I'd need more
>> explanation from you to understand what you meant by that part.  (I
>> tried to understand 'transient' from reading [2] and [3], but
>> unfortunately -- and somewhat surprisingly! -- the documentation at
>> those pages does not give a single concrete example of transient's
>> use.)
>
>You press 'C-x', wait a while - and it pops up a window with the
>descriptions of all commands whose bindings start with 'C-x'. Same for 
>all other "incomplete" key sequences. Looks pretty handy for beginners.

Thanks for the explanation.  I haven't used it myself nor seen anyone else use it, so I don't feel confident in saying one way or the other whether it would help beginners.  Next time I'm teaching someone, maybe I should try it, though.

>> However, your assertion that "the experience for newcomers could be
>> improved without taking away much from the 'oldies'" is exactly what
>> I'm arguing is not true.  I actually think we can't (much) improve
>> this particular part of the experience for newcomers without taking
>> away one of the things about Emacs that most rewards investment.
>> The newcomers who eventually *do* become experts do so in part by
>> first stumbling across new commands accidentally (in that crowded
>> keybinding space) and then using help tools like `C-h l' to see what
>> they just did.  So one of the things we should prioritize is
>> teaching newcomers how important those help facilities are and how
>> to use them in a smart way.  I'm specifically saying that this is
>> *more important for Emacs than it is for other editors*.  Sure,
>> users of (say) the Atom editor should eventually know how to use the
>> built-in help there too.  But it's a difference in prioritization:
>> for Emacs users, using that built-in help is more important than it
>> would be in other editors, and the methods and circumstances of
>> using the help are different too.  So we should incorporate that
>> fact into how we present Emacs to new users.
>
>Yes, ok. Maybe this one is harder to improve that some others.

Thanks -- glad that helped.

>>> Some of them, probably. At this point, I think, there are still a lot
>>> of decisions that would bring us closer to newcomer-friendliness while
>>> keeping no worse high-investment compatibility.
>> That could be true, though I'm a bit more skeptical than you are.
>> In any case, it does not make the principle inoperative; it is
>> consistent with the principle.
>> I believe we'll make better decisions if we keep in mind that
>> "friendly to newcomers" is not, in itself, the primary goal.
>
>It's not like extreme user-friendliness was ever a guiding principle
>here. :-)

In another message I sent a moment ago, I replied to the above (via someone else who was quoting you), so I'll repeat that part of my response here:

  > While "friendly to newcomers" means something on its own,
  > "user-friendliness" only means something after one has characterized
  > the users in question.  That's the main point I've been trying to
  > make: that there is no such thing as a generic user, so we have to
  > make decisions about which kinds of users to optimize for.
  >
  > In most UI/UX conversations (not necessarily here, but on the Net in
  > general), most of the time people unconsciously say "user-friendly"
  > as a synonym for "easy for newcomers to pick up quickly" -- without
  > realizing that it also implies "tends not to reward sustained
  > investment", since these two qualities inevitably trade off.
  > 
  > So if we characterize our users as "those who see, or who have the
  > potential to see, the value of making a sustained investment in
  > their text manipulation environment", *then* yes, by all means Emacs
  > should be user-friendly.  But if we're saying "user-friendly" in the
  > colloquial sense that most people use the term in, then no, I think
  > it would be a mistake for Emacs to aim for that.

I wish that the first thing they would teach in UX school is to stop using the term "user-friendly" :-), much as medical professionals are (I'm told) taught to stop saying "throw it away" because there's no such thing as "away" in a hospital -- each kind of medical waste needs to be disposed of by a specific & suitable method.

>In this we're, again, similar to other professional software.

Well, I'm not sure exactly what "professional software" means in this context, but if it means "expects the user to make sustained investment", then I agree.

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 21.05.2020 01:00, Karl Fogel wrote:
>> In this we're, again, similar to other professional software.
> Well, I'm not sure exactly what "professional software" means in this context, but if it means "expects the user to make sustained investment", then I agree.

I don't know, Blender? Which has reportedly made some strides in 
usability lately. Other 3D editors and associated programs.

Advanced audio/video creativity software.

Re: GNU Emacs raison d'etre

[tomas]

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

On Thu, May 21, 2020 at 01:07:41AM +0300, Dmitry Gutov wrote:
> On 21.05.2020 01:00, Karl Fogel wrote:
> >>In this we're, again, similar to other professional software.
> >Well, I'm not sure exactly what "professional software" means in this context, but if it means "expects the user to make sustained investment", then I agree.
> 
> I don't know, Blender? Which has reportedly made some strides in
> usability lately. Other 3D editors and associated programs.

I keep seeing Blender mentioned here. One thing which should
be considered is that Blender was "born" 1994. At that time,
Emacs was around its 19th version and was already 18 -- so
allowed to drink (in some jurisdictions, that is).

So I'd expect a more complex community to have gathered around
Emacs by now.

Basically, I think the main "asset" [1] of a software project
to be it's community. Software can be written and can be thrown
away (and sometimes it's good to throw some software away, or
better, to stash it away for softwar archaeologists to have
fun fifty years from now). The longer a community lives, the
more complex it is to balance out continuity and innovation.

In my eyes, Emacs is doing an outstanding job on that.

Cheers

[1] I always hesitate to describe humans and groups of them
   as "assets". It's cold, cynical HR talk. So if you have
   a better shorthand for me, I'll adopt it Right Now.

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Emacs raison d'etre

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Thu, May 21, 2020 at 01:07:41AM +0300, Dmitry Gutov wrote:
>> On 21.05.2020 01:00, Karl Fogel wrote:
>> >>In this we're, again, similar to other professional software.
>> >Well, I'm not sure exactly what "professional software" means in this
>> > context, but if it means "expects the user to make sustained investment",
>> > then I agree.
>> 
>> I don't know, Blender? Which has reportedly made some strides in
>> usability lately. Other 3D editors and associated programs.
>
> I keep seeing Blender mentioned here. One thing which should
> be considered is that Blender was "born" 1994. At that time,
> Emacs was around its 19th version and was already 18 -- so
> allowed to drink (in some jurisdictions, that is).
There was an interview in Linux Format magazine, in January issue this
year, with Blender creator, which circled mostly about how Blender
turned into widely accepted professional 3D modelling/animation software
from being an obscure 3D package mostly ignored by professionals.
I recognized Emacs in Blender and posted here so now it is mentioned
here and there. You might get a copy of the issue, or find it on the
Internet, particlar interview is available to read for free, albeit the
website uses non-free javascript, so I'll not link to it here.

> So I'd expect a more complex community to have gathered around
> Emacs by now.
Why? :-)
>
> Basically, I think the main "asset" [1] of a software project
> to be it's community. Software can be written and can be thrown
> away (and sometimes it's good to throw some software away, or
> better, to stash it away for softwar archaeologists to have
> fun fifty years from now). The longer a community lives, the
> more complex it is to balance out continuity and innovation.
Indeed. But for anything to live long, it needs to adapt to changs, and
software/IT community changes rapidly. That seems to be basic law of
evolution. Emacs does not seem to adapt despite being super adaptable
software package so well. Is community big enough to be sustainable in
long term?
> In my eyes, Emacs is doing an outstanding job on that.
Personally I don't think Emacs will go extinct any time soon, neither,
but what will happen in next 40 years? Is it important though? But I
would like to see bigger community now so we get even more developers
and even better Emacs :-)

Re: GNU Emacs raison d'etre

[tomas]

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

On Thu, May 21, 2020 at 11:33:25AM +0200, Arthur Miller wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Thu, May 21, 2020 at 01:07:41AM +0300, Dmitry Gutov wrote:

[...]

> > So I'd expect a more complex community to have gathered around
> > Emacs by now.
> Why? :-)

Because people just don't die that quickly [1] ;-P

> > Basically, I think the main "asset" of a software project
> > to be it's community [...]

[...]

> Indeed. But for anything to live long, it needs to adapt to changs, and
> software/IT community changes rapidly.

Fads, I tell you [2] ;-P

> That seems to be basic law of
> evolution. Emacs does not seem to adapt despite being super adaptable
> software package so well. Is community big enough to be sustainable in
> long term?

> > In my eyes, Emacs is doing an outstanding job on that.

> Personally I don't think Emacs will go extinct any time soon, neither,
> but what will happen in next 40 years? Is it important though? But I
> would like to see bigger community now so we get even more developers
> and even better Emacs :-)

Yes -- and part of the job is, whenever there is a complex community,
discussing with them on what "better" means. And being prepared to
accept that there are other opinions.

Or forking. Both is OK. Heck, if you are careful about it, forking
hasn't to be hostile. And it can be productive, too (cf. XEmacs).

Cheers

[1] that was somewhat tongue-in-cheek. I am surprised that
   ask why a culture complexifies as it evolves.

[2] Of course an exaggeration too. But look back: 1980 it
   was OO all-over-the-place (Smalltalk was picking height).
   Then it culminated with Java (which I call the 2000's COBOL).
   Then it was Hindley-Milner. Now it is leftpad -- uh -- npm.
   Emacs has seen those come and go :-)
   The art (and you *never* know you'll succeed at that) is
   to pick up *some* of that.

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Emacs raison d'etre

[Arthur Miller]

tomas@tuxteam.de writes:

> On Thu, May 21, 2020 at 11:33:25AM +0200, Arthur Miller wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > On Thu, May 21, 2020 at 01:07:41AM +0300, Dmitry Gutov wrote:
>
> [...]
>
>> > So I'd expect a more complex community to have gathered around
>> > Emacs by now.
>> Why? :-)
>
> Because people just don't die that quickly [1] ;-P
>
>> > Basically, I think the main "asset" of a software project
>> > to be it's community [...]
>
> [...]
>
>> Indeed. But for anything to live long, it needs to adapt to changs, and
>> software/IT community changes rapidly.
>
> Fads, I tell you [2] ;-P
>
>> That seems to be basic law of
>> evolution. Emacs does not seem to adapt despite being super adaptable
>> software package so well. Is community big enough to be sustainable in
>> long term?
>
>> > In my eyes, Emacs is doing an outstanding job on that.
>
>> Personally I don't think Emacs will go extinct any time soon, neither,
>> but what will happen in next 40 years? Is it important though? But I
>> would like to see bigger community now so we get even more developers
>> and even better Emacs :-)
>
> Yes -- and part of the job is, whenever there is a complex community,
> discussing with them on what "better" means. And being prepared to
> accept that there are other opinions.
>
> Or forking. Both is OK. Heck, if you are careful about it, forking
> hasn't to be hostile. And it can be productive, too (cf. XEmacs).
>
> Cheers
>
> [1] that was somewhat tongue-in-cheek. I am surprised that
>    ask why a culture complexifies as it evolves.
>
> [2] Of course an exaggeration too. But look back: 1980 it
>    was OO all-over-the-place (Smalltalk was picking height).
>    Then it culminated with Java (which I call the 2000's COBOL).
>    Then it was Hindley-Milner. Now it is leftpad -- uh -- npm.
Njah, npm is already yesteryear :-)

>    Emacs has seen those come and go :-)
>    The art (and you *never* know you'll succeed at that) is
>    to pick up *some* of that.
Indeed, someone said once in some documentary about future, that only
thing we are sure about future is that it always looks differently from
anything we have thought it would look like.

By the way I was just reading some tech new today and I see MS is taking
terminals seroiusly: https://github.com/microsoft/terminal/releases

Seems like they have missed Emacs somehow.

Re: GNU Emacs raison d'etre

[xristos]

On Thu, 21 May 2020 11:33:25 +0200, 
Arthur Miller <arthur.miller@live.com> wrote:
> Indeed. But for anything to live long, it needs to adapt to changs, and
> software/IT community changes rapidly. That seems to be basic law of
> evolution. Emacs does not seem to adapt despite being super adaptable
> software package so well. Is community big enough to be sustainable in
> long term?

Emacs has lived long, hasn't it? It is certainly one of the longest-living
pieces of software that I use daily. This could mean that Emacs has adapted
well to changes in the field or that said changes were fads, not worth
adapting to. Either way, it seems the model that lies at the core of Emacs
has stood the test of time. 

>> In my eyes, Emacs is doing an outstanding job on that.
> Personally I don't think Emacs will go extinct any time soon, neither,
> but what will happen in next 40 years? 

No one can tell what will happen in the next 10 years, never mind 40.
It is a mistake to make decisions by working backwards from a hypothetical
projection rather than looking at the past and recognizing what has made
Emacs truly unique:

Its capacity to symbiotically [1] mold with the user and give raise to a
metasystem [2] that is much more than the sum of its parts. If Emacs has a
superpower, that is it.

> Is it important though? But I would like to see bigger community now so
> we get even more developers and even better Emacs :-)

That would be nice, but Emacs should not compromise on its core values in
order to achieve it. Emacs can not win going toe-to-toe with VSCode but
it can certainly shift the arena from not-quite feature parity with
fad-editor-of-the-decade [3] to doubling down on user-empowerment:

A lot of Emacs users, even old users, don't see Emacs as anything more than
an editor and haven't been exposed to the "moldable information processing
tool" way of thinking. This should be addressed by us doing everything we
can to shorten the time needed for a new user to first be fully exposed
to this paradigm and subsequently ignite the molding process.

I see João admit that he's not familiar with a lot of the C-h commands.
This is a problem that should be easy to fix. I've long seen the Emacs
tutorial as unnecessarily narrow-minded in its focus on text editing.
Richard mentioned a robot game but I suggest the tutorial be reworked
instead to be much more extensive. It should first lay out the models that
make Emacs powerful and then through exercises expose the user to said
models and reinforce the central paradigm.

That should include familiarization with all introspective commands,
configuration and customization, how buffers and processes work, and a
practical introduction to Emacs Lisp, including showing IELM and what one
can do inside it (e.g. Set working buffer).

I think this would go a long way towards letting users have a glimpse of
the possibilities on offer. Emacs has great manuals but either very few
newcomers read them or if they do, still don't get the big picture.
An interactive, hand-on approach would surely work better.

[1] https://groups.csail.mit.edu/medg/people/psz/Licklider.html

[2] https://xristos.sdf.org/why-emacs.txt

[3] That's not to say that Emacs should not provide VSCode features where
    it makes sense to do so. But the moment you start compromising on
    core values (e.g. providing a singular model that everyone should adopt
    and making alternatives hard or impossible to do) is when things start
    to go wrong since you're fighting the essence of what makes you great.
    I haven't so far seen anything here that makes me believe this will be
    the case but it's something to think about.

Re: GNU Emacs raison d'etre

[Arthur Miller]

xristos <xristos@sdf.org> writes:

> A lot of Emacs users, even old users, don't see Emacs as anything more than
> an editor and haven't been exposed to the "moldable information processing
> tool" way of thinking. This should be addressed by us doing everything we
> can to shorten the time needed for a new user to first be fully exposed
> to this paradigm and subsequently ignite the molding process.
Completely agree on that one!

> I see João admit that he's not familiar with a lot of the C-h commands.
> This is a problem that should be easy to fix. I've long seen the Emacs
> tutorial as unnecessarily narrow-minded in its focus on text editing.
> Richard mentioned a robot game but I suggest the tutorial be reworked
> instead to be much more extensive. It should first lay out the models that
> make Emacs powerful and then through exercises expose the user to said
> models and reinforce the central paradigm.
Yes, indeed,  you are onto something here. It would be nice if there
were different smaller tutorials, for example one for text, one for file
managing, one for email etc. I guess everybody could agree with that,
and probably only reason why it didn't happened yet is because somebody
actually have to produce those, which is not as trivial as it might
sound, I guess. There are some floating resources, tutorial-like blog
posts, some YT content etc. I don't know if Emacs could link to those
as extra resources etc.

When we already speak about tutorial, I think it could pick up shortcuts
uses have and automatically show those instead of saying something like
"default shortcut changed" or something similar, I don't remember any
more what it says. Is that very hard to do?

> That should include familiarization with all introspective commands,
> configuration and customization, how buffers and processes work, and a
> practical introduction to Emacs Lisp, including showing IELM and what one
> can do inside it (e.g. Set working buffer).
Yeah, a tutorial on help, a tutorial och semantic navigation, a tutorial
on remote editing, etc. A set of more focused shorter tutorials. But as
said I am affraid that the problem is that somebody has to put
voluntarily work into making this, which might take substantial time.

> I think this would go a long way towards letting users have a glimpse of
> the possibilities on offer.
Sure, I agree.

Re: GNU Emacs raison d'etre

[xristos]

On Sun, 24 May 2020 15:45:08 +0200, 
Arthur Miller <arthur.miller@live.com> wrote:
> Yes, indeed,  you are onto something here. It would be nice if there
> were different smaller tutorials, for example one for text, one for file
> managing, one for email etc. I guess everybody could agree with that,
> and probably only reason why it didn't happened yet is because somebody
> actually have to produce those, which is not as trivial as it might
> sound, I guess. There are some floating resources, tutorial-like blog
> posts, some YT content etc. I don't know if Emacs could link to those
> as extra resources etc.

It is important to stress the need for interactivity. Emacs is an
interactive environment and the existing tutorial -aptly- acknowledges
that by also being interactive. Emacs can link to hundreds of additional
resources that don't even come close to having the same impact a more
extensive, _interactive_ tutorial would.

> > That should include familiarization with all introspective commands,
> > configuration and customization, how buffers and processes work, and a
> > practical introduction to Emacs Lisp, including showing IELM and what one
> > can do inside it (e.g. Set working buffer).

> Yeah, a tutorial on help, a tutorial och semantic navigation, a tutorial
> on remote editing, etc. A set of more focused shorter tutorials. But as
> said I am affraid that the problem is that somebody has to put
> voluntarily work into making this, which might take substantial time.

I am bringing this up here to first determine if what I proposed resonates
with others and build some form of consensus. The necessary time & effort
investment can then be more easily justified.

Let me finish by saying that I've been using & programming Emacs daily
for more than a decade, but most of my observations are based on what
I see others come to #emacs on Freenode to ask questions about. It is my
understanding that very few newcomers read the -extensive- Emacs manuals
and even if they do, a lot of them still lack a basic understanding of
the fundamental models (buffers and processes) that Emacs is built on.
And these are the areas that I would suggest be included first (rather
than specialized areas like semantic navigation, remote editing which can
be added later).

It may be helpful to think of the tutorial as a programmable mode that
can be extended by additional libraries. That way, a library author can
provide a mini-tutorial for his library that plugs into Emacs's. But
let me stress that these are secondary considerations and that plenty of
low-hanging fruit can be plucked by simply extending the existing tutorial
to include material that covers the fundamental models of Emacs and provides
a simple interactive introduction to Emacs Lisp and IELM.

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: xristos <xristos@sdf.org>
> Date: Sun, 24 May 2020 12:52:04 -0400
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> 
> I am bringing this up here to first determine if what I proposed resonates
> with others and build some form of consensus. The necessary time & effort
> investment can then be more easily justified.

There's no need to wait for any consensus.  I'm telling you here and
now that any well-written tutorial on any subject related to using
Emacs will be very welcome.  It's just that writing a good tutorial is
an extremely hard and demanding job.

So if you or someone else have the time and the motivation, and think
you can produce a good tutorial on any of the related subjects, please
do, and thanks in advance.

Re: GNU Emacs raison d'etre

[Philip K.]

Arthur Miller <arthur.miller@live.com> writes:

> Yes, indeed,  you are onto something here. It would be nice if there
> were different smaller tutorials, for example one for text, one for file
> managing, one for email etc. I guess everybody could agree with that,
> and probably only reason why it didn't happened yet is because somebody
> actually have to produce those, which is not as trivial as it might
> sound, I guess. There are some floating resources, tutorial-like blog
> posts, some YT content etc. I don't know if Emacs could link to those
> as extra resources etc.

I find this very interesting, the built in tutorial is often seen as
boring, and I remember trying multiple times to get through it, most
after 10%-20%.

What might be interesting is to use child frames to only show what's
necessary, like many other programms do (highlighting what's
interesting, waiting for user interaction, etc.).

But that would require a kind of DSL or pseudo-DSL to "programm" these
interactive tutorials, unless one would want to manually write them out
for every topic. Might look something like this:

        (deftutorial window-managment "Window Managment"
          "A basic tutorial on window managment"
          :estemated-time "3m"
          :difficulty 'easy
          (show "This tutorial introduces the user to window managment")
          (wait)
          (show "Press \\[split-window-below] to split the current window.")
          (expect 'split-window-below)
          (show "Good! Now you can switch to that buffer with
 C-x o runs the \\[other-window].")
          ...)

where the user might later invoke a command like M-x introduce RET, and
choose "Window Managment" from a list of options. On the other hand, a
list-buffers like approach would be better, because the default
completion system can be unintuitive.

Ideally it might even be used by external packages to introduce user to
whatever it has to offer.

-- 
	Philip K.

Re: GNU Emacs raison d'etre

[João Távora]

xristos <xristos@sdf.org> writes:

> On Thu, 21 May 2020 11:33:25 +0200, 
> I see João admit that he's not familiar with a lot of the C-h commands.
> This is a problem that should be easy to fix. I've long seen the Emacs
> tutorial as unnecessarily narrow-minded in its focus on text editing.

Just caught my name here by accident and accurately cited :-) I just
wanted to add that I first encoutered the Emacs tutorial some 3/4 years
after I started using Emacs and it was a wonderful revelation: _that_
was the thing that made me remove all my "make emacs work like Eclipse"
configuration.  So, narrow-minded or not, pretty effective for me.  I
haven't done the tutorial in years... I do vaguely remember having fun
with it and wanting it to go on, but finding it pretty short.  As a
provocation, I wonder if more of that adventure-style interactive
tutorial wouldn't be the thing to bring those Spacemancs fanboys to
vanilla?

João

Re: GNU Emacs raison d'etre

[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. ]]]

  >   As a
  > provocation, I wonder if more of that adventure-style interactive
  > tutorial wouldn't be the thing to bring those Spacemancs fanboys to
  > vanilla?

I suggested a different sort of game-tutorial a week ago, where you
try to correct random errors in a text while a robot introduces them
and speeds up over time.

We could call it Text Invaders.

-- 
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: GNU Emacs raison d'etre

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> I suggested a different sort of game-tutorial a week ago, where you
> try to correct random errors in a text while a robot introduces them
> and speeds up over time.
>
> We could call it Text Invaders.

That's a nice idea.  A slower-passed classic adventure/charade where
there is an encrypted message in some piece of text could also be fun.
But writing these is hard (I for one wouldn't no where to start).

João

Re: GNU Emacs raison d'etre

[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 could call it Text Invaders.

  > That's a nice idea.  A slower-passed classic adventure/charade where
  > there is an encrypted message in some piece of text could also be fun.
  > But writing these is hard (I for one wouldn't no where to start).

Text Invaders should be easy.  You start with a buffer containing
suitable text.  Set up a timer that runs N times a second
and carries out one move for the invaders.

Every so often you reduce the timer interval a few percent,
so that the game gets harder.

As for the user, you don't have to do anything except switch to the buffer
in a window for the user to edit.
The user's "moves" are simply Emacs editing commands, executed as fast as the
user types them.

Delightfully simple!

The errors don't have to be random.  An invader could move over the
screen, introducing errors.  You eliminate it by moving point onto it.
Then you can fix the errors it has already inserted.

Lots of variations can be imagined.


-- 
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: GNU Emacs raison d'etre

[Drew Adams]

> The errors don't have to be random.  An invader could move over the
> screen, introducing errors.

A `dissociated-press' effect comes to mind...

Re: GNU Emacs raison d'etre

[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. ]]]
>
>   > > We could call it Text Invaders.
>
>   > That's a nice idea.  A slower-passed classic adventure/charade where
>   > there is an encrypted message in some piece of text could also be fun.
>   > But writing these is hard (I for one wouldn't no where to start).
>
> Text Invaders should be easy.  You start with a buffer containing
> suitable text.  Set up a timer that runs N times a second
> and carries out one move for the invaders.
>
> Every so often you reduce the timer interval a few percent,
> so that the game gets harder.
>
> As for the user, you don't have to do anything except switch to the buffer
> in a window for the user to edit.
> The user's "moves" are simply Emacs editing commands, executed as fast as the
> user types them.
>
> Delightfully simple!
>
> The errors don't have to be random.  An invader could move over the
> screen, introducing errors.  You eliminate it by moving point onto it.
> Then you can fix the errors it has already inserted.
>
> Lots of variations can be imagined.
That sounds like a cool idea.

There is also a game called Starcraft, which is a competitive RTS played
in tournaments nowadays, considered as a hardest to date RTS to play.
They have some mods/trainers for people to practice their game skills.
They have one such trainer for peopel to learn shortcuts in game, and
same idea might be usefull for Emacs maybe.

The game would shouw icons of some stuff to be created and poeple would
have to press the shortcut key for that structure/unit etc. It was as
well on a speeding timer and everything would go on for a certain amount
of time. After the complete period of time expired, say 2 minutes or so,
one was presented with a screen of total misses and hits.

I don't know if it is possible, but maybe Emacs could show name of
command to be invoked and user would have to press the associated
shortcut. The Emacs would have to pick whatever shortcut user have
defined. Maybe Emacs could show a sentence and a selected region and
user would have to kill/yank that region, divide window, do whatever
etc. Such tasks could circle with ever shorter timer for say about 2 - 5
minutes and at the end user would be presented with the score of hits &
misses. Could be even saved into a file as a "best score". Don't know if
that idea would work in Emacs, but it feels on a first thought like it
could be used to teach out Emacs terminology and some general global
shortcuts at least.

Re: GNU Emacs raison d'etre

[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
900 messages I have not yet seen.  I just saw your message today.

I think the Text Invaders idea leads to a wide space
of possible interpretations -- if you write it, you will have
lots of room to see what is fun.

Now all we need is someone (or someones) to give it a try.
Interested?


-- 
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: GNU Emacs raison d'etre

[Karl Fogel]

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

On 21 May 2020, tomas@tuxteam.de wrote:
>On Thu, May 21, 2020 at 01:07:41AM +0300, Dmitry Gutov wrote:
>> On 21.05.2020 01:00, Karl Fogel wrote:
>> >>In this we're, again, similar to other professional software.
>> >Well, I'm not sure exactly what "professional software" means in this context, but if it means "expects the user to make sustained investment", then I agree.
>> 
>> I don't know, Blender? Which has reportedly made some strides in
>> usability lately. Other 3D editors and associated programs.
>
>I keep seeing Blender mentioned here. One thing which should
>be considered is that Blender was "born" 1994. At that time,
>Emacs was around its 19th version and was already 18 -- so
>allowed to drink (in some jurisdictions, that is).

For those who would like to learn more about Blender's efforts to improve its usability for "professional" users -- in this case, helped by someone who is literally a professional user -- there's a Libre Lounge podcast episode that talks about this:

  https://librelounge.org/episodes/36-david-revoy-on-pepper--carrot-and-free-culture.html

The interviewee is David Revoy, author of the webcomic series "Pepper and Carrot".  (Our very own Christopher Lemmer Webber is one of the two co-hosts of this episode; the other is libre sofware/culture activist Serge Wroclawski.)

I'm not sure how the lessons there might apply to Emacs, but someone else might think of something I didn't.

Libre Lounge is, naturally, available in entirely Free audio formats (though, alas, I don't think there's a transcript available).

Best regards,
-Karl

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 21.05.2020 20:07, Karl Fogel wrote:
> For those who would like to learn more about Blender's efforts to improve its usability for "professional" users -- in this case, helped by someone who is literally a professional user -- there's a Libre Lounge podcast episode that talks about this:
> 
>    https://librelounge.org/episodes/36-david-revoy-on-pepper--carrot-and-free-culture.html

It's a pretty cool interview, but on the Blender side (or its evolution 
of the UI), it seems to covers less than the articles we've read previously.

Episode 38 is also pretty cool, but again it was more of a life 
story/basic community interaction discussion. If it has any lessons for 
Emacs, it's that it's good practice to watch your users and prioritize 
problems, and that the mailing lists are where the trolls are. :-)

Re: GNU Emacs raison d'etre

[tomas]

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

[not quoting, because mine is more of a general answer]

You made a very interesting set of points, spawning a good discussion.
Thanks!

The question is for whom you are building the software. At the end,
what you want to optimize is the system (stakeholder -- software).

In the case of Free Software, the stakeholder is (ideally!) the user;
in the case of commercial software, it's the buyer (who isn't
necessarily the user: think workplace surveillance). In the case
of "Internet freebie software" it's possibly the ad company, or
Palantir, or whoever. Not always the user, either.

Usually, you have a mixture of things people can't completely
agree over (think FSF's GPL: some think it needs that kind of
hack to copyright law to protect end user's freedom, some other
think end users to be strong enough to protect themselves [1].
So one stakeholder in the Gnu project becomes the FSF, the other
is the end user.

Now let's assume the ideal first case (stakeholder is user).
You want to find an optimum in that system. But the user is
a moving target! She learns. Is the system able to move along?
It's a complex optimization problem with a moving target!

Ideally, the software will entice the user to learn. Over time,
the state of new user population (their needs, their knowledge,
their preferences) changes as well.

We always will end up with many different "solutions" to this
optimization problem. Do you address the "new" user ("build to
sell")? Or the experienced user ("build to use")? The challenge
is to have some adaptability, but that's a very hard problem.
Some compromise will be necessary, as you noticed.

Cheers

[1] This meshes so deeply with other basic convictions that we're
   going to quibble over it for the rest of our lives :-)
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Emacs raison d'etre

[Andreas Röhler]

On 13.05.20 22:05, Karl Fogel wrote:
> On 13 May 2020, Andreas Röhler wrote:
>> Agree with everything beside two last paragraphs. Enjoying the
>> possibilities to extend and assisting new users being productive seems
>> no contradiction. May you give an example where an smooth entrance
>> hinders the power of more complex functionality?
> The newcomer-vs-expert tradeoff is real, and it's pervasive throughout UI and UX design.
>
> One example is button-based functionality.  For both experts and newcomers, those buttons/icons take away screen real estate -- but for newcomers they make features easier to find, so it's worth it.  For experts, they *just* take away screen real estate, while providing little or no benefit.
>
> Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.
>
> Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is *good* for experts, as we know from personal experience.
>
> I could go on.  I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are *good* for the experienced user.


Okay, thanks for the explanation. So we have two items - the way an 
intro is written and the real-case scenario WRT complexity and action.

For the latter Emacs already provides some caveats - disabling some 
commands at the beginning, which works fine. Your observations WRT 
errors of beginners might be of great value. Is there a way to collect 
these difficulties? Maybe the difference between a beginners state and 
advanced state might be extended?

Having a smooth introduction written by a didactically skilled person is 
another thing. IMHO exists not just a powerful tool but also some 
characteristic difficulties WRT beginners. The reason for the advantage 
as the disadvantage looks as the very same, it's mentioned in the 
founding tale of Emacs: exchanging code between developers.

Thanks all,

Andreas


>
> These design tradeoffs cannot be avoided.  It would be a fallacy to think that it's always possible to be *both* maximally newcomer-friendly and investor-friendly.
>
> (The term "user-friendly" is itself misleading.  There is no such thing as "a user" in a way that makes the term "user-friendly" meaningful.  Better terms would at least attempt to make important distinctions -- "newcomer-friendly", "expert-friendly", "ADHD-friendly", "limited-movement-friendly", "visually-impaired-friendly", etc -- and would encourage designers to understand that being good in some categories means being bad in others.)
>
> Best regards,
> -Karl
>

Re: GNU Emacs raison d'etre

[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. ]]]

  > Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.

We made this very simple a few years ago: Just keep typing C-g.
I guess these users don't know that.

Can anyone thing of a better way to teach them about this?
It could teach them first about the minibuffer, then about C-g
to get out.  It could copy the current minibuffer prompt
into the help screen to make the explanation clearer.

The tricky part is how to detect when a user could use this help.

-- 
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: GNU Emacs raison d'etre

[Tak Kunihiro]

>> Another area is the keybinding space and the minibuffer.  Just
>> about every time I have watched a new user use Emacs, I have noticed
>> how frequently they accidentally hit some key combination or sequence
>> and wind up in some weird state that they never meant to be in -- and
>> don't know how to get out of.
>
> We made this very simple a few years ago: Just keep typing C-g.
> I guess these users don't know that.
>
> Can anyone thing of a better way to teach them about this?

How about to click somewhere in main-buffer area to get him out of the
state and say `type C-g next time'?

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Date: Sat, 16 May 2020 09:56:30 +0900
> Cc: Karl Fogel <kfogel@red-bean.com>, tkk@misasa.okayama-u.ac.jp,
>  andreas.roehler@online.de, emacs-devel@gnu.org
> 
> > We made this very simple a few years ago: Just keep typing C-g.
> > I guess these users don't know that.
> >
> > Can anyone thing of a better way to teach them about this?
> 
> How about to click somewhere in main-buffer area to get him out of the
> state and say `type C-g next time'?

That would disable a very useful feature, whereby clicking somewhere
else leaves the minibuffer active and allows you to do something else
temporarily.  I also believe it might break scrolling by clicking on
the scroll bars or other similar mouse gestures, while the minibuffer
is active, or at least make the implementation of those gestures
harder.

It is also not something users will expect: AFAIK other GUI
applications allow you to clock the mouse anywhere without losing the
context of the current prompt.

Re: GNU Emacs raison d'etre

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tak Kunihiro <homeros.misasa@gmail.com>
>> Date: Sat, 16 May 2020 09:56:30 +0900
>> Cc: Karl Fogel <kfogel@red-bean.com>, tkk@misasa.okayama-u.ac.jp,
>>  andreas.roehler@online.de, emacs-devel@gnu.org
>> 
>> > We made this very simple a few years ago: Just keep typing C-g.
>> > I guess these users don't know that.
>> >
>> > Can anyone thing of a better way to teach them about this?
>> 
>> How about to click somewhere in main-buffer area to get him out of the
>> state and say `type C-g next time'?
>
> That would disable a very useful feature, whereby clicking somewhere
> else leaves the minibuffer active and allows you to do something else
> temporarily.

And here there are 2 more problems for newbies. They usually expect
pop-up /modal/ dialog to be thrown on them for anything but text input
or moving around. So, first, they miss minibuffer prompts entirely, and
then get to recursive editing all the time, unintentionally.

I'm not sure if it makes sense to implement "pop-up dialog minibuffer"
mode for newbies though, and then if it makes sense to (optionally?)
make it modal.

Yet another way to help would be making minibuffer modal by default.

-- Sergey

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Sat, 16 May 2020 12:10:25 +0300
> Cc: rms@gnu.org, andreas.roehler@online.de, emacs-devel@gnu.org,
>  kfogel@red-bean.com, Tak Kunihiro <homeros.misasa@gmail.com>,
>  tkk@misasa.okayama-u.ac.jp
> 
> And here there are 2 more problems for newbies. They usually expect
> pop-up /modal/ dialog to be thrown on them for anything but text input
> or moving around.

That happens in Emacs for some/many commands invoked via the menu bar.

Re: GNU Emacs raison d'etre

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Sat, 16 May 2020 12:10:25 +0300
>> Cc: rms@gnu.org, andreas.roehler@online.de, emacs-devel@gnu.org,
>>  kfogel@red-bean.com, Tak Kunihiro <homeros.misasa@gmail.com>,
>>  tkk@misasa.okayama-u.ac.jp
>> 
>> And here there are 2 more problems for newbies. They usually expect
>> pop-up /modal/ dialog to be thrown on them for anything but text input
>> or moving around.
>
> That happens in Emacs for some/many commands invoked via the menu bar.

Then this must be rather easy to achieve for keyboard induced commands
as well.

-- Sergey

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Sat, 16 May 2020 15:24:33 +0300
> Cc: rms@gnu.org, andreas.roehler@online.de, emacs-devel@gnu.org,
>  kfogel@red-bean.com, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp
> 
> >> And here there are 2 more problems for newbies. They usually expect
> >> pop-up /modal/ dialog to be thrown on them for anything but text input
> >> or moving around.
> >
> > That happens in Emacs for some/many commands invoked via the menu bar.
> 
> Then this must be rather easy to achieve for keyboard induced commands
> as well.

Not really.  When the user invokes a command from the menu, we have a
clear signal that the mouse is being used, and therefore can display a
GUI dialog without fear.  But when the user types "C-x C-f", how can
we know that he/she expects a dialog box and not a minibuffer prompt?

Re: GNU Emacs raison d'etre

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Sat, 16 May 2020 15:24:33 +0300
>> Cc: rms@gnu.org, andreas.roehler@online.de, emacs-devel@gnu.org,
>>  kfogel@red-bean.com, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp
>> 
>> >> And here there are 2 more problems for newbies. They usually expect
>> >> pop-up /modal/ dialog to be thrown on them for anything but text input
>> >> or moving around.
>> >
>> > That happens in Emacs for some/many commands invoked via the menu bar.
>> 
>> Then this must be rather easy to achieve for keyboard induced commands
>> as well.
>
> Not really.  When the user invokes a command from the menu, we have a
> clear signal that the mouse is being used, and therefore can display a
> GUI dialog without fear.  But when the user types "C-x C-f", how can
> we know that he/she expects a dialog box and not a minibuffer prompt?

My argument was that newbie never wants minibuffer prompt, so this is
not an issue. I mean it'd always be dialog unless "newbie-mode" is
turned off.

-- Sergey

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 16.05.2020 15:34, Sergey Organov wrote:
>>>>> And here there are 2 more problems for newbies. They usually expect
>>>>> pop-up/modal/  dialog to be thrown on them for anything but text input
>>>>> or moving around.
>>>> That happens in Emacs for some/many commands invoked via the menu bar.
>>> Then this must be rather easy to achieve for keyboard induced commands
>>> as well.
>> Not really.  When the user invokes a command from the menu, we have a
>> clear signal that the mouse is being used, and therefore can display a
>> GUI dialog without fear.  But when the user types "C-x C-f", how can
>> we know that he/she expects a dialog box and not a minibuffer prompt?
> My argument was that newbie never wants minibuffer prompt, so this is
> not an issue. I mean it'd always be dialog unless "newbie-mode" is
> turned off.

My anecdata shows otherwise: it's never been a problem personally.

As for the newbies who want modal dialogs, surely they will use the 
mouse and the toolbar to invoke the corresponding commands?

Re: GNU Emacs raison d'etre

[Sergey Organov]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 16.05.2020 15:34, Sergey Organov wrote:
>>>>>> And here there are 2 more problems for newbies. They usually expect
>>>>>> pop-up/modal/  dialog to be thrown on them for anything but text input
>>>>>> or moving around.
>>>>> That happens in Emacs for some/many commands invoked via the menu bar.
>>>> Then this must be rather easy to achieve for keyboard induced commands
>>>> as well.
>>> Not really.  When the user invokes a command from the menu, we have a
>>> clear signal that the mouse is being used, and therefore can display a
>>> GUI dialog without fear.  But when the user types "C-x C-f", how can
>>> we know that he/she expects a dialog box and not a minibuffer prompt?
>> My argument was that newbie never wants minibuffer prompt, so this is
>> not an issue. I mean it'd always be dialog unless "newbie-mode" is
>> turned off.
>
> My anecdata shows otherwise: it's never been a problem personally.

What exactly? Failure to notice Emacs suddenly asking you for something
in the minibuffer? I see it very often.

Rarely newbies look at the bottom of the screen/frame when cursor is
suddenly gone, even after some training. The most frequent instinct I
see is clicking with the mouse at the position on the screen where they
want cursor to be.

Here is an example:

1. Type C-x b (imitation of accident keystroke)
2. Click with the mouse _here_
3. In the menu click "Edit | Go To | Goto Line"

Result? For me it's:

completing-read-default: Command attempted to use minibuffer while in minibuffer

error message that, besides, is again being output into minibuffer
place, that for me even was immediately overwritten by a help string on
a lisp variable as I was doing it in the *scratch*.

Will any newbie be able to tell why this menu item suddenly didn't work
as expected? I'd rather afraid they may think Emacs is buggy and
unreliable. 

>
> As for the newbies who want modal dialogs, surely they will use the
> mouse and the toolbar to invoke the corresponding commands?

This is unrelated to the context of the suggestion.

Please recall that the problem being discussed is /accidental/
invocation of a command by a keystroke that brings newbie to minibuffer
that she often doesn't even notice! If Emacs rather threw big shiny
dialog into his face (even if only displaying this same minibuffer in
it), it'd leave the newbie little chances to remain ignorant.

In fact, many "expert" commands already do something like this, asking
to be explicitly enabled. This is not that helpful for complete newbies
though as the prompt still uses the minibuffer that newbies often forget
to pay attention to in the first place.

-- Sergey

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 16.05.2020 16:57, Sergey Organov wrote:

>> My anecdata shows otherwise: it's never been a problem personally.
> 
> What exactly? Failure to notice Emacs suddenly asking you for something
> in the minibuffer? I see it very often.

Yes. I _have_ had problems reading the minibuffer's contents, however, 
on a few occasions.

> Rarely newbies look at the bottom of the screen/frame when cursor is
> suddenly gone, even after some training. The most frequent instinct I
> see is clicking with the mouse at the position on the screen where they
> want cursor to be.
> 
> Here is an example:
> 
> 1. Type C-x b (imitation of accident keystroke)
> 2. Click with the mouse _here_
> 3. In the menu click "Edit | Go To | Goto Line"
> 
> Result? For me it's:
> 
> completing-read-default: Command attempted to use minibuffer while in minibuffer
> 
> error message that, besides, is again being output into minibuffer
> place, that for me even was immediately overwritten by a help string on
> a lisp variable as I was doing it in the *scratch*.
> 
> Will any newbie be able to tell why this menu item suddenly didn't work
> as expected? I'd rather afraid they may think Emacs is buggy and
> unreliable.

Fair enough. But in the end, you're probably asking for something that 
doesn't exist in Emacs yet. Like, no graphical switches for buffers 
that's equal in power to the minibuffer-based one.

I agree that the prompts could be positioned better, and the result 
could be better readability. After all, if one uses the minibuffer a 
lot, isn't it a shame that it resides somewhere down below, and uses the 
same font as the rest of Emacs?

In that, I think VS Code, Atom, etc, have a better idea by positioning 
their input area somewhere near the top of the window, in an easy-to-see 
dropdown. Somewhere in the middle of the frame could also work.

If you like, try out https://github.com/honmaple/emacs-maple-minibuffer/ 
with (setq maple-minibuffer:position-type 'frame-top-center) or 
'frame-center.

I'd like to see Emacs something like this by default someday.

> This is unrelated to the context of the suggestion.
> 
> Please recall that the problem being discussed is /accidental/
> invocation of a command by a keystroke that brings newbie to minibuffer
> that she often doesn't even notice! If Emacs rather threw big shiny
> dialog into his face (even if only displaying this same minibuffer in
> it), it'd leave the newbie little chances to remain ignorant.
> 
> In fact, many "expert" commands already do something like this, asking
> to be explicitly enabled. This is not that helpful for complete newbies
> though as the prompt still uses the minibuffer that newbies often forget
> to pay attention to in the first place.

I see where you're coming from, but I think the minibuffer is too large 
a part of Emacs UI to shield the newbies from it like that.

Or at least, the above would be a better solution, by improving 
minibuffer's usability for both newbies and existing users.

Re: GNU Emacs raison d'etre

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Fair enough. But in the end, you're probably asking for something that
> doesn't exist in Emacs yet. Like, no graphical switches for buffers
> that's equal in power to the minibuffer-based one.

Which capabilities are you referring to more exactly here?  I'm not too
familiar with the details, so please forgive me if this is obvious.

> I agree that the prompts could be positioned better, and the result
> could be better readability. After all, if one uses the minibuffer a
> lot, isn't it a shame that it resides somewhere down below, and uses the
> same font as the rest of Emacs?

I have never thought about it, but I personally think it's a very good
idea.  In combination with that, simple changes like giving it a border
or a different background, would also help make it more visible.

One frequent annoyance for me in more "modern" software is that the
popups hide the thing they are about.  For example, a "Search and
replace" dialog box positioned on top of the text it matches, so you
have to manually move the dialog box around to see what you're doing.
I think we should try to avoid that, at least by default, so maybe the
top positioning is a better default than in the center.

> In that, I think VS Code, Atom, etc, have a better idea by positioning
> their input area somewhere near the top of the window, in an easy-to-see
> dropdown. Somewhere in the middle of the frame could also work.

I have never used them.  Do you mean something like this (found on a
quick search)?

https://flight-manual.atom.io/using-atom/images/goto.png

Or could you provide a better screenshot or video of that?

> I'd like to see Emacs something like this by default someday.
[...]
> Or at least, the above would be a better solution, by improving
> minibuffer's usability for both newbies and existing users.

Agreed.

Best regards,
Stefan Kangas

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 16.05.2020 23:05, Stefan Kangas wrote:
> Which capabilities are you referring to more exactly here?  I'm not too
> familiar with the details, so please forgive me if this is obvious.

Switching between buffers using a mouse. Well, I mean, we do have a menu 
for that, but... Is that really better than fuzzy matching in the 
minibuffer?

OTOH, we don't have fuzzy matching by default either. Hmm.

> I have never thought about it, but I personally think it's a very good
> idea.  In combination with that, simple changes like giving it a border
> or a different background, would also help make it more visible.

Yup.

> One frequent annoyance for me in more "modern" software is that the
> popups hide the thing they are about.  For example, a "Search and
> replace" dialog box positioned on top of the text it matches, so you
> have to manually move the dialog box around to see what you're doing.
> I think we should try to avoid that, at least by default, so maybe the
> top positioning is a better default than in the center.

It could probably be configurable with little effort.

One big improvement I expect from such a feature personally is no more 
jumping of windows when the minibuffer goes multiline.

> I have never used them.

I install them occasionally, to see how things change over time.

> Do you mean something like this (found on a
> quick search)?
> 
> https://flight-manual.atom.io/using-atom/images/goto.png
> 
> Or could you provide a better screenshot or video of that?

Some other examples:

https://code.visualstudio.com/assets/docs/editor/editingevolved/symbol.png

Or: https://yann-leguilly.gitlab.io/img/no-member_vs_code/settings.webp

Or: 
https://vscode.rocks/static/fe22cb8c64e112b3acd1b9e6595bc498/0d2bd/file_search.png

Re: GNU Emacs raison d'etre

[Bob Newell]

Aloha everyone,

I'm getting into this a bit late, but I have a slightly
contrarian view.

I certainly agree with the idea that Emacs is a tool that,
like all serious and complex tools, requires effort, and a
measure of how good the tool is can be found in how well the
effort is rewarded. With Emacs my experience has been that the
rewards are enormous, even if the effort involved is certainly
non-trivial. But is there any high-caliber tool (in any field of
endeavor) that doesn't require effort to master?

But let me contradict myself a little. I have been using Emacs
literally for decades, and have not "mastered" it, in the
sense that while I have what are to me sophisticated use
cases, I learn new things all the time. That is a tribute to
the power and depth of Emacs, and I consider this a positive
feature--- I'm always learning new ways to get even more out
of the tool. So, does Emacs take a day or three weeks or four
months or years to "master"? It should be an ongoing, layered
experience.

The difficulty here for newcomers (as I have alluded to in
other threads) is the current "instant gratification"
mentality: the attitude that if I can't get into something
quickly and with minimal effort, I'm not interested.

I first learned Emacs through the tutorial. If a newcomer were
to spend a couple of hours with the tutorial, basic usage
would be immediately possible and there would be an enticing
glimpse of things to come. I was at least minimally productive
with Emacs within part of an afternoon. Is that good enough? I
think so, but it does require a least some willingness to
branch out into the unfamiliar.

A week later, I could do more things. A year later, I could do
a lot of things. Decades later, it's an indispensible tool
with "killer" features such as org-mode and (yes!) gnus
... and as I said above, there are always new things.

If newcomers could be enticed with a layered approach, I think
some of them, at least the ones for whom Emacs is long-term
suitable, may see the advantages and follow the path; and long
though it may be, they will be increasingly more productive
along the way. This implies more tutorials, organized in this
layered manner. It's important, though, to be able to do the
basics in a relatively short time. But that's already possible.

The existing tutorial in fact does really cover the
essentials. The "must-know" features (after learning how to
move the cursor and so on) are C-g and 'undo'. Learn those and
you can always get out of a spot; and the tutorial is very
clear on this.

Now here's the contrarian part: Emacs uses different
terminology, different keybindings, and an overall different
approach from many Unix tools and certainly from Windows
tools. Should we (optionally for newcomers) change that?

I say 'no' and the reason is that from the get-go, I think
potential new users should understand that Emacs is different,
is built on a different paradigm, and does things in a
different way. In the long run, it's embracing these
differences that makes Emacs the tool that it is.

I'd submit that if the differences fatally deter a newcomer,
then perhaps that newcomer was never an Emacs candidate. And
I'll add my usual disclaimer: I do /not/ view Emacs as a tool
for some sort of snobbish elite to which you gain entrance
only through initiation rites and having the proper
pedigree. Emacs, in fact, is a tool for anyone who is willing
to invest in it.

Finally, as a sort of illustrative footnote: there is a
terminal-based text editor called "Fe, the folding editor"
written long ago by Michael Haart (moria.de). It isn't well
know and isn't in any Gnu-Linux distros that I'm aware of. It
is really a minimalist (non-extensible) Emacs to the extent
that it uses Emacs keybinding and contains just enough
essential features (like keyboard macros) to make it very
useful for many text editing use cases. It more or less
represents the level of productivity I had achieved after maybe
a couple of days with Emacs way back when. But that is an
amazingly useful amount.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: GNU Emacs raison d'etre

[Ricardo Wurmus]

Bob Newell <bobnewell@bobnewell.net> writes:

> Finally, as a sort of illustrative footnote: there is a
> terminal-based text editor called "Fe, the folding editor"
> written long ago by Michael Haart (moria.de). It isn't well
> know and isn't in any Gnu-Linux distros that I'm aware of.

It’s available in GNU Guix.

-- 
Ricardo

RE: GNU Emacs raison d'etre

[Drew Adams]

> > I agree that the prompts could be positioned better,
> > and the result could be better readability. After all,
> > if one uses the minibuffer a lot, isn't it a shame
> > that it resides somewhere down below, and uses
> > the same font as the rest of Emacs?
> 
> I personally think it's a very good idea.
> In combination with that, simple changes like
> giving it a border or a different background, 
              ^^^^^^                ^^^^^^^^^^
> would also help make it more visible.

FWIW, I use a separate minibuffer frame, which extends
across the bottom of the screen (by default - size &
position configurable).

I took this idea from Epoch back in the mid-90s.  The
fact that Emacs doesn't provide this as an option out
of the box, I've always thought is too bad.  (Epoch
had other UI innovations, but that's the one I missed
most when I went back to GNU Emacs.)

As a separate frame, `minibuffer-frame-alist' applies,
which includes its own default font (size, color) and
background color.  And as a frame, it has a border.
(By default, the text is larger, and red.)

Wrt positioning, one option is for moving the frame
so it's positioned near point whenever the minibuffer
is activated:

 1on1-move-minibuffer-frame-near-point is a variable
 defined in `oneonone.el'.  Its value is nil

 Documentation:
 Whether to move `1on1-minibuffer-frame' near point, and just where.

 * nil means do not move it.  

 * A single whole number, Y, means offset `top' by Y pixels from point.
   The `left' frame position is unchanged.  As always, positive is
   down (below point), negative is up (above point).

 * A cons of two whole numbers, (X . Y), means offset `left' by X and
   `top' by Y pixels from point.

   For example, (-200 . 30) moves the top left frame corner 200 pixels
   to the left and 30 pixels below point.  This option has no effect if
   `1on1-minibuffer-frame' is nil.

Personally, I prefer the default behavior, of remaining
at the bottom of the screen.  In particular, that way
it doesn't interfere with any Emacs content, anywhere.

> One frequent annoyance for me in more "modern" software
> is that the popups hide the thing they are about.

Exactly - see previous paragraph.  But I can understand
that, at least for some simple interactions, some users
like it.

That's also a problem in general for any popup frame,
whether for completions, info/help, whatever.  Some
DWIM can be applied, but the problem is inherent: how
to know just what is the most noticeable and near the
previous focus of attention, and simultaneously avoids
obscuring the info the user currently cares about.

Beyond letting users configure such behavior to some
extent, and giving some programmed positioning a bit
of "intelligence", giving users quick, keyboard, ways
to move frames around on the fly can help.

> so maybe the top positioning is a better default than
> in the center.

Top positioning has either the same problem as near
point (your annoyance: obscuring info) or the same
problem as bottom-positioning.

With my setup, other frames can be automatically
resized to fit their content, by default, in which
case they never overlap the minibuffer frame when it
stays put (e.g. at screen bottom).  (Auto-fitting of
frames can take a stay-put standalone minibuffer
frame into account, in effect reducing the available
screen space to exclude it.)

The problem with a minibuffer that stays put is that
it can be far from where your eye might currently be
focused.  That's more of a problem for the echo area
than the minibuffer, perhaps, because for the latter
you're anyway expecting to change your attention to it.

For a newbie, I think that having a separate frame,
with larger and more noticeable text takes care of
the problem of not being aware of the minibuffer or
echo-area messages - not knowing where to look or
what's expected of you.

In addition, with my setup the minibuffer frame
background changes hue slightly (configurable) when
it's active (and for each recursive minibuffer), and
also when Isearch is active.  That too helps draw
attention to it, and lets you know the interaction
status/expectation.

https://www.emacswiki.org/emacs/Dedicated_Minibuffer_Frame

Finally, although recursive editing is disabled by
default, to protect the innocent, I think it's
underappreciated as a feature. The main problem with
it is, once again, not being aware that you're in a
recursive edit - which interaction level you're on.
To help with that I have library `rec-edit.el'.  It
highlights the mode-line [[...]] indication, to make
it clear when you're in a recursive edit, and what
level it is.

https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el

RE: GNU Emacs raison d'etre

[Drew Adams]

I meant to mention to that with a standalone
minibuffer frame you don't need a minibuffer
on any other frames (duh).

More importantly than saving screen real estate,
that means (assuming it stays put) that you have
one single, stable place to interact with, not N
places for N frames, any of which can have the
input focus.

RE: GNU Emacs raison d'etre

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I use a separate minibuffer frame, which extends
> across the bottom of the screen (by default - size &
> position configurable).

I'm not convinced frames would be the best technical solution, since
they have to be handled by window managers.  And that invites headaches,
not least when you add things like tiling window managers into the mix.

> Personally, I prefer the default behavior, of remaining
> at the bottom of the screen.

Same here.  But maybe I could be convinced to try something else if it
was done well.

> Top positioning has either the same problem as near
> point (your annoyance: obscuring info) or the same
> problem as bottom-positioning.

Agreed.  Top positioning might be better for other reasons though.

But I suppose this is all academic until Someone™ writes some code.

Best regards,
Stefan Kangas

RE: GNU Emacs raison d'etre

[Drew Adams]

> > FWIW, I use a separate minibuffer frame, which extends
> > across the bottom of the screen (by default - size &
> > position configurable).
> 
> I'm not convinced frames would be the best technical solution,
> since they have to be handled by window managers.  And that
> invites headaches, not least when you add things like tiling
> window managers into the mix.

So Emacs shouldn't offer such a choice (OOTB) for
the many window managers (most?) that are capable
of putting a minibuffer frame at the bottom of
your screen?

Epoch (just another Emacs) did this, out of the
box, in the early 90s.  30 years ago.  And with
no hoops to jump through (such as I jump through
to get a semblance of that behavior with GNU Emacs).

> > Top positioning has either the same problem as near
> > point (your annoyance: obscuring info) or the same
> > problem as bottom-positioning.
> 
> Agreed.  Top positioning might be better for other
> reasons though.

What reasons?  The argument that a minibuffer at
the bottom of each frame is too far away from
point applies equally to top of frame, no?
Likewise, bottom of screen and top of screen.

In any case, most window mgrs that can put a
minibuffer frame at the bottom of the screen
can, I'm guessing, put it at the top instead.

RE: GNU Emacs raison d'etre

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> So Emacs shouldn't offer such a choice (OOTB) for
> the many window managers (most?) that are capable
> of putting a minibuffer frame at the bottom of
> your screen?

I wouldn't be against having the minibuffer in a frame as optional
behaviour.

>> Agreed.  Top positioning might be better for other
>> reasons though.
>
> What reasons?

Well, a visual hierarchy usually starts at the top.  For example when
you read a book, a newspaper or browse the web.

There have been studies on eye-tracking on web pages, which show that
people generally start reading at the top left.

But I'm not an expert at UI design, so please take my opinion with a
grain of salt.  Maybe someone who took the time to study the question in
earnest could come up with a better answer.

Best regards,
Stefan Kangas

RE: GNU Emacs raison d'etre

[Drew Adams]

> >> Agreed.  Top positioning might be better for other
> >> reasons though.
> >
> > What reasons?
> 
> Well, a visual hierarchy usually starts at the top.  For example when
> you read a book, a newspaper or browse the web.

What does that have to do with minibuffer
and echo-area interaction?

> There have been studies on eye-tracking on web
> pages, which show that people generally start
> reading at the top left.

Yes, they do (at least in a left-to-right
language/culture).  But what does that have to
do with where the minibuffer is placed?

Do you start with the minibuffer and then read
farther down or farther ahead through some
hierarchy?  I don't think so.  If you did, then
I imagine it would indeed be up top-left.

The minibuffer real estate is also used for the
echo area.  (Doesn't have to be, but in some ways
that's "natural" - especially makes sense when an
Emacs<->user dialog is involved.)

Having status and error messages at the bottom is
pretty common, and not just in editors.  It may
be less common to also have an input field there.

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 17, 2020, at 15:49, Drew Adams <drew.adams@oracle.com> wrote:
> 
> Having status and error messages at the bottom is
> pretty common, and not just in editors.

But is that a decision based on cognitive studies or on technical limitations when the solution was implemented ?

> It may be less common to also have an input field there.

FWIW, the macos equivalent to the minibuffer is a "frame" that you can move freely around the screen.



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

RE: GNU Emacs raison d'etre

[Drew Adams]

> > It may be less common to also have an input field there.
> 
> FWIW, the macos equivalent to the minibuffer is a "frame" that you can
> move freely around the screen.

In Emacs too the minibuffer can be a frame
that you can move freely around the screen.

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 17, 2020, at 16:11, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> It may be less common to also have an input field there.
>> 
>> FWIW, the macos equivalent to the minibuffer is a "frame" that you can
>> move freely around the screen.
> 
> In Emacs too the minibuffer can be a frame
> that you can move freely around the screen.

I mean in macos it *is*. By default. I would love to have a similar feature by default in emacs.

Btw, I tried emacs-maple-minibuffer earlier today and there must be an issue with my configuration because I had remnants of windows in the desktop file that would float over my frames and just would not go away even after a restart. I had to manually edit the desktop file to make them go away, plus the echo area was not handled by the new windows so I had a minibuffer floating window and the echo remained at the bottom of the frame. It was confusing. But that's a different subject...


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

Re: GNU Emacs raison d'etre

[Marcin Borkowski]

On 2020-05-17, at 11:07, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:

>> On May 17, 2020, at 16:11, Drew Adams <drew.adams@oracle.com> wrote:
>> 
>>>> It may be less common to also have an input field there.
>>> 
>>> FWIW, the macos equivalent to the minibuffer is a "frame" that you can
>>> move freely around the screen.
>> 
>> In Emacs too the minibuffer can be a frame
>> that you can move freely around the screen.
>
> I mean in macos it *is*. By default. I would love to have a similar feature by default in emacs.

FWIW, I would absolutely hate it as the default, since window managers
are in general worse at managing Emacs frames than Emacs is at managing
its windows.

Though of course, if it were made the default, I wouldn't mind so much,
because I'd instantly turn it off.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 17, 2020, at 19:20, Marcin Borkowski <mbork@mbork.pl> wrote:
> 
> 
> On 2020-05-17, at 11:07, Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
>>> On May 17, 2020, at 16:11, Drew Adams <drew.adams@oracle.com> wrote:
>>> 
>>>>> It may be less common to also have an input field there.
>>>> 
>>>> FWIW, the macos equivalent to the minibuffer is a "frame" that you can
>>>> move freely around the screen.
>>> 
>>> In Emacs too the minibuffer can be a frame
>>> that you can move freely around the screen.
>> 
>> I mean in macos it *is*. By default. I would love to have a similar feature by default in emacs.
> 
> FWIW, I would absolutely hate it as the default, since window managers
> are in general worse at managing Emacs frames than Emacs is at managing
> its windows.
> 
> Though of course, if it were made the default, I wouldn't mind so much,
> because I'd instantly turn it off.

Indeed. I'm just thinking of the device as a thing to be packaged in emacs for easy triggering by newcomers, or something like this.


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

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 17 May 2020 18:07:54 +0900
> Cc: Richard Stallman <rms@gnu.org>,
>  Andreas Röhler <andreas.roehler@online.de>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Karl Fogel <kfogel@red-bean.com>,
>  homeros.misasa@gmail.com,
>  tkk@misasa.okayama-u.ac.jp,
>  Sergey Organov <sorganov@gmail.com>,
>  Stefan Kangas <stefankangas@gmail.com>,
>  Dmitry Gutov <dgutov@yandex.ru>,
>  Eli Zaretskii <eliz@gnu.org>
> 
> I mean in macos it *is*. By default. I would love to have a similar feature by default in emacs.

This happens on macOS because that's what users of that system
expect.  I don't think we should follow that on all the other
platforms.

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 18, 2020, at 0:25, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Sun, 17 May 2020 18:07:54 +0900
>> Cc: Richard Stallman <rms@gnu.org>,
>> Andreas Röhler <andreas.roehler@online.de>,
>> Emacs developers <emacs-devel@gnu.org>,
>> Karl Fogel <kfogel@red-bean.com>,
>> homeros.misasa@gmail.com,
>> tkk@misasa.okayama-u.ac.jp,
>> Sergey Organov <sorganov@gmail.com>,
>> Stefan Kangas <stefankangas@gmail.com>,
>> Dmitry Gutov <dgutov@yandex.ru>,
>> Eli Zaretskii <eliz@gnu.org>
>> 
>> I mean in macos it *is*. By default. I would love to have a similar feature by default in emacs.
> 
> This happens on macOS because that's what users of that system
> expect.

? No. macos users don't expect a floating kind of system "minibuffer". That's actually unlike the rest of macos UI. But it happens to exist (that's "Spotlight" in case you want to know and it is an *extremely* limited "minibuffer", by emacs standards.)

I was just mentioning that vs Drew's "in emacs the mini buffer *can* be in a frame". Because *that* requires a lot of manually installing packages that he refers to here:

https://www.emacswiki.org/emacs/OneOnOneEmacs

Which seems to be very nice, by the way.

> I don't think we should follow that on all the other platforms.

Sure. But as far as the UI/UX is concerned, it's actually existing and can be tested to see if a similar UI could work with emacs too. At least, macos users would not be surprised, because there are lots of applications that "extend" spotlight or want to replace it altogether, like Butler, Quicksilver and the likes.

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

Re: GNU Emacs raison d'etre

[Stefan Monnier]

> I was just mentioning that vs Drew's "in emacs the mini buffer *can* be in
> a frame". Because *that* requires a lot of manually installing packages that
> he refers to here:
>
> https://www.emacswiki.org/emacs/OneOnOneEmacs

FWIW, to get started, you just need:

    emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

But this indeed just begs the question of how to *manage* that
minibuffer-only frame (i.e. make it so that it's easily accessible when
the user needs it but it doesn't constantly get in the way the rest of
the time).

I don't know of any package/theme/thingy that provides a good solution
to that yet.  I think such a thing could be very useful&popular, so I'd
encourage you (or whoever else) to take a stab at it.


        Stefan

Re: GNU Emacs raison d'etre

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I was just mentioning that vs Drew's "in emacs the mini buffer *can* be in
>> a frame". Because *that* requires a lot of manually installing packages that
>> he refers to here:
>>
>> https://www.emacswiki.org/emacs/OneOnOneEmacs
>
> FWIW, to get started, you just need:
>
>     emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
>
> But this indeed just begs the question of how to *manage* that
> minibuffer-only frame (i.e. make it so that it's easily accessible when
> the user needs it but it doesn't constantly get in the way the rest of
> the time).
>
> I don't know of any package/theme/thingy that provides a good solution
> to that yet.  I think such a thing could be very useful&popular, so I'd
> encourage you (or whoever else) to take a stab at it.
>
>
>         Stefan
"autohide" (similar as windows taskbar) could be a way? But it is
hardcoded in c-code that minibuffer can not be hidden.

What I learned some decades ago when I took my driving license is that
human eye is trained to register motion, better then static objects. So
if minibuffer poped/raised/lowered (like a quake console :-)) when
needed, that motion could draw attention more then just some text
prompting in a tatic minibuffer. Same effect is probably achieved by
flushing minibuffers background/foreground colors or similar.

RE: GNU Emacs raison d'etre

[Drew Adams]

> "autohide" (similar as windows taskbar) could be a way? But it is
> hardcoded in c-code that minibuffer cannot be hidden.

That's not true (depending on what you mean,
I guess).

1. It's trivial to move a minibuffer-only frame
off screen (and bring it back on screen).

2. Alternatively, it's possible to make a frame
invisible (and visible again).

(modify-frame-parameters 1on1-minibuffer-frame
                         '((alpha . 0)))
(modify-frame-parameters 1on1-minibuffer-frame
                         '((alpha . 100)))
___

[No, alpha is not a satisfactory solution for
trying to get real invisibility.  Zero doesn't
make a frame completely invisible.  And the
frame is still present, at the same location,
which can be bothersome in terms of interaction.

Presumably, frame parameter `visibility' would
also be usable for this, but it doesn't seem
to have an effect on a minibuffer-only frame,
at least on MS Windows.  Same with parameter
`minibuffer-exit', and same with functions
`make-frame-(in)visible'.  Dunno whether those
are just bugs.  As I said, my impression is
that use of minibuffer frames doesn't get
tested much when features are introduced.]

> What I learned some decades ago when I took my driving license is that
> human eye is trained to register motion, better then static objects. So
> if minibuffer poped/raised/lowered (like a quake console :-)) when
> needed, that motion could draw attention more then just some text
> prompting in a tatic minibuffer. Same effect is probably achieved by
> flushing minibuffers background/foreground colors or similar.

One person's helpful attention attracter is
another person's annoyance.  So yes, but such
things need to be optional - user preferences.

Re: GNU Emacs raison d'etre

[Arthur Miller]

Drew Adams <drew.adams@oracle.com> writes:

>> "autohide" (similar as windows taskbar) could be a way? But it is
>> hardcoded in c-code that minibuffer cannot be hidden.
>
> That's not true (depending on what you mean,
> I guess).
>
> 1. It's trivial to move a minibuffer-only frame
> off screen (and bring it back on screen).
>
> 2. Alternatively, it's possible to make a frame
> invisible (and visible again).
>
> (modify-frame-parameters 1on1-minibuffer-frame
>                          '((alpha . 0)))
> (modify-frame-parameters 1on1-minibuffer-frame
>                          '((alpha . 100)))
> ___
>
> [No, alpha is not a satisfactory solution for
> trying to get real invisibility.  Zero doesn't
> make a frame completely invisible.  And the
> frame is still present, at the same location,
> which can be bothersome in terms of interaction.

Indeed, setting alpha is not enough, the frame will still be visible,
and it will also still take space. Believe me I tried, and I traced the
problem to C code (I think in buffer.c, I don't remember). I think there
was even an explicit comment saying minibuffer can not be hidden.By the
way, I wasn't thinking of having it in separate frame. I prefer to have
just one single frame so I minimize frame switching (alt-tabbing). So I
ment for the "usual" minibuffer as on the bottom of the visible Emacs
frame. So that put out of the question to set minibuffer away from the
screen and then show it back. Albeit it might be a solution if
minibuffer would be used in a pop-up manner.
>
> Presumably, frame parameter `visibility' would
> also be usable for this, but it doesn't seem
> to have an effect on a minibuffer-only frame,
> at least on MS Windows.  Same with parameter
> `minibuffer-exit', and same with functions
> `make-frame-(in)visible'.  Dunno whether those
> are just bugs.  As I said, my impression is
> that use of minibuffer frames doesn't get
> tested much when features are introduced.]
>
>> What I learned some decades ago when I took my driving license is that
>> human eye is trained to register motion, better then static objects. So
>> if minibuffer poped/raised/lowered (like a quake console :-)) when
>> needed, that motion could draw attention more then just some text
>> prompting in a tatic minibuffer. Same effect is probably achieved by
>> flushing minibuffers background/foreground colors or similar.
>
> One person's helpful attention attracter is
> another person's annoyance.  So yes, but such
> things need to be optional - user preferences.
It might be; but annoyance or not, it is an attention drawer. It is not
about preferance here, but more about what draws peoples attention.

When they are new to Emacs and dont' notice that minibuffer asks them
something, I recognize myself when I was new, something moving on the
screen might draw the attention. Once they get more experienced with
Emacs they can choose to have it always visible as it is now, place it
somewhere etc.

Just as analogy if it helps, when one drive, the brain automatically
focus on thing that moves, not on things that are static. Don't know if
it is because of evolution or not since bears and tigers were our
neighbours, but obviously that is how we are wired as humans.

Personally I prefer less distraction, that is why I use simple window
manager instead of a desktop, but in this case, I would prefer
minibuffer as autohide. Also because vertical screen estate is a scarce
resource since we evolved into wide-screen age :-).

Re: GNU Emacs raison d'etre

[martin rudalics]

 > 1. It's trivial to move a minibuffer-only frame
 > off screen (and bring it back on screen).

Not in my experience.  Not even for arbitrary frames.

 > 2. Alternatively, it's possible to make a frame
 > invisible (and visible again).
 >
 > (modify-frame-parameters 1on1-minibuffer-frame
 >                           '((alpha . 0)))
 > (modify-frame-parameters 1on1-minibuffer-frame
 >                           '((alpha . 100)))

Only on systems that do support that.

 > Presumably, frame parameter `visibility' would
 > also be usable for this, but it doesn't seem
 > to have an effect on a minibuffer-only frame,
 > at least on MS Windows.  Same with parameter
 > `minibuffer-exit', and same with functions
 > `make-frame-(in)visible'.  Dunno whether those
 > are just bugs.

On every GUI I've seen so far

(make-frame-invisible (window-frame (minibuffer-window)))

works as intended.  I call it thousands of times daily whenever a
minibuffer becomes empty.

 > As I said, my impression is
 > that use of minibuffer frames doesn't get
 > tested much when features are introduced.]

I use a minibuffer child frame all the time.  It is invisible whenever I
don't need it, promptly shows up on any window where I want to interact
with it and resizes just like any normal minibuffer window.

I do not use the echo area for ElDoc though and occasionally the echo
area noisily pops up to tell me that I'm at the beginning or end of a
buffer.  I've been told that I have to live with the latter.

In either case I can assure you that minibuffer frames are tested by me
intensively whenever features are introduced.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 11:32, martin rudalics wrote:
> I use a minibuffer child frame all the time.  It is invisible whenever I
> don't need it, promptly shows up on any window where I want to interact
> with it and resizes just like any normal minibuffer window.

Could you share your config? Perhaps we could make it into a package,  too.

> I do not use the echo area for ElDoc though and occasionally the echo
> area noisily pops up to tell me that I'm at the beginning or end of a
> buffer.  I've been told that I have to live with the latter.

Now that we have set-message-function and clear-message-function, 
couldn't you move message display somewhere else?

Re: GNU Emacs raison d'etre

[martin rudalics]

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

 > Could you share your config? Perhaps we could make it into a package,  too.

An old version is on the last line of that thread

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33498

but I attach the latest version here.

 > Now that we have set-message-function and clear-message-function, couldn't you move message display somewhere else?

Nirvana would be a good choice.  But I haven't tried yet.

martin

[-- Attachment #2: pop-up-mini.el --]
[-- Type: text/x-emacs-lisp, Size: 24299 bytes --]

;;; pop-up-mini.el --- pop up mini window in child frame -*- lexical-binding:t -*-

;; Copyright (C) 2019  Free Software Foundation, Inc.

;; Author: Martin Rudalics <rudalics@gmx.at>
;; Keywords: frames, minibuffers, windows
;; Version: 1.0
;; Package-Requires: ((emacs "27.1"))

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

;; pop-up-mini.el is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; Minor mode to pop up minibuffer and echo area in a child frame of
;; the selected frame.  This mode automatizes the following behaviors:
;;
;; - Reparent child frame when switching frames.
;;
;; - Facultatively host child frame at the bottom or top of selected
;;   window or selected frame's main or root window.
;;
;; - Resize and reposition child frame corresponding to size of its
;;   text and/or host window.
;;
;; - Hide empty child frame.
;;
;; A sample form with recommended variable settings for customizing
;; the .emacs init file is included at the end of this file.

;; Note: This file will work only with Emacs 27.1 and higher.

;;; Code:

(defvar pop-up-mini-mode)

(defvar pop-up-mini-frame nil
  "The minibuffer child-frame of 'pop-up-mini-mode'.
Usually displayed as child frame of the selected frame.")

(defvar pop-up-mini-window nil
  "The root window of 'pop-up-mini-frame'.")

(defgroup pop-up-mini nil
  "Customization group for 'pop-up-mini-mode'."
  :version "27.1"
  :group 'convenience
  :group 'frames)

(defun pop-up-mini--set-value (symbol value)
  "Helper function for customizing 'pop-up-mini-mode' options."
  (set-default symbol value)
  (cond
   ((not (frame-live-p pop-up-mini-frame)))
   ((eq symbol 'pop-up-mini-internal-border)
    (set-face-background 'internal-border value pop-up-mini-frame))
   ((frame-visible-p pop-up-mini-frame)
    (when (frame-live-p (frame-parent pop-up-mini-frame))
      (pop-up-mini-move (frame-parent pop-up-mini-frame))))))

(defcustom pop-up-mini-host 'selected
  "Type of window hosting 'pop-up-mini-frame'.
Choices are

'selected' - the selected window

'main' - the selected frame's main window

'root' - the selected frame's root window

Note that both 'main' and 'root' may overwrite the mode lines of
the windows at the bottom of the frame."
  :type '(choice (const selected)
                 (const main)
                 (const root))
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-host-min-width 20
  "Minimum width of host window for 'pop-up-mini-frame'.
If the window designated by 'pop-up-mini-host' is not as wide as
specified by this option, rehost 'pop-up-mini-frame' at the main
or root window of its parent frame."
  :type 'integer
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-host-min-height 3
  "Minimum height of of host window for 'pop-up-mini-frame'.
If the window designated by 'pop-up-mini-host' is not as high as
specified by this option, rehost 'pop-up-mini-frame' at the main
or root window of its parent frame."
  :type 'integer
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-rehost-to-fit t
  "If non-nil, rehost 'pop-up-mini-frame' when its text does not fit.
If this option is non-nil, 'pop-up-mini-host' equals 'selected'
and the text shown in 'pop-up-mini-frame' exceeds the width of
the selected window, rehost 'pop-up-mini-frame' to the selected
frame's main window."
  :type 'boolean
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-hide-if-empty 0.5
  "If non-nil, delay for hiding the empty 'pop-up-mini-frame'.
If this is nil, never hide the 'pop-up-mini-frame'.  Otherwise,
it specifies the number of seconds to wait before hiding an empty
'pop-up-mini-frame'.  Zero means to hide 'pop-up-mini-frame'
immediately after it becomes empty."
  :type '(choice (const nil)
		 (number :tag "delay"))
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-position 'scroll-bar
  "Position of 'pop-up-mini-frame' within its host window.
Choices are

'body-bottom' - at the bottom of the host's body if the host is a
   live window, at the bottom of the host window otherwise.  For
   a live host window this avoids covering the window's mode line
   and any scroll bars, fringes, or margins.

'body-top' - at the top of the host window's body if the host is
   a live window, at the top of the host window otherwise.  For a
   live host window this avoids covering the window's header line
   and any scroll bars, fringes, or margins.

'scroll-bar' - above the mode line of the host window if it is
   live, at the bottom of the host window otherwise.  This will
   usually hide the horizontal scroll bar of the host window.

'bottom' - at the bottom of the host window.  This will usually
   cover the host window's mode line, if any.

'top' - at the top of the host window.  This will usually cover
   the host window's header line, if any.

The width of 'pop-up-mini-frame' is the body width of the host
window for the first two options and the total width of the host
window for the remaining ones."
  :type '(choice (const body-bottom)
                 (const body-top)
		 (const scroll-bar)
                 (const bottom)
                 (const top))
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-resize-manually t
  "If non-nil, allow manually resizing of 'pop-up-mini-frame'.
This allows to drag the upper border of the 'pop-up-mini-frame'
with the mouse provided its window is the active minibuffer
window, until it either shrinks back to one line or becomes
empty."
  :type 'boolean
  :initialize 'custom-initialize-default
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defcustom pop-up-mini-internal-border "blue"
  "Background of internal border of 'pop-up-mini-frame'."
  :type 'string
  :set 'pop-up-mini--set-value
  :version "27.1"
  :group 'pop-up-mini)

(defvar pop-up-mini-buffer nil
  "Present or past buffer of 'pop-up-mini-window'.
This is the buffer shown in 'pop-up-mini-window' the last time
'resize-mini-frame' was called for its frame.")

(defvar pop-up-mini-text ""
  "Text displayed in 'pop-up-mini-window'.")

(defvar pop-up-mini-text-pixel-size '(0 . 0)
  "Size of 'pop-up-mini-text' the last time it was calculated.
The return value of 'window-text-pixel-size' the last time it was
run for 'pop-up-mini-window'.  The X-LIMIT for that run was the
width of the parent frame of 'pop-up-mini-frame' at that time.
The buffer text of 'pop-up-mini-window' at that time was
'pop-up-mini-text'.")

(defvar pop-up-mini-window-pixel-width 0
  "Pixel width of 'pop-up-mini-window'.")

(defvar pop-up-mini-window-pixel-height 0
  "Pixel height of 'pop-up-mini-window'.")

(defvar pop-up-mini-block-height nil
  "Non-nil means temporarily block height adjustment.")

(defvar pop-up-mini-hide-if-empty-timer nil
  "Timer for hiding 'pop-up-mini-frame'.")

(defun pop-up-mini-host-window (&optional frame)
  "Return window to host 'pop-up-mini-frame' on FRAME.
FRAME defaults to the selected frame."
  (cond
   ((eq pop-up-mini-host 'main)
    (window-main-window frame))
   ((eq pop-up-mini-host 'root)
    (frame-root-window frame))
   (t
    (frame-selected-window frame))))

(defun pop-up-mini-hide ()
  "Hide pop-up-mini-frame."
  (when (frame-live-p pop-up-mini-frame)
    (make-frame-invisible pop-up-mini-frame)
    (when (timerp pop-up-mini-hide-if-empty-timer)
      (cancel-timer pop-up-mini-hide-if-empty-timer)
      (setq pop-up-mini-hide-if-empty-timer nil))))

(defun pop-up-mini-move (frame &optional hide-immediately)
  "Maybe move and resize 'pop-up-mini-frame' to FRAME."
  (let* ((host (pop-up-mini-host-window frame))
	 (position pop-up-mini-position)
	 (body (and (window-live-p host)
		    (memq position '(body-bottom body-top))))
	 (edges (window-edges host body nil t))
	 (borders-width
	  (* (frame-parameter pop-up-mini-frame 'internal-border-width) 2))
	 (body-width (car pop-up-mini-text-pixel-size))
	 (body-height (cdr pop-up-mini-text-pixel-size))
	 total-width total-height extended-width) ; extended-main)

;;     (foo-it hide-immediately)

    (if (and (numberp pop-up-mini-hide-if-empty)
	     (zerop body-width) (zerop body-height))
	(cond
	 ((or hide-immediately (<= pop-up-mini-hide-if-empty 0))
	  ;; An empty 'pop-up-mini-buffer' - hide it.
	  (setq pop-up-mini-block-height nil)
	  (make-frame-invisible pop-up-mini-frame))
	 (t
	  (setq pop-up-mini-block-height nil)
	  (setq pop-up-mini-hide-if-empty-timer
		(run-with-timer
		 pop-up-mini-hide-if-empty nil 'pop-up-mini-hide))))
      ;; If 'pop-up-mini-resize-manually' is non-nil, preserve height
      ;; of a manually resized 'pop-up-mini-frame' as long as its
      ;; window is the active minibuffer window, is larger than one
      ;; line and its buffer is non-empty.
      (if pop-up-mini-block-height
	  (setq pop-up-mini-block-height
		(and (minibuffer-window-active-p pop-up-mini-window)
		     (not (zerop body-width))
		     (not (zerop body-height))
		     (> (window-pixel-height pop-up-mini-window)
			(frame-char-height pop-up-mini-frame))))
	(setq pop-up-mini-block-height
	      (and pop-up-mini-resize-manually
		   (minibuffer-window-active-p pop-up-mini-window)
		   (/= (window-body-height pop-up-mini-window t)
		       body-height))))

;;       (foo-it pop-up-mini-hide-if-empty body-width body-height)

      ;; Check minimum width and height of selected window.
      (cond
       ;; For 'scroll-bar' detract mode line and divider height from
       ;; third edge.
       ((and (eq position 'scroll-bar) (eq pop-up-mini-host 'selected))
	(setq edges (list (nth 0 edges) (nth 1 edges) (nth 2 edges)
			  (- (nth 3 edges) (window-mode-line-height host)
			     (window-bottom-divider-width host))))
	(setq position 'bottom))
       ;; For 'bottom' detract divider height from third edge when host
       ;; is live ('main' slightly loses here).
       ((and (eq position 'bottom) (window-live-p host))
	(setq edges (list (nth 0 edges) (nth 1 edges) (nth 2 edges)
			  (- (nth 3 edges)
			     (window-bottom-divider-width host))))))
      (setq total-width
	    (+ body-width
	       (- (window-pixel-width pop-up-mini-window)
		  (window-body-width pop-up-mini-window t))
	       (- (window-scroll-bar-width pop-up-mini-window))
	       (- (let ((fringes (window-fringes pop-up-mini-window)))
		    (+ (car fringes) (nth 1 fringes))))))

      (unless pop-up-mini-block-height
	(setq total-height
	      (+ body-height
		 (let ((scroll-bars (window-scroll-bars pop-up-mini-window)))
		   (or (nth 3 scroll-bars)
		       (and (eq (nth 5 scroll-bars) t)
			    (frame-scroll-bar-height pop-up-mini-frame))
		       0))
		 (- (frame-scroll-bar-height pop-up-mini-frame)))))

      ;; Extend on scroll bars, maybe.
      (when (and (eq pop-up-mini-position 'scroll-bar)
		 (window-combined-p nil t)
		 (or (< (- (nth 2 edges) (nth 0 edges)
			   (window-right-divider-width host))
			total-width)
		     (< (- (nth 2 edges) (nth 0 edges)
			   (window-right-divider-width host))
			pop-up-mini-host-min-width)))
	(let* ((edge-0 (nth 0 edges))
	       (sibling (window-next-sibling))
	       (edge-2 (nth 2 (window-edges sibling nil nil t)))
	       (width (- edge-2 edge-0)))
	  (while (and sibling (< width total-width))
	    (setq sibling (window-next-sibling sibling))
	    (setq edge-2 (nth 2 (window-edges sibling nil nil t)))
	    (setq width (- edge-2 edge-0)))
	  (if (>= width total-width)
	      (progn
		(setq extended-width width)
;; 		(setq extended-main
;; 		      (and sibling (not (window-live-p sibling))))
		)
	    (setq edge-2 (nth 2 (window-edges
				 (window-main-window frame) nil nil t)))
	    (setq width (- edge-2 edge-0))
	    (when (>= width total-width)
;; 	      (setq extended-main t)
	      (setq extended-width width)))))

      (when (and (not pop-up-mini-block-height)
		 (eq pop-up-mini-host 'selected)
		 (not extended-width)
		 (or (not (zerop pop-up-mini-host-min-width))
		     (not (zerop pop-up-mini-host-min-height))
		     pop-up-mini-rehost-to-fit)
		 (or (and (/= (window-total-width host)
			      (window-total-width (window-main-window frame)))
			  (or (< (- (nth 2 edges) (nth 0 edges)
				    (window-right-divider-width host))
				 total-width)
			      (< (- (nth 2 edges) (nth 0 edges)
				    (window-right-divider-width host))
				 pop-up-mini-host-min-width)
		     (and (/= (window-total-height host)
			      (window-total-height (window-main-window frame)))
			  (or (< (- (nth 3 edges) (nth 1 edges)) total-height)
			      (< (- (nth 3 edges) (nth 1 edges))
				 pop-up-mini-host-min-height)))))))
	;; FRAME's selected window is too small, use its main window.
	(setq host (window-main-window frame))
	(setq position
	      (cond
	       ((eq position 'body-top) 'top)
	       ((eq position 'body-bottom) 'bottom)
	       (t position)))
	(setq edges (window-edges host nil nil t)))

;;       (foo-it pop-up-mini-buffer pop-up-mini-text
;; 	      pop-up-mini-text-pixel-size
;; 	      host (- (nth 2 edges) (nth 0 edges)) body-width)

;;       (foo-it (- (frame-pixel-height frame) (nth 3 edges))
;; 	      total-height)

      ;; Cancel our timer.
      (when (timerp pop-up-mini-hide-if-empty-timer)
	(cancel-timer pop-up-mini-hide-if-empty-timer)
	(setq pop-up-mini-hide-if-empty-timer nil))
      ;; Resize and position.
      (modify-frame-parameters
       pop-up-mini-frame
       `((parent-frame . ,frame)
	 (visibility . t)
	 (top . ,(if (memq pop-up-mini-position '(top body-top))
		     (nth 1 edges)
		   `(- ,(- (frame-pixel-height frame) (nth 3 edges)))))
	 (left . ,(nth 0 edges))
	 ,(unless pop-up-mini-block-height
	    `(height . ,(cons 'text-pixels
			      ;; Don't make 'pop-up-mini-frame' higher
			      ;; than its host window.
			      (min (- (nth 3 edges) (nth 1 edges))
				   total-height))))
	 (width . ,(cons 'text-pixels
			 ;; Make 'pop-up-mini-frame' as wide as its
			 ;; host window.
			 (or (and extended-width
				  (- extended-width
				     (- (window-pixel-width pop-up-mini-window)
					(window-body-width pop-up-mini-window t))
				     borders-width))
			     (- (nth 2 edges) (nth 0 edges)
				(if (window-live-p host)
				    (window-right-divider-width host)
				  0)
				(- (window-pixel-width pop-up-mini-window)
				   (window-body-width pop-up-mini-window t))
				borders-width))))))
      (setq pop-up-mini-window-pixel-width
	    (window-pixel-width pop-up-mini-window))
      (setq pop-up-mini-window-pixel-height
	    (window-pixel-height pop-up-mini-window)))))

(defvar pop-up-mini-window-reparented nil)

(defun pop-up-mini-window-state-change ()
  "'pop-up-mini-mode' function run by 'window-state-change-hook'.
If the selected window, the window specfied by 'pop-up-mini-host'
or 'pop-up-mini-text' changed since last redisplay, reparent,
resize and/or reposition 'pop-up-mini-frame' if necessary."
  (when (frame-live-p pop-up-mini-frame)
    (setq pop-up-mini-window-reparented
	  (and pop-up-mini-window-reparented
	       (not (zerop (minibuffer-depth)))))

    (let* ((old-parent
	    (and (frame-live-p (frame-parent pop-up-mini-frame))
		 (frame-parent pop-up-mini-frame)))
	   (new-parent
	    (cond
	     ((eq (selected-frame) old-parent) old-parent)
	     ((eq (selected-frame) pop-up-mini-frame)
	      (if (minibuffer-selected-window)
		  (let ((frame (window-frame (minibuffer-selected-window))))
		    (if (and (not pop-up-mini-window-reparented)
			     (not (eq frame old-parent))
			     (eq (minibuffer-window frame) pop-up-mini-window))
			;; Special case where selected window changed
			;; _and_ 'pop-up-mini-window' got selected.
			(progn
			  (setq pop-up-mini-window-reparented t)
			  frame)
		      old-parent))))
	     ((eq (minibuffer-window) pop-up-mini-window) (selected-frame))
	     (t old-parent)))
	   hide-immediately)

;;       (unless (eq (frame-old-selected-window new-parent)
;; 		  (frame-selected-window new-parent))
;; 	(foo-it (frame-old-selected-window new-parent)
;; 		(frame-selected-window new-parent)))

      (when (and (frame-live-p new-parent)
		 (or (setq hide-immediately (not (eq old-parent new-parent)))
		     (let ((host-window (pop-up-mini-host-window new-parent)))
		       (setq hide-immediately
			     (or (and (eq pop-up-mini-host 'selected)
				      (not (eq (frame-old-selected-window
						new-parent)
					       (frame-selected-window
						new-parent))))
				 (/= (window-pixel-height host-window)
				     (window-old-pixel-height host-window))
				 (/= (window-pixel-width host-window)
				     (window-old-pixel-width host-window)))))
		     (frame-window-state-change pop-up-mini-frame)))
	;; Something really changed, dig further.
	(pop-up-mini-move new-parent hide-immediately)))))

(defun pop-up-mini-resize-mini-frame (frame)
  "'resize-mini-frames' function of 'pop-up-mini-mode'."
  (when (eq frame pop-up-mini-frame)
    (let* ((buffer (window-buffer pop-up-mini-window))
	   (text (with-current-buffer buffer
		   ;; Since we ignore text properties we will miss the
		   ;; case of displaying the same string with
		   ;; different text properties twice in a row.
		   (buffer-substring-no-properties (point-min) (point-max)))))
      ;; Return when there's no change.  This means that
      ;; 'pop-up-mini-buffer', 'pop-up-mini-text' as well as width and
      ;; height of 'pop-up-mini-window' are the same as the last time
      ;; we displayed them.
      (unless (and (eq buffer pop-up-mini-buffer)
		   (string-equal pop-up-mini-text text)
		   ;; Make sure that we do not miss a case where we
		   ;; want to make 'pop-up-mini-frame' invisible.
		   (or (not pop-up-mini-hide-if-empty)
		       (not (string-equal text ""))
		       (not (frame-visible-p pop-up-mini-frame)))
		   (equal (window-pixel-width pop-up-mini-window)
			  pop-up-mini-window-pixel-width)
		   (equal (window-pixel-height pop-up-mini-window)
			  pop-up-mini-window-pixel-height))
	;; Remember old string.
	(setq pop-up-mini-buffer buffer)
	(setq pop-up-mini-text text)
	(setq pop-up-mini-window-pixel-width
	      (window-pixel-width pop-up-mini-window))
	(setq pop-up-mini-window-pixel-height
	      (window-pixel-height pop-up-mini-window))
	;; This is the only place where we can calculate the size.
	(setq pop-up-mini-text-pixel-size
	      (and (buffer-live-p buffer)
		   (window-text-pixel-size
		    pop-up-mini-window
		    nil nil (frame-text-width
			     (frame-parent pop-up-mini-frame)))))

;; 	(when (buffer-live-p buffer)
;; 	  (foo-it buffer (eq buffer pop-up-mini-buffer)
;; 		  text (string-equal text pop-up-mini-text)
;; 		  pop-up-mini-text-pixel-size
;; 		  (frame-text-width
;; 		   (frame-parent pop-up-mini-frame))))

	;; Notify ourselves of change.
	(set-frame-window-state-change frame t)))))

(defun pop-up-mini-after-make-frame (frame)
  "Maybe make FRAME client of 'pop-up-mini-frame'."
  (when (and (not (frame-parameter frame 'minibuffer))
	     (window-live-p pop-up-mini-window))
    (set-frame-parameter frame 'minibuffer pop-up-mini-window)))

(defun pop-up-mini-setup ()
  "Set up minibuffer child frame mode.
This function makes the first minibuffer-only frame it finds the
'pop-up-mini-frame'.  Needs a minibuffer-only frame."
  (setq pop-up-mini-frame nil)

  ;; Make 'pop-up-mini-frame' the first 'minibuffer-only' frame found
  ;; on 'frame-list'.  Throw an error if we don't find one.
  (unless (catch 'found
	    (dolist (frame (frame-list))
	      (when (eq (frame-parameter frame 'minibuffer) 'only)
		(throw 'found (setq pop-up-mini-frame frame)))))
    (error "'pop-up-mini-mode' needs a minibuffer-only frame"))

  ;; The following will fail whenever someone resets the
  ;; 'unsplittable' parameter of 'pop-up-mini-frame'.
  (setq pop-up-mini-window (frame-root-window pop-up-mini-frame))
  (setq pop-up-mini-buffer (window-buffer pop-up-mini-window))
  (set-face-background
   'internal-border pop-up-mini-internal-border pop-up-mini-frame)
  ;; Usurpate 'resize-mini-frames'.  On exit reset that to nil.
  (setq resize-mini-frames 'pop-up-mini-resize-mini-frame)
  (add-hook
   'window-state-change-hook 'pop-up-mini-window-state-change)
  (add-hook
   'after-make-frame-functions 'pop-up-mini-after-make-frame))

;;;###autoload
(define-minor-mode pop-up-mini-mode
  "Show minibuffer and echo area in a child frame.
'pop-up-mini-mode' uses a child frame called 'pop-up-mini-frame'
for displaying the minibuffer or the echo area.  The parent frame
of 'pop-up-mini-frame' is the currently selected frame.  Within
its parent, 'pop-up-mini-frame' can be hosted at that frame's
selected, main or root window (see 'pop-up-mini-host') either at
that window's top or bottom (see 'pop-up-mini-position').  A
'pop-up-mini-frame' that does not display any text can be hidden
using the option 'pop-up-mini-hide-if-empty'."
  :global t
  :group 'pop-up-mini
  :init-value nil
  :link '(emacs-commentary-link "pop-up-mini.el")
  (if pop-up-mini-mode
      (if frame-initial-frame
	  ;; When the initial frame is still around wait until
	  ;; 'window-setup-hook' is run.
	  (add-hook 'window-setup-hook 'pop-up-mini-setup)
	;; Otherwise run immediately.
	(pop-up-mini-setup))
    ;; Cancel our timer.
    (when (timerp pop-up-mini-hide-if-empty-timer)
      (cancel-timer pop-up-mini-hide-if-empty-timer)
      (setq pop-up-mini-hide-if-empty-timer nil))
    (remove-hook
     'window-state-change-hook 'pop-up-mini-window-state-change)
    (remove-hook
     'after-make-frame-functions 'pop-up-mini-after-make-frame)
    ;; This is not very nice but any previous value might be broken.
    (setq resize-mini-frames nil)
    ;; Reset our variables.
    (setq pop-up-mini-window nil)
    (when pop-up-mini-frame
      ;; Unparent our frame and make it visible.
      (modify-frame-parameters
       pop-up-mini-frame
       `((parent-frame . nil) (visibility . t)))
      (setq pop-up-mini-frame nil))))

(provide 'pop-up-mini)

;;; Recommended variable settings for .emacs init file.

(custom-set-variables
 ;; Enable ourselves.
 '(pop-up-mini-mode 1)
 ;; Resize frames exactly.
 '(frame-resize-pixelwise t)
 ;; At least two lines scroll margin for selected window host.
 '(scroll-margin 2)
 ;; Automatically create a minibuffer child frame at startup and
 ;; reparent it immediately.
 '(initial-frame-alist
    (cons '(minibuffer . child-frame) initial-frame-alist))
 ;; Reuse minibuffer child frame when making a new frame.  Do not use
 ;; '(minibuffer . child-frame) here, it would make a new child frame.
 '(default-frame-alist
    (cons '(minibuffer . nil) default-frame-alist))
 '(minibuffer-frame-alist
   '(;; Initial positioning and sizing for the window manager.
     (height . 1)
     (width . 1.0)
     (top . 1.0)
     ;; Always show at least one line.
     (min-height . 1)
     ;; No horizontal scroll bars (they don't work properly in
     ;; minibuffer windows).
     (horizontal-scroll-bars . nil)
     ;; No title bar.
     (undecorated . t)
     ;; To drag the child frame's top with the mouse.
     (internal-border-width . 1)
     (drag-internal-border . t)
     ;; No special glyphs.
     (no-special-glyphs . t)
     ;; No foucs when child frame is (re-)mapped.
     (no-focus-on-map . t))))

;;; pop-up-mini.el ends here

;; (set-frame-parameter (window-frame (minibuffer-window)) 'mini-window-horizontal-scroll-bar t)
;; (frame-parameter (window-frame (minibuffer-window)) 'mini-window-horizontal-scroll-bar)

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 16:02, martin rudalics wrote:
>  > Could you share your config? Perhaps we could make it into a 
> package,  too.
> 
> An old version is on the last line of that thread
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33498
> 
> but I attach the latest version here.

Thank you.

If I visit the file and M-x eval-buffer, I get this error:

Error setting pop-up-mini-mode: (error ’pop-up-mini-mode’ needs a 
minibuffer-only frame)

(Whether I start from 'emacs -Q' or not.)

>  > Now that we have set-message-function and clear-message-function, 
> couldn't you move message display somewhere else?
> 
> Nirvana would be a good choice.  But I haven't tried yet.

This one?

https://en.wikipedia.org/wiki/NEdit

Re: GNU Emacs raison d'etre

[Robert Pluim]

>>>>> On Mon, 18 May 2020 16:38:36 +0300, Dmitry Gutov <dgutov@yandex.ru> said:

    Dmitry> On 18.05.2020 16:02, martin rudalics wrote:
    >> > Could you share your config? Perhaps we could make it into a
    >> package,  too.
    >> An old version is on the last line of that thread
    >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33498
    >> but I attach the latest version here.

    Dmitry> Thank you.

    Dmitry> If I visit the file and M-x eval-buffer, I get this error:

    Dmitry> Error setting pop-up-mini-mode: (error ’pop-up-mini-mode’ needs a
    Dmitry> minibuffer-only frame)

    Dmitry> (Whether I start from 'emacs -Q' or not.)

And if you set emacs to use a minibuffer-only frame?

    emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

Robert

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 19:31, Robert Pluim wrote:

>      Dmitry> Error setting pop-up-mini-mode: (error ’pop-up-mini-mode’ needs a
>      Dmitry> minibuffer-only frame)
> 
>      Dmitry> (Whether I start from 'emacs -Q' or not.)
> 
> And if you set emacs to use a minibuffer-only frame?
> 
>      emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

That setting is at the bottom of the file Martin attached.

I finally understood what I was doing wrong: I tried to visit the file 
and 'M-x eval-buffer' from an existing graphical frame. That got me the 
error.

If I load it from init.el, the result is fairly functional (though with 
a number of glitches), and it really does look like an improvement over 
the current situation. Even if the main benefit is simply locality: it 
displays the "minibuffer" at the bottom of the current window, not frame.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > I finally understood what I was doing wrong: I tried to visit the file
 > and 'M-x eval-buffer' from an existing graphical frame. That got me
 > the error.

Right.  In a "normal" session you have to create a minibuffer-only frame
first and then delete the normal frame to get uniform behavior.  Emacs
does not offer a function to remove the minibuffer window from a normal
frame so this is the best you can get.

 > If I load it from init.el, the result is fairly functional (though
 > with a number of glitches),

Since I use it with my customizations only, such glitches are to be
expected.  And, as you know, mutter is not very child-frame friendly.

 > and it really does look like an
 > improvement over the current situation. Even if the main benefit is
 > simply locality: it displays the "minibuffer" at the bottom of the
 > current window, not frame.

You can put it anywhere on the parent frame via 'pop-up-mini-host'
and/or 'pop-up-mini-position'.  If something is lacking here, it can be
added easily.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 19.05.2020 11:41, martin rudalics wrote:
>  > I finally understood what I was doing wrong: I tried to visit the file
>  > and 'M-x eval-buffer' from an existing graphical frame. That got me
>  > the error.
> 
> Right.  In a "normal" session you have to create a minibuffer-only frame
> first and then delete the normal frame to get uniform behavior.  Emacs
> does not offer a function to remove the minibuffer window from a normal
> frame so this is the best you can get.

Any chance to change the latter in Emacs 28? Is that difficult?

It would improve the starting experience quite a bit.

>  > If I load it from init.el, the result is fairly functional (though
>  > with a number of glitches),
> 
> Since I use it with my customizations only, such glitches are to be
> expected.  And, as you know, mutter is not very child-frame friendly.

Thanks for the reminder: with the appropriate value of 
x-gtk-resize-child-frames, the behavior looks more sensible now.

The main remaining annoyance is the blink when the child frame is 
resized/repositioned.

>  > and it really does look like an
>  > improvement over the current situation. Even if the main benefit is
>  > simply locality: it displays the "minibuffer" at the bottom of the
>  > current window, not frame.
> 
> You can put it anywhere on the parent frame via 'pop-up-mini-host'
> and/or 'pop-up-mini-position'.  If something is lacking here, it can be
> added easily.

So how do you feel about a package in GNU ELPA?

If we can move the settings into the definition of pop-up-mini-mode, it 
should be quite usable. And also do something with the scenario where 
someone installs it, turns on the mode, and simply stares at the error.

Re: GNU Emacs raison d'etre

[martin rudalics]

 >> Right.  In a "normal" session you have to create a minibuffer-only frame
 >> first and then delete the normal frame to get uniform behavior.  Emacs
 >> does not offer a function to remove the minibuffer window from a normal
 >> frame so this is the best you can get.
 >
 > Any chance to change the latter in Emacs 28? Is that difficult?

It's hairy and that's why people never tried to change the ritual of
setting up an initial frame with a minibuffer window.  Likely to make
sure that if things go wrong anywhere, there's always at least one
minibuffer window you can act upon or that displays vital information
about what went wrong during setup.

Note that producing the minibuffer-less + minibuffer-only setup is
accomplished by 'frame-notice-user-settings' which deletes the initial
minibuffer-equipped frame in a hair-raising fashion in order to make
sure that at least one minibuffer window is available at any time.

 > It would improve the starting experience quite a bit.

The startup experience of general minibuffer-only frame setups or that
of the setup with a minibuffer-only child frame?  I think these are today
also affected by other parameters like, for example, whether you put
these specifications into an early init file or the normal one.

 > The main remaining annoyance is the blink when the child frame is resized/repositioned.

You would have to tell me more about that blink.  If it's due to the
setting of 'x-gtk-resize-child-frames', there's nothing I can do about
it.  If it's due to the delay implied by 'pop-up-mini-hide-if-empty',
try to experiment with that.

 > So how do you feel about a package in GNU ELPA?

Not really enthusiastic.  The historical constraints of how to set up
and use the minibuffer window are too restrictive IMHO so what you see
here is just a workaround.  Maybe things will change in a couple of
years.

 > If we can move the settings into the definition of pop-up-mini-mode,
 > it should be quite usable. And also do something with the scenario
 > where someone installs it, turns on the mode, and simply stares at the
 > error.

What's so bad about that error?  It simply tells what is missing.  If
you provide such a frame, things should work, even in parallel with the
already existing minibuffer window.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 12:06, martin rudalics wrote:
>  >> Right.  In a "normal" session you have to create a minibuffer-only 
> frame
>  >> first and then delete the normal frame to get uniform behavior.  Emacs
>  >> does not offer a function to remove the minibuffer window from a normal
>  >> frame so this is the best you can get.
>  >
>  > Any chance to change the latter in Emacs 28? Is that difficult?
> 
> It's hairy and that's why people never tried to change the ritual of
> setting up an initial frame with a minibuffer window.  Likely to make
> sure that if things go wrong anywhere, there's always at least one
> minibuffer window you can act upon or that displays vital information
> about what went wrong during setup.

I get the idea, but Emacs is not a whole computer, to try to keep 
running at all costs. The config can be fixed, and Emacs can usually be 
restarted. So whatever the original reasons are, a user option could 
still be doable.

> Note that producing the minibuffer-less + minibuffer-only setup is
> accomplished by 'frame-notice-user-settings' which deletes the initial
> minibuffer-equipped frame in a hair-raising fashion in order to make
> sure that at least one minibuffer window is available at any time.

I've also noticed that initial blink during startup, but didn't know 
what to attribute it to. Would be great to be able to avoid it.

>  > It would improve the starting experience quite a bit.
> 
> The startup experience of general minibuffer-only frame setups or that
> of the setup with a minibuffer-only child frame?  I think these are today
> also affected by other parameters like, for example, whether you put
> these specifications into an early init file or the normal one.

The startup experience of pop-up-mini-mode. I can imagine two main 
scenarios:

- The user installs the package and turns the mode one. If we can't 
disable the minibuffer, maybe just enable the rest of the functionality, 
and describe minibuffer-disabling-on-init functionality separately? It 
could even just be a line we'd tell the users to put in their init script.

Alternatively, since you described what happens currently, 
pop-up-mini-mode could try to remember the current window configuration, 
create a new frame on the same position without a minibuffer, restore 
the window configuration there, and delete the original frame. Or is 
that something that could only happen during startup?

- pop-up-mini-mode is enabled in the user's init script. Is that worse 
than early init? We could try to document the early init as the best option.

>  > The main remaining annoyance is the blink when the child frame is 
> resized/repositioned.
> 
> You would have to tell me more about that blink.  If it's due to the
> setting of 'x-gtk-resize-child-frames', there's nothing I can do about
> it.  If it's due to the delay implied by 'pop-up-mini-hide-if-empty',
> try to experiment with that.

My x-gtk-resize-child-frames value is 'resize-mode.

Blinking happens when it's resized. But not every single time.

Here's what I do:

1. src/emacs -Q --eval "(setq x-gtk-resize-child-frames 'resize-mode)" 
-l ~/.emacs.d/site-lisp/pop-up-mini.el

2. M-x ido-mode.

3. C-x C-f, type 'e'. If you're inside Emacs source directory, the 
completions should span 2-3 lines. When the child frame is resized, it 
will blink. Sometimes it looks like the mode-line quickly moves up and 
back (or at least _something_ grey moves like that).

Instead of ido-mode, fido-mode can be used with similar effect. Though 
blinking seems less frequent with it.

Another issue: when the child frame covers the scroll bar, it renders 
some junk on it.

>  > So how do you feel about a package in GNU ELPA?
> 
> Not really enthusiastic.  The historical constraints of how to set up
> and use the minibuffer window are too restrictive IMHO so what you see
> here is just a workaround.  Maybe things will change in a couple of
> years.

Do you mean the child frame problems?

A package could declare that it only works on Emacs 28+, BTW.

>  > If we can move the settings into the definition of pop-up-mini-mode,
>  > it should be quite usable. And also do something with the scenario
>  > where someone installs it, turns on the mode, and simply stares at the
>  > error.
> 
> What's so bad about that error?  It simply tells what is missing.  If
> you provide such a frame, things should work, even in parallel with the
> already existing minibuffer window.

I didn't understand what I needed to do from it, and I'm a fairly 
experienced user. When doing a package, we usually try to cater to even 
less experienced users. Not always succeed, but try to.

BTW, here's a today's thread on Reddit with similar complaints by users: 
https://www.reddit.com/r/emacs/comments/gmsnoy/minibufferecho_area_ergonomics/

One suggestion option is this package: 
https://github.com/muffinmad/emacs-mini-frame.

There are a few others with this goal as well. But none of them try to 
hide the minibuffer (or know that it's possible, looks like). They only 
create a child frame with an "effective" minibuffer, and position it to 
their liking. Whereas the minibuffer line is left untouched, and is only 
used as echo area.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > I get the idea, but Emacs is not a whole computer, to try to keep
 > running at all costs. The config can be fixed, and Emacs can usually
 > be restarted. So whatever the original reasons are, a user option
 > could still be doable.

Not really.  There's C code that relies on the invariant that a
minibuffer/echo area window exists at each and every moment of execution
(I know because I once spent some time to find them all).  If we manage
to remove that single window, Emacs may just crash.

 > I've also noticed that initial blink during startup, but didn't know
 > what to attribute it to. Would be great to be able to avoid it.

Is this a blink that happens also when you do

emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

or does it require the presence of a child frame?

 > - The user installs the package and turns the mode one. If we can't
 > disable the minibuffer, maybe just enable the rest of the
 > functionality, and describe minibuffer-disabling-on-init functionality
 > separately? It could even just be a line we'd tell the users to put in
 > their init script.

It's not as simple as that.  Users who want to use that mode have to
make themselves familiar with child frames and minibuffer-only frames
first.  And even after that there may be glitches, especially when
working with multiple frames.  For example, transferring focus from one
frame to another, while a minibuffer interaction is in progress, is a
hairy operation regardless of whether you use the standard setup, a
top-level minibuffer(-only) frame or a minibuffer child frame.

 > Alternatively, since you described what happens currently,
 > pop-up-mini-mode could try to remember the current window
 > configuration, create a new frame on the same position without a
 > minibuffer, restore the window configuration there, and delete the
 > original frame. Or is that something that could only happen during
 > startup?

I would have to guess the user's intention here.  'pop-up-mini-mode'
does not forbid a mixed mode where one frame uses its own minibuffer
window for interaction and other frames want to use the more "global"
minibuffer-only window 'pop-up-mini-mode' found when it started.  Also
note that we have various strategies to assign the minibuffer window
('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
is more convoluted than it appears at first sight.

 > - pop-up-mini-mode is enabled in the user's init script. Is that worse
 > than early init? We could try to document the early init as the best
 > option.

It's not a good option if it fails for some reason.  On a TTY, say.

 >> You would have to tell me more about that blink.  If it's due to the
 >> setting of 'x-gtk-resize-child-frames', there's nothing I can do about
 >> it.  If it's due to the delay implied by 'pop-up-mini-hide-if-empty',
 >> try to experiment with that.
 >
 > My x-gtk-resize-child-frames value is 'resize-mode.
 >
 > Blinking happens when it's resized. But not every single time.
 >
 > Here's what I do:
 >
 > 1. src/emacs -Q --eval "(setq x-gtk-resize-child-frames 'resize-mode)" -l ~/.emacs.d/site-lisp/pop-up-mini.el
 >
 > 2. M-x ido-mode.
 >
 > 3. C-x C-f, type 'e'. If you're inside Emacs source directory, the completions should span 2-3 lines. When the child frame is resized, it will blink. Sometimes it looks like the mode-line quickly moves up and back (or at least _something_ grey moves like that).

I can't reproduce that here.  But I'm on xfce and currently can't test
with GNOME shell which disabled itself during its never-ending attempts
of unattended upgrades.

 > Instead of ido-mode, fido-mode can be used with similar effect. Though
 > blinking seems less frequent with it.

Again, it would be interesting to know whether this happens with mutter
only.

 > Another issue: when the child frame covers the scroll bar, it renders some junk on it.

The horizontal scroll bar?  That's where it is here all the time.

 >> Not really enthusiastic.  The historical constraints of how to set up
 >> and use the minibuffer window are too restrictive IMHO so what you see
 >> here is just a workaround.  Maybe things will change in a couple of
 >> years.
 >
 > Do you mean the child frame problems?

No.  I spent a couple of months in the intestines of the minibuffer
window implementation and came to the conclusion that sooner or later it
will break down under the load people are piling up on it.

Nobody here can tell you how many messages go by unnoticed in a session
because one last message hides all the ones that were emitted earlier.
And as soon as we start a minibuffer interaction, we enter an area where
a message may temporarily obscure (or amend to?) parts of the text we
just entered.  And all this happens because we got used to it over the
decades like the frog being boiled alive.

What should be reformed here are two things:

- Break up the conflation of minibuffer and echo area you mentioned
   earlier.

- Provide the possibility to make the minibuffer window temporarily
   nonexistent (invisible or dead).

Both are hard to achieve.  The conflation was a premature optimization.
People got used to it with the consequence that it will be very hard to
dissolve it.  Having a minibuffer window always present is a restriction
that is now "built in".  Dissolving it is hard because it would require
to amend lots of code used to the fact that that window is always here.

 > A package could declare that it only works on Emacs 28+, BTW.

pop-up-mini.el has

;; Package-Requires: ((emacs "27.1"))

 >> What's so bad about that error?  It simply tells what is missing.  If
 >> you provide such a frame, things should work, even in parallel with the
 >> already existing minibuffer window.
 >
 > I didn't understand what I needed to do from it, and I'm a fairly experienced user. When doing a package, we usually try to cater to even less experienced users. Not always succeed, but try to.

As I explained above: If you want to use 'pop-up-mini-mode' you have to
get familiar with both, minibuffer windows and child frames, first.

 > BTW, here's a today's thread on Reddit with similar complaints by
 > users:
 > https://www.reddit.com/r/emacs/comments/gmsnoy/minibufferecho_area_ergonomics/

IIUC this one's about using Emacs on a TTY.  In that case
minibuffer-only frames won't help anyway.

 > One suggestion option is this package: https://github.com/muffinmad/emacs-mini-frame.

Years ago I wrote the code to put the minibuffer window on top of a
frame - something which should work on TTYs as well.  But it's annoying:
When resizing the minibuffer, the entire text in the windows beneath has
to move up or down.  When the minibuffer window is at the bottom, the
text in the windows above usually only gets truncated.

 > There are a few others with this goal as well. But none of them try to
 > hide the minibuffer (or know that it's possible, looks like). They
 > only create a child frame with an "effective" minibuffer, and position
 > it to their liking. Whereas the minibuffer line is left untouched, and
 > is only used as echo area.

It would be interesting to see a list of requirements for a practical
solution to this problem.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 21.05.2020 12:07, martin rudalics wrote:

> Not really.  There's C code that relies on the invariant that a
> minibuffer/echo area window exists at each and every moment of execution
> (I know because I once spent some time to find them all).  If we manage
> to remove that single window, Emacs may just crash.

Hmm, okay.

>  > I've also noticed that initial blink during startup, but didn't know
>  > what to attribute it to. Would be great to be able to avoid it.
> 
> Is this a blink that happens also when you do
> 
> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
> 
> or does it require the presence of a child frame?

I couldn't manage to reproduce the bug there. Even with 
resize-mini-frames=t. But then, it doesn't resize as responsively as 
your code.

>  > - The user installs the package and turns the mode one. If we can't
>  > disable the minibuffer, maybe just enable the rest of the
>  > functionality, and describe minibuffer-disabling-on-init functionality
>  > separately? It could even just be a line we'd tell the users to put in
>  > their init script.
> 
> It's not as simple as that.  Users who want to use that mode have to
> make themselves familiar with child frames and minibuffer-only frames
> first.

Please, no.

You know the reason why we only fixed child frames under GNOME now? Or 
why packages using child frames only started to become popular?

This is arcane stuff, and it took someone really motivated to turn the 
child frames support you created into a library every Emacs developer 
can use. There are a few other authors who understand it, but we can't 
expect the average user to know these details.

> And even after that there may be glitches, especially when
> working with multiple frames.  For example, transferring focus from one
> frame to another, while a minibuffer interaction is in progress, is a
> hairy operation regardless of whether you use the standard setup, a
> top-level minibuffer(-only) frame or a minibuffer child frame.

Is there a problem in creating a minibuffer child frame for every frame?

>  > Alternatively, since you described what happens currently,
>  > pop-up-mini-mode could try to remember the current window
>  > configuration, create a new frame on the same position without a
>  > minibuffer, restore the window configuration there, and delete the
>  > original frame. Or is that something that could only happen during
>  > startup?
> 
> I would have to guess the user's intention here.  'pop-up-mini-mode'
> does not forbid a mixed mode where one frame uses its own minibuffer
> window for interaction and other frames want to use the more "global"
> minibuffer-only window 'pop-up-mini-mode' found when it started.

We don't have to support every possible intention, just the most likely 
one. The rest can be left for future development, or available as a 
customization option.

BTW, when you delete the initial frame at startup, is there a 
possibility to make in invisible at the start, so that it's actually 
never displayed, and when it's deleted, that blink doesn't happen?

> Also
> note that we have various strategies to assign the minibuffer window
> ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
> is more convoluted than it appears at first sight.

These are implementation options, right? Just pick the most appropriate.

>  > - pop-up-mini-mode is enabled in the user's init script. Is that worse
>  > than early init? We could try to document the early init as the best
>  > option.
> 
> It's not a good option if it fails for some reason.  On a TTY, say.

So pop-up-mini-mode would check if it's running on a terminal, and if 
so, abort with a message.

>  >> You would have to tell me more about that blink.  If it's due to the
>  >> setting of 'x-gtk-resize-child-frames', there's nothing I can do about
>  >> it.  If it's due to the delay implied by 'pop-up-mini-hide-if-empty',
>  >> try to experiment with that.
>  >
>  > My x-gtk-resize-child-frames value is 'resize-mode.
>  >
>  > Blinking happens when it's resized. But not every single time.
>  >
>  > Here's what I do:
>  >
>  > 1. src/emacs -Q --eval "(setq x-gtk-resize-child-frames 
> 'resize-mode)" -l ~/.emacs.d/site-lisp/pop-up-mini.el
>  >
>  > 2. M-x ido-mode.
>  >
>  > 3. C-x C-f, type 'e'. If you're inside Emacs source directory, the 
> completions should span 2-3 lines. When the child frame is resized, it 
> will blink. Sometimes it looks like the mode-line quickly moves up and 
> back (or at least _something_ grey moves like that).
> 
> I can't reproduce that here.  But I'm on xfce and currently can't test
> with GNOME shell which disabled itself during its never-ending attempts
> of unattended upgrades.

A full reinstall of a distro and/or switch to another one is out of the 
question, I take it?

I'm not sure it's a GNOME issue. It doesn't update itself: package 
managers do it.

>  > Instead of ido-mode, fido-mode can be used with similar effect. Though
>  > blinking seems less frequent with it.
> 
> Again, it would be interesting to know whether this happens with mutter
> only.

With Mutter only, or with GTK3 toolkit build only? I can make a build 
using a different toolkit, at least.

>  > Another issue: when the child frame covers the scroll bar, it renders 
> some junk on it.
> 
> The horizontal scroll bar?  That's where it is here all the time.

The vertical one. The child frame spans the whole width of the frame, 
and its right end overlaps the parent frame's scroll bar.

>  >> Not really enthusiastic.  The historical constraints of how to set up
>  >> and use the minibuffer window are too restrictive IMHO so what you see
>  >> here is just a workaround.  Maybe things will change in a couple of
>  >> years.
>  >
>  > Do you mean the child frame problems?
> 
> No.  I spent a couple of months in the intestines of the minibuffer
> window implementation and came to the conclusion that sooner or later it
> will break down under the load people are piling up on it.
> 
> Nobody here can tell you how many messages go by unnoticed in a session
> because one last message hides all the ones that were emitted earlier.
> And as soon as we start a minibuffer interaction, we enter an area where
> a message may temporarily obscure (or amend to?) parts of the text we
> just entered.  And all this happens because we got used to it over the
> decades like the frog being boiled alive.

I agree it's a problem, just don't see how it is a problem for this 
particular endeavor.

> What should be reformed here are two things:
> 
> - Break up the conflation of minibuffer and echo area you mentioned
>    earlier.
> 
> - Provide the possibility to make the minibuffer window temporarily
>    nonexistent (invisible or dead).
> 
> Both are hard to achieve.  The conflation was a premature optimization.
> People got used to it with the consequence that it will be very hard to
> dissolve it.  Having a minibuffer window always present is a restriction
> that is now "built in".  Dissolving it is hard because it would require
> to amend lots of code used to the fact that that window is always here.

Sounds like we're talking about low-level code only, right? Like prin1. 
I suspect there's a limited number of functions like that.

>  > BTW, here's a today's thread on Reddit with similar complaints by
>  > users:
>  > 
> https://www.reddit.com/r/emacs/comments/gmsnoy/minibufferecho_area_ergonomics/ 
> 
> 
> IIUC this one's about using Emacs on a TTY.  In that case
> minibuffer-only frames won't help anyway.
> 
>  > One suggestion option is this package: 
> https://github.com/muffinmad/emacs-mini-frame.
> 
> Years ago I wrote the code to put the minibuffer window on top of a
> frame - something which should work on TTYs as well.  But it's annoying:
> When resizing the minibuffer, the entire text in the windows beneath has
> to move up or down.  When the minibuffer window is at the bottom, the
> text in the windows above usually only gets truncated.

Right. That's a similar reason why I really want minibuffer out of the 
current frame: as soon as it gets multiline, window borders start 
jumping up and down.

>  > There are a few others with this goal as well. But none of them try to
>  > hide the minibuffer (or know that it's possible, looks like). They
>  > only create a child frame with an "effective" minibuffer, and position
>  > it to their liking. Whereas the minibuffer line is left untouched, and
>  > is only used as echo area.
> 
> It would be interesting to see a list of requirements for a practical
> solution to this problem.

Behavior-wise, I think we're fairly close already, but "the user has to 
get familiar with both, minibuffer windows and child frames, first" 
sounds like a deal-breaker.

Re: GNU Emacs raison d'etre

[martin rudalics]

 >>  > I've also noticed that initial blink during startup,

I forgot to ask what "startup" means here.  Invoking 'pop-up-mini-mode'
itself or starting a dialogue as with 'ido-mode'?

 >>  > but didn't know
 >>  > what to attribute it to. Would be great to be able to avoid it.
 >>
 >> Is this a blink that happens also when you do
 >>
 >> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
 >>
 >> or does it require the presence of a child frame?
 >
 > I couldn't manage to reproduce the bug there. Even with
 >>  > resize-mini-frames=t. But then, it doesn't resize as responsively as your code.

Why not?  The resizing step is quite the same.

 >> It's not as simple as that.  Users who want to use that mode have to
 >> make themselves familiar with child frames and minibuffer-only frames
 >> first.
 >
 > Please, no.
 >
 > You know the reason why we only fixed child frames under GNOME now? Or why packages using child frames only started to become popular?
 >
 > This is arcane stuff, and it took someone really motivated to turn the child frames support you created into a library every Emacs developer can use. There are a few other authors who understand it, but we can't expect the average user to know these details.

This is not about understanding the details.  If you want to use a mode
that is based on child frames and minibuffer-only frames, you first have
to know what kind of advantages these offer.  And both, package
developers and users, should be aware of the basic glitches that are to
be expected in this area.

Sometimes I'm not sure whether child frames are used only because they
are there.  Basically, child frames make sense only if any changes the
window manager applies to the parent frame (like deletion, iconifying,
changes of visibility, size or position including the z-order) should
automatically (without Emacs intervention) apply to the child frame too.
I added child frame support mainly because the handling of the signals
that come with any of these changes can be cumbersome and occasionally
even daunting.

Things a package could handle with a normal frame or a tooltip frame
should probably be done without child frames because, for example,
reparenting a child frame and fitting its size and position to the new
frame can be tricky.

 >> And even after that there may be glitches, especially when
 >> working with multiple frames.  For example, transferring focus from one
 >> frame to another, while a minibuffer interaction is in progress, is a
 >> hairy operation regardless of whether you use the standard setup, a
 >> top-level minibuffer(-only) frame or a minibuffer child frame.
 >
 > Is there a problem in creating a minibuffer child frame for every frame?

I had that in an initial version but it's unlikely that I can still find
the code.  By design, you can create and use an arbitrary number of
minibuffer frames.  The only problem is to find the right frame you want
to use and transfer the text you want to show there to it.

Note also that IIRC the text you see in a minibuffer window is sometimes
only available there and bears no relationship to any text stored in any
buffer (or at least the buffer whose contents the minibuffer window is
supposed to display).  The display engine automagically handles the
display and sometimes cancels the traces of the source it used (Eli will
correct me if I'm wrong).

 >> I would have to guess the user's intention here.  'pop-up-mini-mode'
 >> does not forbid a mixed mode where one frame uses its own minibuffer
 >> window for interaction and other frames want to use the more "global"
 >> minibuffer-only window 'pop-up-mini-mode' found when it started.
 >
 > We don't have to support every possible intention, just the most likely one. The rest can be left for future development, or available as a customization option.

Agreed.  And that's why users have to put the necessary customizations
in their init files and not simply call 'pop-up-mini-mode' from a
running session.  Although the latter might be a seductive way to test
it.

 > BTW, when you delete the initial frame at startup, is there a
 > possibility to make in invisible at the start, so that it's actually
 > never displayed, and when it's deleted, that blink doesn't happen?

You mean when Emacs starts in minibuffer-only mode, I presume.  It
should be possible but the following part

	    ;; If the frame isn't visible yet, wait till it is.
	    ;; If the user has to position the window,
	    ;; Emacs doesn't know its real position until
	    ;; the frame is seen to be visible.
	    (while (not (cdr (assq 'visibility
				   (frame-parameters frame-initial-frame))))
	      (sleep-for 1))

inhibits it currently.  The problem perceived here is that one cannot
derive the actual coordinates of a frame _before_ that frame was mapped
by the WM and mapping always means to make it visible.  OTOH the actual
coordinates of the minibuffer-equipped frame are needed to make the
minibuffer-only frame appear at the same position and with the
requested, properly modified size, taking the user customizations into
account.

 >> Also
 >> note that we have various strategies to assign the minibuffer window
 >> ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
 >> is more convoluted than it appears at first sight.
 >
 > These are implementation options, right? Just pick the most appropriate.

These are user options a user can change any time in a running session.

 >>  > - pop-up-mini-mode is enabled in the user's init script. Is that worse
 >>  > than early init? We could try to document the early init as the best
 >>  > option.
 >>
 >> It's not a good option if it fails for some reason.  On a TTY, say.
 >
 > So pop-up-mini-mode would check if it's running on a terminal, and if so, abort with a message.

But you don't like such aborts ...

 > A full reinstall of a distro and/or switch to another one is out of the question, I take it?
 >
 > I'm not sure it's a GNOME issue. It doesn't update itself: package managers do it.

Maybe it's a also just a GNOME on Debian (unstable) issue.  Installing
GNOME shell here as additional desktop forced me to install all sorts of
additional software amounting in sum to around one GB of code.  This
included games and horrific applications like tracker which I had a hard
time to switch off.  I'll eventually try to remove and reinstall it but
it's nothing for the faint at heart.

 > With Mutter only, or with GTK3 toolkit build only? I can make a build
 > using a different toolkit, at least.

Try both, if you can.

 >>  > Another issue: when the child frame covers the scroll bar, it renders some junk on it.
 >>
 >> The horizontal scroll bar?  That's where it is here all the time.
 >
 > The vertical one. The child frame spans the whole width of the frame, and its right end overlaps the parent frame's scroll bar.

I faintly recall to have seen this with GNOME shell.  Which means you
have to put it on the mode line or the horizontal scroll bar there.  Do
other child frames too have problems when covering the scroll bar?  What
happens with the scroll bar at the right?  What happens when the
minibuffer window has a scroll bar itself?

 > I agree it's a problem, just don't see how it is a problem for this particular endeavor.

Because "this particular endeavor" would then only serve to cover an
underlying, deeper-rooted problem and possibly postpone fixing that.

 > Sounds like we're talking about low-level code only, right? Like prin1. I suspect there's a limited number of functions like that.

High-level code - for example, code that wants to know the width of the
minibuffer window before putting things there.

 >> It would be interesting to see a list of requirements for a practical
 >> solution to this problem.
 >
 > Behavior-wise, I think we're fairly close already, but "the user has to get familiar with both, minibuffer windows and child frames, first" sounds like a deal-breaker.

I'd still like to see a list of what people really would like to see wrt
positioning and resizing the minibuffer window first.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 22.05.2020 12:31, martin rudalics wrote:
>  >>  > I've also noticed that initial blink during startup,
> 
> I forgot to ask what "startup" means here.  Invoking 'pop-up-mini-mode'
> itself or starting a dialogue as with 'ido-mode'?

Neither. Emacs startup, and the blink that comes with re-creating the 
frame. I just meant that I was going to talk about this at some later 
point, but now I didn't have to.

>  >>  > but didn't know
>  >>  > what to attribute it to. Would be great to be able to avoid it.
>  >>
>  >> Is this a blink that happens also when you do
>  >>
>  >> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
>  >>
>  >> or does it require the presence of a child frame?
>  >
>  > I couldn't manage to reproduce the bug there. Even with
>  >>  > resize-mini-frames=t. But then, it doesn't resize as responsively 
> as your code.
> 
> Why not?  The resizing step is quite the same.

One difference I noticed is that the child frame created by 
pop-up-mini-mode is constant width, but the mini-frame created by the 
above recipe updates its width dynamically as well. And always feels 
kinda cramped.

In any case, it really seems like the blink is due to how updating the 
size of the popup works: first, the buffer is updated (and redrawn), 
then the timer resizes the popup, and the buffer is redrawn again. Not 
sure what the better implementation is going to do, though.

>  > This is arcane stuff, and it took someone really motivated to turn 
> the child frames support you created into a library every Emacs 
> developer can use. There are a few other authors who understand it, but 
> we can't expect the average user to know these details.
> 
> This is not about understanding the details.  If you want to use a mode
> that is based on child frames and minibuffer-only frames, you first have
> to know what kind of advantages these offer.  And both, package
> developers and users, should be aware of the basic glitches that are to
> be expected in this area.

That could be described in the README, I suppose. And it's one thing to 
grasp the benefits/drawbacks, and another thing to know in advance how 
to set up a minibuffer-only frame for your own setup.

> Sometimes I'm not sure whether child frames are used only because they
> are there.

Well, why else? It's the only real way we have to implement "popup" 
windows. Too bad they don't work in the terminal.

> Basically, child frames make sense only if any changes the
> window manager applies to the parent frame (like deletion, iconifying,
> changes of visibility, size or position including the z-order) should
> automatically (without Emacs intervention) apply to the child frame too.
> I added child frame support mainly because the handling of the signals
> that come with any of these changes can be cumbersome and occasionally
> even daunting.

Makes sense.

> Things a package could handle with a normal frame or a tooltip frame
> should probably be done without child frames because, for example,
> reparenting a child frame and fitting its size and position to the new
> frame can be tricky.

Not sure how it's relevant to the package under discussion. The 
minibuffer frame I've tried with that default-frame-alist setup didn't 
really provide a good UI, looks or behavior-wise.

>  >> And even after that there may be glitches, especially when
>  >> working with multiple frames.  For example, transferring focus from one
>  >> frame to another, while a minibuffer interaction is in progress, is a
>  >> hairy operation regardless of whether you use the standard setup, a
>  >> top-level minibuffer(-only) frame or a minibuffer child frame.
>  >
>  > Is there a problem in creating a minibuffer child frame for every frame?
> 
> I had that in an initial version but it's unlikely that I can still find
> the code.  By design, you can create and use an arbitrary number of
> minibuffer frames.  The only problem is to find the right frame you want
> to use ...

Via... a frame parameter? OK, I'm probably not going to be very helpful 
here, at this level of discussion detail. If there are specific hard 
problems with repro senarios, I could try to take a look later, but I'm 
only interested in going in this direction if our goal is to make a 
package for a broad audience.

Anyway, having glitches could be fine if they are outside of the main 
usage scenarios and/or well-understood and documented.

> Note also that IIRC the text you see in a minibuffer window is sometimes
> only available there and bears no relationship to any text stored in any
> buffer (or at least the buffer whose contents the minibuffer window is
> supposed to display).  The display engine automagically handles the
> display and sometimes cancels the traces of the source it used (Eli will
> correct me if I'm wrong).

That's um, sounds like space for improvement.

>  >> I would have to guess the user's intention here.  'pop-up-mini-mode'
>  >> does not forbid a mixed mode where one frame uses its own minibuffer
>  >> window for interaction and other frames want to use the more "global"
>  >> minibuffer-only window 'pop-up-mini-mode' found when it started.
>  >
>  > We don't have to support every possible intention, just the most 
> likely one. The rest can be left for future development, or available as 
> a customization option.
> 
> Agreed.  And that's why users have to put the necessary customizations
> in their init files and not simply call 'pop-up-mini-mode' from a
> running session.  Although the latter might be a seductive way to test
> it.

Are you sure this customization couldn't be applied by pop-up-mini-mode? 
Alternatively, it could be a setup function.

>  > BTW, when you delete the initial frame at startup, is there a
>  > possibility to make in invisible at the start, so that it's actually
>  > never displayed, and when it's deleted, that blink doesn't happen?
> 
> You mean when Emacs starts in minibuffer-only mode, I presume.  It
> should be possible but the following part
> 
>          ;; If the frame isn't visible yet, wait till it is.
>          ;; If the user has to position the window,
>          ;; Emacs doesn't know its real position until
>          ;; the frame is seen to be visible.
>          (while (not (cdr (assq 'visibility
>                     (frame-parameters frame-initial-frame))))
>            (sleep-for 1))
> 
> inhibits it currently.  The problem perceived here is that one cannot
> derive the actual coordinates of a frame _before_ that frame was mapped
> by the WM and mapping always means to make it visible.

What about full transparency, then?

> OTOH the actual
> coordinates of the minibuffer-equipped frame are needed to make the
> minibuffer-only frame appear at the same position and with the
> requested, properly modified size, taking the user customizations into
> account.

The minibuffer-only frame which is immediately hidden itself while 
pop-up-mini-mode is active?

>  >> Also
>  >> note that we have various strategies to assign the minibuffer window
>  >> ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
>  >> is more convoluted than it appears at first sight.
>  >
>  > These are implementation options, right? Just pick the most appropriate.
> 
> These are user options a user can change any time in a running session.

Perhaps we can say that they shouldn't.

>  >>  > - pop-up-mini-mode is enabled in the user's init script. Is that 
> worse
>  >>  > than early init? We could try to document the early init as the best
>  >>  > option.
>  >>
>  >> It's not a good option if it fails for some reason.  On a TTY, say.
>  >
>  > So pop-up-mini-mode would check if it's running on a terminal, and if 
> so, abort with a message.
> 
> But you don't like such aborts ...

I don't like abort which presume a lot of prior knowledge and/or manual 
setup.

"Sorry, pop-up-mini-mode is not supported in a terminal" sounds just 
fine to me. There's nothing else to do anyway.

>  > A full reinstall of a distro and/or switch to another one is out of 
> the question, I take it?
>  >
>  > I'm not sure it's a GNOME issue. It doesn't update itself: package 
> managers do it.
> 
> Maybe it's a also just a GNOME on Debian (unstable) issue.  Installing
> GNOME shell here as additional desktop forced me to install all sorts of
> additional software amounting in sum to around one GB of code.  This
> included games and horrific applications like tracker which I had a hard
> time to switch off.  I'll eventually try to remove and reinstall it but
> it's nothing for the faint at heart.

There's also the option to use a virtual machine. Provided the 
"physical" machine is fast enough.

>  > With Mutter only, or with GTK3 toolkit build only? I can make a build
>  > using a different toolkit, at least.
> 
> Try both, if you can.

With Lucid, the blink is the same.

>  >>  > Another issue: when the child frame covers the scroll bar, it 
> renders some junk on it.
>  >>
>  >> The horizontal scroll bar?  That's where it is here all the time.
>  >
>  > The vertical one. The child frame spans the whole width of the frame, 
> and its right end overlaps the parent frame's scroll bar.
> 
> I faintly recall to have seen this with GNOME shell.  Which means you
> have to put it on the mode line or the horizontal scroll bar there.  Do
> other child frames too have problems when covering the scroll bar?  What
> happens with the scroll bar at the right?  What happens when the
> minibuffer window has a scroll bar itself?

I have just tried company-posframe, which renders its popup through the 
posframe package, and could find such artifacts, even when the popup 
overlapped the right scroll bar.

The minibuffer child frame from pop-up-mini-mode seemed to show glitches 
like that when it was resized, to accommodate multiple lines.

>  > I agree it's a problem, just don't see how it is a problem for this 
> particular endeavor.
> 
> Because "this particular endeavor" would then only serve to cover an
> underlying, deeper-rooted problem and possibly postpone fixing that.

I wonder if anyone would be working on it at all, if we weren't talking 
about it here.

>  > Sounds like we're talking about low-level code only, right? Like 
> prin1. I suspect there's a limited number of functions like that.
> 
> High-level code - for example, code that wants to know the width of the
> minibuffer window before putting things there.

OK. I've seen problems of this sort.

>  >> It would be interesting to see a list of requirements for a practical
>  >> solution to this problem.
>  >
>  > Behavior-wise, I think we're fairly close already, but "the user has 
> to get familiar with both, minibuffer windows and child frames, first" 
> sounds like a deal-breaker.
> 
> I'd still like to see a list of what people really would like to see wrt
> positioning and resizing the minibuffer window first.

Does the list at the bottom here look useful? 
https://github.com/honmaple/emacs-maple-minibuffer/#maple-minibufferpostion-type 


If we had something like that, as well as automatic resizing of the 
minibuffer popup without blinking, that would be great. Especially if 
the result worked fine with packages such as icomplete-vertical-mode.

Re: GNU Emacs raison d'etre

[martin rudalics]

 >> I forgot to ask what "startup" means here.  Invoking 'pop-up-mini-mode'
 >> itself or starting a dialogue as with 'ido-mode'?
 >
 > Neither. Emacs startup, and the blink that comes with re-creating the frame. I just meant that I was going to talk about this at some later point, but now I didn't have to.
...
 >
 >>  >>  > but didn't know
 >>  >>  > what to attribute it to. Would be great to be able to avoid it.
 >>  >>
 >>  >> Is this a blink that happens also when you do
 >>  >>
 >>  >> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
 >>  >>
 >>  >> or does it require the presence of a child frame?
 >>  >
 >>  > I couldn't manage to reproduce the bug there.

I'm confused.  When you do

emacs -Q --eval "(setq initial-frame-alist '((minibuffer . nil)))"

you do not see any "blink".  Right?  When instead you do

emacs -Q --eval "(setq initial-frame-alist '((minibuffer . child-frame)))"

do you see the blink?  Finally, when you do

emacs -Q --load ~/pop-up-mini.el

you see a blink.  Right?

 > One difference I noticed is that the child frame created by
 > pop-up-mini-mode is constant width,

I don't understand.  Here it changes its width together with its parent
frame.

 > but the mini-frame created by the
 > above recipe updates its width dynamically as well

Why "as well" if the pop-up-mini-mode child frame is _constant_ width?

 > . And always feels kinda cramped.

Which one is cramped?  The normal minibuffer-only frame?

 > In any case, it really seems like the blink is due to how updating the size of the popup works: first, the buffer is updated (and redrawn), then the timer resizes the popup, and the buffer is redrawn again. Not sure what the better implementation is going to do, though.

There is one problem you cannot avoid: You have to know the size of the
minibuffer text before resizing its frame and only after that you can
determine its position (within the display or its parent frame).

 > Well, why else? It's the only real way we have to implement "popup" windows. Too bad they don't work in the terminal.

We could do that just as we pop up menus in a terminal.  But such popup
windows would be modal - you cannot really pop them down to see the text
beneath them.

 > Not sure how it's relevant to the package under discussion. The minibuffer frame I've tried with that default-frame-alist setup didn't really provide a good UI, looks or behavior-wise.

The (minibuffer . nil) one or the (minibuffer . child-frame) one?

 >>  > Is there a problem in creating a minibuffer child frame for every frame?
 >>
 >> I had that in an initial version but it's unlikely that I can still find
 >> the code.  By design, you can create and use an arbitrary number of
 >> minibuffer frames.  The only problem is to find the right frame you want
 >> to use ...
 >
 > Via... a frame parameter? OK, I'm probably not going to be very helpful here, at this level of discussion detail. If there are specific hard problems with repro senarios, I could try to take a look later, but I'm only interested in going in this direction if our goal is to make a package for a broad audience.

Currently, every frame must have a corresponding minibuffer window.  If
you have more than one minibuffer window at hand, you have to decide
which one to choose.  For example, with (minibuffer . child-frame) the
situation is clear - the minibuffer window of each frame is that of its
minibuffer child frame.

 >> Agreed.  And that's why users have to put the necessary customizations
 >> in their init files and not simply call 'pop-up-mini-mode' from a
 >> running session.  Although the latter might be a seductive way to test
 >> it.
 >
 > Are you sure this customization couldn't be applied by pop-up-mini-mode? Alternatively, it could be a setup function.

In practice 'pop-up-mini-mode' is simply not something that comes up
without customizations in your init file or by calling it from the
command line.  The reason is the one explained before: You cannot
convert a minibuffer-equipped frame into a minibuffer-less frame (or do
the opposite).  The same holds for (minibuffer . child-frame) and
(minibuffer . nil) setups.

 >>  > BTW, when you delete the initial frame at startup, is there a
 >>  > possibility to make in invisible at the start, so that it's actually
 >>  > never displayed, and when it's deleted, that blink doesn't happen?
 >>
 >> You mean when Emacs starts in minibuffer-only mode, I presume.  It
 >> should be possible but the following part
 >>
 >>          ;; If the frame isn't visible yet, wait till it is.
 >>          ;; If the user has to position the window,
 >>          ;; Emacs doesn't know its real position until
 >>          ;; the frame is seen to be visible.
 >>          (while (not (cdr (assq 'visibility
 >>                     (frame-parameters frame-initial-frame))))
 >>            (sleep-for 1))
 >>
 >> inhibits it currently.  The problem perceived here is that one cannot
 >> derive the actual coordinates of a frame _before_ that frame was mapped
 >> by the WM and mapping always means to make it visible.
 >
 > What about full transparency, then?

You mean we should come up with a fully transparent frame first, resize
it and make it opaque then.  I never played around with that but note
that this would require a compositing window manager and not all of them
support transparency of child frames.

 >> OTOH the actual
 >> coordinates of the minibuffer-equipped frame are needed to make the
 >> minibuffer-only frame appear at the same position and with the
 >> requested, properly modified size, taking the user customizations into
 >> account.
 >
 > The minibuffer-only frame which is immediately hidden itself while pop-up-mini-mode is active?

The "normal" frame.  Note that you have to delete the old
minibuffer-equipped frame created initially and then replace it with an
"as similar as possible" minibuffer-less frame.  Look at the code of
'frame-notice-user-settings'.

 >>  >> Also
 >>  >> note that we have various strategies to assign the minibuffer window
 >>  >> ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
 >>  >> is more convoluted than it appears at first sight.
 >>  >
 >>  > These are implementation options, right? Just pick the most appropriate.
 >>
 >> These are user options a user can change any time in a running session.
 >
 > Perhaps we can say that they shouldn't.

I think they do already.

 >> But you don't like such aborts ...
 >
 > I don't like abort which presume a lot of prior knowledge and/or manual setup.
 >
 > "Sorry, pop-up-mini-mode is not supported in a terminal" sounds just fine to me. There's nothing else to do anyway.

It means that when you customize the minibuffer behavior in your init
file, you will have to take into account whether you are going to work
on a terminal or a GUI or maybe both.

 > With Lucid, the blink is the same.

OK.  IIRC you had some old machine somewhere with a non-mutter WM ...

 > I have just tried company-posframe, which renders its popup through the posframe package, and could find such artifacts, even when the popup overlapped the right scroll bar.

"could find" or "could not find"?

 > The minibuffer child frame from pop-up-mini-mode seemed to show glitches like that when it was resized, to accommodate multiple lines.

Glitches with the scroll bar?

 >> I'd still like to see a list of what people really would like to see wrt
 >> positioning and resizing the minibuffer window first.
 >
 > Does the list at the bottom here look useful? https://github.com/honmaple/emacs-maple-minibuffer/#maple-minibufferpostion-type

You mean the list of positions?  We can add that to 'pop-up-mini-mode'
if we make sure that the child frame always fits into its parent.
Although we do not care much about the size of the minibuffer window of
a minibuffer-equipped frame when that frame gets very small either.

 > If we had something like that, as well as automatic resizing of the minibuffer popup without blinking, that would be great. Especially if the result worked fine with packages such as icomplete-vertical-mode.

Since I already don't use icomplete investigating the latter would be
quite demanding for me.  Does 'icomplete-vertical-mode' have problems
with Emacs' default minibuffer layout?

martin

pop-up-mini-mode, was Re: GNU Emacs raison d'etre

[Dmitry Gutov]

Hi Martin,

Sorry for the late response. A detailed reply below.

On 26.05.2020 11:06, martin rudalics wrote:
>  >> I forgot to ask what "startup" means here.  Invoking 'pop-up-mini-mode'
>  >> itself or starting a dialogue as with 'ido-mode'?
>  >
>  > Neither. Emacs startup, and the blink that comes with re-creating the 
> frame. I just meant that I was going to talk about this at some later 
> point, but now I didn't have to.
> ...
>  >
>  >>  >>  > but didn't know
>  >>  >>  > what to attribute it to. Would be great to be able to avoid it.
>  >>  >>
>  >>  >> Is this a blink that happens also when you do
>  >>  >>
>  >>  >> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
>  >>  >>
>  >>  >> or does it require the presence of a child frame?
>  >>  >
>  >>  > I couldn't manage to reproduce the bug there.
> 
> I'm confused.  When you do
> 
> emacs -Q --eval "(setq initial-frame-alist '((minibuffer . nil)))"
> 
> you do not see any "blink".  Right?  When instead you do
> 
> emacs -Q --eval "(setq initial-frame-alist '((minibuffer . child-frame)))"
> 
> do you see the blink?  Finally, when you do
> 
> emacs -Q --load ~/pop-up-mini.el
> 
> you see a blink.  Right?

The "blink" is present in all cases. They all delete the original frame 
to create one without minibuffer, right?

>  > One difference I noticed is that the child frame created by
>  > pop-up-mini-mode is constant width,
> 
> I don't understand.  Here it changes its width together with its parent
> frame.

Okay, it's "constant" width. I don't really change the width of the 
frame often. It's the with of the frame.

>  > but the mini-frame created by the
>  > above recipe updates its width dynamically as well
> 
> Why "as well" if the pop-up-mini-mode child frame is _constant_ width?

Updates its width "as well as" its height, sorry, that was probably unclear.

Either resize-mini-frames is nil, and neither dimension updates 
automatically (meaning the height always stays = 1), or both dimensions 
update automatically, and the width follows the width of the prompt + 
input, and that...

>  > . And always feels kinda cramped.
> 
> Which one is cramped?  The normal minibuffer-only frame?

...feels "cramped". Yes, the (minibuffer . nil) case.

Setting this variable to 't' also has the effect of the minibuffer frame 
starting to "drift" across the desktop. It's probable the same issue 
we've seen with moving frames in GNOME Shell.

>  > In any case, it really seems like the blink is due to how updating 
> the size of the popup works: first, the buffer is updated (and redrawn), 
> then the timer resizes the popup, and the buffer is redrawn again. Not 
> sure what the better implementation is going to do, though.
> 
> There is one problem you cannot avoid: You have to know the size of the
> minibuffer text before resizing its frame and only after that you can
> determine its position (within the display or its parent frame).

I have run with pop-up-mini-mode for a few days, and not I think I have 
a different conclusion: there must be at least one other bug in there, 
and that one could be contributing the most annoying part of the effect:

When the aforementioned "blink" happens, it looks like the mode-line 
itself "blinks" (the one that resides just below the child frame). It's 
too fast to see for sure, but it seems like it travels up and then back 
(meaning, the window dimensions change briefly, making the window 
shorter by the same several lines). Maybe it tries to "give way" to the 
phantom minibuffer which used to be below it?

When it doesn't, the resizing of the child frame happens fairly 
smoothly. So if the aforementioned effect is fixed, that would be a 
significant win.

>  > Well, why else? It's the only real way we have to implement "popup" 
> windows. Too bad they don't work in the terminal.
> 
> We could do that just as we pop up menus in a terminal.

Perhaps Someone (sorry) could start working on that? Then we could 
finally have a popup library that can be used both in terminal and 
graphical Emacs. That would be a significant win. I would certainly

> But such popup
> windows would be modal - you cannot really pop them down to see the text
> beneath them.

IME child frames are also always used to create modal popups.

>  > Not sure how it's relevant to the package under discussion. The 
> minibuffer frame I've tried with that default-frame-alist setup didn't 
> really provide a good UI, looks or behavior-wise.
> 
> The (minibuffer . nil) one or the (minibuffer . child-frame) one?

I meant the first one, but neither really works well as a minibuffer 
replacement. The latter is also not very usable without the tweaks in 
popup-up-mini.el.

>  > Via... a frame parameter? OK, I'm probably not going to be very 
> helpful here, at this level of discussion detail. If there are specific 
> hard problems with repro senarios, I could try to take a look later, but 
> I'm only interested in going in this direction if our goal is to make a 
> package for a broad audience.
> 
> Currently, every frame must have a corresponding minibuffer window.  If
> you have more than one minibuffer window at hand, you have to decide
> which one to choose.  For example, with (minibuffer . child-frame) the
> situation is clear - the minibuffer window of each frame is that of its
> minibuffer child frame.

I don't know the low level details, but as long as the child frames 
themselves don't get focus (hopefully all window managers we want to 
support have provisions to enable that), switching the focus between 
frames should be doable. At least in theory.

>  >> Agreed.  And that's why users have to put the necessary customizations
>  >> in their init files and not simply call 'pop-up-mini-mode' from a
>  >> running session.  Although the latter might be a seductive way to test
>  >> it.
>  >
>  > Are you sure this customization couldn't be applied by 
> pop-up-mini-mode? Alternatively, it could be a setup function.
> 
> In practice 'pop-up-mini-mode' is simply not something that comes up
> without customizations in your init file or by calling it from the
> command line.  The reason is the one explained before: You cannot
> convert a minibuffer-equipped frame into a minibuffer-less frame (or do
> the opposite).  The same holds for (minibuffer . child-frame) and
> (minibuffer . nil) setups.

Even if you can't get all the benefits of pop-up-mini-mode for old 
frames (ones that were created before it was enabled), it would be 
better to enable customizations inside the mode. They would apply 
transparently when the mode is enabled, but otherwise stay out of the 
user's custom file.

Also, I think I suggested the trick of re-creating existing frames with 
minibuffers disabled (following what Emacs already does when the 
minibuffer is customized to be in a dedicated frame)? That should work, 
and even the ensuing "blinking" shouldn't be much of annoyance, given it 
will happen in response to an explicit user command.

>  >> inhibits it currently.  The problem perceived here is that one cannot
>  >> derive the actual coordinates of a frame _before_ that frame was mapped
>  >> by the WM and mapping always means to make it visible.
>  >
>  > What about full transparency, then?
> 
> You mean we should come up with a fully transparent frame first, resize
> it and make it opaque then.  I never played around with that but note
> that this would require a compositing window manager and not all of them
> support transparency of child frames.

Something like that.

Given that this blinking happens only once per "real" frame, and it's a 
purely visual annoyance, I think it might be okay even if only a 
fraction of our users will benefit. I kinda managed to get used to this 
particular blinking after a few days.

>  >> OTOH the actual
>  >> coordinates of the minibuffer-equipped frame are needed to make the
>  >> minibuffer-only frame appear at the same position and with the
>  >> requested, properly modified size, taking the user customizations into
>  >> account.
>  >
>  > The minibuffer-only frame which is immediately hidden itself while 
> pop-up-mini-mode is active?
> 
> The "normal" frame.  Note that you have to delete the old
> minibuffer-equipped frame created initially and then replace it with an
> "as similar as possible" minibuffer-less frame.  Look at the code of
> 'frame-notice-user-settings'.

Makes sense, yes. The "full transparency" idea could help, I think.

>  >>  >> Also
>  >>  >> note that we have various strategies to assign the minibuffer 
> window
>  >>  >> ('set-minibuffer-window', the 'minibuffer' frame parameter) so 
> all this
>  >>  >> is more convoluted than it appears at first sight.
>  >>  >
>  >>  > These are implementation options, right? Just pick the most 
> appropriate.
>  >>
>  >> These are user options a user can change any time in a running session.
>  >
>  > Perhaps we can say that they shouldn't.
> 
> I think they do already.

The users that do, will read the fine print in the package's 
description. The majority doesn't touch these functions (I haven't, in 
the many years of using Emacs), and if the package is going to work for 
them out of the box, it's a win.

>  >> But you don't like such aborts ...
>  >
>  > I don't like abort which presume a lot of prior knowledge and/or 
> manual setup.
>  >
>  > "Sorry, pop-up-mini-mode is not supported in a terminal" sounds just 
> fine to me. There's nothing else to do anyway.
> 
> It means that when you customize the minibuffer behavior in your init
> file, you will have to take into account whether you are going to work
> on a terminal or a GUI or maybe both.

Again, I wish we could do it more automatically.

Otherwise the fraction of our users who can benefit from this is going 
to be severely limited.

>  > With Lucid, the blink is the same.
> 
> OK.  IIRC you had some old machine somewhere with a non-mutter WM ...

Okay, booted it up. The machine has Unity installed, which uses Compiz.

And a last year's build of Emacs 27.

The "mode-line traveling" blinking is there. Just barely perceptible, 
because apparently Compiz is faster at rendering (on an older machine) 
than GNOME Shell released last year.

It also happens less frequently there: I only managed to reproduce it 
like 5 times out of 30 tries (with my init script). And with 'emacs -Q', 
it's harder to catch, I manage to see this like 3 times out of 20 tries.

The scenario, to recap:

1. cd ~/vc/emacs-master (adjust your directory accordingly)
2. M-x ido-mode.
3. C-x C-f e (the minibuffer should grow in size to like 3 lines; if it 
doesn't, change the size of the window).
4. If you saw the mode-line blink, good, if not, C-g and repeat.

And hot on the heels of this scenario, another annoyance:

When I do press C-g on step 4, first the child frame resizes to 1 line 
height, then some text flashes on it (the previous contents of the 
minibuffer? the current ones?), and only then it finally settles on the 
empty line with the word "Quit". That happens every time. I wonder if 
that could be improved, too.

>  > I have just tried company-posframe, which renders its popup through 
> the posframe package, and could find such artifacts, even when the popup 
> overlapped the right scroll bar.
> 
> "could find" or "could not find"?

Sorry, could not find.

>  > The minibuffer child frame from pop-up-mini-mode seemed to show 
> glitches like that when it was resized, to accommodate multiple lines.
> 
> Glitches with the scroll bar?

Yes. They weren't there with posframe.

But I just tried to reproduce these scroll bar glitches with with 
x-gtk-resize-child-frames=resize-mode, and couldn't, in ant of the 
configurations. And posframe sets up this variable's value, so that's 
probably it.

>  >> I'd still like to see a list of what people really would like to see 
> wrt
>  >> positioning and resizing the minibuffer window first.
>  >
>  > Does the list at the bottom here look useful? 
> https://github.com/honmaple/emacs-maple-minibuffer/#maple-minibufferpostion-type 
> 
> You mean the list of positions?  We can add that to 'pop-up-mini-mode'
> if we make sure that the child frame always fits into its parent.
> Although we do not care much about the size of the minibuffer window of
> a minibuffer-equipped frame when that frame gets very small either.

I meant, does that list answer your question? The one about "what people 
really would like to see wrt positioning and resizing the minibuffer 
window".

>  > If we had something like that, as well as automatic resizing of the 
> minibuffer popup without blinking, that would be great. Especially if 
> the result worked fine with packages such as icomplete-vertical-mode.
> 
> Since I already don't use icomplete investigating the latter would be
> quite demanding for me.

What do you use? M-x icomplete-mode is a trivial command, and it should 
be unobtrusive even if you're used to the default completion.

> Does 'icomplete-vertical-mode' have problems
> with Emacs' default minibuffer layout?

It has problems with every child frame based minibuffer emulation 
package that I have tried. But no problems with Emacs' default minibuffer.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > Now that we have set-message-function and clear-message-function, couldn't you move message display somewhere else?

I tried that now but it doesn't work.  Probably because
'set-message-function' works for non-logged messages only.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 19.05.2020 11:40, martin rudalics wrote:
>  > Now that we have set-message-function and clear-message-function, 
> couldn't you move message display somewhere else?
> 
> I tried that now but it doesn't work.  Probably because
> 'set-message-function' works for non-logged messages only.

Is that right? I don't see this distinction in its documentation.

Re: GNU Emacs raison d'etre

[martin rudalics]

 >> I tried that now but it doesn't work.  Probably because
 >> 'set-message-function' works for non-logged messages only.
 >
 > Is that right? I don't see this distinction in its documentation.

set_message in xdisp.c (which here is the only function that handles
Vset_message_function) is called by message3_nolog but not by message3.
I have no idea whether this is by design.  Maybe I'm missing something.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 12:04, martin rudalics wrote:
>  >> I tried that now but it doesn't work.  Probably because
>  >> 'set-message-function' works for non-logged messages only.
>  >
>  > Is that right? I don't see this distinction in its documentation.
> 
> set_message in xdisp.c (which here is the only function that handles
> Vset_message_function) is called by message3_nolog but not by message3.
> I have no idea whether this is by design.  Maybe I'm missing something.

Maybe Juri could elaborate?

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>,
>  Richard Stallman <rms@gnu.org>, Andreas Röhler
>  <andreas.roehler@online.de>, Emacs developers <emacs-devel@gnu.org>,
>  Karl Fogel <kfogel@red-bean.com>, homeros.misasa@gmail.com,
>  tkk@misasa.okayama-u.ac.jp, Sergey Organov <sorganov@gmail.com>,
>  Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 20 May 2020 11:04:41 +0200
> 
>  >> I tried that now but it doesn't work.  Probably because
>  >> 'set-message-function' works for non-logged messages only.
>  >
>  > Is that right? I don't see this distinction in its documentation.
> 
> set_message in xdisp.c (which here is the only function that handles
> Vset_message_function) is called by message3_nolog but not by message3.
> I have no idea whether this is by design.

It's by design: that facility is supposed to control only how the
messages are _displayed_; the logging mechanism is unaffected.  the
doc string says that much:

  If non-nil, function to handle display of echo-area messages.

Note the "display" part.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 17:45, Eli Zaretskii wrote:
> It's by design: that facility is supposed to control only how the
> messages are_displayed_; the logging mechanism is unaffected.  the
> doc string says that much:
> 
>    If non-nil, function to handle display of echo-area messages.
> 
> Note the "display" part.

But it should still affect how the _logged_ messages are displayed, right?

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: drew.adams@oracle.com, arthur.miller@live.com, monnier@iro.umontreal.ca,
>  jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, sorganov@gmail.com,
>  stefankangas@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 20 May 2020 17:56:44 +0300
> 
> >    If non-nil, function to handle display of echo-area messages.
> > 
> > Note the "display" part.
> 
> But it should still affect how the _logged_ messages are displayed, right?

I don't think I understand the question.  A message is first logged
(unless logging is disabled) and then displayed.  set-message-function
is called during the latter part.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > I don't think I understand the question.  A message is first logged
 > (unless logging is disabled) and then displayed.  set-message-function
 > is called during the latter part.

Right.  Then I'm lost.  With either

(defun my-fun (string) "")

or

(defun my-fun (string) t)

and

(setq set-message-function 'my-fun)

(message "?") displays "?".  What am I doing wrong?

martin

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, sorganov@gmail.com,
>  monnier@iro.umontreal.ca, arthur.miller@live.com, drew.adams@oracle.com,
>  stefankangas@gmail.com
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 20 May 2020 19:45:38 +0200
> 
> Right.  Then I'm lost.  With either
> 
> (defun my-fun (string) "")
> 
> or
> 
> (defun my-fun (string) t)
> 
> and
> 
> (setq set-message-function 'my-fun)
> 
> (message "?") displays "?".  What am I doing wrong?

You are evaluation the call to 'message', so the return value is
printed in the echo-area by the evaluation.  The telltale quotes are
the indication of that.

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Date: Wed, 20 May 2020 21:09:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, sorganov@gmail.com,
>  monnier@iro.umontreal.ca, arthur.miller@live.com, dgutov@yandex.ru,
>  drew.adams@oracle.com, stefankangas@gmail.com
> 
> You are evaluation the call to 'message', so the return value is
          ^^^^^^^^^^
"evaluating", sorry

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 21:09, Eli Zaretskii wrote:
> You are evaluation the call to 'message', so the return value is
> printed in the echo-area by the evaluation.  The telltale quotes are
> the indication of that.

Shouldn't it just use my-fun for printing?

Even the results of evaluations.

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, sorganov@gmail.com,
>  monnier@iro.umontreal.ca, arthur.miller@live.com, drew.adams@oracle.com,
>  stefankangas@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 20 May 2020 21:24:06 +0300
> 
> On 20.05.2020 21:09, Eli Zaretskii wrote:
> > You are evaluation the call to 'message', so the return value is
> > printed in the echo-area by the evaluation.  The telltale quotes are
> > the indication of that.
> 
> Shouldn't it just use my-fun for printing?
> 
> Even the results of evaluations.

Why?

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Date: Wed, 20 May 2020 21:33:27 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  rudalics@gmx.at, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp,
>  sorganov@gmail.com, monnier@iro.umontreal.ca, arthur.miller@live.com,
>  drew.adams@oracle.com, stefankangas@gmail.com
> 
> > Shouldn't it just use my-fun for printing?
> > 
> > Even the results of evaluations.
> 
> Why?

To clarify: set-message-function is not supposed to affect all the
ways we have to show something in the echo area, it is only supposed
to affect calls to 'message', because that's how messages to the user
are printed.

eval-last-sexp uses prin1 to display the result, so it is not
affected, as intended.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 21:56, Eli Zaretskii wrote:
> To clarify: set-message-function is not supposed to affect all the
> ways we have to show something in the echo area, it is only supposed
> to affect calls to 'message', because that's how messages to the user
> are printed.
> 
> eval-last-sexp uses prin1 to display the result, so it is not
> affected, as intended.

But aren't all echo area displays targeted at the user anyway?

I'm not saying the current behavior is necessarily "broken", but perhaps 
we could enhance it further.

Re: GNU Emacs raison d'etre

[tomas]

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

On Wed, May 20, 2020 at 10:22:53PM +0300, Dmitry Gutov wrote:
> On 20.05.2020 21:56, Eli Zaretskii wrote:
> >To clarify: set-message-function is not supposed to affect all the
> >ways we have to show something in the echo area, it is only supposed
> >to affect calls to 'message', because that's how messages to the user
> >are printed.
> >
> >eval-last-sexp uses prin1 to display the result, so it is not
> >affected, as intended.
> 
> But aren't all echo area displays targeted at the user anyway?
> 
> I'm not saying the current behavior is necessarily "broken", but
> perhaps we could enhance it further.

Sorry, I don't quite understand. You are proposing that message-fun
should not only take over messages proper but also the repl's print?

Because (message "foo") displays foo twice (well once it's foo, as
a side effect, then it's "foo", as the repl's "print" part, as the
result of the S-expression's evaluation.

FWIW, I'd expect setting set-message-function (strange name for a
var, BTW) to just take over the side effect, not the repl's "print".

But that's just one data point.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 20.05.2020 22:53, tomas@tuxteam.de wrote:
> Sorry, I don't quite understand. You are proposing that message-fun
> should not only take over messages proper but also the repl's print?

Yes, why not?

> Because (message "foo") displays foo twice (well once it's foo, as
> a side effect, then it's "foo", as the repl's "print" part, as the
> result of the S-expression's evaluation.

When it is evaluated in the REPL, yes. Because you're seeing both the 
result of 'message' itself, as well as the result of eval-expression.

> FWIW, I'd expect setting set-message-function (strange name for a
> var, BTW) to just take over the side effect, not the repl's "print".

Do you have an example of set-message-function where it would be a bad idea?

Re: GNU Emacs raison d'etre

[tomas]

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

On Thu, May 21, 2020 at 12:22:04AM +0300, Dmitry Gutov wrote:
> On 20.05.2020 22:53, tomas@tuxteam.de wrote:
> >Sorry, I don't quite understand. You are proposing that message-fun
> >should not only take over messages proper but also the repl's print?
> 
> Yes, why not?

I think, at the end it's a matter of taste/expectations, so
don't attach too much weight to mine.

> >Because (message "foo") displays foo twice [...]

> When it is evaluated in the REPL, yes. Because you're seeing both
> the result of 'message' itself, as well as the result of
> eval-expression.

Exactly. And I'd expect `set-message-function' to only touch the
`(message)' part -- but see above.

> Do you have an example of set-message-function where it would be a bad idea?

Hm. I don't quite understand your question: I suspect that we're
talking past each other, but I can't yet grasp how.

It's not "examples" I'd looking for. It's just that in my head,
the "print" of REPL and the "message" are two different things,
and should be controlled by different knobs.

But, as I said above, it's something rather subjective.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  rudalics@gmx.at, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp,
>  sorganov@gmail.com, monnier@iro.umontreal.ca, arthur.miller@live.com,
>  drew.adams@oracle.com, stefankangas@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 20 May 2020 22:22:53 +0300
> 
> > eval-last-sexp uses prin1 to display the result, so it is not
> > affected, as intended.
> 
> But aren't all echo area displays targeted at the user anyway?
> 
> I'm not saying the current behavior is necessarily "broken", but perhaps 
> we could enhance it further.

The intent was to affect messages that are a "surprise" for the user.
eval-last-sexp is invoked by the user, so no surprise here.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 21.05.2020 05:28, Eli Zaretskii wrote:
>>> eval-last-sexp uses prin1 to display the result, so it is not
>>> affected, as intended.
>> But aren't all echo area displays targeted at the user anyway?
>>
>> I'm not saying the current behavior is necessarily "broken", but perhaps
>> we could enhance it further.
> The intent was to affect messages that are a "surprise" for the user.
> eval-last-sexp is invoked by the user, so no surprise here.

But not all 'message' calls are a "surprise". One might even say that 
the vast majority of them aren't. And yet, they obey set-message-function.

eval-last-sexp uses 'prin1' under the covers. While it's different from 
'message', it's not entirely clear to me that it's intended to be 
different semantically, e.g. used for distinctly different purposes. So 
I might as well imagine the same code that calls 'message' decide at 
some point to call 'prin1' (in addition to 'message', or instead).

Looking at its description, it could delegate to 'standard-output', 
which is overridable. It's not particularly convenient, though.

But this patch would do it:

@@ -1132,7 +1132,7 @@
      ;; Setup the lexical environment if lexical-binding is enabled.
      (elisp--eval-last-sexp-print-value
       (eval (eval-sexp-add-defvars (elisp--preceding-sexp)) 
lexical-binding)
-     (if insert-value (current-buffer) t) no-truncate char-print-limit)))
+     (if insert-value (current-buffer)) no-truncate char-print-limit)))

  (defun elisp--eval-last-sexp-print-value
      (value output &optional no-truncate char-print-limit)

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  rudalics@gmx.at, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp,
>  sorganov@gmail.com, monnier@iro.umontreal.ca, arthur.miller@live.com,
>  drew.adams@oracle.com, stefankangas@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 May 2020 01:19:54 +0300
> 
> >> I'm not saying the current behavior is necessarily "broken", but perhaps
> >> we could enhance it further.
> > The intent was to affect messages that are a "surprise" for the user.
> > eval-last-sexp is invoked by the user, so no surprise here.
> 
> But not all 'message' calls are a "surprise". One might even say that 
> the vast majority of them aren't. And yet, they obey set-message-function.

We provided a possibility to customize this functionality out of
principle, without investing too much research into the various ways
this could be used in situations very different from those for which
the code was written, which is display of a message when the
minibuffer is active.  It is possible that using this as a
customization tool in other situations could also make sense, and that
other sense would then suggest us that the feature should be extended
to other means of displaying messages in the echo area.

However, it sounds too early to consider those additional
possibilities.  I'd like first to collect real-life use experience
with this feature in Emacs 27.

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 22.05.2020 10:28, Eli Zaretskii wrote:
>>>> I'm not saying the current behavior is necessarily "broken", but perhaps
>>>> we could enhance it further.
>>> The intent was to affect messages that are a "surprise" for the user.
>>> eval-last-sexp is invoked by the user, so no surprise here.
>> But not all 'message' calls are a "surprise". One might even say that
>> the vast majority of them aren't. And yet, they obey set-message-function.
> We provided a possibility to customize this functionality out of
> principle, without investing too much research into the various ways
> this could be used in situations very different from those for which
> the code was written, which is display of a message when the
> minibuffer is active.  It is possible that using this as a
> customization tool in other situations could also make sense, and that
> other sense would then suggest us that the feature should be extended
> to other means of displaying messages in the echo area.
> 
> However, it sounds too early to consider those additional
> possibilities.  I'd like first to collect real-life use experience
> with this feature in Emacs 27.

Fair enough.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > To clarify: set-message-function is not supposed to affect all the
 > ways we have to show something in the echo area, it is only supposed
 > to affect calls to 'message', because that's how messages to the user
 > are printed.
 >
 > eval-last-sexp uses prin1 to display the result, so it is not
 > affected, as intended.

OK.  Which means that I should finally stop interpreting whatever I see
and just post my observation: When with emacs -Q I evaluate either

(defun my-fun (string) "")

or

(defun my-fun (string) t)

and then

(setq set-message-function 'my-fun)

and repeatedly press the <up> key, the minibuffer tells me

Beginning of buffer

If this is the intended behavior, then this is simply to inform Dmitry
that 'set-message-function' does not provide any help to fix my problem
with suppressing a message I never want to see.

martin

Re: GNU Emacs raison d'etre

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, rms@gnu.org,
>  andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, sorganov@gmail.com,
>  monnier@iro.umontreal.ca, arthur.miller@live.com, drew.adams@oracle.com,
>  stefankangas@gmail.com
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 21 May 2020 01:07:31 +0200
> 
> (defun my-fun (string) "")
> 
> or
> 
> (defun my-fun (string) t)
> 
> and then
> 
> (setq set-message-function 'my-fun)
> 
> and repeatedly press the <up> key, the minibuffer tells me
> 
> Beginning of buffer
> 
> If this is the intended behavior

Yes, it is.  Errors are not reported via 'message'.

Re: GNU Emacs raison d'etre

[martin rudalics]

>> If this is the intended behavior
>
> Yes, it is.  Errors are not reported via 'message'.

Thanks, martin

RE: GNU Emacs raison d'etre

[Drew Adams]

>  > 1. It's trivial to move a minibuffer-only frame
>  > off screen (and bring it back on screen).
> 
> Not in my experience.  Not even for arbitrary frames.

I think it is, at least on MS Windows, and I think
on other OSes also.

I just did it, interactively, using a command that
moves a frame down incrementally.  It just calls
`modify-frame-parameters, changing `top'.

That works fine, whether the minibuffer is active
or not.

Maybe you meant something different?

>  > Presumably, frame parameter `visibility' would
>  > also be usable for this, but it doesn't seem
>  > to have an effect on a minibuffer-only frame,
>  > at least on MS Windows.  Same with parameter
>  > `minibuffer-exit', and same with functions
>  > `make-frame-(in)visible'.  Dunno whether those
>  > are just bugs.
> 
> On every GUI I've seen so far
> (make-frame-invisible (window-frame (minibuffer-window)))
> works as intended.  I call it thousands of times daily
> whenever a minibuffer becomes empty.

Hm.  I've checked only with my setup.  Maybe
something else is going on there.

(progn (make-frame-invisible
         (window-frame (minibuffer-window)))
       (pp-eval-expression
         (frame-parameter nil 'visibility) t))

tells me `t', with my setup.  And the frame
stays visible.

But if what you say is true, then that too
(in addition to moving the frame off-screen
temporarily) should be an option for the
requested behavior.

> I use a minibuffer child frame all the time.  It is invisible whenever
> I don't need it, promptly shows up on any window where I want to interact
> with it and resizes just like any normal minibuffer window.

Great.  I haven't bothered with child frames yet.

Maybe show (or point to) your code for that, as
it sounds like what the requestor is looking for.

Re: GNU Emacs raison d'etre

[martin rudalics]

 >>   > 1. It's trivial to move a minibuffer-only frame
 >>   > off screen (and bring it back on screen).
 >>
 >> Not in my experience.  Not even for arbitrary frames.
 >
 > I think it is, at least on MS Windows, and I think
 > on other OSes also.

It's up to the respective window manager to decide that.

 > Hm.  I've checked only with my setup.  Maybe
 > something else is going on there.
 >
 > (progn (make-frame-invisible
 >           (window-frame (minibuffer-window)))
 >         (pp-eval-expression
 >           (frame-parameter nil 'visibility) t))
 >
 > tells me `t', with my setup.  And the frame
 > stays visible.

The minibuffer frame does not _stay_ visible.  It becomes visible again
because it is supposed to display the result of 'pp-eval-expression' in
the minibuffer.

If you use the correct form - nil stands for the selected frame which is
not the minibuffer-only frame, 'pp-eval-expression' allows one argument
only -

(progn (make-frame-invisible
          (window-frame (minibuffer-window)))
        (pp-eval-expression
         (window-frame (minibuffer-window))))

it will tell you nil, as expected.

martin

Suppressing beginning/end-of-buffer error messages (WAS: GNU Emacs raison d'etre)

[Noam Postavsky]

On Mon, 18 May 2020 at 04:33, martin rudalics <rudalics@gmx.at> wrote:

> I do not use the echo area for ElDoc though and occasionally the echo
> area noisily pops up to tell me that I'm at the beginning or end of a
> buffer.  I've been told that I have to live with the latter.

Hmm, I don't see why. Try this:

    (defun ignore-edge-of-buffer-errors (default-fun error context signaller)
      (unless (memq (car error) '(beginning-of-buffer end-of-buffer))
        (funcall default-fun error context signaller)))
    (add-function :around command-error-function
                  #'ignore-edge-of-buffer-errors)

Re: Suppressing beginning/end-of-buffer error messages (WAS: GNU Emacs raison d'etre)

[martin rudalics]

 > Try this:
 >
 >      (defun ignore-edge-of-buffer-errors (default-fun error context signaller)
 >        (unless (memq (car error) '(beginning-of-buffer end-of-buffer))
 >          (funcall default-fun error context signaller)))
 >      (add-function :around command-error-function
 >                    #'ignore-edge-of-buffer-errors)

That will save me a lot of trouble.

I suppose it would also work when I set 'command-error-function' to
'ignore-edge-of-buffer-errors' right away but the advice is probably
cleaner.

Many thanks, martin

Re: Suppressing beginning/end-of-buffer error messages (WAS: GNU Emacs raison d'etre)

[Noam Postavsky]

On Fri, 22 May 2020 at 05:30, martin rudalics <rudalics@gmx.at> wrote:

>  >      (defun ignore-edge-of-buffer-errors (default-fun error context signaller)
>  >        (unless (memq (car error) '(beginning-of-buffer end-of-buffer))
>  >          (funcall default-fun error context signaller)))
>  >      (add-function :around command-error-function
>  >                    #'ignore-edge-of-buffer-errors)
>
> That will save me a lot of trouble.
>
> I suppose it would also work when I set 'command-error-function' to
> 'ignore-edge-of-buffer-errors' right away but the advice is probably
> cleaner.

If you set directly, then getting hold of the original value of
command-error-function becomes bit trickier. The following should do
the same, but I prefer the add-function version since it depends less
on the order of evaluation.

    (defvar original-command-error-function command-error-function)
    (defun ignore-edge-of-buffer-errors (error context signaller)
      (unless (memq (car error) '(beginning-of-buffer end-of-buffer))
        (funcall original-command-error-function
                 error context signaller)))
    (setq command-error-function #'ignore-edge-of-buffer-errors)

(alternatively, you can hardcode command-error-default-function, but
then you lose other additions to command-error-function, like
help-command-error-confusable-suggestions)

Re: Suppressing beginning/end-of-buffer error messages (WAS: GNU Emacs raison d'etre)

[Noam Postavsky]

On Sat, 23 May 2020 at 04:22, martin rudalics <rudalics@gmx.at> wrote:

> (setq original-command-error-function #'command-error-function

That should be #'command-error-default-function,

>  > (alternatively, you can hardcode command-error-default-function, but

which is what I meant by this.

>  > then you lose other additions to command-error-function, like
>  > help-command-error-confusable-suggestions)
>
> And maybe 'minibuffer-error-function'.  So I'll stick with your original
> proposal making it the first occurrence of 'add-function' in my initial
> file.

RE: GNU Emacs raison d'etre

[Drew Adams]

> FWIW, to get started, you just need:
>     emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
> 
> But this indeed just begs the question of how to *manage* that
> minibuffer-only frame (i.e. make it so that it's easily accessible when
> the user needs it but it doesn't constantly get in the way the rest of
> the time).

And it always has input focus when you expect/want
it to, and only then, regardless of what interactions
might be going on.

> I don't know of any package/theme/thingy that provides a good solution
> to that yet.  I think such a thing could be very useful&popular, so I'd
> encourage you (or whoever else) to take a stab at it.

+1.

I do think I have a good solution - I've been
using it for decades.  But it's not a perfect
solution.

It's essentially a code-coordinated set of
settings that might be considered more or less
workarounds to the facts that (1) Emacs is not
very friendly to frames (frame-oriented), and
(2) Emacs doesn't ultimately control frame
management/behavior - a window manager does.

Wrt #1, I've long thought that this is because
most Emacs developers (and users) don't try to
use it - Catch-22.  Wrt #2, that's something
to live with, and Emacs generally tries to
work well regardless of window manager.

Re: GNU Emacs raison d'etre

[Stefan Monnier]

> I do think I have a good solution - I've been
> using it for decades.  But it's not a perfect
> solution.

I'm talking about something that just places the minibuffer in
a separate frame without changing the way frames are otherwise used
(e.g. with still an assumption that the user may very work with just
one frame).

That's quite different from your setup (and mine), AFAICT.

In my setup, the minibuffer-only frame is handled specially to try and
behave as some kind of "global" control, kind of like an XFCE4 panel, or
the macOS top menu-bar.  It's placed at the very bottom of the screen
and on a higher "layer" so it's never hidden by normal windows.
This works fairly well (always available since it's "on top" of
everything else, yet out of the way since it's at the bottom of the
screen), but when I'm working with a big screen (e.g. more than
100 text lines) that minibuffer feels kinda far.


        Stefan

RE: GNU Emacs raison d'etre

[Drew Adams]

> I'm talking about something that just places the minibuffer in
> a separate frame without changing the way frames are otherwise used
> (e.g. with still an assumption that the user may very work with just
> one frame).

So the other frames also have minibuffers?

> That's quite different from your setup (and mine), AFAICT.

Yes, different from mine, anyway.

> In my setup, the minibuffer-only frame is handled specially to try and
> behave as some kind of "global" control, kind of like an XFCE4 panel,
> or the macOS top menu-bar.

I don't know what that means, sorry.  (I guess
if I were really curious I could google for
"XFCE4" and "macOS menu-bar".)

> It's placed at the very bottom of the screen
> and on a higher "layer" so it's never hidden by normal windows.

So it obscures all other win-mgr windows
(including other Emacs frames) that overlap it?

> This works fairly well (always available since it's "on top" of
> everything else, yet out of the way since it's at the bottom of the
> screen), but when I'm working with a big screen (e.g. more than
> 100 text lines) that minibuffer feels kinda far.

I thought you said that what you're describing
is quite different from your setup.  Now it
sounds like you're describing your setup.

Care to share the code for your setup in this
regard?

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 17.05.2020 20:06, Stefan Monnier wrote:
> FWIW, to get started, you just need:
> 
>      emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
> 
> But this indeed just begs the question of how to*manage*  that
> minibuffer-only frame (i.e. make it so that it's easily accessible when
> the user needs it but it doesn't constantly get in the way the rest of
> the time).
> 
> I don't know of any package/theme/thingy that provides a good solution
> to that yet.

What your opinion on maple-minibuffer?

Re: GNU Emacs raison d'etre

[Stefan Monnier]

> What your opinion on maple-minibuffer?

No opinion yet, I just saw a reference to it for the first time earlier
in this thread.

[ ... time passes ... ]

I wonder how it works out in practice: I like the idea of the minibuffer
being "near point" rather than at the bottom of my screen, but at the
same time I don't like the minibuffer hiding text "near point".

Another issue is that it only applies to actual minibuffer use, so it
doesn't affect Isearch nor echo-area messages, but for me a significant
part of the problem of having the minibuffer "all the way down" is that
I don't see echo messages either (i.e. it's not just the minibuffer
per-se but all uses of the mini-window).


        Stefan

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 00:17, Stefan Monnier wrote:
> I wonder how it works out in practice: I like the idea of the minibuffer
> being "near point" rather than at the bottom of my screen, but at the
> same time I don't like the minibuffer hiding text "near point".

It doesn't actually follows point, at least in this solution. The 
position is more or less fixed, albeit, if the position is in the center 
of the frame, it would be closer to point on average.

The idea is to rather "capture the gaze".

> Another issue is that it only applies to actual minibuffer use, so it
> doesn't affect Isearch nor echo-area messages, but for me a significant
> part of the problem of having the minibuffer "all the way down" is that
> I don't see echo messages either (i.e. it's not just the minibuffer
> per-se but all uses of the mini-window).

I think that conflation of the minibuffer and the echo area is one of 
oldest problems in Emacs. That's not to say that we can't do anything 
similar for the echo area.

Someone should experiment with that as well: for instance, they could be 
displayed like desktop notifications. Stacked, on the right side of the 
screen (top or bottom). I don't have particular experience with that, 
"solving" the minibuffer seems more urgent.

Another idea: show the messages at the bottom of the minibuffer pop-up, 
on a separate line, perhaps with a different background, when the 
minibuffer is active. Otherwise, continue showing them at the bottom of 
the frame.

Re: GNU Emacs raison d'etre

[martin rudalics]

 > I think that conflation of the minibuffer and the echo area is one of oldest problems in Emacs.

True, unfortunately.  It has been stated often enough here (recall last
year's 'y-or-n-p' - 'yes-or-no-p' controversy) that this conflation has
been carved in stone.

martin

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 18.05.2020 11:33, martin rudalics wrote:
>  > I think that conflation of the minibuffer and the echo area is one of 
> oldest problems in Emacs.
> 
> True, unfortunately.  It has been stated often enough here (recall last
> year's 'y-or-n-p' - 'yes-or-no-p' controversy) that this conflation has
> been carved in stone.

I think that went past me, (un)fortunately.

RE: GNU Emacs raison d'etre

[Drew Adams]

> I like the idea of the minibuffer being "near point"
> rather than at the bottom of my screen, but at the
> same time I don't like the minibuffer hiding text
> "near point".

Exactly.  Having used both (a user option that I
mentioned), I'd say each has pros & cons, and
those differ depending on what you're doing.

E.g., for `M-x', `M-:' and the like, you (I)
typically don't need/want it near point, but
it doesn't bother me there.  But for an
interaction that involves text near point it
can be a real drag.

Perhaps this could be improved with a bit of
smart DWIM and user configuration.

> Another issue is that it only applies to actual minibuffer use, so it
> doesn't affect Isearch nor echo-area messages, but for me a significant
> part of the problem of having the minibuffer "all the way down" is that
> I don't see echo messages either (i.e. it's not just the minibuffer
> per-se but all uses of the mini-window).

Hm.  That's true.  But on the other hand,
you always know where to look for a message,
when you do expect one.  And the annoyance
of a minibuffer frame warping to get near
point would be multiplied if done also for
echo-area use.

It could certainly be done, at least for
`message'. I haven't offered it because I
haven't been convinced of its value.  But
maybe some users would prefer it, so maybe
I should consider it (or at least try it).

RE: GNU Emacs raison d'etre

[Drew Adams]

> macos users don't expect a floating kind of system "minibuffer".
> That's actually unlike the rest of macos UI. But it happens to exist
> (that's "Spotlight" in case you want to know and it is an *extremely*
> limited "minibuffer", by emacs standards.)
> 
> I was just mentioning that vs Drew's "in emacs the mini buffer *can* be
> in a frame". Because *that* requires a lot of manually installing
> packages that he refers to here:
> 
> https://www.emacswiki.org/emacs/OneOnOneEmacs
> 
> Which seems to be very nice, by the way.

I wouldn't say it "requires" all that I try
to do.

I'm sure it's possible to at least have (only)
a standalone minibuffer frame, without all of
what my code tries to do.

E.g., customize `initial-frame-alist' (and
`default-frame-alist' probably), to have a
nil `minibuffer' parameter, and create a
minibuffer frame, will get you partway there.

That wiki page you link to describes problems
I ran into when trying to get reasonable
behavior for a standalone minibuffer frame.
In particular, there can be problems of input
focus not being systematically what one might
expect.

But I think Stefan also uses a standalone
minibuffer frame, and probably he does something
simpler and perhaps better in some ways.  I've
never seen any code for his setup, but he might
have something useful to say about Emacs
offering such a thing as an option.  (Or not.)

RE: GNU Emacs raison d'etre

[Drew Adams]

> >> the macos equivalent to the minibuffer is a "frame"
> >> that you can move freely around the screen.
> >
> > In Emacs too the minibuffer can be a frame
> > that you can move freely around the screen.
> 
> I mean in macos it *is*. By default. I would love to have a similar
> feature by default in emacs.

Have the feature, or make it the default behavior?
Not clear what you mean by "have [the feature] by default".

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 17.05.2020 12:07, Jean-Christophe Helary wrote:
> Btw, I tried emacs-maple-minibuffer earlier today and there must be an issue with my configuration because I had remnants of windows in the desktop file that would float over my frames and just would not go away even after a restart. I had to manually edit the desktop file to make them go away, plus the echo area was not handled by the new windows so I had a minibuffer floating window and the echo remained at the bottom of the frame. It was confusing. But that's a different subject...

Yes, it's not perfect, but it seemed the most stable out of all similar 
packages that I tried (there are several).

This could be another good reason to bring it inside the core, to review 
the code with more experienced eyes.

Re: GNU Emacs raison d'etre

[Sergey Organov]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

>> On May 17, 2020, at 15:49, Drew Adams <drew.adams@oracle.com> wrote:
>> 
>> Having status and error messages at the bottom is
>> pretty common, and not just in editors.
>
> But is that a decision based on cognitive studies or on technical
> limitations when the solution was implemented ?

I suspect it's modeled after simple text terminals, where both latest
messages and the input are at the bottom.

Who and when first moved input line to the top I don't know.

-- Sergey

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 17.05.2020 04:14, Drew Adams wrote:
>>> Top positioning has either the same problem as near
>>> point (your annoyance: obscuring info) or the same
>>> problem as bottom-positioning.
>> Agreed.  Top positioning might be better for other
>> reasons though.
> What reasons?

When the minibuffer is updated, and its height has to change, the 
bottom-positioned minibuffer will have to move its input area up.

That's hella annoying.

RE: GNU Emacs raison d'etre

[Drew Adams]

> >>> Top positioning has either the same problem as near
> >>> point (your annoyance: obscuring info) or the same
> >>> problem as bottom-positioning.
> >> Agreed.  Top positioning might be better for other
> >> reasons though.
> > What reasons?
> 
> When the minibuffer is updated, and its height has to change, the
> bottom-positioned minibuffer will have to move its input area up.
> That's hella annoying.

Is it?  Doesn't annoy me, and that's what I
use daily.

How is it worse than a minibuffer at screen
top extending its input area downward?

In any case, as I said, if you can put the
minibuffer at screen bottom then you can put
it at screen top - user choice.  There's no
need to debate individual preferences or
annoyances in that regard.

Re: GNU Emacs raison d'etre

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 16.05.2020 16:57, Sergey Organov wrote:
>
>>> My anecdata shows otherwise: it's never been a problem personally.
>> What exactly? Failure to notice Emacs suddenly asking you for something
>> in the minibuffer? I see it very often.
>
> Yes. I _have_ had problems reading the minibuffer's contents, however, on a few
> occasions.
>
>> Rarely newbies look at the bottom of the screen/frame when cursor is
>> suddenly gone, even after some training. The most frequent instinct I
>> see is clicking with the mouse at the position on the screen where they
>> want cursor to be.
>> Here is an example:
>> 1. Type C-x b (imitation of accident keystroke)
>> 2. Click with the mouse _here_
>> 3. In the menu click "Edit | Go To | Goto Line"
>> Result? For me it's:
>> completing-read-default: Command attempted to use minibuffer while in
>> minibuffer
>> error message that, besides, is again being output into minibuffer
>> place, that for me even was immediately overwritten by a help string on
>> a lisp variable as I was doing it in the *scratch*.
>> Will any newbie be able to tell why this menu item suddenly didn't work
>> as expected? I'd rather afraid they may think Emacs is buggy and
>> unreliable.
>
> Fair enough. But in the end, you're probably asking for something that doesn't
> exist in Emacs yet. Like, no graphical switches for buffers that's equal in
> power to the minibuffer-based one.
>
> I agree that the prompts could be positioned better, and the result could be
> better readability. After all, if one uses the minibuffer a lot, isn't it a
> shame that it resides somewhere down below, and uses the same font as the rest
> of Emacs?
>
> In that, I think VS Code, Atom, etc, have a better idea by positioning their
> input area somewhere near the top of the window, in an easy-to-see dropdown.
> Somewhere in the middle of the frame could also work.
>
> If you like, try out https://github.com/honmaple/emacs-maple-minibuffer/ with
> (setq maple-minibuffer:position-type 'frame-top-center) or 'frame-center.
>
> I'd like to see Emacs something like this by default someday.
>
>> This is unrelated to the context of the suggestion.
>> Please recall that the problem being discussed is /accidental/
>> invocation of a command by a keystroke that brings newbie to minibuffer
>> that she often doesn't even notice! If Emacs rather threw big shiny
>> dialog into his face (even if only displaying this same minibuffer in
>> it), it'd leave the newbie little chances to remain ignorant.
>> In fact, many "expert" commands already do something like this, asking
>> to be explicitly enabled. This is not that helpful for complete newbies
>> though as the prompt still uses the minibuffer that newbies often forget
>> to pay attention to in the first place.
>
> I see where you're coming from, but I think the minibuffer is too large a part
> of Emacs UI to shield the newbies from it like that.
>
> Or at least, the above would be a better solution, by improving minibuffer's
> usability for both newbies and existing users.
Situation with minibuffer as you describe, being on the bottom and not
being looked is getting even more exaggarated since screens are getting
bigger (I talk about desktop), so one has to explicitly look down to the
bottom of the screen which has some consequence for my neck. I know I
can reposition minibuffer and so on, but I am kind-a used to have it on
the bottom and am not sure where to put it otherwise.

Btw, maybe if minibuffer was hidden away and poped-up only when it is
needed, it might be more attention attracting for new users. Or maybe it
could be flashed with different background color or something similar
that draws attention and eye to minibuffer when it asks for something.

Re: GNU Emacs raison d'etre

[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 not sure if it makes sense to implement "pop-up dialog minibuffer"
  > mode for newbies though, and then if it makes sense to (optionally?)
  > make it modal.

I am partly guessing what that means, but it might be a good feature
for starting newbies out, if it explains the minibuffer and leads
newbies in switchiing to using ordinary minubuffers.

-- 
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: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Richard Stallman wrote:
>>Another area is the keybinding space and the minibuffer.  Just
>>about every time I have watched a new user use Emacs, I have noticed
>>how frequently they accidentally hit some key combination or sequence
>>and wind up in some weird state that they never meant to be in -- and
>>don't know how to get out of.
>
>We made this very simple a few years ago: Just keep typing C-g.
>I guess these users don't know that.

Sometimes they know that, but it's still stressful for them to have to do it.  They don't like the sensation of getting into state they don't understand, and then having to type a magical quit-key to get out of that state.  It makes them apprehensive about even using the editor -- they feel like they got bitten.

>Can anyone thing of a better way to teach them about this?
>It could teach them first about the minibuffer, then about C-g
>to get out.  It could copy the current minibuffer prompt
>into the help screen to make the explanation clearer.
>
>The tricky part is how to detect when a user could use this help.

I don't think the issue is ignorance about C-g.  It's that people have a relationship with software interfaces in which they're not accustomed to being bitten.  Even when the bite draws no blood, they still don't like the feeling.

I can see directly that they don't like the feeling, that it's upsetting to them.  I conjecture that part of the reason is that even if they quickly ascertain that everything's all right this time, they still have a (rational) fear that the next time the bite might actually cause harm -- e.g., that maybe they'll lose a file, or accidentally rename something, or that edits that they don't know about will be accidentally made somewhere.  

I haven't actually asked new users if that's their worry, but on the now-rare occasions when Emacs bites me, I worry about such things.  Also, I've been using Emacs long enough to know that most likely nothing harmful happened, and that if I patiently unwind the state I'll be able to figure it all out.  A newcomer does not have that comfort at first, and they can only acquire it through sustained exposure to the editor.

Again, none of the above is meant to suggest that Emacs should change something.  I'm just saying that we should be intentional about the kinds of users Emacs is likely to attract, and not make changes designed around people who are unlikely to be long-term Emacs users anyway.

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[Eduardo Ochs]

Maybe we should experiment with changing the line in the startup
screen that says

  To quit a partially entered command, type Control-g.

to make it also mention <ESC> <ESC> <ESC>, and also add links to these
nodes of the Emacs Manual...

  (info "(emacs)Quitting")
  (info "(emacs)Basic Undo")

I just noticed that I don't know where the manual explains that Emacs
makes very hard for users to lose files or text with a single wrong
keystroke.  When I learned GNU/Linux it was somehow obvious that an
editor that allowed that would be considered very rude - but I checked
the definiton of "rude" in the Jargon Dictionary with "dict rude" and
it says just this:

  rude
   adj.

      1. (of a program) Badly written.

      2. Functionally poor, e.g., a program that is very difficult to
      use because of gratuitously poor (random?) design decisions.
      Oppose {cuspy}.

      3. Anything that manipulates a shared resource without regard
      for its other users in such a way as to cause a (non-fatal)
      problem. Examples: programs that change tty modes without
      resetting them on exit, or windowing programs that keep forcing
      themselves to the top of the window stack.

which means that I'm misremembering things.

Here's one easy way (untested!) to experiment with that. If you live
with someone who is learning Emacs, change the function
`fancy-startup-tail' in the file startup.el in the person's computer
and explain to her that you are trying to get a better startup screen
and would like her to test it, stick a post-it to her screen or table
or whatever that says "M-x fancy-startup-screen", and tell her to go
back to the modified startup screen whenever she's lost.

I can't test that because of the quarantine and because I live alone
with Doggy.

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/emacsconf2019.html


On Thu, 28 May 2020 at 01:13, Karl Fogel <kfogel@red-bean.com> wrote:
>
> Sometimes they know that, but it's still stressful for them to have
> to do it.  They don't like the sensation of getting into state
> they don't understand, and then having to type a magical quit-key to
> get out of that state.  It makes them apprehensive about even
> using the editor -- they feel like they got bitten.
>
> (...)
>
> I don't think the issue is ignorance about C-g.  It's that people
> have a relationship with software interfaces in which they're not
> accustomed to being bitten.  Even when the bite draws no blood,
> they still don't like the feeling.
>
> I can see directly that they don't like the feeling, that it's
> upsetting to them.  I conjecture that part of the reason is that
> even if they quickly ascertain that everything's all right this
> time, they still have a (rational) fear that the next time the bite
> might actually cause harm -- e.g., that maybe they'll lose a file,
> or accidentally rename something, or that edits that they don't know
> about will be accidentally made somewhere.
>
> I haven't actually asked new users if that's their worry, but on the
> now-rare occasions when Emacs bites me, I worry about such things.
>  Also, I've been using Emacs long enough to know that most likely
> nothing harmful happened, and that if I patiently unwind the state
> I'll be able to figure it all out.  A newcomer does not have that
> comfort at first, and they can only acquire it through sustained
> exposure to the editor.

RE: GNU Emacs raison d'etre

[Drew Adams]

> >We made this very simple a few years ago: Just keep typing C-g.
> >I guess these users don't know that.
> 
> Sometimes they know that, but it's still stressful for them to have to
> do it.  They don't like the sensation of getting into state they don't
> understand, and then having to type a magical quit-key to get out of
> that state.  It makes them apprehensive about even using the editor --
> they feel like they got bitten.
> 
> >Can anyone thing of a better way to teach them about this?
> >It could teach them first about the minibuffer, then about C-g
> >to get out.  It could copy the current minibuffer prompt
> >into the help screen to make the explanation clearer.
> >
> >The tricky part is how to detect when a user could use this help.
> 
> I don't think the issue is ignorance about C-g.  It's that people have
> a relationship with software interfaces in which they're not accustomed
> to being bitten.  Even when the bite draws no blood, they still don't
> like the feeling.
> 
> I can see directly that they don't like the feeling, that it's
> upsetting to them.  I conjecture that part of the reason is that even
> if they quickly ascertain that everything's all right this time, they
> still have a (rational) fear that the next time the bite might actually
> cause harm -- e.g., that maybe they'll lose a file, or accidentally
> rename something, or that edits that they don't know about will be
> accidentally made somewhere.
> 
> I haven't actually asked new users if that's their worry, but on the
> now-rare occasions when Emacs bites me, I worry about such things.
> Also, I've been using Emacs long enough to know that most likely
> nothing harmful happened, and that if I patiently unwind the state I'll
> be able to figure it all out.  A newcomer does not have that comfort at
> first, and they can only acquire it through sustained exposure to the
> editor.
> 
> Again, none of the above is meant to suggest that Emacs should change
> something.  I'm just saying that we should be intentional about the
> kinds of users Emacs is likely to attract, and not make changes
> designed around people who are unlikely to be long-term Emacs users
> anyway.

I hear you, Karl.  Just a thought - sorry it's
longer than I thought it would be.

I think it makes sense for the Emacs tutorial -
or some Emacs tutorial(s) - to have users use C-g
right off the bat, in a realistic way.  In fact,
have them use C-g at various points in the
tutorial, to show what it can do in different
contexts.

Users should get to know C-g and some important
help keys right at the outset - and now and again
throughout the tutorials.  Doing stuff with Emacs
is a dialog with Emacs, including a lot of asking
Emacs and learning about what's going on in any
given context.

By having them use these things over and over, to 
different ends, tutorial(s) can help users learn
why they are important - how helpful they can be.

There's a tremendous amount of stuff you can
learn about Emacs, and you can learn pretty much
all of it by asking Emacs itself.  Learning how
to do that - at least some basic ways - gives
you a leg up.

I mentioned the `Whoops!?' submenu I add to the
`Help' menu.  It has 3 items:

 `Cancel Current Action' (C-g)
 `Back to Top Level' (no key; command `top-level')
 `What Did I Do!?'       (C-h l)

Regardless of whether we put such things in a
help menu, I think an Emacs tutorial should have
users use them a bit.
___

Yes, `C-h l' could still be improved.  But it's
useful as it is, and showing the output in a
tutorial can be a way to point out some key
notation, including pseudo function keys.

The first thing to point out about `C-h l' output
are the keyboard key sequences.  They, at least,
are recognizable, once you know the notation.

We can also say what things like <down-mouse-1>,
<help-echo>, <menu-bar>, <view-lossage>, and
[view-lossage] represent, in general.  That way,
the output isn't so scary or just a wall of vomit.

Knowing in general what you're looking at, even
without understanding it, lets you see past what
(to you at that point) is just noise, to some
meaningful signals that you can recognize (e.g.
keyboard keys).
___

And of course, tutorials that get into some Lisp
can get users acquainted with more powerful ways
to ask Emacs.

Some of the things that are obstacles, because
Emacs is maybe not helpful enough regarding them,
can be subject to (later) tutorial explorations.
How to find out about faces, highlighting, chars,
overlays, fringe, mode-line, etc.

Someone who uses Emacs to work quickly, as Karl
suggests, knows Emacs well in one sense.  Someone
who knows how to dig in and ask Emacs things about
itself knows Emacs well in another sense.

Knowing something about asking Emacs provides (1)
self-confidence, (2) power to learn further, and
(3) knowledge that you can find out, yourself,
how to learn further _further_.  It's an eye-opener
to learn that Emacs is pretty much interactively
transparent all the way down.

RE: GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

28 mai 2020 à 02:13 de drew.adams@oracle.com:

>> >We made this very simple a few years ago: Just keep typing C-g.
>> >I guess these users don't know that.
>>
>> Sometimes they know that, but it's still stressful for them to have to
>> do it. 
>>
What does C-g mean? Why the sequence C-g specifically? I think the disconnect may be that C-g appears outwardly meaningless.

For contrast, <escape> clearly means to retreat and is often used in other applications to cancel (e.g. vi).  C-h is related to help via the 'h', which makes it easy to learn/remember. 

So why 'g'? 

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

>>>> We made this very simple a few years ago: Just keep typing C-g.
>>>> I guess these users don't know that.
>>> 
>>> Sometimes they know that, but it's still stressful for them to have to
>>> do it. 
> For contrast, <escape> clearly means to retreat and is often used in other applications to cancel (e.g. vi).  C-h is related to help via the 'h', which makes it easy to learn/remember. 
> 
> So why 'g'? 

[g]et out of here ?


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

RE: GNU Emacs raison d'etre

[Drew Adams]

> > So why 'g'?
> 
> [g]et out of here ?

Ha!  I just wrote the same thing.  I didn't
really think that it would be so "natural"
as to occur to others, but I guess great
minds think alike. ;-)

Re: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 29, 2020, at 1:34, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> So why 'g'?
>> 
>> [g]et out of here ?
> 
> Ha!  I just wrote the same thing.

Yes, I just saw that. But your reply was way deeper than my one-liner :)

> I didn't
> really think that it would be so "natural"
> as to occur to others, but I guess great
> minds think alike. ;-)

I'm not even sure my kids think I'm a "great mind" :)

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

Re: GNU Emacs raison d'etre

[Philip K.]

excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> What does C-g mean? Why the sequence C-g specifically? I think the
> disconnect may be that C-g appears outwardly meaningless.

I always assumed it was because C-g, when inserted literally had the
same value as does the ASCII bell (BEL, or '\a' in C) character. When
you open the "ascii" man-page on G and BEL even appear on the same
line. So in some sense it's like C-m/C-i, that do the same as
return/tab. 

But I guess that's neither consistent, relavant or intuitive.

-- 
	Philip K.

Re: GNU Emacs raison d'etre

[João Távora]

On Thu, May 28, 2020 at 4:00 PM Philip K. <philip@warpmail.net> wrote:
>
>
> excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org> writes:
>
> > What does C-g mean? Why the sequence C-g specifically? I think the
> > disconnect may be that C-g appears outwardly meaningless.
>
> I always assumed it was because C-g, when inserted literally had the
> same value as does the ASCII bell (BEL, or '\a' in C) character. When
> you open the "ascii" man-page on G and BEL even appear on the same
> line. So in some sense it's like C-m/C-i, that do the same as
> return/tab.

Yes, and those things are where they are because they're very
commonly typed and very easily typed.  I'm in no way a keyboard
historian, but I imagine Control and Meta to have had a similar role
as Shift does nowadays.  Also, Control didn't use to be where it
is today, this is why many, including me, make Caps Lock an
extra control.

João

Re: GNU Emacs raison d'etre

[T.V Raman]

"Philip K." <philip@warpmail.net> writes:


It's no more or no less intuitive than alt-F4 in "other platforms" that
people often label intuitive without thinking about it.

And for the record, the insert/replace key is a carry-over from
DOS word-processors of the early 80's.

> excalamus--- via "Emacs development discussions."
<emacs-devel@gnu.org> writes:  
>
>> What does C-g mean? Why the sequence C-g specifically? I think the
>> disconnect may be that C-g appears outwardly meaningless.
>
> I always assumed it was because C-g, when inserted literally had the
> same value as does the ASCII bell (BEL, or '\a' in C) character. When
> you open the "ascii" man-page on G and BEL even appear on the same
> line. So in some sense it's like C-m/C-i, that do the same as
> return/tab. 
>
> But I guess that's neither consistent, relavant or intuitive.

-- 

Re: GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

May 28, 2020, 12:04 by raman@google.com:

> "Philip K." <philip@warpmail.net> writes:
>
>
> It's no more or no less intuitive than alt-F4 in "other platforms" that
> people often label intuitive without thinking about it.
>
> And for the record, the insert/replace key is a carry-over from
> DOS word-processors of the early 80's.
>
>> excalamus--- via "Emacs development discussions."
>>
> <emacs-devel@gnu.org> writes: 
>
>>> What does C-g mean? Why the sequence C-g specifically? I think the
>>> disconnect may be that C-g appears outwardly meaningless.
>>>
>>
>> I always assumed it was because C-g, when inserted literally had the
>> same value as does the ASCII bell (BEL, or '\a' in C) character. When
>> you open the "ascii" man-page on G and BEL even appear on the same
>> line. So in some sense it's like C-m/C-i, that do the same as
>> return/tab. 
>>
>> But I guess that's neither consistent, relavant or intuitive.
>>
These are excellent observations (and I always love the history I learn through being an Emacs user).  Arguably, 'C-g' is one of the most important keybindings/functions in Emacs.  It's unfortunate that there's not a clear winner for a mnemonic.  "Get out" or "Get away" is the best I can come up with for English.  I tried translating the following possible interpretations to other languages (German, French, Spanish) and "giro" ("turn" in Spanish, apparently) was the 'best'.  

cancel
escape
abort
terminate
scrub
curtail
stop
discontinue
cease
counteract
redirect
avert
undo
disengage
avert
deflect
abstain
divert
reversal
turnabout
doubleback
turnaround
reverse
repeal
retract
annul

Re: GNU Emacs raison d'etre

[T.V Raman]

emacs kbd commands -- and other well-designed ergonomic systems, eg
vi's h,j,k,l for navigation are better thought of as muscle
memory. The mnemonics are useful to learn, yes, but given the weird
layout of the qwerty keyboard,  rigidly sticking to mnemonics often
leads to non-ergonomic keybindings.

So it's always a choice --- does one wish to create a system that is
"easy to learn" but painful to use, or one that "a little harder to
learn" with the benefit of being extremely efficient in the
long-run. I still think VI's nav keys are one of the best choices I've
seen from an ergonomics point of view, but completely "unintuitive"
for whatever "intuitive" means.
excalamus@tutanota.com writes:
 > May 28, 2020, 12:04 by raman@google.com:
 > 
 > > "Philip K." <philip@warpmail.net> writes:
 > >
 > >
 > > It's no more or no less intuitive than alt-F4 in "other platforms" that
 > > people often label intuitive without thinking about it.
 > >
 > > And for the record, the insert/replace key is a carry-over from
 > > DOS word-processors of the early 80's.
 > >
 > >> excalamus--- via "Emacs development discussions."
 > >>
 > > <emacs-devel@gnu.org> writes: 
 > >
 > >>> What does C-g mean? Why the sequence C-g specifically? I think the
 > >>> disconnect may be that C-g appears outwardly meaningless.
 > >>>
 > >>
 > >> I always assumed it was because C-g, when inserted literally had the
 > >> same value as does the ASCII bell (BEL, or '\a' in C) character. When
 > >> you open the "ascii" man-page on G and BEL even appear on the same
 > >> line. So in some sense it's like C-m/C-i, that do the same as
 > >> return/tab. 
 > >>
 > >> But I guess that's neither consistent, relavant or intuitive.
 > >>
 > These are excellent observations (and I always love the history I learn through being an Emacs user).  Arguably, 'C-g' is one of the most important keybindings/functions in Emacs.  It's unfortunate that there's not a clear winner for a mnemonic.  "Get out" or "Get away" is the best I can come up with for English.  I tried translating the following possible interpretations to other languages (German, French, Spanish) and "giro" ("turn" in Spanish, apparently) was the 'best'.  
 > 
 > cancel
 > escape
 > abort
 > terminate
 > scrub
 > curtail
 > stop
 > discontinue
 > cease
 > counteract
 > redirect
 > avert
 > undo
 > disengage
 > avert
 > deflect
 > abstain
 > divert
 > reversal
 > turnabout
 > doubleback
 > turnaround
 > reverse
 > repeal
 > retract
 > annul

-- 
Id: kg:/m/0285kf1 

--
Id: kg:/m/0285kf1

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 28 May 2020, T.V Raman wrote:
>emacs kbd commands -- and other well-designed ergonomic systems, eg
>vi's h,j,k,l for navigation are better thought of as muscle
>memory. The mnemonics are useful to learn, yes, but given the weird
>layout of the qwerty keyboard,  rigidly sticking to mnemonics often
>leads to non-ergonomic keybindings.

Amen to what T.V. says here.

Often, when people say that keybindings should be "intuitive", they mean something like "there should be some connection between a plausible English-language description of what the keybinding does and the letters involved in the keybinding itself".

But such language/key associations are only useful to newcomers anyway.  After all, there is nothing about the word "quit" that inherently suggests its meaning -- it's just that those who have learned English have learned what that word means.  Similarly, those who have learned the language of Emacs know that C-g means the same thing (well, something very similar).

Even independently of keyboard layout (mine is not QWERTY) this kind of intuitiveness is of questionable value.  It *does* help newcomers somewhat, but if used as an overriding principle it can result in an overly sparse keybinding space or in problematic physical combinations like single-finger hurdles.

>So it's always a choice --- does one wish to create a system that is
>"easy to learn" but painful to use, or one that "a little harder to
>learn" with the benefit of being extremely efficient in the
>long-run. I still think VI's nav keys are one of the best choices I've
>seen from an ergonomics point of view, but completely "unintuitive"
>for whatever "intuitive" means.

Agreed.  Vi's default navigation keybindings are, frankly, better than Emacs' (or at least they are on a QWERTY keyboard).  It also takes people a long time to learn them.

(I'm not suggesting Emacs change its default here: too many people have learned the existing way, the efficiency gain is not so huge anyway, and other bits of Emacs have been built around the assumptions of those default navigational keybindings so there's no telling what full effects of such a switch would be at this point.)

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[andres.ramirez]

Hi.

>>>>> "T" == T V Raman <raman@google.com> writes:

    T> emacs kbd commands -- and other well-designed ergonomic
    T> systems, eg vi's h,j,k,l for navigation are better thought of
    T> as muscle memory. The mnemonics are useful to learn, yes, but
    T> given the weird layout of the qwerty keyboard, rigidly sticking
    T> to mnemonics often leads to non-ergonomic keybindings.

Take in account also different keyboard layouts 'dvorak' as an example of
severals. On dvorak C-t is easier than C-x. But perhaps a tip for
someone going to a different layout would be try modal editing with
'god-mode' or other similar tools.

And Also. Do not forget the emacs pinky problem. That' sometimes leads
You to rebind some most used keybindings.

[...]

Best Regards

Re: GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

May 28, 2020, 13:34 by kfogel@red-bean.com:

> On 28 May 2020, T.V Raman wrote:
> >emacs kbd commands -- and other well-designed ergonomic systems, eg
> >vi's h,j,k,l for navigation are better thought of as muscle
> >memory. The mnemonics are useful to learn, yes, but given the weird
> >layout of the qwerty keyboard,  rigidly sticking to mnemonics often
> >leads to non-ergonomic keybindings.
>
> Amen to what T.V. says here.
>
> Often, when people say that keybindings should be "intuitive", they mean something like "there should be some connection between a plausible English-language description of what the keybinding does and the letters involved in the keybinding itself".
>
> But such language/key associations are only useful to newcomers anyway.  After all, there is nothing about the word "quit" that inherently suggests its meaning -- it's just that those who have learned English have learned what that word means.  Similarly, those who have learned the language of Emacs know that C-g means the same thing (well, something very similar).
>
> Even independently of keyboard layout (mine is not QWERTY) this kind of intuitiveness is of questionable value.  It *does* help newcomers somewhat, but if used as an overriding principle it can result in an overly sparse keybinding space or in problematic physical combinations like single-finger hurdles.
>
> >So it's always a choice --- does one wish to create a system that is
> >"easy to learn" but painful to use, or one that "a little harder to
> >learn" with the benefit of being extremely efficient in the
> >long-run. I still think VI's nav keys are one of the best choices I've
> >seen from an ergonomics point of view, but completely "unintuitive"
> >for whatever "intuitive" means.
>
> Agreed.  Vi's default navigation keybindings are, frankly, better than Emacs' (or at least they are on a QWERTY keyboard).  It also takes people a long time to learn them.
>
> (I'm not suggesting Emacs change its default here: too many people have learned the existing way, the efficiency gain is not so huge anyway, and other bits of Emacs have been built around the assumptions of those default navigational keybindings so there's no telling what full effects of such a switch would be at this point.)
>
> Best regards,
> -Karl
>
Fair enough.  My thoughts were centered on how to explain to newcomers the use/benefits of 'C-g', especially within the manual.  I was curious what perspectives others have.

My understanding of the discussion prior to my interjection was that newcomers appear to misunderstand, are reluctant to use, or forget about 'C-g'.  I hope I didn't derail the convo into one of changing the physical location or the keybinding!  There's too much history to change 'C-g'.  For better or worse, it's what we have.

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 28 May 2020, excalamus@tutanota.com wrote:
>My understanding of the discussion prior to my interjection was that
>newcomers appear to misunderstand, are reluctant to use, or forget
>about 'C-g'.  I hope I didn't derail the convo into one of changing
>the physical location or the keybinding!  There's too much history to
>change 'C-g'.  For better or worse, it's what we have.

Agreed.  I've always just taught it as "C-g" -- as an axiomatic thing that should be memorized because it will be used frequently.

Re: GNU Emacs raison d'etre

[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 does C-g mean? Why the sequence C-g specifically? I think the
  > > disconnect may be that C-g appears outwardly meaningless.

I will ask Greenblatt -- he might remember.

-- 
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: GNU Emacs raison d'etre

[Jean-Christophe Helary]

> On May 30, 2020, at 10:44, 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. ]]]
> 
>>> What does C-g mean? Why the sequence C-g specifically? I think the
>>> disconnect may be that C-g appears outwardly meaningless.
> 
> I will ask Greenblatt -- he might remember.

I'm sure it's interesting for historical purposes but as far as such keybindings are concerned the good thing is that we can find our own stories to remember them, and that's what matters.

I can remember C-[g]et out of here, as I hinted, and now I can remember C-why did [G]reenblatt chose this one ? And C-life is certainly [g]reener on the other side of the window, etc.


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

Re: GNU Emacs raison d'etre

[Arthur Miller]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

>> On May 30, 2020, at 10:44, 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. ]]]
>> 
>>>> What does C-g mean? Why the sequence C-g specifically? I think the
>>>> disconnect may be that C-g appears outwardly meaningless.
>> 
>> I will ask Greenblatt -- he might remember.
>
> I'm sure it's interesting for historical purposes but as far as such keybindings
> are concerned the good thing is that we can find our own stories to remember
> them, and that's what matters.
>
> I can remember C-[g]et out of here, as I hinted, and now I can remember C-why
> did [G]reenblatt chose this one ? And C-life is certainly [g]reener on the other
> side of the window, etc.
Ctrl - [G]NU (Control with GNU! :-))

Re: GNU Emacs raison d'etre

[Alfred M. Szmidt]

     > > What does C-g mean? Why the sequence C-g specifically? I think the
     > > disconnect may be that C-g appears outwardly meaningless.

   I will ask Greenblatt -- he might remember.

I suspect there is no deep meaning behind it, the BEL was common way
back then to mean abort, or alert.  TECO and DDT both used C-g for
abort, and since DDT commands where some sort of a C-<ch> sequence it
probobly just made sense..

Re: GNU Emacs raison d'etre

[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 suspect there is no deep meaning behind it, the BEL was common way
  > back then to mean abort, or alert.  TECO and DDT both used C-g for
  > abort,

Are you confident of that?  I don't remember, but if your memory is
clear, that is probably the reason.

-- 
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)

REmacs was Re: GNU Emacs raison d'etre

[T.V Raman]

The "Why emacs" section in the remacs project README  is one of the best
articulations I've read recently of the goodness that Emacs' embodies.

https://github.com/remacs/remacs
Richard Stallman <rms@gnu.org> writes:

s> [[[ 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 suspect there is no deep meaning behind it, the BEL was common way
>   > back then to mean abort, or alert.  TECO and DDT both used C-g for
>   > abort,
>
> Are you confident of that?  I don't remember, but if your memory is
> clear, that is probably the reason.

-- 

Meaning behind Control-G

[Lars Brinkhoff]

> > > > What does C-g mean? Why the sequence C-g specifically? I think
> > > > the disconnect may be that C-g appears outwardly meaningless.
> > > I will ask Greenblatt -- he might remember.
> > I suspect there is no deep meaning behind it, the BEL was common way
> > back then to mean abort, or alert.  TECO and DDT both used C-g for
> > abort,
> Are you confident of that?  I don't remember, but if your memory is
> clear, that is probably the reason.

I remember it clearly, because I use ITS DDT almost daily.  TECO, not so
much but it's easy enough to verify.

Now, why TECO uses Control-G for "quit", I don't know.  ASCII "BEL" as
an "alarm" is a plausible theory, but hard to verify.  In general
there's no strong link between control characteras as inputs and their
corresponding output behaviour.

I see no control character commands here, so maybe Control-G wasn't
in use with PDP-1 TECO:
http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/Murphy_PDP-1_TECO.pdf

I don't see Control-G Here either, so maybe it was added after 1964:
https://github.com/larsbrinkhoff/its-archives/blob/master/ailab/pdp6-memo-2.pdf

Re: Meaning behind Control-G

[Lars Brinkhoff]

Lars Brinkhoff wrote:
> I don't see Control-G Here either, so maybe it was added after 1964:
> https://github.com/larsbrinkhoff/its-archives/blob/master/ailab/pdp6-memo-2.pdf

I don't see Control-G in AI memo 81 "PDP-6 TECO" from 1965.
https://dspace.mit.edu/handle/1721.1/5917

I do see it as "quit" in the description of ITS DDT in AI memo 147 from
1968.  It seems likely that once DDT or TECO added Control-G, it would
have jumped to the other pretty quickly.
https://dspace.mit.edu/handle/1721.1/5862

Re: Meaning behind Control-G

[Lars Brinkhoff]

AI memo 118 from January 1967 is interesting.  It says about TECO:

  "|G   Takes an optional string argument which, if give, is passed on
        to MACDMP [...]"

"|G" means Control-G.  To have TECO go to MACDMP is a form of abort.

https://dspace.mit.edu/handle/1721.1/5878

Re: Meaning behind Control-G

[Stefan Monnier]

> Now, why TECO uses Control-G for "quit", I don't know.  ASCII "BEL" as
> an "alarm" is a plausible theory, but hard to verify.  In general
> there's no strong link between control characteras as inputs and their
> corresponding output behaviour.

FWIW, the link between C-g and "BEL" is pretty clear: it must be
[G]raham [Bel]l


        Stefan

Re: Meaning behind Control-G

[Paul Eggert]

On 6/1/20 6:44 AM, Stefan Monnier wrote:
> FWIW, the link between C-g and "BEL" is pretty clear: it must be
> [G]raham [Bel]l

Hah! As long as we're guessing, why not [G]ordon [Bel]l? His early work predates
ASCII and Wikipedia says he designed the first UART (this was for the PDP-1) so
he was very much in the thick of things when Control-G was invented. I'll cc him
in this email to see whether he knows whether Control-G and BEL are related
because of him.

It's unlikely, though. I looked it up, and BEL goes back to the Western Union
code (sometimes called the Baudot-Murray code, ITA2, or CCITT#2) invented in
1901. It was a 5-bit code with an escape, and BEL was an escaped J. The New
Zealand inventor Donald Murray invented BEL to ring the mechanical bells in his
telegraphic typewriters. (Murray eventually became rich from his teleprinter
patents and died a wealthy philosopher in Switzerland.)

When ASCII was developed in the early 1960s, BEL was one of the standardized
characters for compatibility with ITA2. The developers of ASCII looked at all
the control characters to be standardized, and attempted to maximize the Hamming
distance between the bit patterns of pairs of control characters where confusion
was likely to cause the most damage. (This little tidbit of information comes
from page 245 of Charles E Mackenzie's 1980 book "Coded Character Sets, History
and Development".)

The best person to ask exactly why C-g was assigned to BEL would be Bob Bemer,
co-developer of COBOL and sometimes called the "Father of ASCII" for his lead
role in ASCII standardization. Unfortunately for us he passed away in 2004.

That being said, Western Union and Bell were bitter commercial competitors (see
the Telephone Cases of the 1870s and 1880s), and I very much doubt that Western
Union would name one of its character codes after Alexander Graham Bell.

Re: Meaning behind Control-G

[Lars Brinkhoff]

> Stefan Monnier wrote:
>> FWIW, the link between C-g and "BEL" is pretty clear: it must be
>> [G]raham [Bel]l

That's a good one!  Say, was he an early agent 007?

Paul Eggert wrote:
> The best person to ask exactly why C-g was assigned to BEL would be
> Bob Bemer

That's interesting too but the question was, why is Control-G "quit" in
Emacs?

Re: Meaning behind Control-G

[Stefan Monnier]

>>> FWIW, the link between C-g and "BEL" is pretty clear: it must be
>>> [G]raham [Bel]l
> That's a good one!  Say, was he an early agent 007?

I could answer that question but then I'd have to kill you,


        Stefan

RE: Meaning behind Control-G

[Drew Adams]

> >> FWIW, the link between C-g and "BEL" is pretty clear: it must be
> >> [G]raham [Bel]l
> 
> That's a good one!  Say, was he an early agent 007?

Only hexincidentally.

Re: Meaning behind Control-G

[John Yates]

On Mon, Jun 1, 2020 at 9:52 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> (this was for the PDP-1)

Ah the PDP-1...  Before emacs, and before TECO I used ET
(Expensive Typewriter) on the PDP-1.  And played SpaceWar.
And listened to it play Mozart, Bach and Gilbert & Sullivan.

/john

Re: GNU Emacs raison d'etre

[Lars Brinkhoff]

Richard Stallman wrote:
> > > What does C-g mean? Why the sequence C-g specifically? I think the
> > > disconnect may be that C-g appears outwardly meaningless.
>
> I will ask Greenblatt -- he might remember.

I'm curious if Greenblatt had an answer?

RE: GNU Emacs raison d'etre

[Drew Adams]

> > > > What does C-g mean? Why the sequence C-g specifically? I think
> the
> > > > disconnect may be that C-g appears outwardly meaningless.
> >
> > I will ask Greenblatt -- he might remember.
> 
> I'm curious if Greenblatt had an answer?

Perhaps the answer was interrupted by a cosmic stray C-g. ;-)

Re: GNU Emacs raison d'etre

[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 curious if Greenblatt had an answer?

He never replied.

-- 
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)

FW: GNU Emacs raison d'etre

[Drew Adams]

[For some reason, when I used Reply All to excalamus's
message, emacs-devel got dropped from the cc list.

So I'm forwarding the message I sent a few minutes
ago.  Dunno how many other messages might have gotten
dropped from the list this way.  I believe the same
thing happened to me once before, perhaps when I
replied to another excalamus message.]

-----Original Message-----
From: Drew Adams <drew.adams@oracle.com> 
Sent: Thursday, May 28, 2020 9:33 AM
To: 'excalamus@tutanota.com' <excalamus@tutanota.com>
Cc: 'Karl Fogel' <kfogel@red-bean.com>; 'Richard Stallman' <rms@gnu.org>; 'Andreas Roehler' <andreas.roehler@online.de>
Subject: RE: GNU Emacs raison d'etre

> What does C-g mean? 

It should mean what `C-h k C-g' or `C-h c C-g' tells
you - like other key sequences.  Unfortunately, that
doesn't work.

Maybe/probably by design, but maybe worth revisiting?

How important is being able to easily ask Emacs about
this key, versus being able to use it to quit a help
command that asks about it?  Dunno.  Maybe there's a
third way?

If you somehow can find out that `C-g' is generally
bound to command `keyboard-quit', then `C-h f' gives
you a page of helpful description/explanation.  But
if you don't know that command name then it's not so
easy to find out what `C-g' is all about.  (Yes, the
manual.)

> Why the sequence C-g specifically? I think the
> disconnect may be that C-g appears outwardly meaningless.

(What disconnect?)

Yes, I realize that that's your real question:
what's the mnemonic, or other relation, here?

Well, there is none.  None that's readily useful to
most people nowadays.  For those who might really be
interested, the answer is "hysterical raisins".

The ASCII control character Control G is described
as follows:

 Key       Dec    Hex   Abbr.  Name
 [Ctrl] G	7	07	 BEL	Bell

 Description in C0 of ISO 646:

 A control character that is used when there is a
 need to call for attention; it may control alarm
 or attention devices.

http://ascii-table.com/control-chars.php

That info is actually useful, as is the general
info that some Emacs control keys are associated
by default with ASCII control characters.  That
info is interesting, if somewhat quaint.

But it's not important to understanding what `C-g'
does in Emacs.

How long does it take someone to learn what `C-g'
does in Emacs?  Especially if we cover that at
outset in a tutorial?

> For contrast, <escape> clearly means to retreat

Escape doesn't mean retreat.  But OK.

> and is often used in other applications to
> cancel (e.g. vi).  

And `ESC ESC ESC' is used similarly in Emacs.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Quitting.html

But `ESC' has additional meanings, starting,
again, with its meaning as an ASCII control
char:

 Key       Dec    Hex   Abbr.  Name
 [Ctrl] [	27	1B	 ESC	Escape	 	

 Description in C0 of ISO 646:

 A control character which is used to provide
 additional control functions.
 It alters the meaning of a limited number of
 contiguously following bit combinations.
 The use of this character is specified in
 International Standard ISO 2022.

Well, whaddya know?  It can alter the meaning
of some chars that follow it.  And in Emacs
it's used just that way - for Meta chars.

This is actually a useful thing for users to
learn, and it's one that they don't learn so
much nowadays.

That you can generally use `ESC <key>' in
place of `M-<key>' is handy in some contexts.

Recently I posted messages about my library
`keysee.el', which provides help on keys by
providing key completion.  In that UI, you
can find a key such as `C-M-q' under that
name, but you can also follow `ESC' as a
prefix key and find it as (ESC) `C-q'.

And more generally, Emacs help commands that
list keys show you that `ESC' is a prefix key.
So knowing about this relation between `ESC'
and Meta chars can help.  It can help you ask
Emacs.

> C-h is related to help via the 'h', which
> makes it easy to learn/remember.

Well, yes.  But `h' isn't just associated
with help.  It can be associated with
"highlight", "here", "header", and more.

It's just that you've _learned_ the h=help
association, and it's become second nature.
Another char that's "naturally" associated
with help is `?'.

> So why 'g'?

Why not?  Here's a mnemonic for you: "_G_et
me outta here now!"

Re: GNU Emacs raison d'etre

[Stefan Monnier]

> What does C-g mean?

For me, the intuition is a sound that I find hard to transcribe into
ASCII but could be something like "ghuhuh!" with the accent on the second
"u" and a good dose of frustration sprinkled throughout ;-)


        Stefan

Re: GNU Emacs raison d'etre

[Perry E. Metzger]

On Thu, 28 May 2020 13:37:19 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > What does C-g mean?  
> 
> For me, the intuition is a sound that I find hard to transcribe into
> ASCII but could be something like "ghuhuh!" with the accent on the
> second "u" and a good dose of frustration sprinkled throughout ;-)

And besides, it doesn't matter where C-g comes from. Thousands and
thousands of people memorized it. I memorized it in 1983. My fingers
will not do anything else at this point.

Any other key sequence would, regardless, be just as arbitrary and
capricious, and not any easier to learn for newcomers.

It is the nature of a system like Emacs that the learning curve is
extremely steep, but once you have crossed it, you work far more
efficiently than you did before you assaulted it.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: GNU Emacs raison d'etre

[T.V Raman]

"Perry E. Metzger" <perry@piermont.com> writes:
People often complain of "steep learning curves" as being "bad", but
that is a value judgement.

If you want to go  high, I prefer a steep curve to a flat plain -- and
metaphors aside, so-called easy-to-learn systems  usually dont get their
users anywhere very fast. A better goal is perhaps "fun-to-learn"
> On Thu, 28 May 2020 13:37:19 -0400 Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> > What does C-g mean?  
>> 
>> For me, the intuition is a sound that I find hard to transcribe into
>> ASCII but could be something like "ghuhuh!" with the accent on the
>> second "u" and a good dose of frustration sprinkled throughout ;-)
>
> And besides, it doesn't matter where C-g comes from. Thousands and
> thousands of people memorized it. I memorized it in 1983. My fingers
> will not do anything else at this point.
>
> Any other key sequence would, regardless, be just as arbitrary and
> capricious, and not any easier to learn for newcomers.
>
> It is the nature of a system like Emacs that the learning curve is
> extremely steep, but once you have crossed it, you work far more
> efficiently than you did before you assaulted it.
>
> Perry

-- 

Re: GNU Emacs raison d'etre

[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 think the issue is ignorance about C-g.  It's that people
  > have a relationship with software interfaces in which they're not
  > accustomed to being bitten.  Even when the bite draws no blood,
  > they still don't like the feeling.

  ...
  > Again, none of the above is meant to suggest that Emacs should
  > change something.  I'm just saying that we should be intentional
  > about the kinds of users Emacs is likely to attract, and not make
  > changes designed around people who are unlikely to be long-term
  > Emacs users anyway.

That sounds like valid reasoning 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: GNU Emacs raison d'etre

[T.V Raman]

Karl Fogel <kfogel@red-bean.com> writes:

well said!> On 12 May 2020, excalamus--- via "Emacs development discussions." wrote:
>>May 11, 2020, 23:12 by rms@gnu.org:
>>What are we competing for?  I feel that while other threads are
>>examining "missing features", it would be helpful to examine what GNU
>>Emacs does offer.  Not only in software features, but maybe also in
>>philosophy, community, or tradition.
>>
>>What is it about GNU Emacs that makes this mailing list bustle with
>>enthusiasm?  Other editors use GPL, provide source code, have
>>documentation, are customizable, and extendable.  There's something
>>in how GNU Emacs implements these that is different.  I feel like
>>there are taters to find if we dig a little.
>>
>>Is it because Emacs Lisp is unique to Emacs that Emacs teaches as
>>well as documents?
>>Is it that by being a pseudo-Lisp machine, Emacs puts users in the
>>zone of proximal development?
>>Is GNU Emacs the best embodiment of the GNU philosophy? 
>
> Sure, I'll take the bait:
>
> To the best of my knowledge, no other editing environment rewards sustained user investment so well.
>
> With Emacs, if you keep investing -- i.e., acquiring knowledge and
> skill by reading documentation, writing customizations, and exploring
> others' customizations -- Emacs keeps rewarding you with a better and
> better editing experience.  The degree to which it does this seems
> normal to many of us here, because we've been used to it for many
> years.  I think we sometimes fail to appreciate the degree to which
> non-users, potential ("Emacs-curious") users, and even many actual new
> users are *not* aware of it: they don't realize how enormous the
> reward can be, and how broad its scope.
>
> This should probably affect how we think about promoting Emacs.  Emacs
> shouldn't necessarily try to attract everyone who needs to edit text
> [1].  Many people who edit text nonetheless don't view text editing as
> a primary activity worthy of investment.  Those users are not good
> candidates for Emacs.
>
> Emacs's best prospects are with the sorts of people who *do* see -- or
> who can be persuaded to see -- text editing as worthy of investment.
> There's a loose correlation in which good programmers tend to be those
> sorts of people, because good programmers are usually willing to
> invest in learning their tools in general.  E.g., they'll learn their
> text editor the same way they'll learn their debugger, their
> programming framework, etc.  But the set isn't limited to just
> programmers.  For example, scientists and other academics who edit
> LaTeX documents are often good candidates for Emacs usage, because by
> both temperament and life situation they are well-positioned to
> understand how sustained investment in learning their editing
> environment could pay off in the long term.
>
> So I suggest that GNU Emacs's raison d'être is to be the text editor that best rewards sustained user investment.
>
> I think Emacs actually does so right now, too, and that we just haven't always communicated this fact clearly enough.
>
> Thus, instead of focusing on making Emacs easier for new users, it
> would be better to focus on smoothing out discontinuities in Emacs'
> investment-reward curve.  The long-term health of Emacs as a project
> will not come from a large number of lightly committed users who don't
> appreciate what makes Emacs unique, but rather from a smaller number
> of users for whom Emacs is important and irreplaceable.
>
> I'm not suggesting that we shouldn't improve the new-user experience
> in Emacs, of course.  We should make it as easy as possible for
> newcomers *while still prioritizing invested users*.  In user
> experience design, there are frequently tradeoffs between making
> things easy for newcomers and making them rewarding for experts.
> Unfortunately, too often in design discussions, the new user
> experience automatically wins out -- it's like some kind of magic card
> that people play (even sometimes unconsciously) in UI/UX discussions.
> For Emacs, this would be a mistake.  Emacs's great strength will never
> be in its new-user experience, and this is in some ways a necessary
> consequence of Emacs being so great for highly invested long-term
> users.
>
> This also suggests that the sorts of features that highly-invested
> users tend to want -- for example, LSP-based features -- should be
> more important to us than how square the menus are or what menu items
> are shown in a default startup configuration.  When we make decisions
> that disappoint the core user base, we endanger the project much more
> than when we make decisions that disappoint users (or potential users)
> who weren't likely to become highly invested anyway.
>
> (The fact that Emacs promotes free software by being a good GPL'd
> program is nice too, and is important to many of us, but it's not
> unique to Emacs.)
>
> Best regards,
> -Karl
>

-- 

Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 13.05.2020 19:18, Karl Fogel wrote:
> This also suggests that the sorts of features that highly-invested users tend to want -- for example, LSP-based features

LSP is a high-investment feature?

Reminder: it came to us from VS Code, Microsoft's text editor for 
programmers.

Re: GNU Emacs raison d'etre

[excalamus--- via Emacs development discussions.]

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

May 13, 2020, 12:18 by kfogel@red-bean.com:

> Sure, I'll take the bait:
>
Thank you for your thoughts!  Apologies if it appeared like I was trying to trap anyone or pick an argument.  My intention was to ask something like, "What does Emacs do well and how might we apply that strength more effectively?".  In that sense, it was more like a runner trying to best last week's time rather than trying to arrive first at the finish line.  But I also wasn't sure if there was a specific finish line in mind (singular, plural, fixed, or movable).

> Thus, instead of focusing on making Emacs easier for new users, it would be better to focus on smoothing out discontinuities in Emacs' investment-reward curve.  The long-term health of Emacs as a project will not come from a large number of lightly committed users who don't appreciate what makes Emacs unique, but rather from a smaller number of users for whom Emacs is important and irreplaceable.
>
I like the idea of "focus on smoothing out discontinuities in Emacs' investment-reward curve."  I think there be taters there.

What makes GNU Emacs unique?  After all, there's ITS Emacs, Gosling Emacs, XEmacs, and DrRacket (at least). 

Here's how I think Emacs, if not GNU Emacs, is unique:

Emacs is an editor with a heart and a soul.  Its beats to a rhythm of  compile, eval, garbage collect, transforming code into action.  It performs the raw mechanical functions an application needs to do.  But it also has an intangible quality aficionados recognize.  Like a soul, it's difficult to explain and you probably feel silly trying to.  I think being able to explain that to people would be a tremendous advantage.

I came to Emacs from the mundane need to track work hours (achieved with Org mode).  Emacs' ability to introspect, the marvelous "Introduction to Programming in Emacs Lisp", and it's unique ability for the user to Choose Your Own Programming Adventure led me to Free Software and to change my career to software development.  It changed my life, or at least the way I look at it.  I don't think other editors, or even other GNU projects, exist in a realm where that kind of thing is possible.   It seems to me that Emacs is unique because it occupies a unique space between user and creator.  If that's so, are there ways we might exploit that?

Education is one investment-reward domain.  In what other domains might Emacs be well poised?  

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

Re: GNU Emacs raison d'etre

[H. Dieter Wilhelm]

Karl Fogel <kfogel@red-bean.com> writes:

> To the best of my knowledge, no other editing environment rewards
> sustained user investment so well.  ...

What you are saying is really very well put and I support your opinion
but...

> So I suggest that GNU Emacs's raison d'être is to be the text editor
> that best rewards sustained user investment.

Forgive me if I think above sentence should be a bit reformulated
because GNU Emacs is and must be more than a text editor (as text editor
I would choose Vim).

I like your notion of environment better, because Emacs should be the
glue between - effective - processes or workflows which (can and will)
arise around textual representations.

One example of such workflow support is org-mode which helps structuring
text (ideas), controlling and gathering calculation results, exporting
text together with these results and their recipe into documents and
tangling the code for achieving the results (reproducible research). And
here text becomes true magic.

Thank you

  Dieter


-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, H. Dieter Wilhelm wrote:
>> To the best of my knowledge, no other editing environment rewards
>> sustained user investment so well.  ...
>
>What you are saying is really very well put and I support your opinion
>but...
>
>> So I suggest that GNU Emacs's raison d'être is to be the text editor
>> that best rewards sustained user investment.
>
>Forgive me if I think above sentence should be a bit reformulated
>because GNU Emacs is and must be more than a text editor (as text editor
>I would choose Vim).

Yes, agreed.  My choice of terminology merely shows how deeply Emacs has affected my perception and caused me to use words differently from how others use them :-).  After 28 years inside Emacs, the phrase "text editor" for me simply *means* all the things Emacs does with text -- including handling email, running command-line shells, browsing directory structures, performing version control operations, etc.

(Vi/vim also highly rewards investment, as a pure text editor in the more limited sense that you mean, although in practice its users don't seem to take extensibility quite as far as the most dedicated Emacs users do.)

Anyway, I agree with you, and an improved phrasing might be:

"GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment."

>I like your notion of environment better, because Emacs should be the
>glue between - effective - processes or workflows which (can and will)
>arise around textual representations.

Yep.

(I agree with your later observations about Org Mode too, but my point is not about any particular mode or package, of course.)

Best regards,
-Karl

Re: GNU Emacs raison d'etre

[John Wiegley]

>>>>> "KF" == Karl Fogel <kfogel@red-bean.com> writes:

KF> To the best of my knowledge, no other editing environment rewards
KF> sustained user investment so well.

100% agree.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: GNU Emacs raison d'etre

[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 I suggest that GNU Emacs's raison d'être is to be the text
  > editor that best rewards sustained user investment.

I would say that this is one of the virtues of Emacs -- but I would
not call this the raison d'être.

I think that the investment needed is a downside.  The upside is the
return you get for that investment.  If we could make Emacs give you
the return without the investment, that would be even better -- but we
don't know how to 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: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Richard Stallman wrote:
>  > So I suggest that GNU Emacs's raison d'être is to be the text
>  > editor that best rewards sustained user investment.
>
>I would say that this is one of the virtues of Emacs -- but I would
>not call this the raison d'être.
>
>I think that the investment needed is a downside.  The upside is the
>return you get for that investment.  If we could make Emacs give you
>the return without the investment, that would be even better -- but we
>don't know how to do that ;-(.

I think that is impossible in the general case, and would therefore not be a good goal to aim for.

Naturally, Emacs should give whatever returns it can give that don't require investment.  But that just gets us to the point of making tradeoff decisions.  Emacs has already consumed a lot of the available space in that "for free" region -- I'm sure there's still some space left to grab, and no one here would argue against grabbing it, but those are the easy calls.  They aren't controversial and they don't require much discussion.

The principle I suggest -- calling it a "raison d'être" may be too strong -- is for guiding the decisions that *can* be controversial because they involve tradeoffs.  This is most decisions.

Specifically, I'm arguing against assuming that making Emacs easy for new users is, in itself, a good idea.  It's really only half an idea.  Discussions about how to make Emacs "easy" for "new users" can only be productive if we know where we're trying to bring those users and what level of investment we expect from them, and if we weigh the costs as well as the benefits of changes that favor newcomers (when those changes have negative consequences for experts -- i.e., when those changes are not in the "free space", which most changes aren't).

(I wish I'd kept notes from the in-person Emacs teaching I've done over the years.  Having such notes would be useful right now.  Instead I must rely on memory of repeated experiences.)

Best regards,
-Karl

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Hello,

(1) Docstring of `dired-mark' says

  "If the region is active, mark all files in the region."

However, the file in the last line of the region is never marked, even
if the region spans the whole line of this file.  I find that behavior
wrong and contradicting the docstring.  But it seems it has been like
that for a long time (forever?).  Nevertheless, I'm always confused by
that behavior.

(2) Most of the time I rather want `dired-mark-files-regexp' to respect
an active region - but that isn't implemented (though it would not be
hard to do).  I think that would be useful.

(3) I didn't check if more dired (un)marking commands should be treated
or could be enhanced.  How the region is interpreted (see (1)) should be
kept consistent.


Thanks in advance,

Michael.


In GNU Emacs 28.0.50 (build 40, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
 of 2020-03-04 built on drachen
Repository revision: d79e2a99f105970f7e1e229a8243bf23b9caf615
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12007000
System Description: Debian GNU/Linux bullseye/sid

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> (1) Docstring of `dired-mark' says
>   "If the region is active, mark all files in the region."
> 
> However, the file in the last line of the region is never marked, even
> if the region spans the whole line of this file.

The problem seems to be that movement doesn't
put the cursor where you (and `dired-mark')
expect - the full lines are not selected.

If you do, say, `C-SPC', then `p p p', `then C-a',
then `m' (`dired-mark') then the full 3 lines are
selected and they get marked.  Similarly, if you
select the lines with the mouse.

Should `dired-mark' mark all lines that have any
of their chars selected, instead of lines that
have _all_ of their chars selected?  Maybe so.

bug#39902: 28.0.50; Marking in dired with active region

[Stephen Berman]

On Wed, 4 Mar 2020 07:41:40 -0800 (PST) Drew Adams <drew.adams@oracle.com> wrote:

>> (1) Docstring of `dired-mark' says
>>   "If the region is active, mark all files in the region."
>>
>> However, the file in the last line of the region is never marked, even
>> if the region spans the whole line of this file.
>
> The problem seems to be that movement doesn't
> put the cursor where you (and `dired-mark')
> expect - the full lines are not selected.

This is due to the following code in dired-mark:

	(dired-mark-files-in-region
	 (progn (goto-char beg) (line-beginning-position))
	 (progn (goto-char end) (line-beginning-position))))))

It may be that the second use of line-beginning-position is simply a
mistake, and should be line-end-position (CCing Juri Linkov, who wrote
that code).  That's what diredp-mark-region-files in the library
dired+.el (https://www.emacswiki.org/emacs/dired%2b.el) uses, which is
the inspiration for the dired-mark code (see bug#10624).

Steve Berman

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> >> (1) Docstring of `dired-mark' says
> >>   "If the region is active, mark all files in the region."
> >>
> >> However, the file in the last line of the region is never marked, even
> >> if the region spans the whole line of this file.
> >
> > The problem seems to be that movement doesn't
> > put the cursor where you (and `dired-mark')
> > expect - the full lines are not selected.
> 
> This is due to the following code in dired-mark:
> 
> 	(dired-mark-files-in-region
> 	 (progn (goto-char beg) (line-beginning-position))
> 	 (progn (goto-char end) (line-beginning-position))))))
> 
> It may be that the second use of line-beginning-position is simply a
> mistake, and should be line-end-position (CCing Juri Linkov, who wrote
> that code).  That's what diredp-mark-region-files in the library
> dired+.el uses, which is the inspiration for the dired-mark code
> (see bug#10624).

Indeed.  I looked only at `dired-mark', and saw
that Dired+ doesn't substitute anything different
for that (`m' etc. are still bound to vanilla
`dired-mark').

I agree with you about the bug and proposed fix. 

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> (1) Docstring of `dired-mark' says
>
>   "If the region is active, mark all files in the region."
>
> However, the file in the last line of the region is never marked, even
> if the region spans the whole line of this file.  I find that behavior
> wrong and contradicting the docstring.  But it seems it has been like
> that for a long time (forever?).  Nevertheless, I'm always confused by
> that behavior.

The peculiarity of dired mode is that it puts point in front of file name.
So when the region doesn't cover the file name visually, it should not take
the file name outside the region into consideration for marking.

Exactly like kill-region should not kill text outside of the active region,
dired-mark should not mark files outside of the active region.

Especially more dangerous command dired-flag-file-deletion
should not delete files outside of the active region.

> (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> an active region - but that isn't implemented (though it would not be
> hard to do).  I think that would be useful.

The problem is that this feature should be implemented in the macro
dired-mark-if, but then it will affect many other commands:

dired-mark-files-containing-regexp
dired-mark-symlinks
dired-mark-directories
dired-mark-executables
dired-flag-auto-save-files
dired-flag-backup-files
dired-compare-directories
dired-mark-unmarked-files
dired-mark-sexp
...

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> The peculiarity of dired mode is that it puts point in front of file name.
> So when the region doesn't cover the file name visually, it should not take
> the file name outside the region into consideration for marking.

That's what I said.  It's the navigation keys,
which didn't select complete lines, which led
to the impression that not all files "in" the
region got marked.

It's about creation of the region.  You can
select complete lines, in which case `dired-mark'
does what is expected: marks all of the files
whose (full) lines are selected.

But it's also possible to have `dired-mark'
instead mark all of the files with ANY part of
their line (not ALL of their line) in the region.

> Exactly like kill-region should not kill text outside of the active region,
> dired-mark should not mark files outside of the active region.

Bad analogy.  Especially for purposes of marking or
acting on files "in the region", what's important is
that the region capture _some part_ of a file's line,
not necessarily all of it.

Marking is not, like `kill-region', an action on the
characters of text in the region.  It uses the region
only to indicate a sequence of files to act on.

This, or similar, is the behavior needed, as
Stephen Berman pointed out:

(defun diredp-mark-region-files (&optional unmark-p)
  "Mark all of the files in the current region (if it is active).
With non-nil prefix arg, unmark them instead."
  (interactive "P")
  (let ((beg  (min (point) (mark)))
        (end  (max (point) (mark)))
        (inhibit-field-text-motion  t)) ; Just in case.
    (setq beg  (save-excursion (goto-char beg)
                               (line-beginning-position))
          end  (save-excursion (goto-char end)
                               (line-end-position)))
    (let ((dired-marker-char  (if unmark-p
                                  ?\040
                                dired-marker-char)))
      (diredp-mark-if (and (<= (point) end)
                           (>= (point) beg)
                           (diredp-this-file-unmarked-p))
                      "region file"))))

> Especially more dangerous command dired-flag-file-deletion
> should not delete files outside of the active region.

Not at all.  The command simply marks; it does not
delete.  Subsequently using `x', to delete, prompts
you for confirmation, specifying the files to be
deleted.  I don't see any danger.

> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> > an active region - but that isn't implemented (though it would not be
> > hard to do).  I think that would be useful.
> 
> The problem is that this feature should be implemented in the macro
> dired-mark-if, but then it will affect many other commands:
> 
> dired-mark-files-containing-regexp
> dired-mark-symlinks
> dired-mark-directories
> dired-mark-executables
> dired-flag-auto-save-files
> dired-flag-backup-files
> dired-compare-directories
> dired-mark-unmarked-files
> dired-mark-sexp
> ...

Those are all marking commands, so there's no problem.

That said, I'm not sure it would be a great idea to
have them (or have even just `dired-mark-files-regexp')
act on only the files in the active region.  Maybe,
maybe not.

It's certainly not hard, as a user, to narrow first
and then use such commands (but yes, in that case
you'll want to be sure to get the full lines in the
narrowing).

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> The peculiarity of dired mode is that it puts point in front of file
> name.  So when the region doesn't cover the file name visually, it
> should not take the file name outside the region into consideration
> for marking.

But this does not describe what we currently have: you can mark N
complete lines, from the beginning to the end of the lines.  The file in
line N is always not marked.

> Exactly like kill-region should not kill text outside of the active
> region, dired-mark should not mark files outside of the active region.
>
> Especially more dangerous command dired-flag-file-deletion
> should not delete files outside of the active region.

This is a bit philosophical.  You can find an argument like this for any
behavior.  Personally, in my mind I identify the whole line as
associated to a certain file.  Whatever choice we take we should
document how an an active region is interpreted since different kinds of
behavior might be natural for different users.

> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
> > an active region - but that isn't implemented (though it would not be
> > hard to do).  I think that would be useful.
>
> The problem is that this feature should be implemented in the macro
> dired-mark-if, but then it will affect many other commands:
>
> dired-mark-files-containing-regexp
> dired-mark-symlinks
> dired-mark-directories
> dired-mark-executables
> dired-flag-auto-save-files
> dired-flag-backup-files
> dired-compare-directories
> dired-mark-unmarked-files
> dired-mark-sexp
> ...

Yes.  I think I would vote pro such a change.  It could also be made
optional by introducing a new user option.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> The peculiarity of dired mode is that it puts point in front of file
>> name.  So when the region doesn't cover the file name visually, it
>> should not take the file name outside the region into consideration
>> for marking.
>
> But this does not describe what we currently have: you can mark N
> complete lines, from the beginning to the end of the lines.  The file in
> line N is always not marked.

Currently region-based marking works consistently with
argument-based marking, i.e. marking N files using an argument
marks the same number of files as marked by region, for example:

1. when you want to mark next 2 files, you can type:

   C-u 2 m

2. doing the same using the region, you can type the same argument number:

   C-SPC
   C-u 2 n
   m

Using the same number (2 in this case) marks the same number of files.

>> Exactly like kill-region should not kill text outside of the active
>> region, dired-mark should not mark files outside of the active region.
>>
>> Especially more dangerous command dired-flag-file-deletion
>> should not delete files outside of the active region.
>
> This is a bit philosophical.  You can find an argument like this for any
> behavior.  Personally, in my mind I identify the whole line as
> associated to a certain file.  Whatever choice we take we should
> document how an an active region is interpreted since different kinds of
> behavior might be natural for different users.

What do you think about marking the file on the current line
only when point is at the end of the line,
so the file name is completely inside the region?

>> > (2) Most of the time I rather want `dired-mark-files-regexp' to respect
>> > an active region - but that isn't implemented (though it would not be
>> > hard to do).  I think that would be useful.
>>
>> The problem is that this feature should be implemented in the macro
>> dired-mark-if, but then it will affect many other commands:
>>
>> dired-mark-files-containing-regexp
>> dired-mark-symlinks
>> dired-mark-directories
>> dired-mark-executables
>> dired-flag-auto-save-files
>> dired-flag-backup-files
>> dired-compare-directories
>> dired-mark-unmarked-files
>> dired-mark-sexp
>> ...
>
> Yes.  I think I would vote pro such a change.  It could also be made
> optional by introducing a new user option.

Perhaps no option needed because it's easy just to deactivate the region.
But what is important is to notify in the result message that the operation
was performed on the active region.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> What do you think about marking the file on the current line
> only when point is at the end of the line,
> so the file name is completely inside the region?

Please don't.  Marking a line should not care
where point is on the line.  That's always
been true.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Currently region-based marking works consistently with argument-based
> marking, i.e. marking N files using an argument marks the same number
> of files as marked by region [...]

I don't know if users expect that these behave analogue.  I don't,
others surely will.

> What do you think about marking the file on the current line only when
> point is at the end of the line, so the file name is completely inside
> the region?

I think I would not like that more than what we currently have.

What I expect is a behavior analogue to "graphical" file browsers (with
icons and such - I don't use one, but anyway).  When you mark a region
there with the mouse, all files "touched" are in.  And it's enough when
the icon is included, i.e. the file is not identified with the
occurrence of the name on the screen but with the whole representation,
including the icon etc.  I guess that's where my way of thinking comes
from.

If expectations might be that different maybe the behavior should be
made controllable with a new user option?


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

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

> What I expect is a behavior analogue to "graphical" file browsers (with
> icons and such - I don't use one, but anyway).  When you mark a region
> there with the mouse, all files "touched" are in.  And it's enough when
> the icon is included, i.e. the file is not identified with the
> occurrence of the name on the screen but with the whole representation,
> including the icon etc.  I guess that's where my way of thinking comes
> from.

I tried in the default graphical file browser that I have available,
its name is Caja - the file manager for the MATE desktop,
and it works exactly like Emacs currently works:
it doesn't select files based on lines, but it selects only files
whose filenames are inside the selection.  Here is the screenshot:


[-- Attachment #2: caja.png --]
[-- Type: image/png, Size: 10910 bytes --]

[-- Attachment #3: Type: text/plain, Size: 670 bytes --]


But OTOH, it doesn't have the exact analogy with Emacs,
and I know no other files manager exactly like Dired.

> If expectations might be that different maybe the behavior should be
> made controllable with a new user option?

A new user option will help in any case.  But before adding it, maybe we
could try to improve the visual feedback of selection in Dired.  Would it
be possible to display the whole line (including file name) highlighted
with the 'region' face, even when point is still before the file name?

If this is not possbile to implement, then a new user option could have
a name 'dired-mark-non-selected-files' or 'dired-mark-files-on-current-line'.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> A new user option will help in any case.  But before adding it, maybe
> we could try to improve the visual feedback of selection in Dired.

I'd go the other way, because: When a user has set the new option to a
value that reflects his feeling of what is natural, he probably will not
have problems with the standard highlighting.

> Would it be possible to display the whole line (including file name)
> highlighted with the 'region' face, even when point is still before
> the file name?

AFAIU this would be easy - this is how `rectangle-mark-mode's
highlighting is implemented (rect.el):

(add-function :around redisplay-highlight-region-function
              #'rectangle--highlight-for-redisplay)
(add-function :around redisplay-unhighlight-region-function
              #'rectangle--unhighlight-for-redisplay)
(add-function :around region-extract-function
              #'rectangle--extract-region)
(add-function :around region-insert-function
              #'rectangle--insert-region)

I'm not sure if I would want this, though: marking is only thing that
uses the region.  Copying text is another one, for example.  Would the
changed region semantics have an impact on e.g. `kill-ring-save', etc.?


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

Hi Michael,

Just so I can understand better, what's the 
reason you prefer to use the keyboard to
establish an active region that  selects the
lines you want to mark, and then invoke a
command to mark the lines captured by the
region, rather than just using `m' (e.g.
with a prefix arg)?

E.g., Rather than `C-SPC', navigate to the
desired region-end position, and then `m',
why not just use a prefix arg with `m'?

A guess is that you might use something like
`M->' to go to the region-end position.  But
even then, a large prefix arg should do the
job: `C-u 99999 m' versus `C-SPC M-> m'.

Could you give a recipe/example of your use
of keyboard keys for this, or otherwise
explain the rationale for it?

(NB: I'm not arguing that this bug should
not be fixed.  And as mentioned, the fix
should be trivial.)

In Dired+, though I define command
`diredp-mark-region-files' (which, as has
been pointed out, DTRT wrt this bug), I
don't bind it to a key, by default.

I haven't thought such a binding would be
very useful, which is why I ask for an
example use case.

Instead, I just provide mouse and menu
bindings for it when the region's active:
`S-mouse-1', `Mark Region' in a menu-bar
menu, and `Mark' in a `mouse-3' popup menu.

Similarly, for region commands to unmark,
flag, and toggle marks:
`diredp-unmark-region-files',
`diredp-flag-region-files-for-deletion',
`diredp-toggle-marks-in-region'.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> In Dired+, though I define command
> `diredp-mark-region-files' (which, as has
> been pointed out, DTRT wrt this bug), I
> don't bind it to a key, by default.

IIUC, what Michael described is not like Dired+,
but more like another your library zones.el,
i.e. after activating the region, as you move point
in the Dired buffer, the region highlighting should
be updated to put region faces only on file names
using multiple regions, including the file name
of the current line, regardless of where point
is located on the current line: either before or
after the file name, the file name will be highlighted.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > In Dired+, though I define command
> > `diredp-mark-region-files' (which, as has
> > been pointed out, DTRT wrt this bug), I
> > don't bind it to a key, by default.
> 
> IIUC, what Michael described is not like Dired+,
> but more like another your library zones.el,
> i.e. after activating the region, as you move point
> in the Dired buffer, the region highlighting should
> be updated to put region faces only on file names
> using multiple regions, including the file name
> of the current line, regardless of where point
> is located on the current line: either before or
> after the file name, the file name will be highlighted.

Sorry, I don't follow.

I didn't understand Michael's request to be
about multiple zones/regions (noncontiguous).

I think he's just saying what I was saying
earlier: to mark a "file in the region" it
should be sufficient that some part of the
file's line is in the region.  It should
not be a requirement that the full line -
all of its chars (including newline) be
within the region.

Yes, Michael did mention highlighting, but
I think what's important to him is perhaps
just that you can quickly and easily use
the region to specify a set of files to mark.

Whether the region highlight covers this or
that isn't very important, I think.  What's
surprising is that you (currently) have to
be sure to select every bit of a file's line,
for it to be marked.

Anyway, I'll stay out of this now, at least
until what Michael's asking for gets
clarified.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:


> I didn't understand Michael's request to be
> about multiple zones/regions (noncontiguous).
>
> I think he's just saying what I was saying
> earlier: to mark a "file in the region" it
> should be sufficient that some part of the
> file's line is in the region.  It should
> not be a requirement that the full line -
> all of its chars (including newline) be
> within the region.
>
> Yes, Michael did mention highlighting, but
> I think what's important to him is perhaps
> just that you can quickly and easily use
> the region to specify a set of files to mark.
>
> Whether the region highlight covers this or
> that isn't very important, I think.  What's
> surprising is that you (currently) have to
> be sure to select every bit of a file's line,
> for it to be marked.

Yes, a real good summary, thanks!

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

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

> I think he's just saying what I was saying
> earlier: to mark a "file in the region" it
> should be sufficient that some part of the
> file's line is in the region.  It should
> not be a requirement that the full line -
> all of its chars (including newline) be
> within the region.

Including newline?  Really?
This means that on the following screenshot
the file 'file3' should be marked as well?


[-- Attachment #2: dired-mark-3.png --]
[-- Type: image/png, Size: 6703 bytes --]

[-- Attachment #3: Type: text/plain, Size: 245 bytes --]


Here the beginning of the region is at the beginning of the line with 'file1',
and the end of the region is at the beginning of the line with 'file3'.
I can't believe that 'file3' should be marked only because its newline
is inside the region.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > I think he's just saying what I was saying
> > earlier: to mark a "file in the region" it
> > should be sufficient that some part of the
> > file's line is in the region.  It should
> > not be a requirement that the full line -
> > all of its chars (including newline) be
> > within the region.
> 
> Including newline?  Really?
> This means that on the following screenshot
> the file 'file3' should be marked as well?

No.  That's not what I meant.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Including newline?  Really?
>> This means that on the following screenshot
>> the file 'file3' should be marked as well?
>
> No.  That's not what I meant.

Then we agree that
(progn (goto-char end) (line-beginning-position))
should NOT be replaced with
(progn (goto-char end) (line-end-position))

bug#39902: 28.0.50; Marking in dired with active region

[Stephen Berman]

On Wed, 11 Mar 2020 01:24:20 +0200 Juri Linkov <juri@linkov.net> wrote:

>>> Including newline?  Really?
>>> This means that on the following screenshot
>>> the file 'file3' should be marked as well?
>>
>> No.  That's not what I meant.
>
> Then we agree that
> (progn (goto-char end) (line-beginning-position))
> should NOT be replaced with
> (progn (goto-char end) (line-end-position))

How about this:

 (progn (goto-char end) (line-end-position) (backward-char 1) (point))

Steve Berman

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> Then we agree that
>> (progn (goto-char end) (line-beginning-position))
>> should NOT be replaced with
>> (progn (goto-char end) (line-end-position))
>
> How about this:
>
>  (progn (goto-char end) (line-end-position) (backward-char 1) (point))

Probably you meant

   (progn (goto-char end) (backward-char 1) (line-end-position) (point))

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> (progn (goto-char end) (line-beginning-position))
> should NOT be replaced with
> (progn (goto-char end) (line-end-position))

I see.  Yes.  We can decide how to handle that
corner case.  If the region end is bolp then
`1-' it.  That's one possibility.

(progn (goto-char end)
	 (when (bolp) (backward-char))
	 (line-end-position))

This feature/problem is not a big deal, IMO.
I think what Michael is asking for is pretty
straightforward, as is the code needed.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> I can't believe that 'file3' should be marked only because its newline
> is inside the region.

OTOH, if point is at the end of the region (in contrast to your
screenshot), one could be surprised that the file line where the cursor
is displayed doesn't get marked.

This is a strange corner case.  I never used a region like that, I guess
because I felt that this case is dubious.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> OTOH, if point is at the end of the region (in contrast to your
> screenshot), one could be surprised that the file line where the cursor
> is displayed doesn't get marked.

Right, here is a complete patch that should do the right thing
depending on the new defcustom:

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..486a8213c8 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -3578,6 +3578,12 @@ dired-mark-files-in-region
 	    (insert dired-marker-char)))
       (forward-line 1))))
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' marks file on the region end."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 (defun dired-mark (arg &optional interactive)
   "Mark the file at point in the Dired buffer.
 If the region is active, mark all files in the region.
@@ -3597,7 +3603,11 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (and dired-mark-inclusive
+                         (get-text-property (point) 'dired-filename))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> OTOH, if point is at the end of the region (in contrast to your
>> screenshot), one could be surprised that the file line where the cursor
>> is displayed doesn't get marked.
>
> Right, here is a complete patch that should do the right thing
> depending on the new defcustom:

Sorry, this patch was a response to another your comment:

>> This is a strange corner case.  I never used a region like that, I guess
>> because I felt that this case is dubious.

This means that the patch doesn't handle this strange corner case,
but it handles more usual case where point is on the file name:

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..420938ef2e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -3578,6 +3578,12 @@ dired-mark-files-in-region
 	    (insert dired-marker-char)))
       (forward-line 1))))
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' marks file on the region end."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 (defun dired-mark (arg &optional interactive)
   "Mark the file at point in the Dired buffer.
 If the region is active, mark all files in the region.
@@ -3597,7 +3603,11 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (and dired-mark-inclusive
+                         (or (eolp) (get-text-property (point) 'dired-filename)))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> +(defcustom dired-mark-inclusive nil
> +  "Non-nil means `dired-mark' marks file on the region end."
> +  :type 'boolean
> +  :version "28.1"
> +  :group 'dired)

> +	 (progn (goto-char end)
> +                (if (and dired-mark-inclusive
> +                         (or (eolp) (get-text-property (point) 'dired-
> filename)))
> +                    (line-end-position)
> +                  (line-beginning-position)))))))

I see no reason for such an option.  And no reason
for the broken default behavior that the original
complaint was about.

Is using `line-beginning-position' here really
something you think is useful?

My vote is to use what I suggested, or similar:

(progn (goto-char end)
	 (when (bolp) (backward-char))
	 (line-end-position))

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> My vote is to use what I suggested, or similar:
>
> (progn (goto-char end)
> 	 (when (bolp) (backward-char))
> 	 (line-end-position))

Yes, I think this suits my expectations better than Juri's patch.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I see no reason for such an option.  And no reason
> for the broken default behavior that the original
> complaint was about.

In 2012 you asked me to implement this feature, and after implementing it
you confirmed that it has the right implementation.  Changing its
long-standing default behavior now will cause backward-incompatibility
in users' habits.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > I see no reason for such an option.  And no reason
> > for the broken default behavior that the original
> > complaint was about.
> 
> In 2012 you asked me to implement this feature, and after implementing it
> you confirmed that it has the right implementation.  Changing its
> long-standing default behavior now will cause backward-incompatibility
> in users' habits.

Really?  What feature is that?  Could you please
point me to my request for it?

Could you also please describe the user habit in
question, and the change that would break it?

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

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

> Really?  What feature is that?  Could you please
> point me to my request for it?

bug#10624

> Could you also please describe the user habit in
> question, and the change that would break it?

The most obvious way for users to mark e.g. next 2 files
is to type S-down 2 times, then type 'm', especially
convenient when arrow keys are located near the 'm' key.

For example, here is the screenshot where you agreed
that only 2 files should be marked:


[-- Attachment #2: dired-mark-1.png --]
[-- Type: image/png, Size: 2197 bytes --]

[-- Attachment #3: Type: text/plain, Size: 102 bytes --]


But this is not much different from this screenshot
because 'file3' still is not inside the region:


[-- Attachment #4: dired-mark-2.png --]
[-- Type: image/png, Size: 2298 bytes --]

bug#39902: 28.0.50; Marking in dired with active region

[Pieter van Oostrum]

Juri Linkov <juri@linkov.net> writes:

>> Really?  What feature is that?  Could you please
>> point me to my request for it?
>
> bug#10624
>
>> Could you also please describe the user habit in
>> question, and the change that would break it?
>
> The most obvious way for users to mark e.g. next 2 files
> is to type S-down 2 times, then type 'm', especially
> convenient when arrow keys are located near the 'm' key.
>
> For example, here is the screenshot where you agreed
> that only 2 files should be marked:
>
(>
>
>
> But this is not much different from this screenshot
> because 'file3' still is not inside the region:
>
()Sorry, the images are not included in the followup)

What I see in this scenario (S-down twice), looks like the second image: cursor just before the first character of the third filename, the one that should not be included.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Pieter van Oostrum <pieter-l@vanoostrum.org> writes:

> What I see in this scenario (S-down twice), looks like the second
> image: cursor just before the first character of the third filename,
> the one that should not be included.

Not everybody will think like that (that it should not be included).

Maybe most people avoid that case anyway?  Would it then be appropriate
if the marking commands would just raise a `user-error' in this case/
such cases?

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > What I see in this scenario (S-down twice), looks like the second
> > image: cursor just before the first character of the third filename,
> > the one that should not be included.
> 
> Not everybody will think like that (that it should not be included).
> 
> Maybe most people avoid that case anyway?  Would it then be appropriate
> if the marking commands would just raise a `user-error' in this case/
> such cases?

I've given my opinion in my reply to Juri:

  Act on each file when any non-empty part
  of its line is in the active region.

So far, the actions we're talking about are
only _marking_ actions (mark with * or some
other mark, flag with D, or unmark).

IMO there's no need for any kind of error,
warning, or confirmation requirement when
just (un)marking.

And for commands that _use_ marks, acting on
the marked or flagged files, we already do
require confirmation when it makes sense.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

>>>> I see no reason for such an option.  And no reason
>>>> for the broken default behavior that the original
>>>> complaint was about.
>>>
>>> In 2012 you asked me to implement this feature,
>>> and after implementing it you confirmed that it has
>>> the right implementation.  Changing its long-standing
>>> default behavior now will cause backward-incompatibility
>>> in users' habits.
>>
>> Really?  What feature is that?  Could you please
>> point me to my request for it?
> 
> bug#10624

Sorry, I see nowhere at all in that (long) bug thread
where I asked you to implement such an option or the
broken behavior cited, or where confirmed that such
behavior is correct.

And if you find somewhere where I did say such things
then I'd say now that I was wrong then.  (My reading
of that thread doesn't find anything I disagree with
now or that contradicts what I've said here - but
that's not important.)

To me, that (open) enhancement request is anyway about
more important things than what you implemented or what
we're discussing now.

> > Could you also please describe the user habit in
> > question, and the change that would break it?
> 
> The most obvious way for users to mark e.g. next 2 files
> is to type S-down 2 times, then type 'm', especially
> convenient when arrow keys are located near the 'm' key.

I think that's what we're talking about.

I don't have a problem with users doing that.  What's the
problem with that?  What habit would be broken?

What we're talking about, I thought, is that, IF you use
`m' (or other mark-changing keys) AFTER you do that (or
after something else that selects parts of contiguous
file lines as the active region), THEN that marking
command acts on each file that has ANY part of its line
selected.  That's what the behavior should be, IMO.

You pointed out the corner case of a region that ends
at bol.  A fix for that corner case was provided.

> For example, here is the screenshot where you agreed
> that only 2 files should be marked:
>
> But this is not much different from this screenshot
> because 'file3' still is not inside the region:

That second image, where point is not at bol, _should_
result in the 3rd file being marked, IMO - and it does.
I don't see a problem with the bolp fix provided.

For me, it's about whether ANY (non-empty, hence the
bolp fix) part of a file's line is selected.  It's not
about whether the _file name_ is selected.  Actions in
Dired are generally (maybe even only) apply to a file
line, not to its file-name portion.

(An action, such as renaming, might affect only the
file-name portion as its _result_.  But it takes
effect on the file designated by that line.  And other
actions (e.g. chmod, touch) can affect other parts of
the line (e.g. permissions, date).

We've been around and around about the question now.
I think those who have spoken up in this thread,
including OP Michael - with you as the exception, feel
the same way: Act on each file when any non-empty part
of its line is in the active region.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>> The most obvious way for users to mark e.g. next 2 files
>> is to type S-down 2 times, then type 'm', especially
>> convenient when arrow keys are located near the 'm' key.
>
> I don't have a problem with users doing that.  What's the
> problem with that?  What habit would be broken?

The habit of typing S-down twice to mark two files, not three.

> What we're talking about, I thought, is that, IF you use
> `m' (or other mark-changing keys) AFTER you do that (or
> after something else that selects parts of contiguous
> file lines as the active region), THEN that marking
> command acts on each file that has ANY part of its line
> selected.  That's what the behavior should be, IMO.

1.
> That second image, where point is not at bol, _should_
> result in the 3rd file being marked, IMO - and it does.

2.
> For me, it's about whether ANY (non-empty, hence the
> bolp fix) part of a file's line is selected.

Aren't the above two sentences contradicting?
Because on the second image there is only empty space
before the file name, so according to your second sentence,
the 3rd file should NOT be marked.

> (An action, such as renaming, might affect only the
> file-name portion as its _result_.  But it takes
> effect on the file designated by that line.  And other
> actions (e.g. chmod, touch) can affect other parts of
> the line (e.g. permissions, date).
>
> We've been around and around about the question now.
> I think those who have spoken up in this thread,
> including OP Michael - with you as the exception, feel
> the same way: Act on each file when any non-empty part
> of its line is in the active region.

Why non-empty part of the line?  It's more logical about
the non-empty part of the file name, because dired
commands don't act on lines, but on files.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Why non-empty part of the line?  It's more logical about
> the non-empty part of the file name, because dired
> commands don't act on lines, but on files.

But also not on file names.  I suggest to stop discussing which
identification of a file vs. what appears in the dired buffer is more
logical.  I think it has become clear that we have different viewpoints
here.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Why non-empty part of the line?  It's more logical about
> > the non-empty part of the file name, because dired
> > commands don't act on lines, but on files.
> 
> But also not on file names.  I suggest to stop discussing which
> identification of a file vs. what appears in the dired buffer is more
> logical.  I think it has become clear that we have different viewpoints
> here.

Yes.

RMS might say, "Take a user poll".  I doubt that
will happen.  If the price to pay, to get this
fixed, is for Juri to add an option that lets
users choose the behavior, so be it.

The bug is minor, IMHO.  And so is the fix.
And so is the disagreement about which behavior
is more natural or more useful.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> >> The most obvious way for users to mark e.g. next 2 files
> >> is to type S-down 2 times, then type 'm', especially
> >> convenient when arrow keys are located near the 'm' key.
> >
> > I don't have a problem with users doing that.  What's the
> > problem with that?  What habit would be broken?
> 
> The habit of typing S-down twice to mark two files, not three.

S-down doesn't mark anything.  `m' and other keys
mark files.

And the fact of `m' marking files in the region
is relatively recent.  And there are many ways
to define an active region, and for most of them
the corner case you cited would be very rare.

To me, this is a (minor) bug fix; nothing more.
You can proclaim it backward-incompatible in
terms of interactive behavior.  That doesn't
bother me.

And as someone else pointed out, we usually
don't cry "backward incompatible" when it comes
to changing use behavior; we typically use that
term for code changes.  Emacs developers change
behavior of user interactions fairly often (you
among them), with nary a blink - and especially
when it's about a bug fix.

But if you are truly worried about that, and you
honestly think that either (1) many users will
be shocked by such a behavior fix or (2) you
strongly hate the fix, then just add an option
to provide the old, broken behavior.  I'm not in
favor of such an option, but if that's the price
to pay to get this fixed, so be it.

> > What we're talking about, I thought, is that, IF you use
> > `m' (or other mark-changing keys) AFTER you do that (or
> > after something else that selects parts of contiguous
> > file lines as the active region), THEN that marking
> > command acts on each file that has ANY part of its line
> > selected.  That's what the behavior should be, IMO.
> 
> 1.
> > That second image, where point is not at bol, _should_
> > result in the 3rd file being marked, IMO - and it does.
> 
> 2.
> > For me, it's about whether ANY (non-empty, hence the
> > bolp fix) part of a file's line is selected.
> 
> Aren't the above two sentences contradicting?
> Because on the second image there is only empty space
> before the file name, so according to your second sentence,
> the 3rd file should NOT be marked.

What part of "ANY (non-empty...) part of a
file's line" is unclear?  I didn't say any
non-whitespace part.

> > (An action, such as renaming, might affect only the
> > file-name portion as its _result_.  But it takes
> > effect on the file designated by that line.  And other
> > actions (e.g. chmod, touch) can affect other parts of
> > the line (e.g. permissions, date).
> >
> > We've been around and around about the question now.
> > I think those who have spoken up in this thread,
> > including OP Michael - with you as the exception, feel
> > the same way: Act on each file when any non-empty part
> > of its line is in the active region.
> 
> Why non-empty part of the line?  It's more logical about
> the non-empty part of the file name, because dired
> commands don't act on lines, but on files.

Quite the contrary, as I and others have
explained several times now.  And in fact
that's one of the main points: that's how
Dired behaves.

As I said in the very same paragraph as
your cited #2, above:

  Actions in Dired are generally (maybe even
  only) apply to a file line, not to its
  file-name portion.

  (An action, such as renaming, might affect
  only the file-name portion as its _result_.
  But it takes effect on the file designated
  by that line.  And other actions (e.g. chmod,
  touch) can affect other parts of the line
  (e.g. permissions, date).)

Dired actions act directly on file/directory
lines.  Typically they do something to the
file or dir.  But in terms of the UI they act
on the line.  A mark on a line is, in UI or
behavior terms, a mark on the line.  It is
only actions that _use_ marks that then act
on the file/dir whose line is marked.  The act
of marking is not an action on the file/dir.

But I (and others) have said this more than
once.  You remain unconvinced.  And you are
the one, I guess, who will or won't fix this,
so you are the one who needs convincing.

In terms of arguing for/against this, I think
we're about done, no?

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

>   Actions in Dired are generally (maybe even
>   only) apply to a file line, not to its
>   file-name portion.

When you are marking files, at what part of the Dired buffer
do you look?  I'm sure at file-names.  Therefore
actions in Dired apply to file-names.

> In terms of arguing for/against this, I think
> we're about done, no?

I already provided 2 strong arguments
that support the current implementation:

1. the number of repeated keystrokes is equal
to the number of selected files, e.g.
'm m' selects 2 files, 'C-SPC n n' selects 2 files,
'S-down S-down' selects 2 files, etc.

This is an important property of the current implementation.

2. consistent visual feedback, i.e. when the file name
is not inside the selected region, it should not be marked.

You provided only 1 argument for changes:

1. mark the file name when the end of the region is before
the file name but not on the beginning of the file line.

And I agreed that this makes sense as well.

Then I proposed to add a new option, but you disagreed.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Actions in Dired are generally (maybe even
> > only) apply to a file line, not to its
> > file-name portion.
> 
> When you are marking files, at what part of
> the Dired buffer do you look?  I'm sure at
> file-names.  Therefore actions in Dired apply
> to file-names.

No.

1. You may look at file names, file-name
   extensions, dates, permissions, sizes,
   symlink targets, marks, deletion flags,...
   - any and all of the info on a file line.

2. In particular, when multiple lines are
   marked you may well look at the marks.
   Or at the ranges of marks, when
   contiguous lines are marked.

3. Even if/when you do "look at file names"
   it does not follow ("therefore") that
   the UI actions you perform apply to file
   names.  As I said, they can apply to marks
   (change, add, remove), and they can apply
   to lines (omit, delete, insert).

And as I said, beyond UI actions, sure, many
of the Dired actions ultimately act on files.
Even in that case, they typically do not act
directly on files.  But only very few actions
(in particular, renaming) apply to file names
(as opposed to files).

> > In terms of arguing for/against this,
> > I think we're about done, no?
> 
> I already provided 2 strong arguments
> that support the current implementation:
> 
> 1. the number of repeated keystrokes is equal
> to the number of selected files, e.g.
> 'm m' selects 2 files, 'C-SPC n n' selects 2 files,
> 'S-down S-down' selects 2 files, etc.

So what?  The question before us has nothing
whatsoever to do with repeated `m'.  That's
no argument for supporting the current
behavior wrt using the region for marking.

This is about a completely different way of
marking a group of lines from using repeated
`m'.  The only things they have in common
are (1) in both cases the lines acted on are
consecutive, and (2) in both cases point is
on the first or last of those lines.

> This is an important property of the current
> implementation.

It's not at all a property of the behavior
of using a region to select.  Irrelevant.
Apples & oranges.

> 2. consistent visual feedback, i.e. when the
> file name is not inside the selected region,
> it should not be marked.

It's not about the file name.  As Michael
said, you have a different opinion about
that.

OK.  But that doesn't provide an argument
for the behavior.  That's just saying that
you prefer the current behavior.  Opinion
cannot be a _reason supporting_ itself.

> You provided only 1 argument for changes:
> 
> 1. mark the file name when the end of the
> region is before the file name but not on
> the beginning of the file line.

I said nothing about marking file names.
I don't believe that Dired marks are about
marking file names.

But yes, my opinion (not a reason for my
opinion) is that it's clearer to act on
each line that has some of it selected.

Why?

1. That's what, I think, users expect, and
   it's what (I think) they're used to in
   other, similar UIs.

2. It's consistent with what happens in
   the rest of Dired.  When you hit `m' -
   or perform nearly any other action -
   does it matter where point is on the
   line?  No, of course not.  Do we expect
   that point needs to be on the file name
   itself because that's where you should
   be looking?  No.

> And I agreed that this makes sense as well.

So we agree on the fix?  Any line, any
(non-empty) part of which is selected, gets
the mark action?

> Then I proposed to add a new option, but
> you disagreed.

Please, add any options you like, if the
default behavior is to fix this (minor) bug
as just mentioned.  That doesn't mean that
I agree that we need such an option, or that
it's a good idea to add it.  But (as I said
already) if that's the price for getting the
bug fixed, so be it.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > This is an important property of the current
> > implementation.
>
> It's not at all a property of the behavior
> of using a region to select.  Irrelevant.
> Apples & oranges.

I think he thinks in terms of consistency.  But consistency depends on
the view point, so his consistency is of no value for people with a
different view point.  Too bad we only know about three opinions.

> Please, add any options you like, if the
> default behavior is to fix this (minor) bug
> as just mentioned.  That doesn't mean that
> I agree that we need such an option, or that
> it's a good idea to add it.  But (as I said
> already) if that's the price for getting the
> bug fixed, so be it.

I see our different views as of the same right and value.  And the use
case (who uses marking commands with an active region at all?) is a
corner case.  I don't mind about the default as long as there is a new
option.  I would rather want to discuss what else should be done
(behavior of other marking commands etc, should we change
`dired-mark-if', etc.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I see our different views as of the same right and value.  And the use
> case (who uses marking commands with an active region at all?) is a
> corner case.  I don't mind about the default as long as there is a new
> option.

There is nothing new here.  Mathematicians have been fighting that battle
for centuries until invention of the special notation to differentiate
including and excluding endpoints using either a square bracket or
a reversed parenthesis to indicate inclusive/exclusive intervals:

https://en.wikipedia.org/wiki/Bracket_(mathematics)#Intervals
https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints

The most recent development is still ongoing in new programming languages.
For example, in the initial versions of Rust there were only
exclusive ranges, so e.g.

  for i in 1..3

yields only 1 and 2, but not 3, like the region mark command in Dired now.

But later Rust versions added inclusive ranges as well with special syntax:

  for i in 1..=3

that yields 1, 2 and 3.

Please see more examples at
https://doc.rust-lang.org/edition-guide/rust-2018/data-types/inclusive-ranges.html

So Dired could do the same and support both range types using a new option
'dired-mark-inclusive'.

> I would rather want to discuss what else should be done
> (behavior of other marking commands etc, should we change
> `dired-mark-if', etc.

I think `dired-mark-if' should respect that option too.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

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

>> I see our different views as of the same right and value.  And the use
>> case (who uses marking commands with an active region at all?) is a
>> corner case.  I don't mind about the default as long as there is a new
>> option.
>
> So Dired could do the same and support both range types using a new option
> 'dired-mark-inclusive'.
>
>> I would rather want to discuss what else should be done
>> (behavior of other marking commands etc, should we change
>> `dired-mark-if', etc.
>
> I think `dired-mark-if' should respect that option too.

Here is a complete implementation, please try if it works for you:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dired-mark-inclusive.patch --]
[-- Type: text/x-diff, Size: 2348 bytes --]

diff --git a/lisp/dired.el b/lisp/dired.el
index a4de51f609..6858245ab7 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -296,6 +296,12 @@ dired-always-read-filesystem
   :version "26.1"
   :group 'dired)
 
+(defcustom dired-mark-inclusive nil
+  "Non-nil means `dired-mark' is inclusive."
+  :type 'boolean
+  :version "28.1"
+  :group 'dired)
+
 ;; Internal variables
 
 (defvar dired-marker-char ?*		; the answer is 42
@@ -613,7 +619,21 @@ dired-mark-if
 MSG is a noun phrase for the type of files being marked.
 It should end with a noun that can be pluralized by adding `s'.
 Return value is the number of files marked, or nil if none were marked."
-  `(let ((inhibit-read-only t) count)
+  `(let ((inhibit-read-only t) count
+         (beg (if (use-region-p)
+                  (save-excursion
+                    (goto-char (region-beginning))
+                    (line-beginning-position))
+                (point-min)))
+         (end (if (use-region-p)
+                  (save-excursion
+                    (goto-char (region-end))
+                    (if (if dired-mark-inclusive
+                            (not (bolp))
+                          (get-text-property (1- (point)) 'dired-filename))
+                        (line-end-position)
+                      (line-beginning-position)))
+                (point-max))))
     (save-excursion
       (setq count 0)
       (when ,msg
@@ -626,8 +646,8 @@ dired-mark-if
 		 (if (eq dired-del-marker dired-marker-char)
 		     " for deletion"
 		   "")))
-      (goto-char (point-min))
-      (while (not (eobp))
+      (goto-char beg)
+      (while (< (point) end)
         (when ,predicate
           (unless (= (following-char) dired-marker-char)
             (delete-char 1)
@@ -3597,7 +3622,12 @@ dired-mark
 	    (end (region-end)))
 	(dired-mark-files-in-region
 	 (progn (goto-char beg) (line-beginning-position))
-	 (progn (goto-char end) (line-beginning-position))))))
+	 (progn (goto-char end)
+                (if (if dired-mark-inclusive
+                        (not (bolp))
+                      (get-text-property (1- (point)) 'dired-filename))
+                    (line-end-position)
+                  (line-beginning-position)))))))
    ;; Mark subdir files from the subdir headerline.
    ((dired-get-subdir)
     (save-excursion (dired-mark-subdir-files)))

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Here is a complete implementation, please try if it works for you:

Yes, works well, thank you very much.  Also other marking commands seem
to work well with the new option.

The docstring of `dired-mark-inclusive' should be enhanced a bit I
think.  You could add one sentence about what "inclusive" means, and
another saying that other (un-)marking commands are also covered.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Here is a complete implementation, please try if it works for you:
> 
> Yes, works well, thank you very much.  Also other marking commands seem
> to work well with the new option.
> 
> The docstring of `dired-mark-inclusive' should be enhanced a bit I
> think.  You could add one sentence about what "inclusive" means, and
> another saying that other (un-)marking commands are also covered.

I took a quick look - didn't check much.  

Seems OK to me too (but I'd prefer a non-nil default
value for the option, as already mentioned).

---

However, I notice one thing that seems like a bug
(didn't notice it before) - and the bug is present even
without the patch:

If `use-empty-active-region' is non-nil, and the region
is empty, then `m' marks the current line only sometimes,
depending on where point is.  And the behavior differs,
depending on the value of option `dired-mark-inclusive':

`dired-mark-inclusive' = nil:

   marks line only if point is on the 2nd file-name
   char or any char after that (including eol, i.e.,
   _after_ the file name)

`dired-mark-inclusive' = t:

   marks only if point is not at bol

IMO, the behavior should be the same, regardless of
the cursor position on the line.  I think it should
mark the line:

* for any position, if `dired-mark-inclusive' = t
* for any position on the file name, otherwise

Juri, you decide the behavior for the nil case, but
I think it should be consistent.  Personally, I see
no reason that point on the first file-name char
would act differently from point on the second.  And
by the logic of non-inclusive I'd think that an empty
region _after_ the file name wouldn't mark the line
(no part of the file name is in the region).

For the non-nil case, I think it's important that the
line get marked even when point is at bol.

Why?  Consistency.  And it's easy to hit `C-SPC'
without realizing that you've done so - there's no
good visual signal (just the "Mark activated" msg).

In the non-nil case, especially, I really feel that
a user expects the line to be marked, even if the
region is empty (when `use-empty-active-region' is
non-nil).

---

As I said earlier, I really suspect that Emacs may
have lurking bugs because stuff that makes use of
`use-region-p' might not get tested with non-nil
`use-empty-active-region'.  And yet the reason for
creating that option was for the addition of that
function (or vice versa).

[Frankly, I think things were clearer in the code
before `use-region-p' and that option were added.
`region-active-p' was clear; `use-region-p' hides
use of an option, and I suspect that the non-nil
case doesn't get tested much.  When just
`region-active-p' was used, it kinda invited testing
whether the region was empty.]

(FWIW, I don't use non-nil `use-empty-active-region'.
But I imagine some people do.)

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> I took a quick look - didn't check much.  
>
> Seems OK to me too (but I'd prefer a non-nil default
> value for the option, as already mentioned).
>
> ---
>
> However, I notice one thing that seems like a bug
> (didn't notice it before) - and the bug is present even
> without the patch:
>
> If `use-empty-active-region' is non-nil, and the region
> is empty, then `m' marks the current line only sometimes,
> depending on where point is.  And the behavior differs,
> depending on the value of option `dired-mark-inclusive':
>
> `dired-mark-inclusive' = nil:
>
>    marks line only if point is on the 2nd file-name
>    char or any char after that (including eol, i.e.,
>    _after_ the file name)
>
> `dired-mark-inclusive' = t:
>
>    marks only if point is not at bol
>
> IMO, the behavior should be the same, regardless of
> the cursor position on the line.  I think it should
> mark the line:
>
> * for any position, if `dired-mark-inclusive' = t
> * for any position on the file name, otherwise
>
> Juri, you decide the behavior for the nil case, but
> I think it should be consistent.  Personally, I see
> no reason that point on the first file-name char
> would act differently from point on the second.  And
> by the logic of non-inclusive I'd think that an empty
> region _after_ the file name wouldn't mark the line
> (no part of the file name is in the region).
>
> For the non-nil case, I think it's important that the
> line get marked even when point is at bol.
>
> Why?  Consistency.  And it's easy to hit `C-SPC'
> without realizing that you've done so - there's no
> good visual signal (just the "Mark activated" msg).
>
> In the non-nil case, especially, I really feel that
> a user expects the line to be marked, even if the
> region is empty (when `use-empty-active-region' is
> non-nil).
>
> ---
>
> As I said earlier, I really suspect that Emacs may
> have lurking bugs because stuff that makes use of
> `use-region-p' might not get tested with non-nil
> `use-empty-active-region'.  And yet the reason for
> creating that option was for the addition of that
> function (or vice versa).
>
> [Frankly, I think things were clearer in the code
> before `use-region-p' and that option were added.
> `region-active-p' was clear; `use-region-p' hides
> use of an option, and I suspect that the non-nil
> case doesn't get tested much.  When just
> `region-active-p' was used, it kinda invited testing
> whether the region was empty.]
>
> (FWIW, I don't use non-nil `use-empty-active-region'.
> But I imagine some people do.)

Sorry, I received your message only after I pushed to master.
But nonetheless, your test cases should be handled carefully.
The simplest solution would be just to disallow the option
`use-empty-active-region' to use the empty region in Dired,
i.e. instead of

  (if (use-region-p)
  ... then mark files in the active region ...

to use

  (if (let ((use-empty-active-region nil)) (use-region-p))
  ... then mark files in the active region ...

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> Sorry, I received your message only after I pushed to master.
> But nonetheless, your test cases should be handled carefully.
> The simplest solution would be just to disallow the option
> `use-empty-active-region' to use the empty region in Dired,
> i.e. instead of
> 
>   (if (use-region-p)
>   ... then mark files in the active region ...
> 
> to use
> 
>   (if (let ((use-empty-active-region nil)) (use-region-p))
>   ... then mark files in the active region ...

Yes, that's what I was hinting at: an empty
region should always be ignored, i.e., that case
should be treated as if the region were not
active.

A better way to do it than binding that variable
(even if it were _not_ a user option) is to just
do what one would have done before `use-region-p'
was defined:

(if (and (region-active-p)
         (> (region-end) (region-beginning)))
    ...

Really, `use-region-p', although convenient, is
error prone.  Few use cases really call for
being able to use an empty region (non-nil
`use-empty-active-region'), and code that deals
with the region is much clearer if it says
explicitly what it intends for an empty region.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> And it's easy to hit `C-SPC' without realizing that you've done so -
> there's no good visual signal (just the "Mark activated" msg).

Typing `C-x SPC' shows an indication as a thin vertical bar highlighted
with the region face.  But `C-SPC' doesn't have the same subtle indication.

>> i.e. instead of
>> 
>>   (if (use-region-p)
>>   ... then mark files in the active region ...
>> 
>> to use
>> 
>>   (if (let ((use-empty-active-region nil)) (use-region-p))
>>   ... then mark files in the active region ...
>
> Yes, that's what I was hinting at: an empty
> region should always be ignored, i.e., that case
> should be treated as if the region were not
> active.
>
> A better way to do it than binding that variable
> (even if it were _not_ a user option) is to just
> do what one would have done before `use-region-p'
> was defined:
>
> (if (and (region-active-p)
>          (> (region-end) (region-beginning)))
>     ...
>
> Really, `use-region-p', although convenient, is
> error prone.  Few use cases really call for
> being able to use an empty region (non-nil
> `use-empty-active-region'), and code that deals
> with the region is much clearer if it says
> explicitly what it intends for an empty region.

Thanks for the suggestion, now changed in master.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > And it's easy to hit `C-SPC' without realizing that you've done so -
> > there's no good visual signal (just the "Mark activated" msg).
> 
> Typing `C-x SPC' shows an indication as a thin vertical bar highlighted
> with the region face.  But `C-SPC' doesn't have the same subtle
> indication.

Yes, sorry, I meant `C-SPC'.

> > an empty region should always be ignored...
> > A better way to do it...:
> > (if (and (region-active-p)
> >          (> (region-end) (region-beginning)))
> 
> Thanks for the suggestion, now changed in master.

Glad we reached a conclusion.  Thanks to both of
you for working on this.

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

tags 39902 fixed
close 39902 28.0.50
quit

>> Here is a complete implementation, please try if it works for you:
>
> Yes, works well, thank you very much.  Also other marking commands seem
> to work well with the new option.
>
> The docstring of `dired-mark-inclusive' should be enhanced a bit I
> think.  You could add one sentence about what "inclusive" means, and
> another saying that other (un-)marking commands are also covered.

I enhanced the docstring, renamed to `dired-mark-region',
and pushed to master.

The default behavior was unchanged since it's consistent with
marking without region. But this is not my personal preference.
I have dozens of customized options in my init file, even for features
that I implemented, my customization still differs from default values
that make sense for most users.  The default value of the new option
`dired-mark-region' could be changed too in case more people
will demand this.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > The docstring of `dired-mark-inclusive' should be enhanced a bit I
> > think.  You could add one sentence about what "inclusive" means, and
> > another saying that other (un-)marking commands are also covered.
> 
> I enhanced the docstring, renamed to `dired-mark-region',
> and pushed to master.
> 
> The default behavior was unchanged since it's consistent with
> marking without region. But this is not my personal preference.
> I have dozens of customized options in my init file, even for features
> that I implemented, my customization still differs from default values
> that make sense for most users.  The default value of the new option
> `dired-mark-region' could be changed too in case more people
> will demand this.

Thank you for changing the name of the option.  I meant
to say something about that, but forgot.

I don't know what you have as the doc string (I don't
have the diff/patch), but here's my opinion about the
option description:

It's _not_ good to express it in the terms you described:
as being about including or excluding the limit at the
region end.  That's not it at all, IMO.

This should be expressed in terms of the behavior being
either line-oriented (as is nearly all of Dired) or
file-name oriented.

Put differently, the description should say that the
two choices are these:

1. Mark if _any_ part of the file's line is selected.
2. Mark if _all_ of the file name is selected.

(Where "selected" means "in the region".)

That's much clearer, I think.  It's expressed in terms
of what users do and see.  Either you need to select
some part of the line or you need to select all of the
file name.  What could be simpler?

(Anyway, I'm glad we've more or less reached agreement.)

bug#39902: 28.0.50; Marking in dired with active region

[Juri Linkov]

> It's _not_ good to express it in the terms you described:
> as being about including or excluding the limit at the
> region end.  That's not it at all, IMO.
>
> This should be expressed in terms of the behavior being
> either line-oriented (as is nearly all of Dired) or
> file-name oriented.
>
> Put differently, the description should say that the
> two choices are these:
>
> 1. Mark if _any_ part of the file's line is selected.
> 2. Mark if _all_ of the file name is selected.
>
> (Where "selected" means "in the region".)
>
> That's much clearer, I think.  It's expressed in terms
> of what users do and see.  Either you need to select
> some part of the line or you need to select all of the
> file name.  What could be simpler?
>
> (Anyway, I'm glad we've more or less reached agreement.)

Thanks, now the option is changed to provide two values to distinguish
line/file name based cases instead of exclusive/inclusive.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > (Anyway, I'm glad we've more or less reached agreement.)
> 
> Thanks, now the option is changed to provide two values to distinguish
> line/file name based cases instead of exclusive/inclusive.

Sounds good.  Thx.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> My vote is to use what I suggested, or similar:
> 
> (progn (goto-char end)
> 	 (when (bolp) (backward-char))
> 	 (line-end-position))

This (and I guess the variants that others
proposed) has a bug when point is at bol, the
region is empty, and `use-empty-active-region'
is non-nil.  In that case it raises an error
saying that "start > end" (which is not a very
clear error message in general, BTW).

This code seems to DTRT:

(progn (goto-char end)
       (when (and (bolp) (> end beg))
         (backward-char))
       (line-end-position))

[Non-nil option `use-empty-active-region' is
a pesky use case.  A guess is that there are
other, similar bugs lurking in Emacs.  I
wonder how many times we actually test for
that use case when we use `use-region-p'.]

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > In Dired+, though I define command
> > `diredp-mark-region-files' (which, as has
> > been pointed out, DTRT wrt this bug), I
> > don't bind it to a key, by default.
>
> IIUC, what Michael described is not like Dired+,
> but more like another your library zones.el,
> i.e. after activating the region, as you move point
> in the Dired buffer, the region highlighting should
> be updated to put region faces only on file names
> using multiple regions, including the file name
> of the current line, regardless of where point
> is located on the current line: either before or
> after the file name, the file name will be highlighted.

I don't care that much what is highlighted.  I just care about how the
region, i.e. the current value of point and mark, are interpreted.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Could you give a recipe/example of your use of keyboard keys for this,
> or otherwise explain the rationale for it?

Say the files in the dired buffer are photos/songs or so.  I mark all of
them, or those of them I'm interested in.  I open the files with a
viewer or vlc or whatever.  There I have a look at them, in the same
order as they originally appeared in dired.  Now say I am interrupted,
and/or I have deleted some of the files, and want to resume with the
rest of the files, or some other subset.  I.e. I want to mark subsets
(of subsequent files) in a dired buffer to look at the files in this
order, and the most natural way for me to do this is to use the region
for marking.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> > Could you give a recipe/example of your use of
> > keyboard keys for this, or otherwise explain
> > the rationale for it?
> 
> Say the files in the dired buffer are photos/songs or so.  I mark all of
> them, or those of them I'm interested in.  I open the files with a
> viewer or vlc or whatever.  There I have a look at them, in the same
> order as they originally appeared in dired.  Now say I am interrupted,
> and/or I have deleted some of the files, and want to resume with the
> rest of the files, or some other subset.  I.e. I want to mark subsets
> (of subsequent files) in a dired buffer to look at the files in this
> order, and the most natural way for me to do this is to use the region
> for marking.

I still don't understand well.

1. You mark some files in Dired, then open them in
some other app.  Those files are still marked in
Dired, I suppose.  Or do you unmark them?  Or
doesn't it matter?

2. In that app, you do something with the files,
viewing and manipulating them in the same order
they had in Dired.  You may even delete some or
add some new ones.

3. You're interrupted.  How so - is Emacs closed?
is the other app closed?  What's the significance
of the interruption?

4. Later (same Emacs session?) you want to resume
using the external app with some of the marked files
you haven't yet manipulated.

That much I get.  I don't understand the rest.

5. You want to mark, in Dired, some of the files
you haven't yet worked with in the app.  OK.

"to look at the files in this order"  In what order?
What's the importance of the order?

Can you describe what you want to do at this point?
In particular, what do you want to do wrt selecting
and then marking the selected files?

IOW, I still have the same question: What's your
expected use of keyboard keys for this, and why?

For example, why wouldn't you just use `g' (to
refresh the listing, to reflect deleted or added
files), then `C-u 99999 m' starting where you left
off?

To be clear, I'm not trying to say you should do
something different from what you're requesting.
I'm just trying to understand what you want to do
and why.

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> I still don't understand well.

Oh dear...ok.

> 1. You mark some files in Dired, then open them in
> some other app.  Those files are still marked in
> Dired, I suppose.  Or do you unmark them?  Or
> doesn't it matter?

Typically they are still marked.

> 2. In that app, you do something with the files,
> viewing and manipulating them in the same order
> they had in Dired.  You may even delete some or
> add some new ones.

Yes.

> 3. You're interrupted.  How so - is Emacs closed?

No no.  But I didn't use Emacs in the meantime.  Doesn't that count as
interrupted?

> is the other app closed?

Typically, yes.

> What's the significance of the interruption?

That I'm typically done with a subset of the previously marked files,
and I want to restart the external app or whatever with the rest of the
files, or a subset of them.

> 4. Later (same Emacs session?)

Yes, same session.

> 5. You want to mark, in Dired, some of the files
> you haven't yet worked with in the app.  OK.
>
> "to look at the files in this order"  In what order?

The order the files appear in the dired buffer.

> What's the importance of the order?

If I did not have a look at all of the files in the external app, and
the external app would present the files to me in some different order,
it would be hard to mark "the rest" of the files in dired to continue.

> For example, why wouldn't you just use `g' (to
> refresh the listing, to reflect deleted or added files),

I do that of course.

> then `C-u 99999 m' starting where you left off?

I could do that.  I didn't use to use these keys because I just
... wanted to use the region.  Plus, maybe I don't want to continue with
all of the remaining files but only a subset?

> To be clear, I'm not trying to say you should do
> something different from what you're requesting.

Yeah, and I think this is only just one random personal use case of `m'
with active region, let's not overstate this case.  I expect marking in
dired with region active to always behave the same no matter why I do
it.

> I'm just trying to understand what you want to do and why.

If you didn't understand now I'm willing to pay a flight to Germany so I
can show you ;-)


Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

Thanks for the details.  Sorry about not getting it.

> > `C-u 99999 m' starting where you left off?
> 
> I could do that.  I didn't use to use these keys because I just
> ... wanted to use the region.  Plus, maybe I don't want to continue with
> all of the remaining files but only a subset?

OK.  Confirming:

1. You could use `C-u <some number> m', and it would
   be about as easy (number of keystrokes).  You
   might have to guess <some number>, if you wanted
   only some of the remaining files.

2. The point is that, regardless of _why_ you might
   want to mark the files in the region, doing that
   should just work, where "work" means that any file
   with any part of its line in the active region
   gets marked.  (Likewise, for unmarking, flagging,
   changing marks, etc.)

   As you put it:

   > I expect marking in dired with region active to
   > always behave the same no matter why I do it.

As I think I've indicated, I agree 100%.  And I think
the fix is trivial, and it has already been given in
this thread (more than once).  The bug, found by
Stephen Berman, was presumably just a typo in the
first place:

(progn (goto-char end) (line-beginning-position))
should be
(progn (goto-char end) (line-end-position))

Hopefully someone will apply that fix.

> If you didn't understand now I'm willing to pay a
> flight to Germany so I can show you ;-)

In a short while, flights will be almost free, in
money terms - unfortunately for world health. ;-)

bug#39902: 28.0.50; Marking in dired with active region

[martin rudalics]

 > What I expect is a behavior analogue to "graphical" file browsers (with
 > icons and such - I don't use one, but anyway).  When you mark a region
 > there with the mouse, all files "touched" are in.  And it's enough when
 > the icon is included, i.e. the file is not identified with the
 > occurrence of the name on the screen but with the whole representation,
 > including the icon etc.  I guess that's where my way of thinking comes
 > from.

Such "graphical" file browsers are line-based, they do not have a way to
specify a position within such a line unless you are in the (usually F2
invoked) rename mode which puts a mask on the file name whose contents
you can modify.

martin

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Such "graphical" file browsers are line-based, they do not have a way
> to specify a position within such a line unless you are in the
> (usually F2 invoked) rename mode which puts a mask on the file name
> whose contents you can modify.

I don't get your argument.  FWIW, most of these browsers have different
kinds of "views", and I have in mind the view that is not line based but
uses a grid of icons with names under them.  Marking a region with the
mouse happens continuously.

What I want to say here is that the current behavior makes no sense to
me.  And I very much think that I'm not the only one.  I don't want to
justify why I have this expectation and be told that my mental model is
wrong.  There is no way to mathematically prove whose expectations are
right and whose are wrong.  These expectations are always subjective.
When some users are confused by the current behavior, it would be good
to improve Emacs when it's simple as it is here.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[Drew Adams]

> FWIW, most of these browsers have different
> kinds of "views", and I have in mind the view
> that is not line based but uses a grid of icons
> with names under them.  Marking a region with
> the mouse happens continuously.
> 
> What I want to say here is that the current
> behavior makes no sense to me.  And I very much
> think that I'm not the only one.  I don't want
> to justify why I have this expectation and be
> told that my mental model is wrong...
> When some users are confused by the current
> behavior, it would be good to improve Emacs when
> it's simple as it is here.

Ah, I think maybe I'm starting to understand.  (Maybe.)

In your external app you'll select some files, in
a particular order (e.g. as presented in that app).
You might do so using the mouse (in that app), but
that's not really important for the use of Emacs.

Then, you want that selection, made in that app, in
its particular order, to be reflected as a selection
in Dired.

Is that right, so far?

If so, what if the order is so different from the
sort order in Dired that the resulting "selection"
in Dired would be a noncontiguous region - multiple
zones, as Juri mentioned?  Is that a problem?

Assuming that's not a problem (e.g. Dired has the
same order, since the original order came from
Dired - but see below), how would you transfer a
selection in the external app to a selection
(region) in Emacs?

If that's not really needed, then why wouldn't
just `g' in Dired (to refresh the listing)
followed by, say, `C-u 9999 m' work?

I guess `g' might not do what you want if Dired's
sort order is by date/time, since the external app
could have updated some files, making them more
recent, so the order in Dired would change from
what it was originally, and the Dired selection
you would need might even be noncontiguous (?).

Dunno whether I'm on the right track in starting
to understand.  Let me know.

(I'm not trying to make you justify why you want
what you want.  I'm just trying to understand it
better.)

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> If so, what if the order is so different from the sort order in Dired
> that the resulting "selection" in Dired would be a noncontiguous
> region - multiple zones, as Juri mentioned?  Is that a problem?

That would be a problem.  I just try to avoid this case.

> Assuming that's not a problem (e.g. Dired has the
> same order, since the original order came from
> Dired - but see below), how would you transfer a
> selection in the external app to a selection
> (region) in Emacs?

I'm using the name of the file at the "border" between files I had
looked at and those I didn't (typically the last file I handled in the
external app).

> I guess `g' might not do what you want if Dired's
> sort order is by date/time, since the external app
> could have updated some files, making them more
> recent, so the order in Dired would change from
> what it was originally, and the Dired selection
> you would need might even be noncontiguous (?).

As said, I just try to avoid that case.

Michael.

bug#39902: 28.0.50; Marking in dired with active region

[martin rudalics]

 >> Such "graphical" file browsers are line-based, they do not have a way
 >> to specify a position within such a line unless you are in the
 >> (usually F2 invoked) rename mode which puts a mask on the file name
 >> whose contents you can modify.
 >
 > I don't get your argument.  FWIW, most of these browsers have different
 > kinds of "views", and I have in mind the view that is not line based but
 > uses a grid of icons with names under them.  Marking a region with the
 > mouse happens continuously.

I used the line-based (aka "detailed view") paradigm because it's the
nearest equivalence to 'dired' those file browsers usually provide.  If
you prefer the "a grid of icons with names under them" paradigm, then
the difference is just as evident: You cannot, for example, mark only an
icon and not mark its name in such a view.

The point I want to make is that in file browsers and managers the thing
that stands for a file on the screen - text, icon or thumbnail - is an
atomic entity.  You cannot mark only part of it (apart from in-place
renaming).

 > What I want to say here is that the current behavior makes no sense to
 > me.  And I very much think that I'm not the only one.  I don't want to
 > justify why I have this expectation and be told that my mental model is
 > wrong.  There is no way to mathematically prove whose expectations are
 > right and whose are wrong.  These expectations are always subjective.
 > When some users are confused by the current behavior, it would be good
 > to improve Emacs when it's simple as it is here.

The only way to put this into work reliably is to provide a special mode
that restricts highlighting to whole lines.

martin

bug#39902: 28.0.50; Marking in dired with active region

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> > When some users are confused by the current behavior, it would be good
> > to improve Emacs when it's simple as it is here.
>
> The only way to put this into work reliably is to provide a special
> mode that restricts highlighting to whole lines.

I don't see a reason for that claim.  We have one behavior now, and it
works reliably.  The behavior I expect would function with comparable
reliability.

Michael.