bug#13752: Suggestions regarding the minibuffer

bug#13752: Suggestions regarding the minibuffer

[E Sabof]

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

1. Would it be possible to add a property to error symbols that would
prevent the error message from appearing in the mini-buffer? I see
little utility in  messages such a "End of buffer", "Beginning of buffer"
and "Text read-only". It could be seen as implementation logic leaking into
UI.

2. Could an option be created that wouldn't allow messages (regular or
error) from being displayed, while the minibuffer is active and selected?

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

bug#13752: Suggestions regarding the minibuffer

[Stefan Monnier]

> 1. Would it be possible to add a property to error symbols that would
> prevent the error message from appearing in the mini-buffer? I see
> little utility in  messages such a "End of buffer", "Beginning of buffer"
> and "Text read-only".
> It could be seen as implementation logic leaking into UI.

I don't think these messages have anything to do with implementation.
Instead, they're present to explain to the user why nothing else
happened in response to their keypress.

As for your request, I would welcome a patch that makes the display of
error messages more flexible.

> 2. Could an option be created that wouldn't allow messages (regular or
> error) from being displayed, while the minibuffer is active and selected?

Not displaying them might not be the best default choice (tho an option
for it could be OK), but I'd welcome a patch that makes them less
intrusive (e.g. display the message at the end of the minibuffer, like
the " [No match]" message in completions).


        Stefan

bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

E Sabof <esabof@gmail.com> writes:

> 1. Would it be possible to add a property to error symbols that would prevent the error
> message from appearing in the mini-buffer? I see little utility in  messages such a "End
> of buffer", "Beginning of buffer" and "Text read-only". It could be seen as
> implementation logic leaking into UI.

Hm.  I thought that the introduction of `set-message-function' would
allow users to filter messages like this, but

(setq set-message-function (lambda (string)
			     'no))

only seems to inhibit messages from `message', not from `signal'?  I'm
having some difficulty tracing the logic here...  Anybody know whether
this is by design?

> 2. Could an option be created that wouldn't allow messages (regular or
> error) from being displayed, while the minibuffer is active and
> selected?

This problem has mostly been fixed in Emacs 28 -- messages are appended
instead of overwriting the minibuffer.

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

bug#13752: Suggestions regarding the minibuffer

[Juri Linkov]

>> 1. Would it be possible to add a property to error symbols that would prevent the error
>> message from appearing in the mini-buffer? I see little utility in  messages such a "End
>> of buffer", "Beginning of buffer" and "Text read-only". It could be seen as
>> implementation logic leaking into UI.
>
> Hm.  I thought that the introduction of `set-message-function' would
> allow users to filter messages like this, but
>
> (setq set-message-function (lambda (string)
> 			     'no))
>
> only seems to inhibit messages from `message', not from `signal'?  I'm
> having some difficulty tracing the logic here...  Anybody know whether
> this is by design?

This looks like a new feature request :-)  If this can't be implemented
using the existing signal-hook-function or signaling-function,
maybe then a new set-signal-function could be added?

bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> only seems to inhibit messages from `message', not from `signal'?  I'm
>> having some difficulty tracing the logic here...  Anybody know whether
>> this is by design?
>
> This looks like a new feature request :-)  If this can't be implemented
> using the existing signal-hook-function or signaling-function,
> maybe then a new set-signal-function could be added?

Sure -- but I was just expecting `set-message-function' to work here,
though.

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

bug#13752: Suggestions regarding the minibuffer

[Juri Linkov]

>>> only seems to inhibit messages from `message', not from `signal'?  I'm
>>> having some difficulty tracing the logic here...  Anybody know whether
>>> this is by design?
>>
>> This looks like a new feature request :-)  If this can't be implemented
>> using the existing signal-hook-function or signaling-function,
>> maybe then a new set-signal-function could be added?
>
> Sure -- but I was just expecting `set-message-function' to work here,
> though.

But does `signal' use one of too low-level messaging functions?
I can't find what function displays the error message in the echo area.

bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But does `signal' use one of too low-level messaging functions?
> I can't find what function displays the error message in the echo area.

I hoped that was only me.  :-)  I tried following the logic from Ferror
to Fsignal to signal_or_quit, but it wasn't at all obvious to me where
that's actually displaying the message.

I instrumented set_message, and that's called by Fsignal at some point,
but even with Vset_message_function set properly, the error message
still ends up in the echo area...

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

bug#13752: Suggestions regarding the minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 02 Jun 2021 07:46:04 +0200
> Cc: E Sabof <esabof@gmail.com>, 13752@debbugs.gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > But does `signal' use one of too low-level messaging functions?
> > I can't find what function displays the error message in the echo area.
> 
> I hoped that was only me.  :-)  I tried following the logic from Ferror
> to Fsignal to signal_or_quit, but it wasn't at all obvious to me where
> that's actually displaying the message.
> 
> I instrumented set_message, and that's called by Fsignal at some point,
> but even with Vset_message_function set properly, the error message
> still ends up in the echo area...

