bug#34939: Some minibuffer behaviour is annoying

bug#34939: Some minibuffer behaviour is annoying

[pinkanon pinkanon]

Hi! I have two issues regarding minibuffer usage:

(1) when I press backspace and the prompt is empty, minibuffer tells me
"Text is read-only". You. Don't. Say.

Proposed solution: while it can be argued that this is an OK default,
it would be great to have an option to show nothing instead.

(2) When I try to quit and some buffer is unchanged, I get the usual
deal asking me what I want. The problem I have here [in addition to
the problem discussed in (1), adapted to this case: "Type C-h for
help."] is that I must use C-g, but not good old escape.

Proposed solution: make [an option to be able to] ESC any minibuffer
prompt. In this particular case, maybe ESC could be added to one of
the possible response options, but that's an implementation detail as
far as I am concerned, a regular user.

Here are some other people trying to solve this problem with no luck.
https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc

I come from Vim background and these problems make Emacs look sluggish to
me. I really hope for a solution.

Thank you.

Best,
Pink Anon.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 21.03.2019 21:13, pinkanon pinkanon wrote:
> Hi! I have two issues regarding minibuffer usage:
> 
> (1) when I press backspace and the prompt is empty, minibuffer tells me
> "Text is read-only". You. Don't. Say.

Agreed.

> Proposed solution: while it can be argued that this is an OK default,
> it would be great to have an option to show nothing instead.

As a "solution", patch would be better.

Off the top of my head, I don't see a simple fix while the prompt is 
still implemented using the read-only text property.

> (2) When I try to quit and some buffer is unchanged, I get the usual
> deal asking me what I want. The problem I have here [in addition to
> the problem discussed in (1), adapted to this case: "Type C-h for
> help."] is that I must use C-g, but not good old escape.
> 
> Proposed solution: make [an option to be able to] ESC any minibuffer
> prompt. In this particular case, maybe ESC could be added to one of
> the possible response options, but that's an implementation detail as
> far as I am concerned, a regular user.
> 
> Here are some other people trying to solve this problem with no luck.
> https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc

Probably no simple way to make ESC work that way. The answer gives a 
hint why. But you could go the ergoemacs way, I guess.

bug#34939: Some minibuffer behaviour is annoying

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

  > > (1) when I press backspace and the prompt is empty, minibuffer tells me
  > > "Text is read-only". You. Don't. Say.

  > Agreed.

This error message may be surprising, but it is not actually wrong.
The minibuffer prompt is text in the minibiffer.  You can move point
through it.  Kill commands will not delete it, but they will put it in
the kill ring.

We could add special-case code to handle that specific case differently,
perhaps with a different error message that won't seem strange.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 23.03.2019 4:32, Richard Stallman wrote:

> This error message may be surprising, but it is not actually wrong.

This is true, but...

> We could add special-case code to handle that specific case differently,
> perhaps with a different error message that won't seem strange.

The error message is annoying because I only ever try to delete the 
prompt by mistake.

And when it's shows, I simply have to wait the second or so for it to go 
away and to see the minibuffer again (patiently staying away from C-g).

So I'd rather there was no error message.

bug#34939: Some minibuffer behaviour is annoying

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 23 Mar 2019 11:46:38 +0200
> Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org
> 
> And when it's shows, I simply have to wait the second or so for it to go 
> away and to see the minibuffer again (patiently staying away from C-g).

Doesn't some innocent key, like the right arrow, end the wait
immediately?

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 23.03.2019 11:50, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 23 Mar 2019 11:46:38 +0200
>> Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org
>>
>> And when it's shows, I simply have to wait the second or so for it to go
>> away and to see the minibuffer again (patiently staying away from C-g).
> 
> Doesn't some innocent key, like the right arrow, end the wait
> immediately?

First, even if it worked, it would be a workaround. New users hitting 
the "is read-only" problem would continue to do so.

Second, <right> is just a likely to hit me with the "End of buffer" 
error message instead. Also useless, by the way.

I'd rather the minibuffer didn't show either error, especially because 
it gets concealed by the echo area.

bug#34939: Some minibuffer behaviour is annoying

[pinkanon pinkanon]

> We could add special-case code to handle that specific case differently,
perhaps with a different error message that won't seem strange.

Just to clarify myself.
I didn't mean that the error message was strange.
The fact that the message pops up at all is my concern.
It's maybe is OK for newcomers, 
but an option to not show - not to give any textual feedback - is what I had in mind.

> > Here are some other people trying to solve this problem with no luck.
> > https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc
  
> Probably no simple way to make ESC work that way. The answer gives a 
>  hint why. But you could go the ergoemacs way, I guess.

Hmmm, no easy way to replace C-g... could it be made possible
to let the user slip in a custom key+function pair into the response 
option stack "(y, n, !, ., q, C-r, d or C-h)"?

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> > And when it's shows, I simply have to wait the second or so for it to go
> > away and to see the minibuffer again (patiently staying away from C-g).
> 
> Doesn't some innocent key, like the right arrow, end the wait
> immediately?

I've wondered from time to time how we might
unobtrusively let more users know whenever a
message to the echo area would be removed upon
a user action.

E.g., `sit-for' behavior (not `sleep-for') is
invisible and unknown to many users.  That's
generally as it should be (unobtrusive), but
I've still wondered if there isn't some subtle
way to indicate to observant users that Emacs
is waiting only passively, i.e., in an easily
interruptible way.

A tiny indication in the mode line or the
echo area perhaps?  Something (e.g. one char)
that at least some users might notice, wonder
about, and investigate to find out that what it
indicates.  Kind of like the mode-line
indications of current status (CS:CH:FR) that
many users learn about (but perhaps many users
never bother to find out about).  Probably the
echo area would be the right place for this,
perhaps as a prefix?  Maybe one or two chars
such as "| ".  (Or perhaps there's an emoticon
char that signifies something relevant?)

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

> (Or perhaps there's an emoticon char that signifies something relevant?)

👍

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

> (1) when I press backspace and the prompt is empty, minibuffer tells me
> "Text is read-only". You. Don't. Say.

Messages in the echo area should not conceal the minibuffer.  Period.

There is a special function minibuffer-message for this purpose:

  (add-hook 'minibuffer-setup-hook
            (lambda ()
              (setq-local command-error-function
                          (lambda (error context _command)
                            (minibuffer-message
                             (concat context (get (car error)
                                                  'error-message)))))))

> (2) When I try to quit and some buffer is unchanged, I get the usual
> deal asking me what I want. The problem I have here [in addition to
> the problem discussed in (1), adapted to this case: "Type C-h for
> help."] is that I must use C-g, but not good old escape.

To avoid all such problems, just bind keyboard-escape-quit globally
when not on a tty where an ESC prefix still might be needed:

  (when window-system
    (define-key global-map [escape] 'keyboard-escape-quit))

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> (1) when I press backspace and the prompt is empty, minibuffer tells me
>> "Text is read-only". You. Don't. Say.
>
> Messages in the echo area should not conceal the minibuffer.  Period.
>
> There is a special function minibuffer-message for this purpose:

There is another place where messages conceal the minibuffer:
running a version-control command that asks for a branch name
and typing TAB for completion runs a command to fetch branch names.
Its output conceals the minibuffer when vc-command-messages is non-nil.
Here is a fix:

diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index edbb83f3df..c4b327a3f0 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -324,7 +324,8 @@ vc-do-command
 		       (apply 'start-file-process command (current-buffer)
                               command squeezed))))
 		(when vc-command-messages
-		  (message "Running in background: %s" full-command))
+		  (let ((inhibit-message (eq (selected-window) (active-minibuffer-window))))
+		    (message "Running in background: %s" full-command)))
                 ;; Get rid of the default message insertion, in case we don't
                 ;; set a sentinel explicitly.
 		(set-process-sentinel proc #'ignore)
@@ -332,11 +333,13 @@ vc-do-command
 		(setq status proc)
 		(when vc-command-messages
 		  (vc-run-delayed
-		    (let ((message-truncate-lines t))
+		    (let ((message-truncate-lines t)
+			  (inhibit-message (eq (selected-window) (active-minibuffer-window))))
 		      (message "Done in background: %s" full-command)))))
 	    ;; Run synchronously
 	    (when vc-command-messages
-	      (message "Running in foreground: %s" full-command))
+	      (let ((inhibit-message (eq (selected-window) (active-minibuffer-window))))
+		(message "Running in foreground: %s" full-command)))
 	    (let ((buffer-undo-list t))
 	      (setq status (apply 'process-file command nil t nil squeezed)))
 	    (when (and (not (eq t okstatus))
@@ -350,7 +353,8 @@ vc-do-command
 		     (if (integerp status) (format "status %d" status) status)
 		     full-command))
 	    (when vc-command-messages
-	      (message "Done (status=%d): %s" status full-command))))
+	      (let ((inhibit-message (eq (selected-window) (active-minibuffer-window))))
+		(message "Done (status=%d): %s" status full-command)))))
 	(vc-run-delayed
 	  (run-hook-with-args 'vc-post-command-functions
 			      command file-or-list flags))

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 31.03.2019 23:29, Juri Linkov wrote:

> There is another place where messages conceal the minibuffer:
> running a version-control command that asks for a branch name
> and typing TAB for completion runs a command to fetch branch names.
> Its output conceals the minibuffer when vc-command-messages is non-nil.
> Here is a fix:

The patch is okay, but wouldn't it be better if 'message', when called 
from the minibuffer, went through command-error-function, or something 
like that?

So we could have a unified interface through which to change the behavior.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> There is another place where messages conceal the minibuffer:
>> running a version-control command that asks for a branch name
>> and typing TAB for completion runs a command to fetch branch names.
>> Its output conceals the minibuffer when vc-command-messages is non-nil.
>> Here is a fix:
>
> The patch is okay, but wouldn't it be better if 'message', when called from
> the minibuffer, went through command-error-function, or something
> like that?

It's impossible to override ‘message’ with something like

  (advice-add 'message :around
              (lambda (orig-fun &rest args)
                (if (eq (selected-window) (active-minibuffer-window))
                    (apply 'minibuffer-message args)
                  (apply orig-fun args)))
              '((name . message-minibuffer)))

because ‘minibuffer-message’ has ‘message’ calls
and this goes into infinite recursion.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 01.04.2019 23:31, Juri Linkov wrote:

> It's impossible to override ‘message’ with something like
> 
> ...
> 
> because ‘minibuffer-message’ has ‘message’ calls
> and this goes into infinite recursion.

We could change minibuffer-message and introduce a new function that 
would do "raw" output, to be used in there. And in 'message' too.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> It's impossible to override ‘message’ with something like
>>
>> ...
>>
>> because ‘minibuffer-message’ has ‘message’ calls
>> and this goes into infinite recursion.
>
> We could change minibuffer-message and introduce a new function that would
> do "raw" output, to be used in there. And in 'message' too.

IOW, using the same design as discussed for i18n where gettext
is called from a subfunction format-message, not from 'message'.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> There is another place where messages conceal the minibuffer:
>> running a version-control command that asks for a branch name
>> and typing TAB for completion runs a command to fetch branch names.
>> Its output conceals the minibuffer when vc-command-messages is non-nil.
>> Here is a fix:
>
> The patch is okay

Pushed to master.

bug#34939: Some minibuffer behaviour is annoying

[pinkanon pinkanon]

31.03.2019, 23:16, "Juri Linkov" <juri@linkov.net>:
> Messages in the echo area should not conceal the minibuffer. Period.
>
> There is a special function minibuffer-message for this purpose:
>
>   (add-hook 'minibuffer-setup-hook
>             (lambda ()
>               (setq-local command-error-function
>                           (lambda (error context _command)
>                             (minibuffer-message
>                              (concat context (get (car error)
>                                                   'error-message)))))))
>

This does the job! Thank you, Juri.

>>  (2) When I try to quit and some buffer is unchanged, I get the usual
>>  deal asking me what I want. The problem I have here [in addition to
>>  the problem discussed in (1), adapted to this case: "Type C-h for
>>  help."] is that I must use C-g, but not good old escape.
>
> To avoid all such problems, just bind keyboard-escape-quit globally
> when not on a tty where an ESC prefix still might be needed:
>
>   (when window-system
>     (define-key global-map [escape] 'keyboard-escape-quit))

 I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux.
 steps: emacs -Q somefile -> Eval the code -> type something -> C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help"

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>>>  (2) When I try to quit and some buffer is unchanged, I get the usual
>>>  deal asking me what I want. The problem I have here [in addition to
>>>  the problem discussed in (1), adapted to this case: "Type C-h for
>>>  help."] is that I must use C-g, but not good old escape.
>>
>> To avoid all such problems, just bind keyboard-escape-quit globally
>> when not on a tty where an ESC prefix still might be needed:
>>
>>   (when window-system
>>     (define-key global-map [escape] 'keyboard-escape-quit))
>
>  I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux.
>  steps: emacs -Q somefile -> Eval the code -> type something ->
>  C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help"

Thanks for detailed test case, I misunderstood your original description,
but now it's clear.

`C-x C-c' (save-buffers-kill-terminal) is a special case that
requires a special customization:

  (define-key query-replace-map [escape] 'quit)

bug#34939: Some minibuffer behaviour is annoying

[pinkanon pinkanon]

> `C-x C-c' (save-buffers-kill-terminal) is a special case that
> requires a special customization:
>
> (define-key query-replace-map [escape] 'quit)

Great! Thanks, Juri! Thanks all!

01.04.2019, 23:46, "Juri Linkov" <juri@linkov.net>:
>>>>   (2) When I try to quit and some buffer is unchanged, I get the usual
>>>>   deal asking me what I want. The problem I have here [in addition to
>>>>   the problem discussed in (1), adapted to this case: "Type C-h for
>>>>   help."] is that I must use C-g, but not good old escape.
>>>
>>>  To avoid all such problems, just bind keyboard-escape-quit globally
>>>  when not on a tty where an ESC prefix still might be needed:
>>>
>>>    (when window-system
>>>      (define-key global-map [escape] 'keyboard-escape-quit))
>>
>>   I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux.
>>   steps: emacs -Q somefile -> Eval the code -> type something ->
>>   C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help"
>
> Thanks for detailed test case, I misunderstood your original description,
> but now it's clear.
>
> `C-x C-c' (save-buffers-kill-terminal) is a special case that
> requires a special customization:
>
>   (define-key query-replace-map [escape] 'quit)

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 31.03.2019 22:49, Juri Linkov wrote:
> Messages in the echo area should not conceal the minibuffer.  Period.
> 
> There is a special function minibuffer-message for this purpose:

Shouldn't we make this behavior the default, then?

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> Messages in the echo area should never conceal the minibuffer.  Period.
>>
>> There is a special function minibuffer-message for this purpose:
>
> Shouldn't we make this behavior the default, then?

I agree it should be the default.  But unfortunately I have no idea
how to do this.  Both ways to catch error signals in the minibuffer:

1. Overriding the default error function with command-error-function;

2. Using condition-case like

  (condition-case lossage
      ... minibuffer reading ...
    (text-read-only
     (minibuffer-message (get (car lossage) 'error-message)))))

Both they override the default error handling called by
‘error-message-string’ in the function ‘print_error_message’
that performs many useful things that include logging of error
messages in the *Messages* buffer.  Overriding the default error
function will exclude this useful default behavior.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>>> Messages in the echo area should never conceal the minibuffer.  Period.
>>>
>>> There is a special function minibuffer-message for this purpose:
>>
>> Shouldn't we make this behavior the default, then?
>
> I agree it should be the default.  But unfortunately I have no idea
> how to do this.  Both ways to catch error signals in the minibuffer:
>
> 1. Overriding the default error function with command-error-function;
>
> 2. Using condition-case like
>
>   (condition-case lossage
>       ... minibuffer reading ...
>     (text-read-only
>      (minibuffer-message (get (car lossage) 'error-message)))))
>
> Both they override the default error handling called by
> ‘error-message-string’ in the function ‘print_error_message’
> that performs many useful things that include logging of error
> messages in the *Messages* buffer.  Overriding the default error
> function will exclude this useful default behavior.

Another variant is to extend 'echo_area_display' to use
'minibufer-message' in case of the active minibuffer.

More radical approach is to disjoint the minibuffer from the echo area
and display them separately one above another.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 07.04.2019 23:43, Juri Linkov wrote:
> Another variant is to extend 'echo_area_display' to use
> 'minibufer-message' in case of the active minibuffer.

I think I'd like that. Guess the only downside is having to decide 
whatever's going to happen when the current minibuffer contents are too 
long for the area to accommodate both them and the message?

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> Another variant is to extend 'echo_area_display' to use
>> 'minibufer-message' in case of the active minibuffer.
>
> I think I'd like that. Guess the only downside is having to decide
> whatever's going to happen when the current minibuffer contents are too
> long for the area to accommodate both them and the message?

I see no downsides - using minibuffer-message already does the right thing:
it resizes the minibuffer area.

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> >> Another variant is to extend 'echo_area_display' to use
> >> 'minibufer-message' in case of the active minibuffer.
> >
> > I think I'd like that. Guess the only downside is having to decide
> > whatever's going to happen when the current minibuffer contents are
> > too long for the area to accommodate both them and the message?
> 
> I see no downsides - using minibuffer-message already does the right
> thing: it resizes the minibuffer area.


Apologies for not following this thread.

My impression is that you might be trying to make
messages, when the minibuffer is active, always use
`minibuffer-message' and never `message'.  If so, that
would be a very bad thing.  Not only simplistic but
misguided.

The two behaviors are quite different, and both can
be useful during an interaction while the minibuffer
is active.  `message' replaces the content of the
minibuffer momentarily. `minibuffer-message' does
not replace the content but adds to it (mixes with
it).

I'm sure you're aware of this difference, so I'm
confused why youwould think it might be a good idea
to make Emacs always use `minibuffer-message'.  I'm
hoping I've simply misunderstood what you're up to.

In a way those are two different levels/dimensions
of minibuffer messaging - at least they can be used
to that effect.

Their difference is just what I stated.  Their uses
follow from their difference - use each behavior for
its particular effect.  It's silly to think that
either of them is useless or inappropriate, in some
blanket way.  Each of them can be useless or
inappropriate in a given context, and each can be
useful and helpful in a given context.

I have lots of code that interacts with the
minibuffer, in all kinds of way, including dialogs
that involve multiple buffers and multiple levels
of minibuffers.

There is not only _one_ kind of minibuffer-user
interaction.

It's a judgment call which function (`message' or
`minibuffer-message') to use in a specific context.
No simple rule can replace such design/judgment.
User interactions can take all kinds of forms, with
and without the minibuffer.

Being able to get the `message' behavior when the
minibuffer is active is essential - an important
tool in our tool chest.  Please do not try to
remove that tool.

`message' interrupts minibuffer use with echo-area
messaging - it's good for that purpose.
`minibuffer-message' does not interrupt temporally;
it interrupts minibuffer content spatially.

It's not about echo-area display inappropriately
"concealing" the minibuffer.  It's about that
display appropriately interrupting it temporarily
(controlled by application, not by some silly
Emacs built-in lockdown restriction).

If you're toying with the idea of replacing
`message' behavior with `minibuffer-message'
behavior when the minibuffer is active, please ask
yourselves what the _real_ problem is that you're
trying to solve.  I'm sure that's not its solution.

(FWIW, I don't see anything in the original problem
description that would invite such a "solution".)

That a programmer _can_ create a lousy dialog with
users, "concealing" minibuffer input inappropriately,
should not cause Emacs itself to try to second-guess
programmers by preventing them from defining dialogs
of all sorts.  That's the opposite of Emacs.

This, BTW, is completely wrong:

 > Messages in the echo area should never conceal
   the minibuffer.  Period.

 > There is a special function minibuffer-message
   for this purpose

Neither of those statements is correct.  IMO, such
a doctrinaire posture belies ignorance of the
spectrum/space of possible minibuffer uses.

Thx.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 09.04.2019 1:00, Drew Adams wrote:
> If you're toying with the idea of replacing
> `message' behavior with `minibuffer-message'
> behavior when the minibuffer is active, please ask
> yourselves what the_real_  problem is that you're
> trying to solve.

Avoiding hiding the minibuffer contents while the user is interacting 
with them (e.g. basically anytime the minibuffer is active).

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> > If you're toying with the idea of replacing
> > `message' behavior with `minibuffer-message'
> > behavior when the minibuffer is active, please ask
> > yourselves what the_real_  problem is that you're
> > trying to solve.
> 
> Avoiding hiding the minibuffer contents while the user is interacting
> with them (e.g. basically anytime the minibuffer is active).

Avoiding hiding ... is a "solution", not a problem.

Well, if you systematically prevent that "hiding"
then yes, you will have introduced a problem.

Count me as one strongly objecting to such a plan.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 09.04.2019 2:32, Drew Adams wrote:
> Avoiding hiding ... is a "solution", not a problem.

The problem is that it's hard to efficiently interact with something you 
cannot see.

I'd think that much would be obvious.

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> The problem is that it's hard to efficiently interact
> with something you cannot see.

But you _can_ see it.  Before and after the `message',
which disappears as soon as you type your next input
char or perform some other action.  Seeing happens
in time, over time.

> I'd think that much would be obvious.

It's too general and abstract.  Too blanket, too
black-&-white.  Too simplistic, dogmatic.

Sometimes in a dialog what's _wanted_ is to interrupt.
And there are different ways of interrupting, each of
which can be useful, helpful.

Sometimes, while a user is inputting content in the
minibuffer, she wants to interrupt her own inputting
to do something else temporarily.  Would you prevent
her from doing that too?

Sometimes something else going on wants to interrupt
her inputting to remind/report/signal/... something.

The point is that `message' interrupts temporally,
and `minibuffer-message' interrupts spatially.

They both interfere with what appears in that little
dialog space (minibuffer/echo-area real estate), but
they do so in different ways.

Those different ways lend themselves to different
uses/purposes.  They can be put to good use together
or separately.

"I'd think that much would be obvious." It should be.

You're trying to impede the use of an important
dialog construct.

To return to the OP problem statement -

Minibuffer behavior can be annoying or helpful.
Programmers have the means to do good or bad.
Your removing one of their tools does not improve
things - quite the contrary.

It's not `message' + minibuffer that's bad.  It's
a programmer's misguided use of the combination
that _can_ be bad.

Please leave programming minibuffer interaction to
programmers, instead of trying to dictate it from
on high.

Thx.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 09.04.2019 2:59, Drew Adams wrote:

> But you _can_ see it.  Before and after the `message',
> which disappears as soon as you type your next input
> char or perform some other action.  Seeing happens
> in time, over time.

Yeah, it's annoying and creates a bad image for the editor. Just see the 
original report.

>> I'd think that much would be obvious.
> 
> It's too general and abstract.  Too blanket, too
> black-&-white.  Too simplistic, dogmatic.
> 
> Sometimes in a dialog what's _wanted_ is to interrupt.
> And there are different ways of interrupting, each of
> which can be useful, helpful.

If we do get around to having message always delegate to 
minibuffer-message, there will be another function for "interrupting" 
messages. It would require you to do some compatibility shimming in your 
code, though.

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> > But you _can_ see it.  Before and after the `message',
> > which disappears as soon as you type your next input
> > char or perform some other action.  Seeing happens
> > in time, over time.
> 
> Yeah, it's annoying and creates a bad image for the
> editor. Just see the original report.

One user does not speak for all Emacs users.

Bad image of the editor is in the eye of the beholder,
and it should not be our primary concern.  Usefulness
for users (including Elisp programmers) should be our
main concern.

Different users make different uses of Emacs.  One
size - even the one size you think is great - does
not fit all.

> >> I'd think that much would be obvious.
> >
> > It's too general and abstract.  Too blanket, too
> > black-&-white.  Too simplistic, dogmatic.
> >
> > Sometimes in a dialog what's _wanted_ is to interrupt.
> > And there are different ways of interrupting, each of
> > which can be useful, helpful.
> 
> If we do get around to having message always delegate to
> minibuffer-message, there will be another function for "interrupting"
> messages. It would require you to do some compatibility shimming in your
> code, though.

I made my points.  I'm not going to argue with you.
As you do, you will just do what you want anyway.

I will say this though.

1. Whatever you do, please do it in Lisp, not C, so
   users can advise, redefine, remove, or improve
   on it according to their needs using Lisp.

2. Please make the behavior controllable by users
   and by code (Lisp).

3. Since 2009 I've used the following simple
   function in my code.  It lets code and users
   control the behavior.

   It is in _addition_ to `minibuffer-message'
   and `message', as another alternative.  IOW,
   sometimes I call `minibuffer-message',
   sometimes`message', and sometimes this function.

   An example of code controlling the behavior is
   binding `icicle-minibuffer-message-ok-p' to nil
   (conditionally) to avoid delays from using
   `minibuffer-message' or to inhibit possible
   message display.

   I have over a hundred calls to this function,
   so you can see that I am sensitive to the need
   to often use `minibuffer-message' when the
   minibuffer is active.  What I disagree with is
   your black-&-white view of things, which leads
   you to want to always impose the single behavior
   of `minibuffer-message'.

(defun icicle-msg-maybe-in-minibuffer (format-string &rest args)
  "Display FORMAT-STRING as a message.
If called with the minibuffer inactive, use `message'.
Otherwise:
 If `icicle-minibuffer-message-ok-p', then use `minibuffer-message'.
 Else do nothing (no message display)."
  (if (active-minibuffer-window)
      (when icicle-minibuffer-message-ok-p
        (save-selected-window
          (select-window (minibuffer-window))
          (minibuffer-message
            (apply #'format (concat "  [" format-string "]")
                            args))))
    (apply #'message format-string args)))

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 31.03.2019 22:49, Juri Linkov wrote:
> There is a special function minibuffer-message for this purpose:
> 
>    (add-hook 'minibuffer-setup-hook
>              (lambda ()
>                (setq-local command-error-function
>                            (lambda (error context _command)
>                              (minibuffer-message
>                               (concat context (get (car error)
>                                                    'error-message)))))))

So um, what's the best way to make this behavior the default?

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> There is a special function minibuffer-message for this purpose:
>>
>>    (add-hook 'minibuffer-setup-hook
>>              (lambda ()
>>                (setq-local command-error-function
>>                            (lambda (error context _command)
>>                              (minibuffer-message
>>                               (concat context (get (car error)
>>                                                    'error-message)))))))
>
> So um, what's the best way to make this behavior the default?

This is a nice behavior but the problem is that overriding
command-error-function also removes other useful default features
such as logging error messages to the *Messages* buffer
(see more at ‘print_error_message’).

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 27.05.2019 23:15, Juri Linkov wrote:

>> So um, what's the best way to make this behavior the default?
> 
> This is a nice behavior but the problem is that overriding
> command-error-function also removes other useful default features
> such as logging error messages to the *Messages* buffer
> (see more at ‘print_error_message’).

Could we first print it and then call minibuffer-message?

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

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

>>> So um, what's the best way to make this behavior the default?
>>
>> This is a nice behavior but the problem is that overriding
>> command-error-function also removes other useful default features
>> such as logging error messages to the *Messages* buffer
>> (see more at ‘print_error_message’).
>
> Could we first print it and then call minibuffer-message?

Here is a complete 1-to-1 rewrite of the C function ‘print_error_message’
in Lisp that now can be used for more user-friendly displaying error messages
in the minibuffer:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuffer-error-function.patch --]
[-- Type: text/x-diff, Size: 1854 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index 4454791ad2..5f5c6b1a59 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2440,6 +2440,45 @@ minibuffer-history-isearch-pop-state
   (goto-history-element hist-pos))
 
 \f
+(add-hook 'minibuffer-setup-hook 'minibuffer-error-initialize)
+
+(defun minibuffer-error-initialize ()
+  "Set up minibuffer error processing."
+  (setq-local command-error-function 'minibuffer-error-function))
+
+(defun minibuffer-error-function (data context caller)
+  "Display output error messages in the active minibuffer.
+Its arguments are the same as in `command-error-default-function'."
+  (discard-input)
+  (ding)
+  (let* ((errname (car data))
+         errmsg file-error tail text
+         (sep ": "))
+    (cond
+     ((eq errname 'error)
+      (setq data (cdr data))
+      (when (consp data) (setq data nil))
+      (setq errmsg (car data)))
+     (t
+      (setq errmsg (substitute-command-keys (get errname 'error-message))
+            file-error (memq 'file-error (get errname 'error-conditions)))))
+    (setq tail (cdr-safe data))
+    (when (and file-error (consp tail))
+      (setq errmsg (car tail)
+            tail (cdr tail)))
+    (setq text (if (stringp errmsg) errmsg "peculiar error"))
+    (while tail
+      (setq text (concat text sep))
+      (if (or file-error (eq errname 'end-of-file) (eq errname 'user-error))
+          (setq text (concat text (format "%s" (car tail))))
+        (setq text (concat text (format "%S" (car tail)))))
+      (setq sep ", ")
+      (setq tail (cdr tail)))
+    (let ((inhibit-message t))
+      (message "%s%s" (if caller (format "%s: " caller) "") text))
+    (minibuffer-message (concat context text))))
+
+\f
 ;Put this on C-x u, so we can force that rather than C-_ into startup msg
 (define-obsolete-function-alias 'advertised-undo 'undo "23.2")
 

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> Here is a complete 1-to-1 rewrite of the C function ‘print_error_message’
> in Lisp that now can be used for more user-friendly displaying error messages
                   ^^^^^^^^^^^
> in the minibuffer

I haven't been following this thread.  But it looks
like this will use `minibuffer-message' for errors
raised during minibuffer input, and block `message',
except for logging.  Is that right?

If not, just what does this change represent?

If so, please do not do this.  We should continue to
use `message' by default - have normal error messaging,
whether the minibuffer is active or not - there's no
substitute for `message' in this context.

If a particular user wants to add this function to
`minibuffer-setup-hook' she can do so, but it should
not be the default behavior.

Your "can be used" is appropriate for a user choice.
It's not appropriate for changing the default behavior.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> Here is a complete 1-to-1 rewrite of the C function ‘print_error_message’
>> in Lisp that now can be used for more user-friendly displaying error messages
>                                        ^^^^^^^^^^^^^
>> in the minibuffer
>
> I haven't been following this thread.  But it looks
> like this will use `minibuffer-message' for errors
> raised during minibuffer input, and block `message',
> except for logging.  Is that right?

No, it won't block messages.

> If not, just what does this change represent?

It will display messages together with the minibuffer contents
instead of replacing it.

Currently it requires the user to wait 2 seconds
before the user can see the minibuffer contents again.
Most often, this happens after typing M-n to see if any default values
are available, and it replaces the minibuffer contents with the message
“End of history; no default available”.  I have to wait several times
per day for this message to go away.  Totally it takes ~1 minute per day,
~300 minutes (5 hours) per year, and ~50 hours per decade - this is
a whole workweek of just looking at the message and waiting for Godot.

bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> > I haven't been following this thread.  But it looks
> > like this will use `minibuffer-message' for errors
> > raised during minibuffer input, and block `message',
> > except for logging.  Is that right?
> 
> No, it won't block messages.

It will block `message', not messages.  It will hijack
`message' to effect instead `minibuffer-message'.

That's not right or fair.  Code that calls `message'
should get `message' behavior.

> It will display messages together with the minibuffer contents
> instead of replacing it.

Which means that code that _intends_ `message'
behavior, which does (temporarily) replace your
input in the minibuffer, no longer does that.

No way around it - `message' just gets hijacked.

It is so _easy_ for any code to explicitly call
`minibuffer-message' when it wants that effect.
But now you want to make it impossible for code
that calls `message' to get `message' behavior.

Not needed and not the right thing.  You're
impoverishing Emacs behavior by replacing two
possible behaviors with one.

> Currently it requires the user to wait 2 seconds
> before the user can see the minibuffer contents again.

No, it does not.  User input cancels the `message'
text.  And this is during an overall input reading,
remember?  And code that calls `message' can invoke
`(message nil)' to also cancel the `message' text
at _any_ time it deems appropriate.  There is no
mandatory 2-sec wait, such as you suggest.

> Most often, this happens after typing M-n to see if any default values
> are available, and it replaces the minibuffer contents with the message
> “End of history; no default available”.

If you think there is a _particular_ context or
use of `message' that is problematic then fix that.
What you're proposing/doing instead is smashing
with a sledgehammer.

> I have to wait several times
> per day for this message to go away.  Totally it takes ~1 minute per day,
> ~300 minutes (5 hours) per year, and ~50 hours per decade - this is
> a whole workweek of just looking at the message and waiting for Godot.

Ridiculous exaggeration. I use `M-n' all the time
and have never had to wait like that.

This is a bad idea.  If you want to let users opt
in to such a reduction in behaviors then fine, please
do create a user option that lets them opt in for that.
No one will have a problem with that.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>> > I haven't been following this thread.  But it looks
>> > like this will use `minibuffer-message' for errors
>> > raised during minibuffer input, and block `message',
>> > except for logging.  Is that right?
>>
>> No, it won't block messages.
>
> It will block `message', not messages.  It will hijack
> `message' to effect instead `minibuffer-message'.
>
> That's not right or fair.  Code that calls `message'
> should get `message' behavior.

What `message' are you talking about?  Currently `message'
is not called during error processing at all.

>> Currently it requires the user to wait 2 seconds
>> before the user can see the minibuffer contents again.
>
> No, it does not.  User input cancels the `message'
> text.

It's dangerous and error-prone to type any keys blindly
while the minibuffer contents is obscured by the error message.

bug#34939: Some minibuffer behaviour is annoying

[Juri Linkov]

>>>> So um, what's the best way to make this behavior the default?
>>>
>>> This is a nice behavior but the problem is that overriding
>>> command-error-function also removes other useful default features
>>> such as logging error messages to the *Messages* buffer
>>> (see more at ‘print_error_message’).
>>
>> Could we first print it and then call minibuffer-message?
>
> more user-friendly displaying error messages in the minibuffer:

With no more comments received, pushed to master and closed.

bug#34939: Some minibuffer behaviour is annoying

[Dmitry Gutov]

On 03.06.2019 23:27, Juri Linkov wrote:

> With no more comments received, pushed to master and closed.

Thank you Juri.

But you pushed a different patch than the one you showed here (1-to-1 
rewrite of the C function ‘print_error_message’), didn't you?