Re: Interpretation of a space in regexp isearch?

[Davis Herring]

>> Unless you filled a paragraph (perhaps via auto-fill-mode) and don't
>> remember doing so.
> 
> ?
> 
> Perhaps you mean filling with justification, so there can be stretches of
> multiple SPC chars?  Or perhaps you are referring to `SPC SPC' after a period?
> Sorry, I don't see the problem you are hinting at.

Because you typed a space between two words, but it eventually became a
newline (and possibly indentation).

> You would search for that anytime you would search for it. ;-)  Try searching
> your own message for `a b', for instance - that's `a', `SPC', `b'.
> 
> Honestly, it is silly to suppose that users never or rarely want to search 
> for a
> set number of SPC chars, including for just one SPC.  Especially programmers.

What is silly is a file that contains (for a fixed ?a and ?b) so many "a
 b" substrings that C-s-ing through them to find your desired "a b"
instance is troublesome.

>> Is "let's add an isearch toggle key" what you meant by "We've been
>> through this before"?
> 
> No.  I have a vague recollection that we have discussed before whether Isearch
> should search for only a single SPC when you type a SPC.  I do not have a
> reference for you, however.

The "through this before" I hinted at was "you often argue for
additional toggle keys in isearch".  It was a bit of a poke, nothing
important.

> And yet we still have SPC being magic for regexp search, don't we?  Even 
> though
> it is simple enough to use \s-+, and it always has been.

That's why all the +1s in this thread have been for moving the magic (by
default) to the non-regexp case where this trick doesn't work.

> I recognize that SPC acting "magically" can be useful whatever the search 
> mode.
> Apparently you do not.

I see it as so useful in the simple case that it can merely be
customizable, not "togglable".

In the regexp case, it is not always useful, but it's already easy to
change, so I again need no toggle key for it.  Either I customize it on,
and I can use C-q SPC as needed, or I customize it off, and I can use
\s-+ as needed.

> But you are comparing apples and orangutans.  C-q does not toggle the search
> mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an
> otherwise magic-space sea.

With the default set to "more magic", C-q gets you "no magic", same as
your toggle would.  Your toggle would work the other way too, but as I
said I don't feel the need for the other way (often enough for an
isearch key).

> If [one occurrence] is what you're saying, it is a red herring, Mr Herring.  
> That same
> situation exists both today and with the proposal from Yidong.
> 
> That is a difficulty for simple search whether magic is off or on: One cannot
> easily match both a stretch of whitespace and a single SPC (as opposed to a
> stretch) in the same search string.  It is inherent to simple search - that 
> use
> case cries out for regexp search instead.

With magic C-s, you can easily match it with appropriate C-q.  The
toggle would only be a win for a search string like
"lots_of_words_like_foo_bar_baz quux quoo frobozz bandersnatch cupcake"
where the _ represents a magic space and the spaces are not magic.  If
the string is instead "alternating words_with different_kinds
of_spaces", the toggle will be twice as expensive as C-q.  (I have no
idea which one of these is more likely; neither seems terribly common.)

>>> * Users can set the variable value in their init files, if
>>>   they want to change the default (i.e., initial) behavior.
>>
>> Er, yes?
> 
> Yes?
> 
> Dunno what is unclear here.  The point is that you and I can each start out 
> with
> the behavior we want.

That users can customize Emacs is so obvious as to render that text
distracting.  It's not important.

> Today, the _code_ decides in a hard-coded way that regexp search uses
> magic-space and simple search does not.  Yidong proposes the opposite - but
> still hard-coding.  And I guess you are agreeing with that proposal.

The current code decides that regexp search has a custom option (which
is of course much heavier when it is not key-accessible), and that
simple search has no choice at all.  Yidong's proposal (given obvious
backward-compatibility obligations and standard customizability ideas)
would surely be to change the default for the existing variable and add
`search-search-whitespace-regexp' or so that controlled C-s, defaulted
to the current default for `search-whitespace-regexp'.  Given the rarity
(IMO) of caring about searching for single spaces in a simple search (as
would justify having quick access to both modes within simple search),
and the relative ease of making a regexp search do whatever you want
regardless of the value of `search-whitespace-regexp', I find no problem
with this proposal.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.