emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Interpretation of a space in regexp isearch?


From: Drew Adams
Subject: RE: Interpretation of a space in regexp isearch?
Date: Wed, 15 Aug 2012 09:43:24 -0700

> > By default, "magic-space" searching should be OFF for both 
> > simple and regexp search.  Each SPC you type should search
> > for a single SPC, by default.  Simple.  No surprise.
> 
> 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.

The behavior of SPC meaning to search for a single SPC char is pretty common in
other editors (from TextPad to MS Word).  And it has always been the default
behavior for simple search in Emacs as well.  How is it surprising?

> If you're searching just for a space, the only differences 
> will be...

We know what the differences are.

> Why would you even care?  Sure, if you're searching for
> "a b" you'll find "a  b",

You answered your own question.

> but when would you search for that, caring about missing
> the latter, and not be using a regexp (as to find sentences
> with only one space separating them)?

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.

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

> > * Treat both simple and regexp search the same way.
> 
> In regexp search, you can choose between \s-+ and SPC -- that's why so
> many have said just now that this magic is appropriate for C-s and not
> C-M-s.

Yes, I realize that.

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.

If people have in the past thought that SPC being magic in regexp search was
handy (and yes, it can be easier to hit `SPC' than to type `\s-+', especially
for multiple such in a long regexp), then their arguments still apply.

And yes, "so many" clearly have thought that in the past, including Richard.
The magic-space behavior for regexp search is at least as old as Emacs 20.

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

* I do not see magic-space SPC as something that is useful ONLY for
  regexp search (the current and traditional approach).  And I do not
  see it as useful ONLY for simple search (which you seem to be arguing).

* I do not see literal-space SPC as something that is useful ONLY for
  regexp search (which you seem to be arguing).  And I do not see it as
  useful ONLY for simple search (the current and traditional approach).

Each SPC-search mode can be useful for both simple and regexp search, IMO.

> > * Have a toggle key that flips the Boolean value.
> >   The new value stays in effect (including in future
> >   searches for the same session) until flipped again.
> >   (Some candidates for the key: `M-SPC', `M-s SPC'.)
> 
> How is M-SPC any easier than C-q?

No one said it was.

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.

> (This is an argument for having the default be "on" for this magic;

It's not much of an argument, AFAICT.

I don't care much whether the _default_ default is on or off.  If users can set
the default SPC-search mode themselves, and if they have a simple way to toggle
the mode, then a discussion about what the _default_ default behavior should be
amounts to much ado about nothing.

> otherwise you need a way to summon it for one use and C-q
> doesn't fit there.)

Not sure what you mean by "one use".  Do you mean one search or one occurrence
in a search string that also has other occurrences of SPC?

If the former, then the answer is to toggle (and then toggle again when that
one-off search is over).  A quick toggle is perfect for a one-off search in the
other mode.

If the latter, then I guess you are saying that if magic-space search is off
(why talk about the _default_ here?) then in simple search it is hard to search
for _both_ a contiguous stretch of whitespace and a single SPC (or a given
number N of SPC chars) in the same search string.

If that's 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.

As such, this has nothing to do with what the default behavior should be.  But
as I say, I really do not care much what the default behavior is, as long as
users can set their own default behavior and toggle the behavior on the fly.

> As always, adding keys to isearch reduces the set you can use on exit
> (M-SPC is useful here).

Blah.

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

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.

I'm saying let the user decide.  Both what the initial behavior is and on the
fly.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]