bug#22494: still can't search for two spaces

bug#22494: still can't search for two spaces

[Drew Adams]

>   > > I still can't search for two spaces with C-s SPC SPC.
>   > > It still just sits on the first match for single space.
> 
>   > Crystal ball says you didn't read the manual, which explains that you
>   > need to type M-s SPC after C-s to get what you want (which is literal
>   > space matching).
> 
> This is a bug.  When the user types SPC SPC in a search string,
> person clearly wants to search for two spaces.  It should do that.

+1

If lax-whitespace matching is currently turned on, typing
multiple whitespace chars contiguously could turn it off.

But in that case a message should let the user know that this
change has occurred.

And then what if the user made a mistake typing that second SPC
char - i.e., didn't really mean to search literally for multiple
whitespace chars?  It won't be enough to just delete the second
SPC char (but the user might try that).

Perhaps the message that lax whitespace matching has been switched
to literal should also mention the key sequence for toggling
back to lax matching.

bug#22494: still can't search for two spaces

[Marcin Borkowski]

On 2016-01-30, at 23:28, Drew Adams <drew.adams@oracle.com> wrote:

>>   > > I still can't search for two spaces with C-s SPC SPC.
>>   > > It still just sits on the first match for single space.
>> 
>>   > Crystal ball says you didn't read the manual, which explains that you
>>   > need to type M-s SPC after C-s to get what you want (which is literal
>>   > space matching).
>> 
>> This is a bug.  When the user types SPC SPC in a search string,
>> person clearly wants to search for two spaces.  It should do that.
>
> +1

+1

> And then what if the user made a mistake typing that second SPC
> char - i.e., didn't really mean to search literally for multiple
> whitespace chars?  It won't be enough to just delete the second
> SPC char (but the user might try that).

Why couldn't it be enough?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

bug#22494: still can't search for two spaces

[Drew Adams]

> >>   > > I still can't search for two spaces with C-s SPC SPC.
> >>   > > It still just sits on the first match for single space.
> >>
> >>   > Crystal ball says you didn't read the manual, which explains that you
> >>   > need to type M-s SPC after C-s to get what you want (which is literal
> >>   > space matching).
> >>
> >> This is a bug.  When the user types SPC SPC in a search string,
> >> person clearly wants to search for two spaces.  It should do that.
> >
> > +1
> 
> +1
> 
> > And then what if the user made a mistake typing that second SPC
> > char - i.e., didn't really mean to search literally for multiple
> > whitespace chars?  It won't be enough to just delete the second
> > SPC char (but the user might try that).
> 
> Why couldn't it be enough?

It's not a clear indication that the user wants to return to
lax whitespace matching.  What if s?he deleted the second SPC
and typed a TAB or other whitespace char?  Or typed a SPC char
again?  Would you toggle back again?

More than one whitespace char in a row might be sufficient cause
to switch to literal whitespace matching, but it's not clear that
a single such char is sufficient cause to switch to lax matching.

