GNU Emacs raison d'etre

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

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

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

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

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

[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

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

> 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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

 > 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

[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

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

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

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

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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

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

  > 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

[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

[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

[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)

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

[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

[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)

Re: GNU Emacs raison d'etre

[Clive Tovero]

Personally, I side with the approach of Emacs rather than Blender.  I've 
been using Emacs since 1985 on TOPS-20.  I'm working on a set of 
extensions to Emacs do do 3D modeling without the cockpit-like interface 
of Blender.  I use "Emacs" in the general sense, and include 
MIT-Scheme's Edwin, Dylan's Deuce, CL's Portable Hemlock, or QEmacs by 
Fabrice Bellard as candidates for my system.  Someone did a video 
editing app on Emacs a number of years ago (looks like it might be 
abandoned, but waiting):

https://gneve-webma-dev.blogspot.com/

My summary from a private message to RMS yesterday (he keeps asking me 
to volunteer for GNU, and I am trying to do that):

 > My project is adding extensions to Emacs to provide the functionality 
that the free software program Blender provides--but without the GUI and 
using code.  Blender is a program to model, animate, edit, and produce 
CG movies.  The models can be used for 3D printing.  It is very popular, 
and nice, but its interface looks like the cockpit of a 747.  I get lost 
among the widgets.  OpenSCAD is another similar project, without a 
GUI--but has its own modeling language.

 > My software provides 3D model functional graphical modeling, a 
relatively new technique to express geometry with the potential 
expressiveness of the lambda calculus.  Models in my software are 
specified in Lisp (most dialects could be used), a very natural language 
for the domain.  Previous work:

 > https://common-lisp.net/project/tovero/
 > https://common-lisp.net/project/clive

 > I've made quite a bit of progress in the past two years (mostly 
unpublished).

 > I have written a demo viewer in Guile running under Emacs with Geiser 
to show more proof of concept:

 > https://gitlab.com/kavalogic-inc/inspekt3d

 > Again, I would like to work with GNU on this, and I'm still open to 
it, but I just haven't been able connect for some reason.

Re: GNU Emacs raison d'etre

[Alexandre Garreau]

Le dimanche 9 août 2020, 19:11:33 CEST Clive Tovero a écrit :
> Personally, I side with the approach of Emacs rather than Blender.  I've
> been using Emacs since 1985 on TOPS-20.  I'm working on a set of
> extensions to Emacs do do 3D modeling without the cockpit-like
> interface of Blender.  I use "Emacs" in the general sense, and include
> MIT-Scheme's Edwin, Dylan's Deuce, CL's Portable Hemlock, or QEmacs by
> Fabrice Bellard as candidates for my system.  Someone did a video
> editing app on Emacs a number of years ago (looks like it might be
> abandoned, but waiting):
> 
> https://gneve-webma-dev.blogspot.com/
> 
> My summary from a private message to RMS yesterday (he keeps asking me
> 
> to volunteer for GNU, and I am trying to do that):
>  > My project is adding extensions to Emacs to provide the functionality
> 
> that the free software program Blender provides--but without the GUI and
> using code.  Blender is a program to model, animate, edit, and produce
> CG movies.  The models can be used for 3D printing.  It is very
> popular, and nice, but its interface looks like the cockpit of a 747. 
> I get lost among the widgets.  OpenSCAD is another similar project,
> without a GUI--but has its own modeling language.
> 
>  > My software provides 3D model functional graphical modeling, a
> 
> relatively new technique to express geometry with the potential
> expressiveness of the lambda calculus.  Models in my software are
> specified in Lisp (most dialects could be used), a very natural language
> for the domain.  Previous work:
>  > https://common-lisp.net/project/tovero/
>  > https://common-lisp.net/project/clive

Have you ever heard of SDFs? used in guile’s libfive and Doug Moen’s curv 
(both FP)?

This is really encouraging as something I’ve already hoped about (video 
and 3D editing within emacs).

For that matter, if emacs had more complex interfaces than stylized buffer, 
to me it would be a better browser than anything else, also (and given the 
importance of the web nowadays :/)…

I recall about Emacsy, a guile project about furnishing a standardized 
emacs-like application framework, with a minibuffer, but with what’s over 
it implementation-specific also…

Re: GNU Emacs raison d'etre

[Clive Tovero]

 > Have you ever heard of SDFs? used in guile’s libfive and Doug Moen’s 
curv (both FP)?

My Common Lisp program Tovero uses Libfive as the backend for modeling 
and *is* SDF (signed distance field) based.  I also wrote the direct 
Guile viewer for Libfive, which can be used under in a Geiser REPL in 
Emacs, as I mentioned in my previous post:

 >> I have written a demo viewer in Guile running under Emacs with 
Geiser to show more proof of concept:
 >> https://gitlab.com/kavalogic-inc/inspekt3d

This replaces Libfive's Studio editor.

 > I recall about Emacsy, a guile project about furnishing a standardized
emacs-like application framework

Thanks--I hadn't seen this, and seems like a promising idea.

My other project project, Clive, provides a interface toolkit from SGI's 
Open Inventor (used in FreeCAD), for direct 3D interaction outside of 
Emacs.  Open Inventor is a quite powerful scene graph system.  My 
website on common-lisp.net doesn't do it justice--and I need to do more 
demos of it--but I have been extensively modifying it and haven't had time.

My understanding is that Dylan's Deuce has enhancements to GNU Emacs' 
buffer model which facilitates multimedia embedded directly in the 
editor, and is derived from ZWEI--an older Lisp based Emacs. It would be 
fun to get it running someday:

http://people.csail.mit.edu/gregs/info-dylan-archive-html-2001/msg00763.html

QEmacs is interesting too--it can embed videos using FFMpeg (developed 
by Bellard too!) directly in an editor window.  It has C based functions 
based on a subset of GNU Emacs, which might be fairly straightforward to 
wrap in Guile or other Scheme implementation for a lightweight Emacs system.