bug#16546: C-s vs. whitespace highlighting

bug#16546: C-s vs. whitespace highlighting

[jidanni]

Do C-s SPACE SPACE SPACE,
notice that even isolated spaces are highlighted.
The only spaces that should be highlighted are those three in a row,
just like it works for e.g., C-s ddd.

bug#16546: C-s vs. whitespace highlighting

[Bastien]

jidanni@jidanni.org writes:

> Do C-s SPACE SPACE SPACE,
> notice that even isolated spaces are highlighted.

This is by design.

You can use `C-s M-s ' (control s meta s space) to temporarily
search with `search-whitespace-regexp' set to nil or customize
this option directly.

> The only spaces that should be highlighted are those three in a row,
> just like it works for e.g., C-s ddd.

I think the default is good because the need to match "a  word" with
"C-s a word" is more likely than the need not to match "a word" with
"C-s a  word".

-- 
 Bastien

bug#16546: C-s vs. whitespace highlighting

[Dani Moncayo]

> I think the default is good because the need to match "a  word"

or "a<newline>word", or in general "a<whitespace>word"

> with
> "C-s a word" is more likely than the need not to match "a word" with
> "C-s a  word".

I agree.

-- 
Dani Moncayo

bug#16546: C-s vs. whitespace highlighting

[Nicolas Richard]

Bastien <bzg@altern.org> writes:
> I think the default is good because the need to match "a  word" with
> "C-s a word" is more likely than the need not to match "a word" with
> "C-s a  word".

When I specifically add two spaces to my search string, it usually means
that, at that point, I want at least two spaces. If I compare to the
similar feature of case folding, that one is deactivated when there is
an explicit capital letter in the search string. OTOH, the cases where I
actually want to match multiple spaces are rare enough.

-- 
Nico.

bug#16546: C-s vs. whitespace highlighting

[Bastien]

Hi Nicolas,

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Bastien <bzg@altern.org> writes:
>> I think the default is good because the need to match "a  word" with
>> "C-s a word" is more likely than the need not to match "a word" with
>> "C-s a  word".
>
> When I specifically add two spaces to my search string, it usually means
> that, at that point, I want at least two spaces. If I compare to the
> similar feature of case folding, that one is deactivated when there is
> an explicit capital letter in the search string. OTOH, the cases where I
> actually want to match multiple spaces are rare enough.

Yes, good idea.  I also think search for two whitespace chars in a row
should temporary toggle `search-whitespace-regexp' to nil.

-- 
 Bastien

bug#16546: C-s vs. whitespace highlighting

[Stefan Monnier]

> Yes, good idea.  I also think search for two whitespace chars in a row
> should temporary toggle `search-whitespace-regexp' to nil.

That, or the resulting regexp should require at least 2 space.


        Stefan

bug#16546: C-s vs. whitespace highlighting

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, good idea.  I also think search for two whitespace chars in a row
>> should temporary toggle `search-whitespace-regexp' to nil.
>
> That, or the resulting regexp should require at least 2 space.

Or maybe: the resulting regexp should be

  (concat [an-isearch-string-with-only-whitespace-chars]
          search-whitespace-regexp)

?

That way two spaces means " \\s-+"

If so, I will have a look.

PS: I guess this is not a bugfix, but I'll prepare a patch for this
thread anyway.

-- 
 Bastien

bug#16546: C-s vs. whitespace highlighting

[Dani Moncayo]

>> When I specifically add two spaces to my search string, it usually means
>> that, at that point, I want at least two spaces. If I compare to the
>> similar feature of case folding, that one is deactivated when there is
>> an explicit capital letter in the search string. OTOH, the cases where I
>> actually want to match multiple spaces are rare enough.
>
> Yes, good idea.  I also think search for two whitespace chars in a row
> should temporary toggle `search-whitespace-regexp' to nil.

IMO, that behavior would make sense only when the whitespace chars are
entered interactively (i.e. typed on the keyboard), because if the
search string comes from another place (copy&paste, grabbed from the
buffer, ...), I don't think it would be a good idea to temporarily set
`search-whitespace-regexp' to nil.  And BTW, that reasoning applies
equally to case-fold-search.

IOW, if I copy some text "foo<any-whitespace>bar" from one place and
then go to Emacs and do "C-s C-y", I definitely want a "lax" search
wrt whitespace.

At least, that behavior should be configurable, IMO.

-- 
Dani Moncayo

bug#16546: C-s vs. whitespace highlighting

[martin rudalics]

 >> Yes, good idea.  I also think search for two whitespace chars in a row
 >> should temporary toggle `search-whitespace-regexp' to nil.
 >
 > IMO, that behavior would make sense only when the whitespace chars are
 > entered interactively (i.e. typed on the keyboard), because if the
 > search string comes from another place (copy&paste, grabbed from the
 > buffer, ...), I don't think it would be a good idea to temporarily set
 > `search-whitespace-regexp' to nil.  And BTW, that reasoning applies
 > equally to case-fold-search.
 >
 > IOW, if I copy some text "foo<any-whitespace>bar" from one place and
 > then go to Emacs and do "C-s C-y", I definitely want a "lax" search
 > wrt whitespace.
 >
 > At least, that behavior should be configurable, IMO.

Searching for two or more whitespace characters without any surrounding
non-whitespace characters should bind `search-whitespace-regexp' to nil.
This would trivially take care of Dan's original problem.  And it should
go into Emacs 24.4 because Dan's scenario reveals a very obvious bug.