I'd propose a clear message indicating that Emacs has guessed,
because you typed more than one whitespace char in a row, that
you really want literal whitespace char matching, and so it has
switched to that mode.  And at the same time indicate that you
can toggle the whitespace-matching behavior using `M-s SPC'.
That should be clear enough, I would think.

bug#22494: still can't search for two spaces

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's not a clear indication that the user wants to return to
  > lax whitespace matching.  What if s?he deleted the second SPC
  > and typed a TAB or other whitespace char?  Or typed a SPC char
  > again?  Would you toggle back again?

Don't think if it as "toggling" but rather as heeding what is in
the search string.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22494: still can't search for two spaces

[Juri Linkov]

> And then what if the user made a mistake typing that second SPC
> char - i.e., didn't really mean to search literally for multiple
> whitespace chars?  It won't be enough to just delete the second
> SPC char (but the user might try that).

Then the state of lax-whitespace should be remembered in the
stack of isearch-cmds.

bug#22494: still can't search for two spaces

[Drew Adams]

>   > It's not a clear indication that the user wants to return to
>   > lax whitespace matching.  What if s?he deleted the second SPC
>   > and typed a TAB or other whitespace char?  Or typed a SPC char
>   > again?  Would you toggle back again?
> 
> Don't think if it as "toggling" but rather as heeding what is in
> the search string.

Heeding what is in the search string means nothing - or anything.

What is in the search string is a search pattern.  How it is
interpreted is the question.  Literal matching of whitespace
chars is one such interpretation.

I've already agreed that more than one whitespace char in
a row is a reasonable indication that the user wants/expects
whitespace chars to be matched literally.

Why?  Because with lax whitespace matching there is never any
reason to type multiple, contiguous whitespace chars - it
serves no purpose.

(But see also what I wrote about pasting copied text that
might contain multiple, contiguous whitespace chars.)

What is not obvious is whether whitespace search should be
changed away from literal matching just because there are
not (no longer) multiple such chars in a row in the search
pattern.  That was the subject of the text you quoted.

bug#22494: still can't search for two spaces

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What is in the search string is a search pattern.  How it is
  > interpreted is the question.

Right.  And I am proposing a way to interpret part of it.  Namely, 
two spaces in a row means to match two spaces in the buffer.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22494: still can't search for two spaces

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>   > What is in the search string is a search pattern.  How it is
>   > interpreted is the question.
>
> Right.  And I am proposing a way to interpret part of it.  Namely, 
> two spaces in a row means to match two spaces in the buffer.

But if you isearch-yank them they should be normalized so that they
continue to do lax matching.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#22494: still can't search for two spaces

[Dani Moncayo]

>>   > What is in the search string is a search pattern.  How it is
>>   > interpreted is the question.
>>
>> Right.  And I am proposing a way to interpret part of it.  Namely,
>> two spaces in a row means to match two spaces in the buffer.
>
> But if you isearch-yank them they should be normalized so that they
> continue to do lax matching.

Quoting from [1]:

  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.

IOW, I don't think that normalization is a good idea.

But I agree with you that two (or more) consecutive spaces should
be treated specially _only_ if they were *typed* by the user (not
yanked from the kill ring or grabbed from the buffer)

---
Dani Moncayo

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16546#43

bug#22494: still can't search for two spaces

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Heeding what is in the search string means nothing - or anything.

I don't know why you're saying this Drew.

If the user types something into the search string, and exactly that something
is present in the buffer, Emacs should locate it before any "lax" variant.

This means that type "nD" where nD exists, should find nD. Typing " " where
two spaces exist, should find the two spaces.

Whether or not lax whitespace matching should be the default is an entirely
separate matter. I rather like the lax matching, so long as my use of two
spaces in a search string does not mean that I can't find two spaces.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22494: still can't search for two spaces

[Drew Adams]

> > Heeding what is in the search string means nothing - or anything.
> 
> I don't know why you're saying this Drew.

By itself, it could mean anything.  What does it mean to "heed"
the current search pattern?  Nothing implies that a single
whitespace char in a row should mean that "heed" means switch
to lax whitespace matching.

The whole question about what kind of matching to do (lax, literal,
regexp,...) is about the meaning of "heeding" the search pattern
in a given context.

> If the user types something into the search string, and exactly that
> something is present in the buffer, Emacs should locate it before any
> "lax" variant.

Really?  Always?  I wouldn't have a problem with that (except if
you mean for it to apply also to regexp search).  But those who
are fans of lax whitespace search might not like it.

Today, not only is lax whitespace matching a possibility, but it
is the default for C-s.  What you suggest would mean that even 
with lax w-s matching, search should first look for an exact
match, before finding a lax match (i.e., even if that lax match
came before the literal match). 

> This means that type "nD" where nD exists, should find nD. Typing
> " " where two spaces exist, should find the two spaces.

I have no problem with that, and have said so multiple times now.
I was the first to +1 the motion that multiple, contiguous whitespace
chars should automatically turn off lax-ws matching.

> Whether or not lax whitespace matching should be the default is an entirely
> separate matter. I rather like the lax matching, so long as my use of two
> spaces in a search string does not mean that I can't find two spaces.

Yes, the default behavior is a different matter from whether the
matching mode should switch automatically depending on the search
string.

I think perhaps you misread what I've written.  I simply pointed
out that, while I agree with the proposal to automatically turn
off lax w-s if you type multiple w-s chars, there are some possible
questions for what to do in these cases:

a. You delete the multiple w-s chars, so there is now only one
   in a row.  Should we then turn lax w-s matching back on?
   I only raised the question - I didn't propose an answer.

b. Instead of _typing_ multiple, contiguous w-s chars (which
   some of us have agreed should turn off lax w-s), you _paste_
   text that includes multiple, contiguous w-s chars.  Should
   we turn off lax w-s in that case too?  Again, I only raised
   the question - I didn't propose an answer.

   In some cases where you paste such text, you might be well
   aware that there are multiple such chars in a row, and you
   might purposefully want to search for them literally.
   This can be the case if you copy and yank code, for example.
   And it is more likely to be true if you copy+paste text
   from an Emacs buffer than non-code text from outside Emacs.

   In other cases, you might not realize that there are
   multiple such chars in a row, and you might not really
   care to search literally.  This can happen if you paste
   text copied from outside Emacs, for instance.

In sum:

1. I agree (!) with the proposal to automatically turn OFF
   lax w-s search if you type multiple, contiguous w-s chars.

2. I proposed that when that happens we clearly indicate the
   change to users.

3. I raised a question about whether lax w-s matching should
   be automatically turned back ON if you change the search
   string (e.g. delete some chars) so that it no longer has
   multiple, contiguous w-s chars.

4. I raised a question about whether lax w-s matching should
   be automatically turned OFF if you _paste_ (not type) text
   that contains multiple, contiguous w-s chars.

TL;DR:

DWIM is hard.  It never does what everyone means, in every
context.  It's about compromises & judgment.  And it requires
good feedback about what it's doing for "free".  DWIM behind
a user's back always bites someone, in the end. ;-)

Hope this clears things up a bit.

bug#22494: still can't search for two spaces

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Really? Always? I wouldn't have a problem with that (except if you mean for
> it to apply also to regexp search). But those who are fans of lax whitespace
> search might not like it.

> Today, not only is lax whitespace matching a possibility, but it is the
> default for C-s. What you suggest would mean that even with lax w-s
> matching, search should first look for an exact match, before finding a lax
> match (i.e., even if that lax match came before the literal match).

Sorry, I wasn't entirely clear: I meant, if the user enters a search string
which contravenes the notion of lax matching, such as two spaces. In the same
way that we do for case folding.

> 1. I agree (!) with the proposal to automatically turn OFF
>    lax w-s search if you type multiple, contiguous w-s chars.

Yay!

> 2. I proposed that when that happens we clearly indicate the
>    change to users.

I'm fine with that too.

> 3. I raised a question about whether lax w-s matching should
>    be automatically turned back ON if you change the search
>    string (e.g. delete some chars) so that it no longer has
>    multiple, contiguous w-s chars.

I wonder about this too.

> 4. I raised a question about whether lax w-s matching should
>    be automatically turned OFF if you _paste_ (not type) text
>    that contains multiple, contiguous w-s chars.

I think it should be, as with typing them.

> DWIM is hard. It never does what everyone means, in every context. It's
> about compromises & judgment. And it requires good feedback about what it's
> doing for "free". DWIM behind a user's back always bites someone, in the
> end. ;-)
>
> Hope this clears things up a bit.

Yes, very much, thanks Drew!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22494: still can't search for two spaces

[Drew Adams]

> > 4. I raised a question about whether lax w-s matching should
> >    be automatically turned OFF if you _paste_ (not type) text
> >    that contains multiple, contiguous w-s chars.
> 
> I think it should be, as with typing them.

Maybe.  But it's easy to copy some text (e.g. non-code) from
some external source (not Emacs), and search for it (by yanking).

You might not even know whether it contains more than one
whitespace char in a row.  And if it does, I'm guessing that
some users might be surprised to see lax whitespace matching
turned off after the yank.

Not a big deal, as long as they are clearly notified, in a
way that they understand _why_ the search mode has changed
(e.g. the search string now contains more than one w-s char
in a row).

But I still have the question of what the right approach is.
There are different possibilities, when someone yanks some
text to add to the search string, regarding the intention
wrt searching for whitespace.

My guess is that whatever behavior we choose some users will
be confused.  This just underlines the importance of letting
the user know (a) that a change in behavior has taken place
and (b) why it has.

bug#22494: still can't search for two spaces

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 02 Feb 2016 22:45:41 -0800
> Cc: 22494@debbugs.gnu.org, mbork@mbork.pl, rms@gnu.org, jidanni@jidanni.org
> 
> If the user types something into the search string, and exactly that something
> is present in the buffer, Emacs should locate it before any "lax" variant.

Of course, with the way it works in Emacs, there's no "before".
There's either this or that: either Emacs finds only the literal
matches, or it finds both literal and lax matches.  If the latter, the
first literal or lax match after point will be the first one found,
even if it's a lax match and there's a literal match farther away.

bug#22494: still can't search for two spaces

[Nicolas Richard]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>
>> Heeding what is in the search string means nothing - or anything.
>
> I don't know why you're saying this Drew.
>
> If the user types something into the search string, and exactly that something
> is present in the buffer, Emacs should locate it before any "lax" variant.

That looks like setting lax-ws to nil by default but turning it on
automatically if there's no match. One question is which one(s) of those
lax-foo options should be turned on first ?

-- 
Nicolas

bug#22494: still can't search for two spaces

[積丹尼 Dan Jacobson]

I still can't search for two spaces with C-s SPC SPC.
It still just sits on the first match for single space.

(emacs-version)"GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.6)
 of 2016-01-23 on x86-csail-01, modified by Debian"

bug#22494: still can't search for two spaces

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@jidanni.org>
> Date: Sat, 30 Jan 2016 14:34:12 +0800
> 
> I still can't search for two spaces with C-s SPC SPC.
> It still just sits on the first match for single space.

Crystal ball says you didn't read the manual, which explains that you
need to type M-s SPC after C-s to get what you want (which is literal
space matching).  If you want this to be a permanent setting, there's
a variable to customize, also described in the manual.

bug#22494: still can't search for two spaces

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I still can't search for two spaces with C-s SPC SPC.
  > > It still just sits on the first match for single space.

  > Crystal ball says you didn't read the manual, which explains that you
  > need to type M-s SPC after C-s to get what you want (which is literal
  > space matching).

This is a bug.  When the user types SPC SPC in a search string,
person clearly wants to search for two spaces.  It should do that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22494: still can't search for two spaces

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> This is a bug. When the user types SPC SPC in a search string, person
> clearly wants to search for two spaces. It should do that.

Yes, exactly in the same sense that we disable case folding if mixed case is
used in a search string.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22494: still can't search for two spaces

[Drew Adams]

> > This is a bug. When the user types SPC SPC in a search string, person
> > clearly wants to search for two spaces. It should do that.
> 
> Yes, exactly in the same sense that we disable case folding if mixed case is
> used in a search string.

1. We do both, yes.  But I see no logical connection between those
two design decisions.  Neither of them implies or supports the other.

2. Here's another consideration that might apply to whether we
automatically switch to literal whitespace search due to multiple,
contiguous whitespace chars (and yes, you could argue similarly wrt
automatic turn-off of case-folding):

If a user _types_ additional whitespace chars then it is
reasonable to assume that literal search is what is intended.

But if a user _pastes_ some copied text that includes multiple,
contiguous whitespace chars, then such an assumption is less
reasonable.

The intention might depend on where the text was copied from, etc.
It's really hard to guess whether the user intended to respect the
copied whitespace literally - or even whether s?he is aware that
there are multiple, contiguous whitespace chars in the pasted text.

bug#22494: still can't search for two spaces

[積丹尼 Dan Jacobson]

>>>>> "DA" == Drew Adams <drew.adams@oracle.com> writes:

DA> What is not obvious is whether whitespace search should be
DA> changed away from literal matching just because there are
DA> not (no longer) multiple such chars in a row in the search
DA> pattern.  That was the subject of the text you quoted.

All I know is an Auntie Nelda-like person (me) typed those two spaces
and expected them to match. I don't know about all that other stuff.

bug#22494: still can't search for two spaces

[Drew Adams]

> All I know is an Auntie Nelda-like person (me) typed those two spaces
> and expected them to match. I don't know about all that other stuff.

I, at least, have agreed with you and your Auntie Nelda.
And I think that Richard has also agreed about this.

FWIW, I said so (in emacs-devel@gnu.org) before Isearch was changed
to provide lax whitespace search as a possibility, and I opposed
(unsuccessfully) making it the default behavior.

For me, as for your Auntie Nelda also, it seems, literal search is
clearest as a default behavior for C-s.  I disagree that C-s should
default to a "handy", Emacs-knows-what-you-really-want/need behavior.

bug#22494: still can't search for two spaces

[積丹尼 Dan Jacobson]

>>>>> "DA" == Drew Adams <drew.adams@oracle.com> writes:

DA> I, at least, have agreed with you and your Auntie Nelda.

Besides, if the user is using emacs -nw then one can't tell if he pasted
or typed anyway...