GNU bug report logs -
#12988
isearch fails to persistently indicate case sensitivity
Previous Next
Reported by: Kelly Dean <kellydeanch <at> yahoo.com>
Date: Sun, 25 Nov 2012 02:08:01 UTC
Severity: wishlist
Tags: wontfix
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 12988 in the body.
You can then email your comments to 12988 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sun, 25 Nov 2012 02:08:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kelly Dean <kellydeanch <at> yahoo.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 25 Nov 2012 02:08:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is a UI improvement suggestion, not a bug report.
Using 24.2, do: C-s
Then, if you do M-s w, then type a search string, the minibuffer continues to indicate word mode while you type your string. That's good.
But if instead you do M-c, the minibuffer just momentarily flashes a case sensitivity indicator, then gives no indication of case sensitivity status while you type your search string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sun, 25 Nov 2012 09:59:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> This is a UI improvement suggestion, not a bug report.
> Using 24.2, do: C-s
> Then, if you do M-s w, then type a search string, the minibuffer
> continues to indicate word mode while you type your string. That's good.
> But if instead you do M-c, the minibuffer just momentarily flashes
> a case sensitivity indicator, then gives no indication of case
> sensitivity status while you type your search string.
Adding "case-sensitive" to the search prompt would make it too long.
adding a shorter abbreviation like "cs" would make it too cryptic.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sun, 25 Nov 2012 17:58:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> > But if instead you do M-c, the minibuffer just momentarily flashes
> > a case sensitivity indicator, then gives no indication of case
> > sensitivity status while you type your search string.
>
> Adding "case-sensitive" to the search prompt would make it too long.
> adding a shorter abbreviation like "cs" would make it too cryptic.
This is not an unsolvable problem. There is probably more than one reasonable
way to solve it.
I think I've mentioned this way before, but perhaps not: In Isearch+, the
mode-line lighter makes clear (continually) whether searching is currently
case-sensitive. Vanilla Emacs could do likewise.
When case-sensitive, the lighter is `Isearch'.
When case-insensitive, the lighter is `ISEARCH'.
This is one simple way to make things clear to users.
It requires no extra space anywhere.
Here is a simplified version of the code I use. (In Isearch+, the lighter also
indicates by its face whether search is wrapped - that is not done here.) This
code should be usable by vanilla Isearch.
(defun isearch-highlight-lighter ()
"Update minor-mode mode-line lighter to reflect case sensitivity."
(let ((case-fold-search isearch-case-fold-search))
(when (and (eq case-fold-search t) search-upper-case)
(setq case-fold-search
(isearch-no-upper-case-p isearch-string isearch-regexp)))
;; Vanilla Isearch uses `isearch-mode', hence the first of these.
(setq minor-mode-alist
(delete '(isearch-mode isearch-mode) minor-mode-alist)
minor-mode-alist
(delete '(isearch-mode " ISEARCH") minor-mode-alist)
minor-mode-alist
(delete '(isearch-mode " Isearch") minor-mode-alist))
(let ((lighter (if case-fold-search " ISEARCH" " Isearch")))
(add-to-list 'minor-mode-alist `(isearch-mode ,lighter))))
(condition-case nil (redisplay t) (error nil)))
(add-hook 'isearch-update-post-hook 'isearch-highlight-lighter)
(defun isearch-toggle-case-fold ()
"Toggle case folding in searching on or off."
(interactive)
(setq isearch-case-fold-search
(if isearch-case-fold-search nil 'yes)
isearch-success t
isearch-adjusted t)
(isearch-highlight-lighter)
(let ((message-log-max nil))
(message "%s%s [case %ssensitive]"
(isearch-message-prefix nil isearch-nonincremental)
isearch-message (if isearch-case-fold-search "in" "")))
(sit-for 1)
(isearch-update))
However, I notice that, from `emacs -Q' and this code, with an empty search
string the lighter does not change until you type something. And (regardless of
the search string) the lighter does not change until after the delay for showing
the "case-[in]sensitive" message.
Neither of those problems exists for Isearch+. I don't have the time to dig
into why they happen for vanilla Isearch. If you are interested, the Isearch+
code is here. Clearly something else in that code prevents these two minor
problems.
http://www.emacswiki.org/emacs-en/download/isearch%2b.el
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sun, 25 Nov 2012 18:05:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> I think I've mentioned this way before, but perhaps not:
Yes, I did. I couldn't find any mention in the bugs list, but I mentioned it in
emacs-devel over a year ago. And I even included the source code. This was
Stefan's reply:
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00475.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Wed, 28 Nov 2012 23:33:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> I think I've mentioned this way before, but perhaps not: In Isearch+, the
> mode-line lighter makes clear (continually) whether searching is currently
> case-sensitive. Vanilla Emacs could do likewise.
>
> When case-sensitive, the lighter is `Isearch'.
> When case-insensitive, the lighter is `ISEARCH'.
Clever trick, but not obvious without knowing what does it mean.
We need indication for other isearch parameters too,
e.g. for `isearch-lax-whitespace'. Do you think
it would be equally clever to display `I s e a r c h'
to indicate lax-whitespace mode ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Thu, 29 Nov 2012 00:09:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> > I think I've mentioned this way before, but perhaps not: In
> > Isearch+, the mode-line lighter makes clear (continually)
> > whether searching is currently case-sensitive. Vanilla Emacs
> > could do likewise.
> >
> > When case-sensitive, the lighter is `Isearch'.
> > When case-insensitive, the lighter is `ISEARCH'.
>
> Clever trick, but not obvious without knowing what does it mean.
I hear you, and Stefan said the same thing. I think it doesn't take someone
long to figure it out, even with no explanation. Once you know about it you
look there, but yes, until you do you are not in the habit of looking there.
In Icicles, I use it also to indicate case sensitivity during completion. So
users see the convention in two places, which reinforces it.
> We need indication for other isearch parameters too,
> e.g. for `isearch-lax-whitespace'. Do you think
> it would be equally clever to display `I s e a r c h'
> to indicate lax-whitespace mode ;-)
I doubt it. And I'm not sure that all isearch parameters are created equal. ;-)
On the other hand, I might be persuaded that `I search' vs `Isearch' would not
be too bad, especially if the ` ' were highlighted. ;-)
So in that case:
Isearch - case sensitive, strict whitespace
ISEARCH - case insensitive, strict whitespace
I search - case sensitive, lax whitespace
I SEARCH - case insensitive, lax whitespace
Not too bad for a few chars.
I suggest picking only those isearch parameters that users need most to be aware
of, and if an easy means suggests itself to you for making them aware of those,
then use it. And it need not be the same mechanism for each indication.
In Icicles, as another example, the minor-mode lighter, `Icy', (optionally)
shows several things at once:
* availability of completion: lighter colored red
* whether completion is lax or strict: overline+underline for strict
* case-sensitivity, as mentioned: Icy or ICY
* whether current command is a multi-command (`+' appended): Icy+
* whether candidates are multi-completions (`||' appended): Icy||
* whether set of cands shown is truncated (`...' appended): Icy...
So you see that in the case of Icicles completion a lot of info is packed into a
few chars of the modeline, in a small field intended anyway to convey info about
this minor mode.
Users are generally quick to discover things, even without reading doc. Just by
noticing what these symbols seem to correspond to in action, it is pretty easy
to catch on after a while. And I would suggest that the `Icy' vs `ICY' meaning
is the easiest indicator to guess.
I would certainly argue that `Isearch' vs `ISEARCH' is clearer that what Stefan
proposed as an alternative:
SM> An obvious choice is to use the same letter as the one used
SM> for the corresponding key-binding, e.g. "Isearch/r/c:".
That encoding is NOT obvious to users, IMHO. But as with all such smoke
signals, eventually some users would figure that one out also.
That said, I would agree, if someone made the remark that if we use the
mode-line lighter to indicate some isearch state, that means that users have two
places to look for state info, and a priori, looking in two places is harder
than looking in one.
A (weak) answer is that if the info conveyed is different in the two places,
it's not so bad - e.g., case-sensitivity in the lighter, mode (regexp/simple) in
the prompt. But in absolute terms, yes, looking in only one place for all info
is generally better.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 00:42:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> Isearch - case sensitive, strict whitespace
> ISEARCH - case insensitive, strict whitespace
> I search - case sensitive, lax whitespace
> I SEARCH - case insensitive, lax whitespace
ISEARCH is too loud. All-caps text usually indicates SHOUTING ;-)
What do you think about altering only the capital letter:
`Isearch' vs `isearch'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 01:21:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> > Isearch - case sensitive, strict whitespace
> > ISEARCH - case insensitive, strict whitespace
> > I search - case sensitive, lax whitespace
> > I SEARCH - case insensitive, lax whitespace
>
> ISEARCH is too loud. All-caps text usually indicates SHOUTING ;-)
>
> What do you think about altering only the capital letter:
> `Isearch' vs `isearch'.
I disagree, but please do whatever you like. I disagree because the change from
one to the other is MUCH clearer using uppercase: There is far more visual
difference between Isearch and ISEARCH than between Isearch and isearch.
I agree that ALL CAPS IN TEXT IS LIKE SHOUTING. This is not a paragraph,
however, but a short symbol. And here we actually WANT to draw attention to the
change/difference (IMHO). I, at lest, *want* the change to be easily to notice.
[FWIW, all caps is also a programming idiom as the way case-insensitive testing
is typically done (convert everything to uppercase, then test). (Could equally
be lowercase, I guess, but uppercase seems to be what is used.) So at least
some (esp. old perhaps) programmers associate UPPERCASE with case-insensitivity
(and even with old, uppercase-only languages and keyboards).]
But I have no objection to all lowercase instead of all uppercase. I have no
objection to anything else you might choose.
I have no objection to:
isearch - case-insensitive
Isearch - case-sensitive
I search - and lax whitespace
I*search - and regexp
I* search - and lax ws and regexp
...
or whatever.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 01:41:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> I have no objection to:
>
> isearch - case-insensitive
> Isearch - case-sensitive
> I search - and lax whitespace
> I*search - and regexp
> I* search - and lax ws and regexp
> ...
Then word and symbol search need indication too, e.g.:
<Isearch> - word search
_<Isearch_> - symbol search
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 03:53:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> > isearch - case-insensitive
> > Isearch - case-sensitive
> > I search - and lax whitespace
> > I*search - and regexp
> > I* search - and lax ws and regexp
> > ...
>
> Then word and symbol search need indication too, e.g.:
>
> <Isearch> - word search
> _<Isearch_> - symbol search
Why not? Or shorter, reflecting syntax-class designator chars:
Isearchw - word
Isearch_ - symbol
I searchw - word, lax whitespace
I search_ - symbol, lax whitespace
(I still think `I SEARCH_' is better than `i search_' for
case-insensitive search.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 08:26:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> jurta.org>
> Date: Fri, 30 Nov 2012 03:34:10 +0200
> Cc: 'Kelly Dean' <kellydeanch <at> yahoo.com>, 12988 <at> debbugs.gnu.org
>
> > I have no objection to:
> >
> > isearch - case-insensitive
> > Isearch - case-sensitive
> > I search - and lax whitespace
> > I*search - and regexp
> > I* search - and lax ws and regexp
> > ...
>
> Then word and symbol search need indication too, e.g.:
>
> <Isearch> - word search
> _<Isearch_> - symbol search
Please don't do that. That way lies madness. There's no way the user
will be able to pick up the hints from this UI.
If you must have some indication of the kind of i-search, add some
clearly visible indicators, like
I-search(NC) -- case-insensitive ("no-case")
I-search(CS) -- case-sensitive
I-search(CS,WS) -- and lax whitespace
I-search(CS,WS,RX) -- and regexp
etc. (I don't insist on the particular acronyms, perhaps better ones
can be found). Yes, these are cryptic as well (so maybe consider
making them longer), but at least they are _explicit_, so the user who
is curious has a very clear hint staring it her, and could go RTFM if
needed.
Another, orthogonal idea to make this easier for users is to add a
tool-tip to the "I-search" field. It's orthogonal because it won't
help on a TTY.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 08:38:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 12988 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I-search(NC) -- case-insensitive ("no-case")
> I-search(CS) -- case-sensitive
> I-search(CS,WS) -- and lax whitespace
> I-search(CS,WS,RX) -- and regexp
I think that would be fine, though full strings (like "case",
"strict-space") might be better than cryptic acryonyms.
Also, the default state should be associated with a blank indicator,
i.e. plain "Isearch".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 08:39:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> If you must have some indication of the kind of i-search, add some
> clearly visible indicators, like
>
> I-search(NC) -- case-insensitive ("no-case")
> I-search(CS) -- case-sensitive
> I-search(CS,WS) -- and lax whitespace
> I-search(CS,WS,RX) -- and regexp
I'd like to mention that a bad consequence of this approach is that
the prompt string would have a variable length, so that the search
string would not be shown in a stable position, making harder for the
user to concentrate on it.
This problem has been discussed in bug #12078, where I proposed to
move all these indicators to the right side of the search string. But
this approach has also its drawbacks, since it feels weird to have
text following the search string.
Maybe the modeline would be the best place to put all these I-search flags...
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 09:59:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 30 Nov 2012 09:36:06 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: Juri Linkov <juri <at> jurta.org>, kellydeanch <at> yahoo.com, 12988 <at> debbugs.gnu.org
>
> > If you must have some indication of the kind of i-search, add some
> > clearly visible indicators, like
> >
> > I-search(NC) -- case-insensitive ("no-case")
> > I-search(CS) -- case-sensitive
> > I-search(CS,WS) -- and lax whitespace
> > I-search(CS,WS,RX) -- and regexp
>
> I'd like to mention that a bad consequence of this approach is that
> the prompt string would have a variable length, so that the search
> string would not be shown in a stable position, making harder for the
> user to concentrate on it.
If that is indeed a problem (I doubt it), then it can be easily taken
care of with align-to display spec.
> Maybe the modeline would be the best place to put all these I-search flags...
The mode line is too crammed already, so you may not have enough space
there. But we could try putting this in the minor-mode string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 10:12:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> I'd like to mention that a bad consequence of this approach is that
>> the prompt string would have a variable length, so that the search
>> string would not be shown in a stable position, making harder for the
>> user to concentrate on it.
>
> If that is indeed a problem (I doubt it),
I have no doubt about my how I feel when the Isearch prompt changes
during an Isearch session: I feel annoyed. Although this change is
more frequent due to "Failing", "Overwrapped" etc, than changes in the
type of search (normal, regexp, word, ...).
> then it can be easily taken
> care of with align-to display spec.
I don't know about that, but if it puts the search string in a stable
position, that would be quite more pleasant for the users, definitely.
>> Maybe the modeline would be the best place to put all these I-search flags...
>
> The mode line is too crammed already, so you may not have enough space
> there. But we could try putting this in the minor-mode string.
Yes, the that approach is not flawless either.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 13:38:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 12988 <at> debbugs.gnu.org (full text, mbox):
Dani Moncayo <dmoncayo <at> gmail.com> writes:
> Maybe the modeline would be the best place to put all these I-search flags...
The mode-line may be far away from the echo area.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 14:22:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> I-search(NC) -- case-insensitive ("no-case")
>> I-search(CS) -- case-sensitive
>> I-search(CS,WS) -- and lax whitespace
>> I-search(CS,WS,RX) -- and regexp
> I think that would be fine, though full strings (like "case",
> "strict-space") might be better than cryptic acryonyms.
In an earlier thread I suggested "Isearch/w/c" where the letters would
match the keys used to enable/select those options.
> I'd like to mention that a bad consequence of this approach is that
> the prompt string would have a variable length, so that the search
> string would not be shown in a stable position, making harder for the
> user to concentrate on it.
We're talking about switches which usually are not changed during
the search.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 15:41:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> Maybe the modeline would be the best place to put all these I-search flags...
>
> The mode-line may be far away from the echo area.
Indeed, in a multi-window layout. So that was a bad idea.
Thanks.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 15:49:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>>> I-search(NC) -- case-insensitive ("no-case")
>>> I-search(CS) -- case-sensitive
>>> I-search(CS,WS) -- and lax whitespace
>>> I-search(CS,WS,RX) -- and regexp
>> I think that would be fine, though full strings (like "case",
>> "strict-space") might be better than cryptic acryonyms.
>
> In an earlier thread I suggested "Isearch/w/c" where the letters would
> match the keys used to enable/select those options.
Sounds fine to me. Short and intuitive.
(It could be even shorter if you write only the first slash, because
every single character on its right side would represent an individual
flag. E.g.: "Isearch/wc")
>> I'd like to mention that a bad consequence of this approach is that
>> the prompt string would have a variable length, so that the search
>> string would not be shown in a stable position, making harder for the
>> user to concentrate on it.
>
> We're talking about switches which usually are not changed during
> the search.
Yes, the ones that appear often during the search and those related to
the status of the current search ("(over)wrapped", "failing", etc).
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 16:02:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> We're talking about switches which usually are not changed during
>> the search.
>
> Yes, the ones that appear often during the search and those related to
^^^
Pfffff, I meant "are". Sorry.
> the status of the current search ("(over)wrapped", "failing", etc).
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 16:58:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> (It could be even shorter if you write only the first slash, because
> every single character on its right side would represent an individual
> flag. E.g.: "Isearch/wc")
Agreed.
>>> I'd like to mention that a bad consequence of this approach is that
>>> the prompt string would have a variable length, so that the search
>>> string would not be shown in a stable position, making harder for the
>>> user to concentrate on it.
>> We're talking about switches which usually are not changed during
>> the search.
> Yes, the ones that appear often during the search aer those related to
> the status of the current search ("(over)wrapped", "failing", etc).
Indeed the failing/wrapped/pending messages are different and should not
cause the text to move. But the display of search style
(case-sensitivity/regexp/word/lax/younameit) seems quite acceptable in
the prompt.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 18:42:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> I think that would be fine, though full strings (like "case",
>> "strict-space") might be better than cryptic acryonyms.
>
> In an earlier thread I suggested "Isearch/w/c" where the letters would
> match the keys used to enable/select those options.
The problem is that some of these keys are not alphanumeric,
thus not easily recognizable when displayed in the prompt.
>> Also, the default state should be associated with a blank indicator,
>> i.e. plain "Isearch".
Since the default prompt should be short plain "Isearch",
after adding longer non-cryptic indicators for non-default states,
the problem of the long prompt will occur less often,
especially after removing the failing/wrapped/pending messages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 19:29:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>>> I think that would be fine, though full strings (like "case",
>>> "strict-space") might be better than cryptic acryonyms.
>> In an earlier thread I suggested "Isearch/w/c" where the letters would
>> match the keys used to enable/select those options.
> The problem is that some of these keys are not alphanumeric,
> thus not easily recognizable when displayed in the prompt.
Which non-alphanumeric keys are you thinking about?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 19:49:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>>>> I think that would be fine, though full strings (like "case",
>>>> "strict-space") might be better than cryptic acryonyms.
>>> In an earlier thread I suggested "Isearch/w/c" where the letters would
>>> match the keys used to enable/select those options.
>> The problem is that some of these keys are not alphanumeric,
>> thus not easily recognizable when displayed in the prompt.
>
> Which non-alphanumeric keys are you thinking about?
For example, the space character `M-s SPC' that toggles lax-whitespace mode,
or the underscore character `M-s _' that toggles symbol mode. A prompt like
"Isearch/ /_" cannot be easily deciphered.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 20:13:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 12988 <at> debbugs.gnu.org (full text, mbox):
>> Which non-alphanumeric keys are you thinking about?
> For example, the space character `M-s SPC' that toggles lax-whitespace mode,
> or the underscore character `M-s _' that toggles symbol mode. A prompt like
> "Isearch/ /_" cannot be easily deciphered.
"Isearch/_" doesn't sound too bad, but indeed "Isearch/ " wouldn't
work well.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Fri, 30 Nov 2012 21:39:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> "Isearch/_" doesn't sound too bad, but indeed "Isearch/ " wouldn't
> work well.
The slash is useless anyway. Why not consider the proposals discussed earlier
in the thread (repeated below)? "I search" works fine, especially if the " " is
highlighted (the complete lighter also has a mouseover highlight).
ISEARCH - case-insensitive
Isearch - case-sensitive
Case-sensitive examples:
I search - lax whitespace
I*search - regexp
I* search - lax ws & regexp
Isearchw - word
Isearch_ - symbol
I searchw - word & lax ws
I search_ - symbol & lax ws
Case-insensitive is similar, with SEARCH instead of search. E.g.,
I* SEARCH - lax ws & regexp
And each of the chars SPC _ w * could be highlighted, for increased clarity.
This convention uses a maximum of 2 more characters than what we use now, and it
covers everything discussed so far.
The notation used should be short. It should be noticeable and recognizable for
someone who is familiar with the notation.
Less important is to have something that also suggests its meaning. Why is that
less important? Because once you learn the meaning, the suggestion is not
needed anymore, except as a reminder.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sat, 01 Dec 2012 06:07:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 12988 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> The slash is useless anyway. Why not consider the proposals discussed
> earlier in the thread (repeated below)?
>
> I search - lax whitespace
> I*search - regexp
> I* search - lax ws & regexp
> Isearchw - word
> Isearch_ - symbol
> I searchw - word & lax ws
> I search_ - symbol & lax ws
Because these look terrible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sat, 01 Dec 2012 06:42:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 12988 <at> debbugs.gnu.org (full text, mbox):
Chong Yidong <cyd <at> gnu.org> writes:
> "Drew Adams" <drew.adams <at> oracle.com> writes:
>
>> The slash is useless anyway. Why not consider the proposals discussed
>> earlier in the thread (repeated below)?
>>
>> I search - lax whitespace
>> I*search - regexp
>> I* search - lax ws & regexp
>> Isearchw - word
>> Isearch_ - symbol
>> I searchw - word & lax ws
>> I search_ - symbol & lax ws
>
> Because these look terrible.
Drew's idea is nice.
Isearch( *Aw_):
Have a fixed width string like that. Characters/Glyphs in the bracket
are basically all possible indicators or controls. If a character is
on, highlight that on. There is also some control on where the space
character goes.
One can even cycle through the glyphs and turn those switches on/off one
by one.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sat, 01 Dec 2012 07:04:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> Isearch( *Aw_):
>
> Have a fixed width string like that. Characters/Glyphs in the bracket
> are basically all possible indicators or controls. If a character is
> on, highlight that on. There is also some control on where the space
> character goes.
>
> One can even cycle through the glyphs and turn those switches
> on/off one by one.
That's another interesting idea. (Given the colon, I suppose you are talking
about using this in the prompt instead of the mode-line lighter.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sat, 01 Dec 2012 08:06:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 12988 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
>> Isearch( *Aw_):
>>
>> Have a fixed width string like that. Characters/Glyphs in the bracket
>> are basically all possible indicators or controls. If a character is
>> on, highlight that on. There is also some control on where the space
>> character goes.
>>
>> One can even cycle through the glyphs and turn those switches
>> on/off one by one.
>
> That's another interesting idea. (Given the colon, I suppose you are talking
> about using this in the prompt instead of the mode-line lighter.)
It can go wherever.
But key thing is there is this switchboard with a bunch of switches one
for kitchen, one for hall etc. Then you walk to each of them and toggle
them.
So there are basically two commands - one to walk to next switch and one
to toggle it. Switch themselves report whether they are ON/OFF and
IN-FOCUS/OUT-OF-FOCUS. Choice of switches themselves become immaterial.
If one wants a new control then all one has to think about is what
character or glyph it will take and add it to the switchboard.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Sat, 01 Dec 2012 16:41:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 12988 <at> debbugs.gnu.org (full text, mbox):
> It can go wherever.
>
> But key thing is there is this switchboard with a bunch of
> switches one for kitchen, one for hall etc. Then you walk
> to each of them and toggle them.
>
> So there are basically two commands - one to walk to next
> switch and one to toggle it. Switch themselves report whether
> they are ON/OFF and IN-FOCUS/OUT-OF-FOCUS. Choice of switches
> themselves become immaterial.
>
> If one wants a new control then all one has to think about is what
> character or glyph it will take and add it to the switchboard.
Yes, I understood that. I think it's a very good idea.
I also think the prompt is the best place for it.
Highlighting the current switches in some way is important to the usability of
it, I think.
It's perhaps worth pointing out that this can also obviate the use of the prompt
prefix "Regexp". And if we included other state indicators, such as
wrap/overwrap, it would obviate using their more verbose prompt indicators as
well.
That does not mean that we should remove the more verbose prompt hints - only
that we could. Best would be to let users optionally remove/add the redundant
more-verbose indicators (and optionally remove/add the new feature).
FWIW, in Isearch+ I highlight the prompt hints "Regexp", "Wrapped", and
"overwrapped", and I highlight the `Isearch' mode-line lighter using the same
face as each of those prompt qualifiers.
I mention that only to say that I think such a cue helps a user recognize the
state change - in particular wrt wrapping. (Have you ever continued searching a
few times after overwrapping without meaning to, because you did not immediately
notice the "overwrapped" hint?)
With such state indicators abbreviated a la your suggestion, highlighting the
appropriate state chars would be quite helpful, IMO.
Such a highlight lets a user notice the state change without requiring that s?he
actually look at the state indicator. IOW, it's an easy-to-perceive cue.
But such highlighting too should be customizable by users, of course. At least
by customizing their faces (including to `default', to selectively turn it off).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#12988; Package
emacs.
(Wed, 27 Apr 2022 18:49:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 12988 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> jurta.org> writes:
>> This is a UI improvement suggestion, not a bug report.
>> Using 24.2, do: C-s
>> Then, if you do M-s w, then type a search string, the minibuffer
>> continues to indicate word mode while you type your string. That's good.
>> But if instead you do M-c, the minibuffer just momentarily flashes
>> a case sensitivity indicator, then gives no indication of case
>> sensitivity status while you type your search string.
>
> Adding "case-sensitive" to the search prompt would make it too long.
> adding a shorter abbreviation like "cs" would make it too cryptic.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I agree with Juri -- we either have to make the prompt really long, or
make it really cryptic. And I think the way it is now is fine, 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.
(Wed, 27 Apr 2022 18:49:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
12988 <at> debbugs.gnu.org and Kelly Dean <kellydeanch <at> yahoo.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 27 Apr 2022 18:49: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.
(Thu, 26 May 2022 11:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.