GNU bug report logs - #12078
24.1; Improve the I-search prompt

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Sat, 28 Jul 2012 18:04:02 UTC

Severity: wishlist

Tags: wontfix

Found in version 24.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Sat, 28 Jul 2012 18:04:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dani Moncayo <dmoncayo <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 28 Jul 2012 18:04:02 GMT) Full text and rfc822 format available.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; Improve the I-search prompt
Date: Sat, 28 Jul 2012 19:56:48 +0200
Severity: wishlist

Hello,

As discussed in bug #9918
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9918#50), I propose to
change the format of the I-search prompt, so that instead of (e.g.):

  Failing I-search: foobar
  Overwrapped I-search: foobar
  Failing overwrapped I-search: foobar
  Failing I-search: foobar [initial node]

would be

  I-search: foobar  [failing]
  I-search: foobar  [overwrapped]
  I-search: foobar  [failing, overwrapped]
  I-search: foobar  [failing, initial node]

That is: present all the I-search "flags" at the right side of the
search string, using that common pattern.

Advantages:
* This would add consistency to the Isearch visual feedback.
* The search string would be shown in a fixed position in the message
(now the search string jumps right and left when the I-search flags
are added/removed in the prompt text.  This makes difficult to
concentrate on the search string).

TIA.

-- 
Dani Moncayo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Sun, 29 Jul 2012 00:46:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Sun, 29 Jul 2012 03:35:31 +0300
>   Failing I-search: foobar
>   Overwrapped I-search: foobar
>   Failing overwrapped I-search: foobar
>   Failing I-search: foobar [initial node]
>
> would be
>
>   I-search: foobar  [failing]
>   I-search: foobar  [overwrapped]
>   I-search: foobar  [failing, overwrapped]
>   I-search: foobar  [failing, initial node]

I think we should distinguish between momentary messages and search states.
For instance, "failing" is a momentary message, but "overwrapped"
is a search state.  It would be very annoying to display persistent
search states like "overwrapped" at the end of the search prompt.

Meanwhile, for consistency with the isearch message "end of manual",
I propose to rename its counterpart "initial node" to "end of node":

