* bug#10113: 24.0.91; Isearch & `M-e'
@ 2011-11-22 22:44 Dani Moncayo
2011-11-22 23:21 ` Juri Linkov
0 siblings, 1 reply; 17+ messages in thread
From: Dani Moncayo @ 2011-11-22 22:44 UTC (permalink / raw)
To: 10113
Hi,
Here are two recipes (from emacs -Q) that seem to be bugs in Isearch:
--------------------------------------------
First case:
1. Write the text "buffer buffeR".
2. Type "C-a C-s b u f f e R M-e DEL RET".
--> Here the _current_ match should be the first "buffe", but it's the
second one.
--------------------------------------------
Second case:
1. Write the text "buffer buffeR".
2. Type "C-a C-s b u f f e R M-e DEL r RET".
--> Here both words should be matched, but only the first one is.
--------------------------------------------
In GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601)
of 2011-11-21 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.6)'
--
Dani Moncayo
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-22 22:44 bug#10113: 24.0.91; Isearch & `M-e' Dani Moncayo
@ 2011-11-22 23:21 ` Juri Linkov
2011-11-23 8:02 ` Dani Moncayo
0 siblings, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2011-11-22 23:21 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
> Here are two recipes (from emacs -Q) that seem to be bugs in Isearch:
Thanks for recipes.
> --------------------------------------------
> First case:
> 1. Write the text "buffer buffeR".
> 2. Type "C-a C-s b u f f e R M-e DEL RET".
> --> Here the _current_ match should be the first "buffe", but it's the
> second one.
Why do think Isearch should go back to the first match without the user
typing `C-r C-r' explicitly?
> --------------------------------------------
> Second case:
> 1. Write the text "buffer buffeR".
> 2. Type "C-a C-s b u f f e R M-e DEL r RET".
> --> Here both words should be matched, but only the first one is.
Actually this is unrelated to `isearch-edit-string'.
The first time you type an upper-case letter,
Isearch switches to case-sensitive mode.
You can observe this effect with the following case:
1. Write the text "buffer buffeR buffeRr buffeRR".
2. Type "C-a C-s b u f f e R r M-c".
After you type the first upper-case letter `R', Isearch switches
to case-sensitive mode, and after typing the next lower-case `r'
Isearch doesn't match "buffeRR". It does that only when you
switch back to case-insensitive search mode by typing `M-c'.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-22 23:21 ` Juri Linkov
@ 2011-11-23 8:02 ` Dani Moncayo
2011-11-23 14:30 ` Stefan Monnier
2011-11-23 20:20 ` Juri Linkov
0 siblings, 2 replies; 17+ messages in thread
From: Dani Moncayo @ 2011-11-23 8:02 UTC (permalink / raw)
To: Juri Linkov; +Cc: 10113
>> --------------------------------------------
>> First case:
>> 1. Write the text "buffer buffeR".
>> 2. Type "C-a C-s b u f f e R M-e DEL RET".
>> --> Here the _current_ match should be the first "buffe", but it's the
>> second one.
>
> Why do think Isearch should go back to the first match without the user
> typing `C-r C-r' explicitly?
Because, removing the final "R" via minibuffer should be equivalent to
do it directly by typing DEL (just after the "R"). After all, the
final situation is the same in both cases:
* Search string = "buffer".
* Starting point = just before "buffer".
IOW, after editing the search string in the minibuffer, the Isearch
should be re-started from the beginning, using the new (edited) search
string.
>> --------------------------------------------
>> Second case:
>> 1. Write the text "buffer buffeR".
>> 2. Type "C-a C-s b u f f e R M-e DEL r RET".
>> --> Here both words should be matched, but only the first one is.
>
> Actually this is unrelated to `isearch-edit-string'.
> The first time you type an upper-case letter,
> Isearch switches to case-sensitive mode.
> You can observe this effect with the following case:
>
> 1. Write the text "buffer buffeR buffeRr buffeRR".
> 2. Type "C-a C-s b u f f e R r M-c".
>
> After you type the first upper-case letter `R', Isearch switches
> to case-sensitive mode, and after typing the next lower-case `r'
> Isearch doesn't match "buffeRR". It does that only when you
> switch back to case-insensitive search mode by typing `M-c'.
In this second case, my reasoning is analogous: Changing the final "R"
with a "r" via minibuffer should be equivalent to doing that directly
(typing "DEL r" just after the "R").
IOW, the case-sensitivity of the Isearch, when it's determined
_automatically_ (not by typing `M-c'), should be revised after editing
the search string in the minibuffer, to produce a result consistent
with the principle I said before.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 8:02 ` Dani Moncayo
@ 2011-11-23 14:30 ` Stefan Monnier
2011-11-23 14:56 ` Dani Moncayo
2011-11-23 20:20 ` Juri Linkov
1 sibling, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2011-11-23 14:30 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
> Because, removing the final "R" via minibuffer should be equivalent to
> do it directly by typing DEL (just after the "R"). After all, the
> final situation is the same in both cases:
I understand what you mean, but I don't think it's important to make the
two behave identically: after all, if you want to DEL behavior, you know
where to find it.
> IOW, after editing the search string in the minibuffer, the Isearch
> should be re-started from the beginning, using the new (edited) search
> string.
That wouldn't always result in the same behavior as what DEL does
(think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
Making it really reproduce the behavior of DEL would require a good bit
more care.
And if we do try to make it behave like you want when the result of M-e
is a prefix of the original string, that will make it behave
inconsistently with the other cases when the result is not a prefix.
Nah, not a good idea.
> In this second case, my reasoning is analogous: Changing the final "R"
> with a "r" via minibuffer should be equivalent to doing that directly
> (typing "DEL r" just after the "R").
> IOW, the case-sensitivity of the Isearch, when it's determined
> _automatically_ (not by typing `M-c'), should be revised after editing
> the search string in the minibuffer, to produce a result consistent
> with the principle I said before.
I could agree here, OTOH. My reasoning is not "because this is similar
to some earlier state" but rather because I think that there's no reason
to decide that entering an upper case letter should change the state
from "auto" to "ignore-case". Instead it should stay as "auto" (until
the user explicitly choose a case sensitivity via M-c) and hence the
decision on whether to ignore case should be re-evaluated at every step.
I.e. C-s TOTO M-e C-a C-k foo RET should search for "foo" while
ignoring case.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 14:30 ` Stefan Monnier
@ 2011-11-23 14:56 ` Dani Moncayo
2011-11-23 19:54 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Dani Moncayo @ 2011-11-23 14:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10113
>> IOW, after editing the search string in the minibuffer, the Isearch
>> should be re-started from the beginning, using the new (edited) search
>> string.
>
> That wouldn't always result in the same behavior as what DEL does
> (think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
> Making it really reproduce the behavior of DEL would require a good bit
> more care.
> And if we do try to make it behave like you want when the result of M-e
> is a prefix of the original string, that will make it behave
> inconsistently with the other cases when the result is not a prefix.
Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
all cases.
I just think that, after editing the search string in the minibuffer,
the search should be re-started from the beginning. Not doing so
makes little sense to me. Why continue from a point that was reached
using a different search string?
--
Dani Moncayo
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 14:56 ` Dani Moncayo
@ 2011-11-23 19:54 ` Stefan Monnier
2011-11-23 21:14 ` Dani Moncayo
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2011-11-23 19:54 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
>>> IOW, after editing the search string in the minibuffer, the Isearch
>>> should be re-started from the beginning, using the new (edited) search
>>> string.
>> That wouldn't always result in the same behavior as what DEL does
>> (think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
>> Making it really reproduce the behavior of DEL would require a good bit
>> more care.
>> And if we do try to make it behave like you want when the result of M-e
>> is a prefix of the original string, that will make it behave
>> inconsistently with the other cases when the result is not a prefix.
> Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
> all cases.
> I just think that, after editing the search string in the minibuffer,
> the search should be re-started from the beginning. Not doing so
> makes little sense to me. Why continue from a point that was reached
> using a different search string?
It's as good a starting point as any. The original starting point for
the search is also a possibility, indeed, but I don't think that it is
better in any significant way: it's sometimes better, sometimes worse.
So it's hard to justify such a change.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 19:54 ` Stefan Monnier
@ 2011-11-23 21:14 ` Dani Moncayo
0 siblings, 0 replies; 17+ messages in thread
From: Dani Moncayo @ 2011-11-23 21:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10113
>> Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
>> all cases.
>> I just think that, after editing the search string in the minibuffer,
>> the search should be re-started from the beginning. Not doing so
>> makes little sense to me. Why continue from a point that was reached
>> using a different search string?
>
> It's as good a starting point as any. The original starting point for
> the search is also a possibility, indeed, but I don't think that it is
> better in any significant way: it's sometimes better, sometimes worse.
>
> So it's hard to justify such a change.
Fair enough. Let's forget this use-case then.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 8:02 ` Dani Moncayo
2011-11-23 14:30 ` Stefan Monnier
@ 2011-11-23 20:20 ` Juri Linkov
2011-11-23 20:59 ` Dani Moncayo
1 sibling, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2011-11-23 20:20 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
> Because, removing the final "R" via minibuffer should be equivalent to
> do it directly by typing DEL (just after the "R").
Actually `M-e DEL RET' is not equivalent to `DEL'.
It is equivalent to `C-M-w' (`isearch-del-char').
> In this second case, my reasoning is analogous: Changing the final "R"
> with a "r" via minibuffer should be equivalent to doing that directly
> (typing "DEL r" just after the "R").
`M-e DEL r RET' is not equivalent to `DEL r'.
It is equivalent to `C-M-w r'.
> IOW, the case-sensitivity of the Isearch, when it's determined
> _automatically_ (not by typing `M-c'),
WRT automatic changing of case-sensitivity after entering
an upper-case letter, this is a traditional behavior that
you can disable by customizing `search-upper-case' to nil.
> should be revised after editing the search string in the minibuffer,
> to produce a result consistent with the principle I said before.
This is unrelated to `isearch-edit-string'. You'll get the same result
when you type `C-a C-s b u f f e R C-M-w r'.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 20:20 ` Juri Linkov
@ 2011-11-23 20:59 ` Dani Moncayo
2011-11-23 21:23 ` Juri Linkov
0 siblings, 1 reply; 17+ messages in thread
From: Dani Moncayo @ 2011-11-23 20:59 UTC (permalink / raw)
To: Juri Linkov; +Cc: 10113
On Wed, Nov 23, 2011 at 21:20, Juri Linkov <juri@jurta.org> wrote:
>> Because, removing the final "R" via minibuffer should be equivalent to
>> do it directly by typing DEL (just after the "R").
>
> Actually `M-e DEL RET' is not equivalent to `DEL'.
> It is equivalent to `C-M-w' (`isearch-del-char').
Agreed.
>> In this second case, my reasoning is analogous: Changing the final "R"
>> with a "r" via minibuffer should be equivalent to doing that directly
>> (typing "DEL r" just after the "R").
>
> `M-e DEL r RET' is not equivalent to `DEL r'.
> It is equivalent to `C-M-w r'.
Agreed.
>> IOW, the case-sensitivity of the Isearch, when it's determined
>> _automatically_ (not by typing `M-c'),
>
> WRT automatic changing of case-sensitivity after entering
> an upper-case letter, this is a traditional behavior that
> you can disable by customizing `search-upper-case' to nil.
Customizing that variable is not what I want. See below.
>> should be revised after editing the search string in the minibuffer,
>> to produce a result consistent with the principle I said before.
>
> This is unrelated to `isearch-edit-string'. You'll get the same result
> when you type `C-a C-s b u f f e R C-M-w r'.
You're right, you get the same (undesirable) result that way too.
I'll try to express myself better: by default (without touching
`isearch-edit-string'), the "case fold search" behavior can be
switched on/off in two ways:
a. Manually: by typing `M-c'.
b. Automatically (only applies if the previous criterion is "case
insensitive"): based on whether the current search string contains any
uppercase letter or not.
What I say is that currently (as we are shown) the (b) criterion is
not always re-evaluated, and it should.
BTW, Stefan agrees on this, and I hope you too :-).
--
Dani Moncayo
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 20:59 ` Dani Moncayo
@ 2011-11-23 21:23 ` Juri Linkov
2011-12-01 19:41 ` Stefan Monnier
2011-12-04 18:14 ` Johan Bockgård
0 siblings, 2 replies; 17+ messages in thread
From: Juri Linkov @ 2011-11-23 21:23 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
> I'll try to express myself better: by default (without touching
> `isearch-edit-string'), the "case fold search" behavior can be
> switched on/off in two ways:
> a. Manually: by typing `M-c'.
> b. Automatically (only applies if the previous criterion is "case
> insensitive"): based on whether the current search string contains any
> uppercase letter or not.
>
> What I say is that currently (as we are shown) the (b) criterion is
> not always re-evaluated, and it should.
>
> BTW, Stefan agrees on this, and I hope you too :-).
True, currently after the first typed upper case letter,
case-sensitivity is not re-evaluated anymore.
This behavior can be changed with the following patch:
=== modified file 'lisp/isearch.el'
--- lisp/isearch.el 2011-11-19 21:51:29 +0000
+++ lisp/isearch.el 2011-11-23 21:21:22 +0000
@@ -1658,7 +1658,7 @@ (defun isearch-search-and-update ()
(setq isearch-success t
isearch-error nil
isearch-other-end (match-end 0))
- (if (and (eq isearch-case-fold-search t) search-upper-case)
+ (if search-upper-case
(setq isearch-case-fold-search
(isearch-no-upper-case-p isearch-string isearch-regexp))))
;; Not regexp, not reverse, or no match at point.
@@ -2328,7 +2328,7 @@ (defun isearch-search ()
(if isearch-message-function
(funcall isearch-message-function nil t)
(isearch-message nil t))
- (if (and (eq isearch-case-fold-search t) search-upper-case)
+ (if search-upper-case
(setq isearch-case-fold-search
(isearch-no-upper-case-p isearch-string isearch-regexp)))
(condition-case lossage
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 21:23 ` Juri Linkov
@ 2011-12-01 19:41 ` Stefan Monnier
2011-12-04 18:14 ` Johan Bockgård
1 sibling, 0 replies; 17+ messages in thread
From: Stefan Monnier @ 2011-12-01 19:41 UTC (permalink / raw)
To: Juri Linkov; +Cc: 10113
> True, currently after the first typed upper case letter,
> case-sensitivity is not re-evaluated anymore.
> This behavior can be changed with the following patch:
I don't think this qualifies as a bug, but I think it's a good change.
So let's keep it for 24.2 (e.g. you can install it in the `pending' branch).
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10113: 24.0.91; Isearch & `M-e'
2011-11-23 21:23 ` Juri Linkov
2011-12-01 19:41 ` Stefan Monnier
@ 2011-12-04 18:14 ` Johan Bockgård
2011-12-05 10:49 ` Juri Linkov
1 sibling, 1 reply; 17+ messages in thread
From: Johan Bockgård @ 2011-12-04 18:14 UTC (permalink / raw)
To: Juri Linkov; +Cc: 10113
Juri Linkov <juri@jurta.org> writes:
>> I'll try to express myself better: by default (without touching
>> `isearch-edit-string'), the "case fold search" behavior can be
>> switched on/off in two ways:
>> a. Manually: by typing `M-c'.
>> b. Automatically (only applies if the previous criterion is "case
>> insensitive"): based on whether the current search string contains any
>> uppercase letter or not.
>>
>> What I say is that currently (as we are shown) the (b) criterion is
>> not always re-evaluated, and it should.
>>
>> BTW, Stefan agrees on this, and I hope you too :-).
>
> True, currently after the first typed upper case letter,
> case-sensitivity is not re-evaluated anymore.
>
> This behavior can be changed with the following patch:
Your patch breaks the `M-c' case.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-12-04 18:14 ` Johan Bockgård
@ 2011-12-05 10:49 ` Juri Linkov
2011-12-05 17:19 ` Richard Stallman
2022-03-21 21:52 ` Lars Ingebrigtsen
0 siblings, 2 replies; 17+ messages in thread
From: Juri Linkov @ 2011-12-05 10:49 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10113
>>> I'll try to express myself better: by default (without touching
>>> `isearch-edit-string'), the "case fold search" behavior can be
>>> switched on/off in two ways:
>>> a. Manually: by typing `M-c'.
>>> b. Automatically (only applies if the previous criterion is "case
>>> insensitive"): based on whether the current search string contains any
>>> uppercase letter or not.
>>>
>>> What I say is that currently (as we are shown) the (b) criterion is
>>> not always re-evaluated, and it should.
>>>
>>> BTW, Stefan agrees on this, and I hope you too :-).
>>
>> True, currently after the first typed upper case letter,
>> case-sensitivity is not re-evaluated anymore.
>>
>> This behavior can be changed with the following patch:
>
> Your patch breaks the `M-c' case.
Yes, this patch makes automatic toggling in both directions:
from case-insensitive to case-sensitive and back from case-sensitive
to case-insensitive.
Without this patch the current behavior is automatic toggling in one
direction: from case-insensitive to case-sensitive (on the first
encountered upper case letter). Toggling back from case-sensitive
to case-insensitive is manual with `M-c', and this choice is remembered
with the value `yes' of `isearch-case-fold-search'.
To remember the user's toggle in the reverse direction (from
case-insensitive to case-sensitive) we need to introduce
a new value of `isearch-case-fold-search' (e.g. `no',
but treating it as a nil value would be quite ugly).
So perhaps instead of that, a better solution would be
to re-evaluate case-sensitivity only in two places:
in `isearch-edit-string' and `isearch-del-char'.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-12-05 10:49 ` Juri Linkov
@ 2011-12-05 17:19 ` Richard Stallman
2022-03-21 21:52 ` Lars Ingebrigtsen
1 sibling, 0 replies; 17+ messages in thread
From: Richard Stallman @ 2011-12-05 17:19 UTC (permalink / raw)
To: Juri Linkov; +Cc: 10113
I think it was a mistake to give M-c this special meaning in an
isearch. It is useful for M-c to exit the isearch and capitalize the
next word.
The only situation where the special M-c meaning is needed
is to search for a word only in all lower case. That is a rare use case,
and I think that complicating the isearch interface just for that
is making things worse.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2011-12-05 10:49 ` Juri Linkov
2011-12-05 17:19 ` Richard Stallman
@ 2022-03-21 21:52 ` Lars Ingebrigtsen
2022-03-22 8:47 ` Juri Linkov
1 sibling, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-21 21:52 UTC (permalink / raw)
To: Juri Linkov; +Cc: Dani Moncayo, 10113
Juri Linkov <juri@jurta.org> writes:
> Yes, this patch makes automatic toggling in both directions:
> from case-insensitive to case-sensitive and back from case-sensitive
> to case-insensitive.
This was ten years ago, and isearch behaves the same, as far as I can
tell.
> Without this patch the current behavior is automatic toggling in one
> direction: from case-insensitive to case-sensitive (on the first
> encountered upper case letter). Toggling back from case-sensitive
> to case-insensitive is manual with `M-c', and this choice is remembered
> with the value `yes' of `isearch-case-fold-search'.
I think your patch makes sense -- make `M-c' toggle the case
sensitivity in both directions, if I understand correctly?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2022-03-21 21:52 ` Lars Ingebrigtsen
@ 2022-03-22 8:47 ` Juri Linkov
2022-03-22 14:12 ` Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2022-03-22 8:47 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Dani Moncayo, 10113
>> Yes, this patch makes automatic toggling in both directions:
>> from case-insensitive to case-sensitive and back from case-sensitive
>> to case-insensitive.
>
> This was ten years ago, and isearch behaves the same, as far as I can
> tell.
This request is exactly as bug#14729 - to change the traditional behavior
of isearch for no gain, only for consistency with some abstract ideas.
>> Without this patch the current behavior is automatic toggling in one
>> direction: from case-insensitive to case-sensitive (on the first
>> encountered upper case letter). Toggling back from case-sensitive
>> to case-insensitive is manual with `M-c', and this choice is remembered
>> with the value `yes' of `isearch-case-fold-search'.
>
> I think your patch makes sense -- make `M-c' toggle the case
> sensitivity in both directions, if I understand correctly?
The patch implemented automatic case-fold toggling in both directions,
where typing a letter re-evaluates case-sensitivity of the search string.
This might break some users' habits. So another idea was to re-evaluate
case-sensitivity only in `isearch-edit-string' and `isearch-del-char'.
Still such change might be unexpected for some users.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10113: 24.0.91; Isearch & `M-e'
2022-03-22 8:47 ` Juri Linkov
@ 2022-03-22 14:12 ` Lars Ingebrigtsen
0 siblings, 0 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-22 14:12 UTC (permalink / raw)
To: Juri Linkov; +Cc: Dani Moncayo, 10113
Juri Linkov <juri@jurta.org> writes:
> The patch implemented automatic case-fold toggling in both directions,
> where typing a letter re-evaluates case-sensitivity of the search string.
> This might break some users' habits. So another idea was to re-evaluate
> case-sensitivity only in `isearch-edit-string' and `isearch-del-char'.
> Still such change might be unexpected for some users.
So I guess the conclusion here is that we don't really want to do
anything? The user can always use `M-c' to toggle the case sensitivity
if they've done some odd sequence of commands that end up with a
sensitivity that's not what they want.
So I'm therefore closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-03-22 14:12 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-22 22:44 bug#10113: 24.0.91; Isearch & `M-e' Dani Moncayo
2011-11-22 23:21 ` Juri Linkov
2011-11-23 8:02 ` Dani Moncayo
2011-11-23 14:30 ` Stefan Monnier
2011-11-23 14:56 ` Dani Moncayo
2011-11-23 19:54 ` Stefan Monnier
2011-11-23 21:14 ` Dani Moncayo
2011-11-23 20:20 ` Juri Linkov
2011-11-23 20:59 ` Dani Moncayo
2011-11-23 21:23 ` Juri Linkov
2011-12-01 19:41 ` Stefan Monnier
2011-12-04 18:14 ` Johan Bockgård
2011-12-05 10:49 ` Juri Linkov
2011-12-05 17:19 ` Richard Stallman
2022-03-21 21:52 ` Lars Ingebrigtsen
2022-03-22 8:47 ` Juri Linkov
2022-03-22 14:12 ` 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).