* bug#12078: 24.1; Improve the I-search prompt
@ 2012-07-28 17:56 Dani Moncayo
2012-07-29 0:35 ` Juri Linkov
2020-09-18 15:05 ` Lars Ingebrigtsen
0 siblings, 2 replies; 12+ messages in thread
From: Dani Moncayo @ 2012-07-28 17:56 UTC (permalink / raw)
To: 12078
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-28 17:56 bug#12078: 24.1; Improve the I-search prompt Dani Moncayo
@ 2012-07-29 0:35 ` Juri Linkov
2012-07-29 18:04 ` Juri Linkov
2020-09-18 15:05 ` Lars Ingebrigtsen
1 sibling, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-07-29 0:35 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-29 0:35 ` Juri Linkov
@ 2012-07-29 18:04 ` Juri Linkov
2012-07-30 0:45 ` Dani Moncayo
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-07-29 18:04 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
>> 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 ""))))
\f
;; 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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-29 18:04 ` Juri Linkov
@ 2012-07-30 0:45 ` Dani Moncayo
2012-07-30 9:25 ` Stefan Monnier
2012-08-08 8:06 ` Juri Linkov
0 siblings, 2 replies; 12+ messages in thread
From: Dani Moncayo @ 2012-07-30 0:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: 12078
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 0:45 ` Dani Moncayo
@ 2012-07-30 9:25 ` Stefan Monnier
2012-07-30 9:30 ` Dani Moncayo
2012-08-08 8:06 ` Juri Linkov
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2012-07-30 9:25 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 9:25 ` Stefan Monnier
@ 2012-07-30 9:30 ` Dani Moncayo
2012-07-30 23:03 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Dani Moncayo @ 2012-07-30 9:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12078
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 9:30 ` Dani Moncayo
@ 2012-07-30 23:03 ` Stefan Monnier
2012-07-30 23:50 ` Dani Moncayo
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2012-07-30 23:03 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
>> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 23:03 ` Stefan Monnier
@ 2012-07-30 23:50 ` Dani Moncayo
2012-08-01 23:29 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Dani Moncayo @ 2012-07-30 23:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12078
>>> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 23:50 ` Dani Moncayo
@ 2012-08-01 23:29 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2012-08-01 23:29 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-30 0:45 ` Dani Moncayo
2012-07-30 9:25 ` Stefan Monnier
@ 2012-08-08 8:06 ` Juri Linkov
2012-08-08 8:30 ` Dani Moncayo
1 sibling, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-08-08 8:06 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
> 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".
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-08-08 8:06 ` Juri Linkov
@ 2012-08-08 8:30 ` Dani Moncayo
0 siblings, 0 replies; 12+ messages in thread
From: Dani Moncayo @ 2012-08-08 8:30 UTC (permalink / raw)
To: Juri Linkov; +Cc: 12078
>> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12078: 24.1; Improve the I-search prompt
2012-07-28 17:56 bug#12078: 24.1; Improve the I-search prompt Dani Moncayo
2012-07-29 0:35 ` Juri Linkov
@ 2020-09-18 15:05 ` Lars Ingebrigtsen
1 sibling, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-18 15:05 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 12078
Dani Moncayo <dmoncayo@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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-09-18 15:05 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-28 17:56 bug#12078: 24.1; Improve the I-search prompt Dani Moncayo
2012-07-29 0:35 ` Juri Linkov
2012-07-29 18:04 ` Juri Linkov
2012-07-30 0:45 ` Dani Moncayo
2012-07-30 9:25 ` Stefan Monnier
2012-07-30 9:30 ` Dani Moncayo
2012-07-30 23:03 ` Stefan Monnier
2012-07-30 23:50 ` Dani Moncayo
2012-08-01 23:29 ` Stefan Monnier
2012-08-08 8:06 ` Juri Linkov
2012-08-08 8:30 ` Dani Moncayo
2020-09-18 15:05 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).