=== modified file 'lisp/info.el'
--- lisp/info.el	2012-07-10 11:51:54 +0000
+++ lisp/info.el	2012-07-29 00:23:39 +0000
@@ -342,12 +340,12 @@ (defcustom Info-search-whitespace-regexp
 (defcustom Info-isearch-search t
   "If non-nil, isearch in Info searches through multiple nodes.
 Before leaving the initial Info node, where isearch was started,
-it fails once with the error message [initial node], and with
+it fails once with the error message [end of node], and with
 subsequent C-s/C-r continues through other nodes without failing
 with this error message in other nodes.  When isearch fails for
-the rest of the manual, it wraps around the whole manual and
-restarts the search from the top/final node depending on
-search direction.
+the rest of the manual, it displays the error message [end of manual],
+wraps around the whole manual and restarts the search from the top/final
+node depending on search direction.
 
 Setting this option to nil restores the default isearch behavior
 with wrapping around the current Info node."
@@ -1863,7 +1867,7 @@ (defun Info-search (regexp &optional bou
 		 (not bound)
 		 (or give-up (and found (not (and (> found opoint-min)
 						  (< found opoint-max))))))
-	(signal 'search-failed (list regexp "initial node")))
+	(signal 'search-failed (list regexp "end of node")))
 
       ;; If no subfiles, give error now.
       (if give-up





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Sun, 29 Jul 2012 18:15:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Sun, 29 Jul 2012 21:04:51 +0300
>>   Failing I-search: foobar
>>   Overwrapped I-search: foobar
>>   Failing overwrapped I-search: foobar
>>   Failing I-search: foobar [initial node]
>>
>> would be
>>
>>   I-search: foobar  [failing]
>>   I-search: foobar  [overwrapped]
>>   I-search: foobar  [failing, overwrapped]
>>   I-search: foobar  [failing, initial node]
>
> I think we should distinguish between momentary messages and search states.
> For instance, "failing" is a momentary message, but "overwrapped"
> is a search state.  It would be very annoying to display persistent
> search states like "overwrapped" at the end of the search prompt.

So what could be moved to the end of the search string are two messages
"failing" and "pending".  With the following patch a failed search will
display the message suffix "[failed]".  A failed search in Info will
display the message suffix either "[failed at the end of node]" or
"[failed at the end of manual]", and pending will display "[pending]".

I don't propose to install this change immediately.
Please try this out for a while.

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2012-07-18 09:27:23 +0000
+++ lisp/isearch.el	2012-07-29 18:01:27 +0000
@@ -2371,8 +2412,8 @@ (defun isearch-message-prefix (&optional
 	 (error nil)))
   ;; If currently failing, display no ellipsis.
   (or isearch-success (setq ellipsis nil))
-  (let ((m (concat (if isearch-success "" "failing ")
-		   (if isearch-adjusted "pending " "")
+  (let ((m (concat ;; (if isearch-success "" "failing ")
+		   ;; (if isearch-adjusted "pending " "")
 		   (if (and isearch-wrapped
 			    (not isearch-wrap-function)
 			    (if isearch-forward
@@ -2402,11 +2448,14 @@ (defun isearch-message-prefix (&optional
 		'face 'minibuffer-prompt)))
 
 (defun isearch-message-suffix (&optional c-q-hack _ellipsis)
-  (concat (if c-q-hack "^Q" "")
-	  (if isearch-error
-	      (concat " [" isearch-error "]")
-	    "")
-	  (or isearch-message-suffix-add "")))
+  (let ((m (mapconcat 'identity
+		      (delq nil (list (if (not isearch-success) "failed")
+				      (if isearch-adjusted "pending")
+				      isearch-error))
+		      " ")))
+    (concat (if c-q-hack "^Q" "")
+	    (if (> (length m) 0) (concat " [" m "]") "")
+	    (or isearch-message-suffix-add ""))))
 
 
 ;; Searching

=== modified file 'lisp/info.el'
--- lisp/info.el	2012-07-10 11:51:54 +0000
+++ lisp/info.el	2012-07-29 18:01:28 +0000
@@ -1863,13 +1867,13 @@ (defun Info-search (regexp &optional bou
 		 (not bound)
 		 (or give-up (and found (not (and (> found opoint-min)
 						  (< found opoint-max))))))
-	(signal 'search-failed (list regexp "initial node")))
+	(signal 'search-failed (list regexp "at the end of node")))
 
       ;; If no subfiles, give error now.
       (if give-up
 	  (if (null Info-current-subfile)
 	      (if isearch-mode
-		  (signal 'search-failed (list regexp "end of manual"))
+		  (signal 'search-failed (list regexp "at the end of manual"))
 		(let ((search-spaces-regexp
 		       (if (or (not isearch-mode) isearch-regexp)
 			   Info-search-whitespace-regexp)))
@@ -1946,7 +1951,7 @@ (defun Info-search (regexp &optional bou
 	      (if found
 		  (message "")
 		(signal 'search-failed (if isearch-mode
-					   (list regexp "end of manual")
+					   (list regexp "at the end of manual")
 					 (list regexp)))))
 	  (if (not found)
 	      (progn (Info-read-subfile osubfile)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Mon, 30 Jul 2012 00:53:02 GMT) Full text and rfc822 format available.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Mon, 30 Jul 2012 02:45:42 +0200
> I don't propose to install this change immediately.
> Please try this out for a while.

Thanks Juri.  I've tried your patch and I think that is a step forward.

However, on second thought, I think that the "failing" message is
actually unnecessary.  Looking at the echo area, it is obvious whether
the current search is failing or not (if it's failing, the unmatched
text will be on a different face).

Regarding the "search states" (wrapped, overwrapped, ...), I see that
we disagree :).  These states are currently inserted at the left side
of the search string, and I definitely would prefer to have them at
the right side, for the reason exposed in a previous post: avoid the
horizontal movement of the search string, which makes harder to
concentrate on the search string.  This is an important factor, IMO.

In the left part of the search string, I would put only the info that
does _not_ depend on the state of the search, i.e., the "I-search"
text and (when necessary) the type of search (word and/or regexp).

All other messages (i.e. those that _do_ depend on the state of the
search) would go to the right side of the search string (as "[flag1
flag2 ...]"), for the reason already explained.

Just my opinion...

Thanks.

-- 
Dani Moncayo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Mon, 30 Jul 2012 09:34:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Mon, 30 Jul 2012 05:25:42 -0400
> Regarding the "search states" (wrapped, overwrapped, ...), I see that
> we disagree :).  These states are currently inserted at the left side
> of the search string, and I definitely would prefer to have them at
> the right side, for the reason exposed in a previous post: avoid the
> horizontal movement of the search string, which makes harder to
> concentrate on the search string.  This is an important factor, IMO.

While I agree, I think always having a "[...]" to the right of the
search string is even more problematic.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Mon, 30 Jul 2012 09:38:01 GMT) Full text and rfc822 format available.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Mon, 30 Jul 2012 11:30:29 +0200
> While I agree, I think always having a "[...]" to the right of the
> search string is even more problematic.

But my idea doesn't meant to have always a "[...]" to the right.  Only
when there is a message to show ("end of node", "pending", "wrapped"),
and most of those messages would last for a very short period of
time...

-- 
Dani Moncayo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Mon, 30 Jul 2012 23:12:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Mon, 30 Jul 2012 19:03:48 -0400
>> While I agree, I think always having a "[...]" to the right of the
>> search string is even more problematic.

> But my idea doesn't meant to have always a "[...]" to the right.  Only
> when there is a message to show ("end of node", "pending", "wrapped"),
> and most of those messages would last for a very short period of
> time...

I didn't really mean "always", but for example "wrapped" would stay
there until the end of the search: it's not transient.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Mon, 30 Jul 2012 23:58:02 GMT) Full text and rfc822 format available.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Tue, 31 Jul 2012 01:50:29 +0200
>>> While I agree, I think always having a "[...]" to the right of the
>>> search string is even more problematic.
>
>> But my idea doesn't meant to have always a "[...]" to the right.  Only
>> when there is a message to show ("end of node", "pending", "wrapped"),
>> and most of those messages would last for a very short period of
>> time...
>
> I didn't really mean "always", but for example "wrapped" would stay
> there until the end of the search: it's not transient.

Ok, that's true.

Now I ask you: why would be so problematic to have (in some cases)
such text to the right of the search string?  The text of these
messages could use the same face as the prompt text (the "I-search:
"), to make perfectly clear what is the search string (in default
face) and what is the "search status feedback".


-- 
Dani Moncayo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Wed, 01 Aug 2012 23:37:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Wed, 01 Aug 2012 19:29:05 -0400
> Now I ask you: why would be so problematic to have (in some cases)
> such text to the right of the search string?  The text of these
> messages could use the same face as the prompt text (the "I-search:
> "), to make perfectly clear what is the search string (in default
> face) and what is the "search status feedback".

It's just annoying and goes against usual Emacs behavior, where such
text is reserved for transient messages.
This said, I don't really know why we need "wrapped" to stay
there forever.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Wed, 08 Aug 2012 08:17:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Wed, 08 Aug 2012 11:06:19 +0300
> However, on second thought, I think that the "failing" message is
> actually unnecessary.  Looking at the echo area, it is obvious whether
> the current search is failing or not (if it's failing, the unmatched
> text will be on a different face).

After trying this I think the "[failing]" message doesn't look too nice.
As you mentioned, it is unnecessary due to the `isearch-fail' face.
But then this message still should be displayed in environments that don't
support the `isearch-fail' face.

The "[pending]" message should be changed too to address complaints
that it's unclear what does it mean.  Maybe something like
"[Search type changed]"

The "[wrapped]" message could be displayed only once after wrapping,
like e.g. in Firefox that displays the message
"Reached top of page, continued from bottom" or
"Reached end of page, continued from top".




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Wed, 08 Aug 2012 08:39:01 GMT) Full text and rfc822 format available.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Wed, 8 Aug 2012 10:30:43 +0200
>> However, on second thought, I think that the "failing" message is
>> actually unnecessary.  Looking at the echo area, it is obvious whether
>> the current search is failing or not (if it's failing, the unmatched
>> text will be on a different face).
>
> After trying this I think the "[failing]" message doesn't look too nice.
> As you mentioned, it is unnecessary due to the `isearch-fail' face.
> But then this message still should be displayed in environments that don't
> support the `isearch-fail' face.

Agreed.

> The "[pending]" message should be changed too to address complaints
> that it's unclear what does it mean.  Maybe something like
> "[Search type changed]"

Currently I don't remember what is the meaning of this "pending" flag,
but I trust you :)

> The "[wrapped]" message could be displayed only once after wrapping,
> like e.g. in Firefox that displays the message
> "Reached top of page, continued from bottom" or
> "Reached end of page, continued from top".

Fine with me too.

Thank you.

-- 
Dani Moncayo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12078; Package emacs. (Fri, 18 Sep 2020 15:07:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12078 <at> debbugs.gnu.org
Subject: Re: bug#12078: 24.1; Improve the I-search prompt
Date: Fri, 18 Sep 2020 17:05:51 +0200
Dani Moncayo <dmoncayo <at> gmail.com> writes:

> As discussed in bug #9918
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9918#50), I propose to
> change the format of the I-search prompt, so that instead of (e.g.):
>
>   Failing I-search: foobar
>   Overwrapped I-search: foobar
>   Failing overwrapped I-search: foobar
>   Failing I-search: foobar [initial node]
>
> would be
>
>   I-search: foobar  [failing]
>   I-search: foobar  [overwrapped]
>   I-search: foobar  [failing, overwrapped]
>   I-search: foobar  [failing, initial node]
>
> That is: present all the I-search "flags" at the right side of the
> search string, using that common pattern.

There didn't seem to be much enthusiasm for this, and I agree --
changing the prompt here just seems more intuitive and easier to
understand than something that looks like a feature set after the search
string.

So I'm closing this bug report.

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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 18 Sep 2020 15:07:01 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 12078 <at> debbugs.gnu.org and Dani Moncayo <dmoncayo <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 18 Sep 2020 15:07:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 17 Oct 2020 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 189 days ago.

Previous Next


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