RE: Displaying the state of isearch toggles [was Re: ASCII-folded search]

[Drew Adams]

> > I have nothing against *also* offering a dialog-box interface,
> > but that should not be the main approach or the goal.
> 
> Why not?  Is this some kind of principle, or are there specific
> arguments related to this specific feature?

Perhaps I should have said that it should not be the *exclusive*
approach or the *only* goal.  That is what I meant.  Please note
the first part of that sentence: "I have nothing against *also*
offering...."

As one who uses such dialog boxes in other apps, I can assure
you that they do not always compare well with keyboard keys
for just toggling/cycling values.

(Obviously, if there are many values then cycling, alone,
can be impractical.  Think toggle key, if you really want
to understand what I am saying.)

Dialog boxes can be good to have, but they can be a pain if
they are all that one has.

It's a bit like having to use the Customize UI to toggle
a binary value or to choose a simple enumeration value -
versus hitting a toggle key or hitting a cycle key and
choosing among those values.

As another analogy, having a key binding does not preclude
being able to use `M-x' with the command.  It is not about
having only one or the other means.

> > 1. On demand info (e.g., pop up a help window when you hit
> >    a key - either one window with all the info or separate
> >    help echoes for different keys).
> >
> >    Currently, for example, you can hit `M-c` to see the echo
> >    message telling you the (new) state wrt case sensitivity.
> >    So `M-c M-c` is a no-op that tells you the current state.
> >    That's a rudimentary way to see the case-sensitivity state,
> >    but it works, and is quick.
> 
> IMO, showing this in echo area doesn't scale: it could work for a
> few options, but not when there are a dozen of them.
> 
> A help window is free from this limitation, but it's not different
> from the dialog-type UI that you rejected, so I'm not sure what
> I'm missing here.

I didn't reject anything.  I specifically agreed that a dialog
box is useful for being able to set/change multiple search
attributes.  What I argued for are additional, and quicker,
ways to change single attributes.

It is possible to combine on-demand help with on-demand change
in the form of a dialog box - of course.  That would be like,
for example, letting `C-u C-x =' give you the possibility of
changing properties of the character that is currently at point
(e.g. add or change a text property).  I am not against such a
possibility.

> > 2. Persistent feedback showing the current state.  This is
> >    possible for at least some of the more important state
> >    qualities.  I gave some examples using the mode-line lighter.
> 
> Again, I don't see how this will scale to a situation where we have
> a dozen optional modifiers.

What part of "some of the more important" did you not understand?

Please read my previous messages, where I was the first to
note that it is unrealistic to try to indicate a multitude
of attribute states in the lighter text.

I gave examples (that I currently use) where case folding,
regexp, wrap, and overwrap are indicated are all indicated
in the lighter, to show that "some of the more important"
attributes can indeed be indicated by the lighter.

(Which are the most important is open for discussion and
can change as more possibilities are added.)

But one of my main points here, from the outset, was that
trying to show everything directly in the lighter is
problematic - just as you say now, it does not scale.
IOW, we are, I think, in agreement about that.

You seem to be trying to pick a fight, BTW.  I don't have
any argument against your adding a search dialog box.  My
argument is that I would not like to see that become the
*only* way of interacting with search (Isearch, in particular).

I will add this about a search dialog box, however: I would
not like it to be modifiable only from C code (I'm not
saying that you suggested that).

I would want users/3rd-partiers to be able to modify it
using Lisp, to add their own search state information and
their own search attributes.  This is the kind of thing
where we should facilitate experimentation & improvement.

> Will we show one letter for each, and hope the user will
> remember what each one of them means?  There simply isn't
> enough space on the mode line for that.

I believe that was one of the other suggestions, or close
to it.  And it is a suggestion that I explicitly opposed,
for the very same reasons you are mentioning now (lack of
clarity, lack of space).  Please read what I wrote.

What I did suggest along similar lines to that suggestion,
and along similar lines the the help-window/dialog-box
suggestion, was to use the mode-line *menu* (replacing the
current, useless minor-mode menu for Isearch) to provide
toggle items and items that would prompt you for one of
an enumeration of possible values (e.g. with completion,
or choosing directly from a popup list).

In sum, what I suggested was that (a) we *can* indicate
*some* attributes of the current search state directly in
the lighter, and (b) we can use the lighter *menu* to
provide access to (i) info about the others (all) and
(ii) ways to modify the others (all).

Is that an alternative to using a dialog box?  Yes.
Do I oppose *also* providing a dialog box?  No.  All I
said about a dialog box was that I would not want it to
become the *only* way that users can see or change
attributes of the current Isearch state.

> > 3. Toggling of individual state attributes.  One
> >    suggestion is to use the lighter (minor mode) menu
> >    for this.
> 
> IMO, a menu is inappropriate for turning on or off several
> independent option.

Care to say why?  Obviously, if you want to do that to
several options at the same time, then it is not ideal
(until/unless we choose to keep the menu up after each
individual change, until explicitly dismissed).

This is akin to using the menu-bar `Options' menu to
toggle options.  You can see the list (of all of those
that are shown), which provides help, and you can toggle
any of them individually.

To be clear: I do not set a menu in opposition to a dialog
box.  The mode-line lighter menu is already there, and it
is currently 100% useless for Isearch.  I think it might
not be a bad idea to put it to use this way; that's all.
That says nothing against adding a dialog box.  Clear enough?
 
> > In sum, I'd suggest that we stick close to the traditional
> > Emacs design: provide keyboard toggle keys, pop up info
> > windows, etc.
> 
> The creeping featurism in isearch way exceeds any other
> feature I know of; perhaps it's high time we admit that it
> no longer fits within "traditional Emacs design", and some
> new ideas are required.

Vague, abstract hand waving, I'm afraid.  If you want to
mention specific ways in which Isearch does not fit
"traditional Emacs design", that would probably be helpful.

And of course new ideas are welcome, and likely required.
That's what the discussion is about.  We have already seen
some new ideas.

Whether we toss everything out and create a completely new
design or we start from what we have now and evolve it, the
discussion should stick to relatively concrete problems and
features and how we might address them.

Just proclaiming that nothing works and we must start over
at the drawing board is not very constructive.  Just what
doesn't work, and why?

Of the more concrete suggestions made so far (and I hope
we are at the beginning, not the end, of such suggesting),
I'm guessing that you would like the addition of a search
dialog box.  Other than that, it's hard to see, so far,
what you might be suggesting.