all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#16546: C-s vs. whitespace highlighting
@ 2014-01-25  9:49 jidanni
  2014-01-25 13:46 ` Bastien
  2014-01-25 14:23 ` jidanni
  0 siblings, 2 replies; 14+ messages in thread
From: jidanni @ 2014-01-25  9:49 UTC (permalink / raw)
  To: 16546

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-25  9:49 bug#16546: C-s vs. whitespace highlighting jidanni
@ 2014-01-25 13:46 ` Bastien
  2014-01-25 14:17   ` Dani Moncayo
  2014-01-26 21:46   ` Nicolas Richard
  2014-01-25 14:23 ` jidanni
  1 sibling, 2 replies; 14+ messages in thread
From: Bastien @ 2014-01-25 13:46 UTC (permalink / raw)
  To: jidanni; +Cc: 16546

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-25 13:46 ` Bastien
@ 2014-01-25 14:17   ` Dani Moncayo
  2014-01-26 21:46   ` Nicolas Richard
  1 sibling, 0 replies; 14+ messages in thread
From: Dani Moncayo @ 2014-01-25 14:17 UTC (permalink / raw)
  To: Bastien; +Cc: Dan Jacobson, 16546

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-25  9:49 bug#16546: C-s vs. whitespace highlighting jidanni
  2014-01-25 13:46 ` Bastien
@ 2014-01-25 14:23 ` jidanni
  1 sibling, 0 replies; 14+ messages in thread
From: jidanni @ 2014-01-25 14:23 UTC (permalink / raw)
  To: bzg; +Cc: 16546-done

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-25 13:46 ` Bastien
  2014-01-25 14:17   ` Dani Moncayo
@ 2014-01-26 21:46   ` Nicolas Richard
  2014-01-26 22:32     ` Bastien
  1 sibling, 1 reply; 14+ messages in thread
From: Nicolas Richard @ 2014-01-26 21:46 UTC (permalink / raw)
  To: Bastien; +Cc: jidanni, 16546

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-26 21:46   ` Nicolas Richard
@ 2014-01-26 22:32     ` Bastien
  2014-01-27  2:16       ` Stefan Monnier
  2014-01-27  7:50       ` Dani Moncayo
  0 siblings, 2 replies; 14+ messages in thread
From: Bastien @ 2014-01-26 22:32 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: jidanni, 16546

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-26 22:32     ` Bastien
@ 2014-01-27  2:16       ` Stefan Monnier
  2014-01-27  7:09         ` Bastien
  2014-01-27  7:50       ` Dani Moncayo
  1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2014-01-27  2:16 UTC (permalink / raw)
  To: Bastien; +Cc: Nicolas Richard, jidanni, 16546

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  2:16       ` Stefan Monnier
@ 2014-01-27  7:09         ` Bastien
  0 siblings, 0 replies; 14+ messages in thread
From: Bastien @ 2014-01-27  7:09 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Nicolas Richard, jidanni, 16546

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-26 22:32     ` Bastien
  2014-01-27  2:16       ` Stefan Monnier
@ 2014-01-27  7:50       ` Dani Moncayo
  2014-01-27  8:21         ` martin rudalics
  2014-01-27  9:21         ` Juri Linkov
  1 sibling, 2 replies; 14+ messages in thread
From: Dani Moncayo @ 2014-01-27  7:50 UTC (permalink / raw)
  To: Bastien; +Cc: Nicolas Richard, Dan Jacobson, 16546

>> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  7:50       ` Dani Moncayo
@ 2014-01-27  8:21         ` martin rudalics
  2014-01-27  8:35           ` Dani Moncayo
  2014-01-27  9:21         ` Juri Linkov
  1 sibling, 1 reply; 14+ messages in thread
From: martin rudalics @ 2014-01-27  8:21 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: Bastien, 16546, Nicolas Richard, Dan Jacobson

 >> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  8:21         ` martin rudalics
@ 2014-01-27  8:35           ` Dani Moncayo
  0 siblings, 0 replies; 14+ messages in thread
From: Dani Moncayo @ 2014-01-27  8:35 UTC (permalink / raw)
  To: martin rudalics; +Cc: Bastien, 16546, Nicolas Richard, Dan Jacobson

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  7:50       ` Dani Moncayo
  2014-01-27  8:21         ` martin rudalics
@ 2014-01-27  9:21         ` Juri Linkov
  2014-01-27  9:55           ` Dani Moncayo
  1 sibling, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2014-01-27  9:21 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: Bastien, 16546, Nicolas Richard, Dan Jacobson

> 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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  9:21         ` Juri Linkov
@ 2014-01-27  9:55           ` Dani Moncayo
  2014-01-28  7:30             ` Juri Linkov
  0 siblings, 1 reply; 14+ messages in thread
From: Dani Moncayo @ 2014-01-27  9:55 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Bastien, 16546, Nicolas Richard, Dan Jacobson

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#16546: C-s vs. whitespace highlighting
  2014-01-27  9:55           ` Dani Moncayo
@ 2014-01-28  7:30             ` Juri Linkov
  0 siblings, 0 replies; 14+ messages in thread
From: Juri Linkov @ 2014-01-28  7:30 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: Bastien, 16546, Nicolas Richard, Dan Jacobson

> 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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-01-28  7:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-25  9:49 bug#16546: C-s vs. whitespace highlighting jidanni
2014-01-25 13:46 ` Bastien
2014-01-25 14:17   ` Dani Moncayo
2014-01-26 21:46   ` Nicolas Richard
2014-01-26 22:32     ` Bastien
2014-01-27  2:16       ` Stefan Monnier
2014-01-27  7:09         ` Bastien
2014-01-27  7:50       ` Dani Moncayo
2014-01-27  8:21         ` martin rudalics
2014-01-27  8:35           ` Dani Moncayo
2014-01-27  9:21         ` Juri Linkov
2014-01-27  9:55           ` Dani Moncayo
2014-01-28  7:30             ` Juri Linkov
2014-01-25 14:23 ` jidanni

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.