* spaces in isearch
@ 2004-11-21 1:10 Richard Stallman
2004-11-21 2:43 ` Juri Linkov
2004-11-23 6:07 ` Harald Maier
0 siblings, 2 replies; 10+ messages in thread
From: Richard Stallman @ 2004-11-21 1:10 UTC (permalink / raw)
I wrote these changes to isearch.el that take advantage of the new
search feature I just installed. It fixes the bug, but has a
drawback: C-q SPC would no longer work as a way to search for a
literal space. One would need to write [ ]. This is actually more
logical, but some users might be accustomed to C-q SPC. What do
people think?
*** isearch.el 12 Oct 2004 04:45:09 -0400 1.242
--- isearch.el 20 Nov 2004 09:22:33 -0500
***************
*** 112,117 ****
--- 112,119 ----
(defcustom search-whitespace-regexp "\\(?:\\s-+\\)"
"*If non-nil, regular expression to match a sequence of whitespace chars.
This applies to regular expression incremental search.
+ When you put a space or spaces in the incremental regexp, it stands for
+ this, unless it is inside of a regexp construct such as [...] or *, + or ?.
You might want to use something like \"\\\\(?:[ \\t\\r\\n]+\\\\)\" instead.
In the Customization buffer, that is `\\(?:[' followed by a space,
a tab, a carriage return (control-M), a newline, and `]+\\)'."
***************
*** 260,267 ****
(define-key map "\r" 'isearch-exit)
(define-key map "\C-j" 'isearch-printing-char)
(define-key map "\t" 'isearch-printing-char)
- (define-key map " " 'isearch-whitespace-chars)
- (define-key map [?\S-\ ] 'isearch-whitespace-chars)
(define-key map "\C-w" 'isearch-yank-word-or-char)
(define-key map "\M-\C-w" 'isearch-del-char)
--- 262,267 ----
***************
*** 485,491 ****
Do incremental search forward for regular expression.
With a prefix argument, do a regular string search instead.
Like ordinary incremental search except that your input
! is treated as a regexp. See \\[isearch-forward] for more info."
(interactive "P\np")
(isearch-mode t (null not-regexp) nil (not no-recursive-edit)))
--- 485,496 ----
Do incremental search forward for regular expression.
With a prefix argument, do a regular string search instead.
Like ordinary incremental search except that your input
! is treated as a regexp. See \\[isearch-forward] for more info.
!
! In regexp incremental searches, a space or spaces normally matches
! any whitespace (the variable `search-whitespace-regexp' controls
! precisely what that means). If you want to search for a literal space
! and nothing else, enter `[ ]'."
(interactive "P\np")
(isearch-mode t (null not-regexp) nil (not no-recursive-edit)))
***************
*** 1704,1725 ****
(isearch-process-search-multibyte-characters char)
(isearch-process-search-char char)))))
- (defun isearch-whitespace-chars ()
- "Match all whitespace chars, if in regexp mode.
- If you want to search for just a space, type \\<isearch-mode-map>\\[isearch-quote-char] SPC."
- (interactive)
- (if isearch-regexp
- (if (and search-whitespace-regexp (not isearch-within-brackets)
- (not isearch-invalid-regexp))
- (isearch-process-search-string search-whitespace-regexp " ")
- (isearch-printing-char))
- (progn
- ;; This way of doing word search doesn't correctly extend current search.
- ;; (setq isearch-word t)
- ;; (setq isearch-adjusted t)
- ;; (goto-char isearch-barrier)
- (isearch-printing-char))))
-
(defun isearch-process-search-char (char)
;; Append the char to the search string, update the message and re-search.
(isearch-process-search-string
--- 1709,1714 ----
***************
*** 1960,1965 ****
--- 1949,1955 ----
(let ((inhibit-point-motion-hooks search-invisible)
(inhibit-quit nil)
(case-fold-search isearch-case-fold-search)
+ (search-spaces-regexp search-whitespace-regexp)
(retry t))
(if isearch-regexp (setq isearch-invalid-regexp nil))
(setq isearch-within-brackets nil)
***************
*** 2373,2379 ****
(defun isearch-lazy-highlight-search ()
"Search ahead for the next or previous match, for lazy highlighting.
Attempt to do the search exactly the way the pending isearch would."
! (let ((case-fold-search isearch-case-fold-search))
(funcall (isearch-search-fun)
isearch-string
(if isearch-forward
--- 2363,2370 ----
(defun isearch-lazy-highlight-search ()
"Search ahead for the next or previous match, for lazy highlighting.
Attempt to do the search exactly the way the pending isearch would."
! (let ((case-fold-search isearch-case-fold-search)
! (search-spaces-regexp search-whitespace-regexp))
(funcall (isearch-search-fun)
isearch-string
(if isearch-forward
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-21 1:10 spaces in isearch Richard Stallman
@ 2004-11-21 2:43 ` Juri Linkov
2004-11-21 11:08 ` Alex Schroeder
2004-11-22 14:07 ` Richard Stallman
2004-11-23 6:07 ` Harald Maier
1 sibling, 2 replies; 10+ messages in thread
From: Juri Linkov @ 2004-11-21 2:43 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> I wrote these changes to isearch.el that take advantage of the new
> search feature I just installed. It fixes the bug, but has a
> drawback: C-q SPC would no longer work as a way to search for a
> literal space. One would need to write [ ]. This is actually more
> logical, but some users might be accustomed to C-q SPC. What do
> people think?
Since C-q in isearch mode is processed by isearch-quote-char,
it could intercept SPC and insert [ ] into the search string.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-21 2:43 ` Juri Linkov
@ 2004-11-21 11:08 ` Alex Schroeder
2004-11-21 17:09 ` Juri Linkov
2004-11-22 14:07 ` Richard Stallman
1 sibling, 1 reply; 10+ messages in thread
From: Alex Schroeder @ 2004-11-21 11:08 UTC (permalink / raw)
Cc: rms, emacs-devel
Juri Linkov <juri@jurta.org> writes:
> Since C-q in isearch mode is processed by isearch-quote-char,
> it could intercept SPC and insert [ ] into the search string.
I'm not sure I like that. C-q <something> should insert <something>,
not stuff that means what you might have intended. So I'm happy with
the current C-q behaviour.
I didn't know about the special behaviour of <space> in
isearch-forward-regexp. Given that the behaviour is not new, adding
information to the doc-string seems like the right thing to do. I
believe no further changes are necessary.
Alex.
--
.O. http://www.emacswiki.org/alex/
..O Schroeder's fifth law:
OOO Never accept more work than you can handle in one night of hacking.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-21 11:08 ` Alex Schroeder
@ 2004-11-21 17:09 ` Juri Linkov
2004-11-22 0:35 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2004-11-21 17:09 UTC (permalink / raw)
Cc: rms, emacs-devel
Alex Schroeder <alex@emacswiki.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> Since C-q in isearch mode is processed by isearch-quote-char,
>> it could intercept SPC and insert [ ] into the search string.
>
> I'm not sure I like that. C-q <something> should insert <something>,
No, C-q <something> should be used to insert <something_different>.
There is no sense to use C-q <something> to insert the same <something>.
> I didn't know about the special behaviour of <space> in
> isearch-forward-regexp.
The old behavior: SPC inserts \\(?:\\s-+\\), C-q SPC inserts SPC.
The new behavior: SPC inserts SPC (which now internally means \\(?:\\s-+\\)).
So C-q SPC inserting SPC has no sense anymore since SPC now is
inserted by SPC itself.
Moreover, to achieve backward compatibility for users using C-q SPC
to match just a space, C-q SPC should do something to preserve the
literal meaning of a space. Adding [ ] to the search string in regexp
isearch mode is the most natural thing to do.
>From implementation point of view this means moving the old code from
`isearch-whitespace-chars' to `isearch-quote-char' and replacing
(isearch-process-search-string search-whitespace-regexp " ")
with
(isearch-process-search-string "[ ]" " ")
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-21 2:43 ` Juri Linkov
2004-11-21 11:08 ` Alex Schroeder
@ 2004-11-22 14:07 ` Richard Stallman
2004-11-22 18:39 ` Kevin Rodgers
1 sibling, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2004-11-22 14:07 UTC (permalink / raw)
Cc: emacs-devel
Since C-q in isearch mode is processed by isearch-quote-char,
it could intercept SPC and insert [ ] into the search string.
I thought about that, but it would not work right in all contexts.
For instance, suppose you're inside a [...] grouping already.
It's true that you don't *need* to use C-q if you're inside a [...]
grouping already. But using it there shouldn't cause wrong results.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-22 14:07 ` Richard Stallman
@ 2004-11-22 18:39 ` Kevin Rodgers
0 siblings, 0 replies; 10+ messages in thread
From: Kevin Rodgers @ 2004-11-22 18:39 UTC (permalink / raw)
Richard Stallman wrote:
> Since C-q in isearch mode is processed by isearch-quote-char,
> it could intercept SPC and insert [ ] into the search string.
>
> I thought about that, but it would not work right in all contexts.
> For instance, suppose you're inside a [...] grouping already.
>
> It's true that you don't *need* to use C-q if you're inside a [...]
> grouping already. But using it there shouldn't cause wrong results.
Can't Emacs detect that it's inside a non-terminated [...] and do
the right thing in that context?
--
Kevin Rodgers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-21 1:10 spaces in isearch Richard Stallman
2004-11-21 2:43 ` Juri Linkov
@ 2004-11-23 6:07 ` Harald Maier
2004-11-23 6:52 ` Juri Linkov
1 sibling, 1 reply; 10+ messages in thread
From: Harald Maier @ 2004-11-23 6:07 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> I wrote these changes to isearch.el that take advantage of the new
> search feature I just installed. It fixes the bug, but has a
> drawback: C-q SPC would no longer work as a way to search for a
> literal space. One would need to write [ ]. This is actually more
> logical, but some users might be accustomed to C-q SPC. What do
> people think?
If I now use '^ +A' in an interactive regexp search then emacs hangs
in the minibuffer. In a version from October 17 it doesn't happen.
To reproduce this use:
,----
| $ emacs -Q
| M-x man bash
| C-u C-s ^ +A
`----
Harald
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-23 6:07 ` Harald Maier
@ 2004-11-23 6:52 ` Juri Linkov
2004-11-24 5:37 ` Harald Maier
0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2004-11-23 6:52 UTC (permalink / raw)
Cc: rms, emacs-devel
Harald Maier <harald@maierh.de> writes:
> Richard Stallman <rms@gnu.org> writes:
>> I wrote these changes to isearch.el that take advantage of the new
>> search feature I just installed. It fixes the bug, but has a
>> drawback: C-q SPC would no longer work as a way to search for a
>> literal space. One would need to write [ ]. This is actually more
>> logical, but some users might be accustomed to C-q SPC. What do
>> people think?
>
> If I now use '^ +A' in an interactive regexp search then emacs hangs
> in the minibuffer. In a version from October 17 it doesn't happen.
Are you sure this didn't happen before October 17? From what I see,
quite contrary: Richard's changes were intended to fix the same bug
as you reported. But they are not even installed to CVS (though it's
strange that there is a ChangeLog entry already for uninstalled change).
So you can't see the effect of changes in isearch.el unless you applied
the proposed patch to your local source tree.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: spaces in isearch
2004-11-23 6:52 ` Juri Linkov
@ 2004-11-24 5:37 ` Harald Maier
0 siblings, 0 replies; 10+ messages in thread
From: Harald Maier @ 2004-11-24 5:37 UTC (permalink / raw)
Cc: rms, emacs-devel
Juri Linkov <juri@jurta.org> writes:
> Harald Maier <harald@maierh.de> writes:
>> Richard Stallman <rms@gnu.org> writes:
>>> I wrote these changes to isearch.el that take advantage of the new
>>> search feature I just installed. It fixes the bug, but has a
>>> drawback: C-q SPC would no longer work as a way to search for a
>>> literal space. One would need to write [ ]. This is actually more
>>> logical, but some users might be accustomed to C-q SPC. What do
>>> people think?
>>
>> If I now use '^ +A' in an interactive regexp search then emacs hangs
>> in the minibuffer. In a version from October 17 it doesn't happen.
>
> Are you sure this didn't happen before October 17?
I tried it again and there both constructs seem to work really fine:
'^ A' and '^ +A'. I don't know which change afterwards has broken the
latter.
> From what I see, quite contrary: Richard's changes were intended to
> fix the same bug as you reported. But they are not even installed
> to CVS (though it's strange that there is a ChangeLog entry already
> for uninstalled change). So you can't see the effect of changes in
> isearch.el unless you applied the proposed patch to your local
> source tree.
I saw the problem too by accident and so I did my comments without
verifying whether Richard has already installed the patch. Sorry for
the noice.
Harald
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-11-24 5:37 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-21 1:10 spaces in isearch Richard Stallman
2004-11-21 2:43 ` Juri Linkov
2004-11-21 11:08 ` Alex Schroeder
2004-11-21 17:09 ` Juri Linkov
2004-11-22 0:35 ` Stefan Monnier
2004-11-22 14:07 ` Richard Stallman
2004-11-22 18:39 ` Kevin Rodgers
2004-11-23 6:07 ` Harald Maier
2004-11-23 6:52 ` Juri Linkov
2004-11-24 5:37 ` Harald Maier
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).