* isearch-repeat-forward: wrong overlay after failure
@ 2008-05-11 15:52 David Reitter
2008-05-11 16:59 ` Juri Linkov
0 siblings, 1 reply; 21+ messages in thread
From: David Reitter @ 2008-05-11 15:52 UTC (permalink / raw
To: emacs-pretest-bug
isearch wrongly highlights a part of a buffer when `isearch-forward'
fails.
To reproduce, create buffer A, containing just the following:
123456
Also, create buffer B, containing
12346
Now switch to buffer A, move point to the beginning, and do C-s 5.
The `5' will be highlighted.
Then switch to buffer B and move point to the beginning. (You can
show the buffers in two windows, or just switch between them: it
doesn't matter.)
Then do M-x isearch-repeat-forward. (Do NOT do C-s C-s.)
You will find that `6' is highlighted, and a (correct) message is
displayed that the search failed. (It appears that the text at a
position equivalent to where the last match was in the previous buffer
is highlighted.)
The overlay in buffer B shouldn't be there.
This issue has been around for a long time, and I suspect it was never
noticed because many people just do C-s C-s rather than binding a key
to `isearch-repeat-forward'.
In GNU Emacs 22.2.50.2 (i386-apple-darwin9.2.2, Carbon Version 1.6.0)
of 2008-04-26 on plume.sr.unh.edu
Windowing system distributor `Apple Inc.', version 10.5.2
configured using `configure '--without-x' '--prefix=/usr/local''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
C-x b <return> <up> <up> <up> <up> <up> C-k C-k C-k
C-k C-k C-k 1 <return> 2 <return> 3 <return> 4 <return>
5 <return> 6 5 <return> <backspace> <backspace> <return>
<escape> x v i s i t - n e <tab> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> c r e a t e - b <tab> u <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> v i s i <tab> C-x
C-f T e m p SPC t 1 <backspace> <backspace> <backspace>
/ t 2 <return> 1 <return> 2 <return> 3 <return> 4 <return>
6 <return> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> C-x b <return> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> C-s 5 C-x b <return>
<escape> x i s e a r c h - r e <tab> <tab> p e <tab>
f o r <tab> <return> <menu-bar> <help-menu> <send-
emacs-bug-report>
Recent messages:
Making completion list...
Loading help-mode...done
Quit
(New file)
Mark saved where search started
Making completion list...
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
byte-code: Text is read-only [2 times]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
@ 2008-05-11 15:52 David Reitter
0 siblings, 0 replies; 21+ messages in thread
From: David Reitter @ 2008-05-11 15:52 UTC (permalink / raw
To: emacs-pretest-bug
isearch wrongly highlights a part of a buffer when `isearch-forward'
fails.
To reproduce, create buffer A, containing just the following:
123456
Also, create buffer B, containing
12346
Now switch to buffer A, move point to the beginning, and do C-s 5.
The `5' will be highlighted.
Then switch to buffer B and move point to the beginning. (You can
show the buffers in two windows, or just switch between them: it
doesn't matter.)
Then do M-x isearch-repeat-forward. (Do NOT do C-s C-s.)
You will find that `6' is highlighted, and a (correct) message is
displayed that the search failed. (It appears that the text at a
position equivalent to where the last match was in the previous buffer
is highlighted.)
The overlay in buffer B shouldn't be there.
This issue has been around for a long time, and I suspect it was never
noticed because many people just do C-s C-s rather than binding a key
to `isearch-repeat-forward'.
In GNU Emacs 22.2.50.2 (i386-apple-darwin9.2.2, Carbon Version 1.6.0)
of 2008-04-26 on plume.sr.unh.edu
Windowing system distributor `Apple Inc.', version 10.5.2
configured using `configure '--without-x' '--prefix=/usr/local''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
C-x b <return> <up> <up> <up> <up> <up> C-k C-k C-k
C-k C-k C-k 1 <return> 2 <return> 3 <return> 4 <return>
5 <return> 6 5 <return> <backspace> <backspace> <return>
<escape> x v i s i t - n e <tab> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> c r e a t e - b <tab> u <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> v i s i <tab> C-x
C-f T e m p SPC t 1 <backspace> <backspace> <backspace>
/ t 2 <return> 1 <return> 2 <return> 3 <return> 4 <return>
6 <return> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> C-x b <return> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> C-s 5 C-x b <return>
<escape> x i s e a r c h - r e <tab> <tab> p e <tab>
f o r <tab> <return> <menu-bar> <help-menu> <send-
emacs-bug-report>
Recent messages:
Making completion list...
Loading help-mode...done
Quit
(New file)
Mark saved where search started
Making completion list...
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
byte-code: Text is read-only [2 times]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 15:52 isearch-repeat-forward: wrong overlay after failure David Reitter
@ 2008-05-11 16:59 ` Juri Linkov
2008-05-11 21:48 ` David Reitter
2008-05-11 21:48 ` David Reitter
0 siblings, 2 replies; 21+ messages in thread
From: Juri Linkov @ 2008-05-11 16:59 UTC (permalink / raw
To: David Reitter; +Cc: emacs-pretest-bug
> This issue has been around for a long time, and I suspect it was never
> noticed because many people just do C-s C-s rather than binding a key to
> isearch-repeat-forward'.
`isearch-repeat-forward' is not an entry point to the incremental search:
it doesn't activate isearch mode neither deactivates it. IIUC, it was
never intended for non-incremental search, so it doesn't guarantee to
work when isearch mode is not active.
If you want to find the next occurrence without highlighting it
and without activating isearch mode, you can use the command
`search-forward'.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 16:59 ` Juri Linkov
2008-05-11 21:48 ` David Reitter
@ 2008-05-11 21:48 ` David Reitter
1 sibling, 0 replies; 21+ messages in thread
From: David Reitter @ 2008-05-11 21:48 UTC (permalink / raw
To: Juri Linkov; +Cc: emacs-pretest-bug, 222
On 11 May 2008, at 17:59, Juri Linkov wrote:
>
> `isearch-repeat-forward' is not an entry point to the incremental
> search:
> it doesn't activate isearch mode neither deactivates it. IIUC, it was
> never intended for non-incremental search, so it doesn't guarantee to
> work when isearch mode is not active.
>
> If you want to find the next occurrence without highlighting it
> and without activating isearch mode, you can use the command
> `search-forward'.
isearch-repeat-forward is interactive, which is why I thought it would
be a decent entry point.
It works beautifully, except when you switch buffers and when
nonsensical text is highlighted.
Something like (search-forward isearch-string) works too, as long as
the match is visualized. That's what I'm doing now; thanks for
pointing out this (better) variant.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 16:59 ` Juri Linkov
@ 2008-05-11 21:48 ` David Reitter
2008-05-11 22:54 ` David Kastrup
2008-05-11 22:54 ` David Kastrup
2008-05-11 21:48 ` David Reitter
1 sibling, 2 replies; 21+ messages in thread
From: David Reitter @ 2008-05-11 21:48 UTC (permalink / raw
To: Juri Linkov; +Cc: emacs-pretest-bug, 222
On 11 May 2008, at 17:59, Juri Linkov wrote:
>
> `isearch-repeat-forward' is not an entry point to the incremental
> search:
> it doesn't activate isearch mode neither deactivates it. IIUC, it was
> never intended for non-incremental search, so it doesn't guarantee to
> work when isearch mode is not active.
>
> If you want to find the next occurrence without highlighting it
> and without activating isearch mode, you can use the command
> `search-forward'.
isearch-repeat-forward is interactive, which is why I thought it would
be a decent entry point.
It works beautifully, except when you switch buffers and when
nonsensical text is highlighted.
Something like (search-forward isearch-string) works too, as long as
the match is visualized. That's what I'm doing now; thanks for
pointing out this (better) variant.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 21:48 ` David Reitter
2008-05-11 22:54 ` David Kastrup
@ 2008-05-11 22:54 ` David Kastrup
1 sibling, 0 replies; 21+ messages in thread
From: David Kastrup @ 2008-05-11 22:54 UTC (permalink / raw
To: David Reitter; +Cc: emacs-pretest-bug, 222
David Reitter <david.reitter@gmail.com> writes:
> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>
>> `isearch-repeat-forward' is not an entry point to the incremental
>> search:
>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>> never intended for non-incremental search, so it doesn't guarantee to
>> work when isearch mode is not active.
>>
>> If you want to find the next occurrence without highlighting it
>> and without activating isearch mode, you can use the command
>> `search-forward'.
>
> isearch-repeat-forward is interactive, which is why I thought it would
> be a decent entry point.
Which I would call a reasonable expectation. However, keybindings even
in specialized keymaps need to be bound to interactive functions. So if
we have functions that are only intended for use in specialized keymaps,
there is no way to keep people from binding them to normal keymaps.
So it is sort of a combined documentation/expectation problem. I have
no good idea how to approach this.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 21:48 ` David Reitter
@ 2008-05-11 22:54 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
` (3 more replies)
2008-05-11 22:54 ` David Kastrup
1 sibling, 4 replies; 21+ messages in thread
From: David Kastrup @ 2008-05-11 22:54 UTC (permalink / raw
To: David Reitter; +Cc: Juri Linkov, emacs-pretest-bug, 222
David Reitter <david.reitter@gmail.com> writes:
> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>
>> `isearch-repeat-forward' is not an entry point to the incremental
>> search:
>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>> never intended for non-incremental search, so it doesn't guarantee to
>> work when isearch mode is not active.
>>
>> If you want to find the next occurrence without highlighting it
>> and without activating isearch mode, you can use the command
>> `search-forward'.
>
> isearch-repeat-forward is interactive, which is why I thought it would
> be a decent entry point.
Which I would call a reasonable expectation. However, keybindings even
in specialized keymaps need to be bound to interactive functions. So if
we have functions that are only intended for use in specialized keymaps,
there is no way to keep people from binding them to normal keymaps.
So it is sort of a combined documentation/expectation problem. I have
no good idea how to approach this.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 22:54 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
@ 2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-12 14:41 ` Stefan Monnier
2008-05-12 14:41 ` Stefan Monnier
3 siblings, 0 replies; 21+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-11 23:00 UTC (permalink / raw
To: David Kastrup; +Cc: 222, emacs-pretest-bug
David Kastrup wrote:
> David Reitter <david.reitter@gmail.com> writes:
>
>> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>> `isearch-repeat-forward' is not an entry point to the incremental
>>> search:
>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>> never intended for non-incremental search, so it doesn't guarantee to
>>> work when isearch mode is not active.
>>>
>>> If you want to find the next occurrence without highlighting it
>>> and without activating isearch mode, you can use the command
>>> `search-forward'.
>> isearch-repeat-forward is interactive, which is why I thought it would
>> be a decent entry point.
>
> Which I would call a reasonable expectation. However, keybindings even
> in specialized keymaps need to be bound to interactive functions. So if
> we have functions that are only intended for use in specialized keymaps,
> there is no way to keep people from binding them to normal keymaps.
>
> So it is sort of a combined documentation/expectation problem. I have
> no good idea how to approach this.
Maybe an error message that explains/points to an explanation?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 22:54 ` David Kastrup
@ 2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-11 23:25 ` David Kastrup
2008-05-11 23:25 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
` (2 subsequent siblings)
3 siblings, 2 replies; 21+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-11 23:00 UTC (permalink / raw
To: David Kastrup; +Cc: Juri Linkov, David Reitter, 222, emacs-pretest-bug
David Kastrup wrote:
> David Reitter <david.reitter@gmail.com> writes:
>
>> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>> `isearch-repeat-forward' is not an entry point to the incremental
>>> search:
>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>> never intended for non-incremental search, so it doesn't guarantee to
>>> work when isearch mode is not active.
>>>
>>> If you want to find the next occurrence without highlighting it
>>> and without activating isearch mode, you can use the command
>>> `search-forward'.
>> isearch-repeat-forward is interactive, which is why I thought it would
>> be a decent entry point.
>
> Which I would call a reasonable expectation. However, keybindings even
> in specialized keymaps need to be bound to interactive functions. So if
> we have functions that are only intended for use in specialized keymaps,
> there is no way to keep people from binding them to normal keymaps.
>
> So it is sort of a combined documentation/expectation problem. I have
> no good idea how to approach this.
Maybe an error message that explains/points to an explanation?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-11 23:25 ` David Kastrup
@ 2008-05-11 23:25 ` David Kastrup
1 sibling, 0 replies; 21+ messages in thread
From: David Kastrup @ 2008-05-11 23:25 UTC (permalink / raw
To: Lennart Borgman (gmail); +Cc: 222, emacs-pretest-bug
"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> David Kastrup wrote:
>> David Reitter <david.reitter@gmail.com> writes:
>>
>>> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>>> `isearch-repeat-forward' is not an entry point to the incremental
>>>> search:
>>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>>> never intended for non-incremental search, so it doesn't guarantee to
>>>> work when isearch mode is not active.
>>>>
>>>> If you want to find the next occurrence without highlighting it
>>>> and without activating isearch mode, you can use the command
>>>> `search-forward'.
>>> isearch-repeat-forward is interactive, which is why I thought it would
>>> be a decent entry point.
>>
>> Which I would call a reasonable expectation. However, keybindings even
>> in specialized keymaps need to be bound to interactive functions. So if
>> we have functions that are only intended for use in specialized keymaps,
>> there is no way to keep people from binding them to normal keymaps.
>>
>> So it is sort of a combined documentation/expectation problem. I have
>> no good idea how to approach this.
>
> Maybe an error message that explains/points to an explanation?
What should trigger an error here?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:00 ` Lennart Borgman (gmail)
@ 2008-05-11 23:25 ` David Kastrup
2008-05-11 23:59 ` bug#222: " Juri Linkov
2008-05-11 23:59 ` Juri Linkov
2008-05-11 23:25 ` David Kastrup
1 sibling, 2 replies; 21+ messages in thread
From: David Kastrup @ 2008-05-11 23:25 UTC (permalink / raw
To: Lennart Borgman (gmail)
Cc: Juri Linkov, David Reitter, 222, emacs-pretest-bug
"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> David Kastrup wrote:
>> David Reitter <david.reitter@gmail.com> writes:
>>
>>> On 11 May 2008, at 17:59, Juri Linkov wrote:
>>>> `isearch-repeat-forward' is not an entry point to the incremental
>>>> search:
>>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>>> never intended for non-incremental search, so it doesn't guarantee to
>>>> work when isearch mode is not active.
>>>>
>>>> If you want to find the next occurrence without highlighting it
>>>> and without activating isearch mode, you can use the command
>>>> `search-forward'.
>>> isearch-repeat-forward is interactive, which is why I thought it would
>>> be a decent entry point.
>>
>> Which I would call a reasonable expectation. However, keybindings even
>> in specialized keymaps need to be bound to interactive functions. So if
>> we have functions that are only intended for use in specialized keymaps,
>> there is no way to keep people from binding them to normal keymaps.
>>
>> So it is sort of a combined documentation/expectation problem. I have
>> no good idea how to approach this.
>
> Maybe an error message that explains/points to an explanation?
What should trigger an error here?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:25 ` David Kastrup
@ 2008-05-11 23:59 ` Juri Linkov
2008-05-11 23:59 ` Juri Linkov
1 sibling, 0 replies; 21+ messages in thread
From: Juri Linkov @ 2008-05-11 23:59 UTC (permalink / raw
To: David Kastrup; +Cc: 222, emacs-pretest-bug
>>> Which I would call a reasonable expectation. However, keybindings even
>>> in specialized keymaps need to be bound to interactive functions. So if
>>> we have functions that are only intended for use in specialized keymaps,
>>> there is no way to keep people from binding them to normal keymaps.
>>>
>>> So it is sort of a combined documentation/expectation problem. I have
>>> no good idea how to approach this.
>>
>> Maybe an error message that explains/points to an explanation?
>
> What should trigger an error here?
(unless isearch-mode
(error "This command doesn't work when isearch mode is not active"))
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:25 ` David Kastrup
2008-05-11 23:59 ` bug#222: " Juri Linkov
@ 2008-05-11 23:59 ` Juri Linkov
2008-05-12 7:21 ` David Reitter
2008-05-12 7:21 ` bug#222: " David Reitter
1 sibling, 2 replies; 21+ messages in thread
From: Juri Linkov @ 2008-05-11 23:59 UTC (permalink / raw
To: David Kastrup
Cc: David Reitter, Lennart Borgman (gmail), 222, emacs-pretest-bug
>>> Which I would call a reasonable expectation. However, keybindings even
>>> in specialized keymaps need to be bound to interactive functions. So if
>>> we have functions that are only intended for use in specialized keymaps,
>>> there is no way to keep people from binding them to normal keymaps.
>>>
>>> So it is sort of a combined documentation/expectation problem. I have
>>> no good idea how to approach this.
>>
>> Maybe an error message that explains/points to an explanation?
>
> What should trigger an error here?
(unless isearch-mode
(error "This command doesn't work when isearch mode is not active"))
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:59 ` Juri Linkov
2008-05-12 7:21 ` David Reitter
@ 2008-05-12 7:21 ` David Reitter
2008-05-12 7:56 ` David Reitter
2008-05-12 7:56 ` David Reitter
1 sibling, 2 replies; 21+ messages in thread
From: David Reitter @ 2008-05-12 7:21 UTC (permalink / raw
To: Juri Linkov; +Cc: emacs-pretest-bug, David Kastrup, 222
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On 12 May 2008, at 00:59, Juri Linkov wrote:
>
> (unless isearch-mode
> (error "This command doesn't work when isearch mode is not
> active"))
Would this
(unless isearch-mode
(isearch-mode 1))
be not more reasonable?
- D
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 23:59 ` Juri Linkov
@ 2008-05-12 7:21 ` David Reitter
2008-05-12 7:21 ` bug#222: " David Reitter
1 sibling, 0 replies; 21+ messages in thread
From: David Reitter @ 2008-05-12 7:21 UTC (permalink / raw
To: Juri Linkov; +Cc: emacs-pretest-bug, Lennart Borgman (gmail), 222
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On 12 May 2008, at 00:59, Juri Linkov wrote:
>
> (unless isearch-mode
> (error "This command doesn't work when isearch mode is not
> active"))
Would this
(unless isearch-mode
(isearch-mode 1))
be not more reasonable?
- D
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-12 7:21 ` bug#222: " David Reitter
@ 2008-05-12 7:56 ` David Reitter
2008-05-12 7:56 ` David Reitter
1 sibling, 0 replies; 21+ messages in thread
From: David Reitter @ 2008-05-12 7:56 UTC (permalink / raw
To: 222; +Cc: emacs-pretest-bug, David Kastrup
On 12 May 2008, at 08:21, David Reitter wrote:
>
> (unless isearch-mode
> (isearch-mode 1))
Another alternative would be to make isearch-repeat-forward simply
work in this case because it does something useful.
We've had Command-G bound to it for three years now (i.e., in
Aquamacs, with Command-F bound to isearch-forward) and I've never had
any complaints from users about the functionality.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-12 7:21 ` bug#222: " David Reitter
2008-05-12 7:56 ` David Reitter
@ 2008-05-12 7:56 ` David Reitter
2008-05-13 0:30 ` Juri Linkov
1 sibling, 1 reply; 21+ messages in thread
From: David Reitter @ 2008-05-12 7:56 UTC (permalink / raw
To: 222; +Cc: Juri Linkov, emacs-pretest-bug
On 12 May 2008, at 08:21, David Reitter wrote:
>
> (unless isearch-mode
> (isearch-mode 1))
Another alternative would be to make isearch-repeat-forward simply
work in this case because it does something useful.
We've had Command-G bound to it for three years now (i.e., in
Aquamacs, with Command-F bound to isearch-forward) and I've never had
any complaints from users about the functionality.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-11 22:54 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-11 23:00 ` Lennart Borgman (gmail)
@ 2008-05-12 14:41 ` Stefan Monnier
2008-05-12 14:41 ` Stefan Monnier
3 siblings, 0 replies; 21+ messages in thread
From: Stefan Monnier @ 2008-05-12 14:41 UTC (permalink / raw
To: David Kastrup; +Cc: 222, emacs-pretest-bug
>>> `isearch-repeat-forward' is not an entry point to the incremental
>>> search:
>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>> never intended for non-incremental search, so it doesn't guarantee to
>>> work when isearch mode is not active.
>>>
>>> If you want to find the next occurrence without highlighting it
>>> and without activating isearch mode, you can use the command
>>> `search-forward'.
>>
>> isearch-repeat-forward is interactive, which is why I thought it would
>> be a decent entry point.
> Which I would call a reasonable expectation. However, keybindings even
> in specialized keymaps need to be bound to interactive functions. So if
> we have functions that are only intended for use in specialized keymaps,
> there is no way to keep people from binding them to normal keymaps.
> So it is sort of a combined documentation/expectation problem. I have
> no good idea how to approach this.
It's a very general problem: many keybindings used in major-mode or
minor modes only work properly if the corresponding mode is
currently active.
Of course, many work perfectly in other contexts too, and yet many more
work 98% OK as well.
I don't think it makes sense to document each and every function
describing whether it's expected to work in other modes or not.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: isearch-repeat-forward: wrong overlay after failure
2008-05-11 22:54 ` David Kastrup
` (2 preceding siblings ...)
2008-05-12 14:41 ` Stefan Monnier
@ 2008-05-12 14:41 ` Stefan Monnier
2011-07-09 17:39 ` bug#222: " Glenn Morris
3 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2008-05-12 14:41 UTC (permalink / raw
To: David Kastrup; +Cc: Juri Linkov, David Reitter, 222, emacs-pretest-bug
>>> `isearch-repeat-forward' is not an entry point to the incremental
>>> search:
>>> it doesn't activate isearch mode neither deactivates it. IIUC, it was
>>> never intended for non-incremental search, so it doesn't guarantee to
>>> work when isearch mode is not active.
>>>
>>> If you want to find the next occurrence without highlighting it
>>> and without activating isearch mode, you can use the command
>>> `search-forward'.
>>
>> isearch-repeat-forward is interactive, which is why I thought it would
>> be a decent entry point.
> Which I would call a reasonable expectation. However, keybindings even
> in specialized keymaps need to be bound to interactive functions. So if
> we have functions that are only intended for use in specialized keymaps,
> there is no way to keep people from binding them to normal keymaps.
> So it is sort of a combined documentation/expectation problem. I have
> no good idea how to approach this.
It's a very general problem: many keybindings used in major-mode or
minor modes only work properly if the corresponding mode is
currently active.
Of course, many work perfectly in other contexts too, and yet many more
work 98% OK as well.
I don't think it makes sense to document each and every function
describing whether it's expected to work in other modes or not.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-12 7:56 ` David Reitter
@ 2008-05-13 0:30 ` Juri Linkov
0 siblings, 0 replies; 21+ messages in thread
From: Juri Linkov @ 2008-05-13 0:30 UTC (permalink / raw
To: David Reitter; +Cc: emacs-pretest-bug
>> (unless isearch-mode
>> (isearch-mode 1))
>
> Another alternative would be to make isearch-repeat-forward simply work in
> this case because it does something useful.
I think we need a general function that will start isearch with
an arbitrary string. This string could be the last search string
or the word/symbol/thing at point. The latter will provide a
useful feature currently presented in Vim (keys `*' and `#').
There is one implementation I helped to create in
http://www.emacswiki.org/cgi-bin/wiki/SearchAtPoint
This could be generalized and added to isearch.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#222: isearch-repeat-forward: wrong overlay after failure
2008-05-12 14:41 ` Stefan Monnier
@ 2011-07-09 17:39 ` Glenn Morris
0 siblings, 0 replies; 21+ messages in thread
From: Glenn Morris @ 2011-07-09 17:39 UTC (permalink / raw
To: 222-done
I don't see a need to keep open this particular report, which was marked
"wontfix" some time ago.
Stefan Monnier wrote:
> It's a very general problem: many keybindings used in major-mode or
> minor modes only work properly if the corresponding mode is
> currently active.
>
> Of course, many work perfectly in other contexts too, and yet many more
> work 98% OK as well.
>
> I don't think it makes sense to document each and every function
> describing whether it's expected to work in other modes or not.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-07-09 17:39 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-11 15:52 isearch-repeat-forward: wrong overlay after failure David Reitter
2008-05-11 16:59 ` Juri Linkov
2008-05-11 21:48 ` David Reitter
2008-05-11 22:54 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-11 23:25 ` David Kastrup
2008-05-11 23:59 ` bug#222: " Juri Linkov
2008-05-11 23:59 ` Juri Linkov
2008-05-12 7:21 ` David Reitter
2008-05-12 7:21 ` bug#222: " David Reitter
2008-05-12 7:56 ` David Reitter
2008-05-12 7:56 ` David Reitter
2008-05-13 0:30 ` Juri Linkov
2008-05-11 23:25 ` David Kastrup
2008-05-11 23:00 ` Lennart Borgman (gmail)
2008-05-12 14:41 ` Stefan Monnier
2008-05-12 14:41 ` Stefan Monnier
2011-07-09 17:39 ` bug#222: " Glenn Morris
2008-05-11 22:54 ` David Kastrup
2008-05-11 21:48 ` David Reitter
-- strict thread matches above, loose matches on Subject: below --
2008-05-11 15:52 David Reitter
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.