'set_message' isn't called to display errors signaled by 'signal',
because those messages don't go the 'message' route.  Those messages
go through cmd_error, which eventually calls command-error-function.
The latter is by default bound to command-error-default-function,
which displays the error message via print_error_message.

I think Lisp programs that want to control this should bind
command-error-function to the function of their liking.

bug#13752: Suggestions regarding the minibuffer

[Juri Linkov]

>> > But does `signal' use one of too low-level messaging functions?
>> > I can't find what function displays the error message in the echo area.
>>
>> I hoped that was only me.  :-)  I tried following the logic from Ferror
>> to Fsignal to signal_or_quit, but it wasn't at all obvious to me where
>> that's actually displaying the message.
>>
>> I instrumented set_message, and that's called by Fsignal at some point,
>> but even with Vset_message_function set properly, the error message
>> still ends up in the echo area...
>
> 'set_message' isn't called to display errors signaled by 'signal',
> because those messages don't go the 'message' route.  Those messages
> go through cmd_error, which eventually calls command-error-function.
> The latter is by default bound to command-error-default-function,
> which displays the error message via print_error_message.
>
> I think Lisp programs that want to control this should bind
> command-error-function to the function of their liking.

Unbelievable that I forgot that recently I already implemented

  (setq-local command-error-function 'minibuffer-error-function)

for the minibuffer :-)

So like we already have 'set-message-function' that can be set to
'set-minibuffer-message', the corresponding pair of existing error-related
functions are 'command-error-function' and 'minibuffer-error-function'.

This there is nothing to do more here?

bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 'set_message' isn't called to display errors signaled by 'signal',
> because those messages don't go the 'message' route.  Those messages
> go through cmd_error, which eventually calls command-error-function.
> The latter is by default bound to command-error-default-function,
> which displays the error message via print_error_message.

Thanks!  That's the missing piece of the puzzle.  I've now extended the
doc strings of these two variables to mention each other.

> I think Lisp programs that want to control this should bind
> command-error-function to the function of their liking.

Indeed.  For future reference, the feature request can be achieved by
something like

(setq command-error-function
      (lambda (data string func)
	(unless (eq (car data) 'end-of-buffer)
	  (command-error-default-function data string func))))

to display all error messages except `end-of-buffer'.

So I'm closing this bug report.

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

bug#13752: Suggestions regarding the minibuffer

[Juri Linkov]

>> I think Lisp programs that want to control this should bind
>> command-error-function to the function of their liking.
>
> Indeed.  For future reference, the feature request can be achieved by
> something like
>
> (setq command-error-function
>       (lambda (data string func)
> 	(unless (eq (car data) 'end-of-buffer)
> 	  (command-error-default-function data string func))))
>
> to display all error messages except `end-of-buffer'.
>
> So I'm closing this bug report.

Maybe then bug#42865 could be closed for the same reason?
Because in its last message https://debbugs.gnu.org/42865#86
I demonstrated a similar example how to disable messages
selectively using set-message-function.

bug#42865: bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Maybe then bug#42865 could be closed for the same reason?
> Because in its last message https://debbugs.gnu.org/42865#86
> I demonstrated a similar example how to disable messages
> selectively using set-message-function.

Yes, that part about suppressing messaging is taken care more generally
by set-message-function, so I don't think adding a defcustom for
suppressing the message in copy-region is necessary.

But that bug report is also about blinking the cursor, which is a
separate issue.

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

bug#13752: Suggestions regarding the minibuffer

[Juri Linkov]

>> Maybe then bug#42865 could be closed for the same reason?
>> Because in its last message https://debbugs.gnu.org/42865#86
>> I demonstrated a similar example how to disable messages
>> selectively using set-message-function.
>
> Yes, that part about suppressing messaging is taken care more generally
> by set-message-function, so I don't think adding a defcustom for
> suppressing the message in copy-region is necessary.
>
> But that bug report is also about blinking the cursor, which is a
> separate issue.

Long ago I already pushed the patch that handles the blinking cursor
in 81588748bd85827468e297d3e44a72844438e807.

bug#13752: Suggestions regarding the minibuffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> But that bug report is also about blinking the cursor, which is a
>> separate issue.
>
> Long ago I already pushed the patch that handles the blinking cursor
> in 81588748bd85827468e297d3e44a72844438e807.

Oops; didn't notice.  Yes, then I think 42865 can be closed, so I'm
doing that now.

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