martin

bug#16546: C-s vs. whitespace highlighting

[Dani Moncayo]

> Searching for two or more whitespace characters without any surrounding
> non-whitespace characters should bind `search-whitespace-regexp' to nil.

In that concrete scenario, I'd tend to agree, yes.

-- 
Dani Moncayo

bug#16546: C-s vs. whitespace highlighting

[Juri Linkov]

> IMO, that behavior would make sense only when the whitespace chars are
> entered interactively (i.e. typed on the keyboard), because if the
> search string comes from another place (copy&paste, grabbed from the
> buffer, ...), I don't think it would be a good idea to temporarily set
> `search-whitespace-regexp' to nil.  And BTW, that reasoning applies
> equally to case-fold-search.

I agree that when the user types several spaces in a row explicitly
then spaces should be treated as intended by the user.

Actually, whitespace search already does this in regexp mode.
Relevant lines from regex.c:

	    /* If the spaces are followed by a repetition op,
	       treat them normally.  */
	    if (p1 != pend
		&& (*p1 == '*' || *p1 == '+' || *p1 == '?'
		    || (*p1 == '\\' && p1 + 1 != pend && p1[1] == '{')))
	      goto normal_char;

This means that when the user types ` +' then `search-whitespace-regexp'
is ignored.  I think the same should be implemented for a non-regexp search
as well, so typing `   ' will transform the input to ` +' and ignored.

> IOW, if I copy some text "foo<any-whitespace>bar" from one place and
> then go to Emacs and do "C-s C-y", I definitely want a "lax" search
> wrt whitespace.

Indeed.

> At least, that behavior should be configurable, IMO.

For better configurability I'm using such implementation:

  (defun search-forward-lax-whitespace (string &optional bound noerror count)
    (re-search-forward (search-whitespace-regexp (regexp-quote string)) bound noerror count))
  (defun search-backward-lax-whitespace (string &optional bound noerror count)
    (re-search-backward (search-whitespace-regexp (regexp-quote string)) bound noerror count))
  (defun re-search-forward-lax-whitespace (regexp &optional bound noerror count)
    (re-search-forward (search-whitespace-regexp regexp) bound noerror count))
  (defun re-search-backward-lax-whitespace (regexp &optional bound noerror count)
    (re-search-backward (search-whitespace-regexp regexp) bound noerror count))

where in `search-whitespace-regexp' you can do any whitespace handling.

bug#16546: C-s vs. whitespace highlighting

[Dani Moncayo]

> This means that when the user types ` +' then `search-whitespace-regexp'
> is ignored.  I think the same should be implemented for a non-regexp search
> as well, so typing `   ' will transform the input to ` +' and ignored.

Just one comment, regarding the "transform" part:

IMO, Emacs should refrain from making permanent changes to the search
string, as given by the user.  IOW, the search string should be kept
untouched, and any transformations of it should be done "on the fly"
to achieve the intended behavior, based on both the _current_ search
string and the _current_ user options that govern the search behavior.

That way, if/when either the search string or the user options
changes, Emacs will be able to exhibit the expected behavior.

But currently, there are cases where the original search string is
lost (e.g. "C-s C-y" when the "yanked" text contains uppercase letters
and case-fold-search is non-nil).

For concrete use-cases related to this, see bugs #13480 or #10118.

-- 
Dani Moncayo

bug#16546: C-s vs. whitespace highlighting

[Juri Linkov]

> IMO, Emacs should refrain from making permanent changes to the search
> string, as given by the user.  IOW, the search string should be kept
> untouched, and any transformations of it should be done "on the fly"
> to achieve the intended behavior, based on both the _current_ search
> string and the _current_ user options that govern the search behavior.

I agree that we have to keep the original string, and interpret it
differently according to the current search options.

And to distinguish the case when the search string was entered manually
and the case when the search string was yanked with `C-s C-y' I think
we should inspect the stack of `isearch-cmds'.  If it contains two or more
manually entered space characters then preserve them while matching whitespace.

bug#16546: C-s vs. whitespace highlighting

[jidanni]

Well OK, it is all over my head. Closing.