spaces in isearch

spaces in isearch

[Richard Stallman]

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

Re: spaces in isearch

[Juri Linkov]

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/

Re: spaces in isearch

[Alex Schroeder]

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.

Re: spaces in isearch

[Juri Linkov]

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/

Re: spaces in isearch

[Stefan Monnier]

> The old behavior: SPC inserts \\(?:\\s-+\\), C-q SPC inserts SPC.
> The new behavior: SPC inserts SPC (which now internally means \\(?:\\s-+\\)).

I must have missed the thread that lead to this change.
Why is this new behavior better than the old one?


        Stefan

Re: spaces in isearch

[Richard Stallman]

    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.

Re: spaces in isearch

[Kevin Rodgers]

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

Re: spaces in isearch

[Harald Maier]

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

Re: spaces in isearch

[Juri Linkov]

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/

Re: spaces in isearch

[Harald Maier]

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