[Top][All Lists]

[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, 29 Aug 2012 09:01:33 -0700

> > But let's not sacrifice some char (e.g. nobreak-space), so that its
> > use in a search string means something special, not 
> searching for itself.
> The space character is special to indicate whitespace.
> We need another special character

IMO, you are too liberal with the "we need"s.

> to indicate literal space in non-regexp searches.

I don't buy the assumption that we need a "special char" to indicate a literal
space in a non-regexp search.

Toggling this new mode on/off should suffice for most simple searches where you
want to search for literal SPC chars.

For the remainder, i.e., simple searches where both literal spaces and
magic-whitespace are searched for in the same search string, I would say that
users should take one of these approaches:

1. use regexp search instead (seriously)
2. use C-q (or perhaps C-u?) to escape the following character to be treated

#2 might require some work by Emacs Dev.

> Could you find a better character than nobreak-space?

Sorry, I don't buy the claim that "we need another special character to indicate
literal space in non-regexp searches."


Look, we could be doing this kind of thing for other magic search strings also.
Essentially the idea is to come up with a shortcut (for typing and visibility)
for a regexp (or other complex searching pattern/mechanism) that is used often,
for common matches.

A second part of the idea is to hide the fact that such complex searching is
involved - whether for simple or regexp searching.

If a user knows that s?he is doing regexp search, then any shortcut "mode" that
enables the user to, say, type only `(' instead of `\(', can be turned on/off
with a toggle.  Yes, sure, we need to define each mode state completely, e.g.,
how to indicate a literal `(' when `(' means what `\(' means in the opposite
mode state.

I proposed long ago, for instance, a toggle for a `.' in regexp search to match
also newlines, i.e., any character.  IOW, `.' in one mode state of the toggle,
`.' would be equivalent to "\\(.\\|[\n]\\)" in the other (traditional) state.

I still think that particular enhancement would be helpful.  I've used it in
Icicles for years, and it is very handy, IMO.  I use text properties so the user
(optionally, and by default) sees only `.' when s?he types `.', but in fact what
is used is the regexp that matches also \n.

Such a magic, multi-line dot is (optionally) highlighted in the minibuffer, so
you can distinguish it.  And you can hit a key to toggle the state.  And you can
hit another key to toggle whether the `.' is shown as `.' or as its underlying
regexp.  When such a multi-line dot is present in the minibuffer, editing treats
it as a single char; e.g., it DTRT when you delete or transpose chars.

How do I deal with the case of mixing multi-line and ordinary dots in the same
minibuffer input (analog to a search string)?  A prefix arg to `.' flips it from
its usual behavior (whether multi-line or normal/literal) to the opposite.  We
_might_ want to do similarly for Isearch.

Here is a bit more explanation.

Consider that food for thought.  I'm not actively suggesting that the same
approach should be used for Isearch, or that it is "the answer".

My point here is:

1. The motivation for the current magic whitespace discussion can be generalized
to other magic chars or SOMETHING-ignoring modes.  So the discussion should
perhaps be more general also.

2. Sacrificing a "special char" (e.g. nobreak-space) for this kind of thing is
the wrong approach, IMO.

I would also add that whenever we do something like this that hides what's
really going on from the user, as a convenience, there is the possibility of
confusion and complication.  So we had better enable users to alternatively SEE
what is otherwise hidden.

A toggle to show the ugly, underlying stuff as part of the search string is
helpful to users.  For one thing, it can help them understand why what they
think they are searching for might not be what they are really searching for.
It gives them a means to investigate and learn more.

reply via email to

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