GNU bug report logs - #13752
Suggestions regarding the minibuffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13752 in the body.
You can then email your comments to 13752 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: E Sabof <esabof <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Suggestions regarding the minibuffer
Date: Mon, 18 Feb 2013 19:44:36 +0000

[Message part 1 (text/plain, inline)]

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?

[Message part 2 (text/html, inline)]

Message #8 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: E Sabof <esabof <at> gmail.com>
Cc: 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Mon, 18 Feb 2013 15:02:36 -0500

> 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

Message #11 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: E Sabof <esabof <at> gmail.com>
Cc: 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Mon, 31 May 2021 09:06:19 +0200

E Sabof <esabof <at> 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

Message #14 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: E Sabof <esabof <at> gmail.com>, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Mon, 31 May 2021 23:13:03 +0300

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

Message #17 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: E Sabof <esabof <at> gmail.com>, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Tue, 01 Jun 2021 08:17:33 +0200

Juri Linkov <juri <at> 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

Message #20 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: E Sabof <esabof <at> gmail.com>, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Tue, 01 Jun 2021 23:34:15 +0300

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

Message #23 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: E Sabof <esabof <at> gmail.com>, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Wed, 02 Jun 2021 07:46:04 +0200

Juri Linkov <juri <at> 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

Message #26 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 13752 <at> debbugs.gnu.org, esabof <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Wed, 02 Jun 2021 15:32:34 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 02 Jun 2021 07:46:04 +0200
> Cc: E Sabof <esabof <at> gmail.com>, 13752 <at> debbugs.gnu.org
> 
> Juri Linkov <juri <at> 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.

Message #29 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, esabof <at> gmail.com, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Thu, 03 Jun 2021 00:06:01 +0300

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

Message #32 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13752 <at> debbugs.gnu.org, esabof <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Thu, 03 Jun 2021 09:30:41 +0200

Eli Zaretskii <eliz <at> 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

Message #37 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com, 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Thu, 03 Jun 2021 23:29:48 +0300

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

Message #40 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 42865 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com,
 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Fri, 04 Jun 2021 11:42:29 +0200

Juri Linkov <juri <at> 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

Message #43 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 42865 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com,
 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Fri, 04 Jun 2021 19:27:03 +0300

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

Message #46 received at 13752 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 42865 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com,
 13752 <at> debbugs.gnu.org
Subject: Re: bug#13752: Suggestions regarding the minibuffer
Date: Sun, 06 Jun 2021 11:17:57 +0200

Juri Linkov <juri <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.