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

[Drew Adams <drew.adams@oracle.com>]

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