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

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

> > Here's a suggestion on how verbose toggles could be done,
> > following Kaushal's previous mention of multi-line echo areas.
> > It shows the state of all toggles on a line above the prompt. This
> > is given the usual `minibuffer-prompt' face and it stays fixed while
> > the user is typing/searching, so it's not a distraction.
> 
> An alternative idea is not to show _any_ toggles, and provide a
> separate key to display it if the user so wants.

1. I'm glad that we are thinking this over.  This, together with
   practical experience (e.g., using the new char folding feature),
   is exactly what will help us find a good UI for this.  Now is
   a good time for some blue-sky ideas, and with more experience
   we will get better ideas and code suggestions.

2. IMO, this is not only about "showing toggles".  It is about
   both (1) indicating the current search state attributes and
   (2) providing toggles for them.

   Examples of such attributes:

    . whether search is regexp or literal (or other, in future?)
    . which foldings are in effect (each is a separate attribute)
    . whether search has wrapped or overwrapped
    . whether search is multi-buffer (and maybe which buffer is next)

   We want to be able to show such things either (a) on demand or
   (b) directly-&-always.  And we want to give users a way to
   toggle each attribute individually (toggle if binary, cycle if
   multi-valued).

3. Another suggestion for this is to have the mode-line lighter
   do both of the following:

   a. Indicate a few of the aspects of the state directly.
      I gave the example of `Isearch' vs `ISEARCH' for case
      sensitivity.  Wrapping and overwrapping can be indicated
      using an overline and an overline and underline, respectively.
      (See attachments.)  Regexp search might be shown as `Rsearch'
      (and `RSEARCH') or as `Isearch*' (and `ISEARCH*').

      The point is to keep it fairly simple and clear, and not to
      try to make the lighter do too much - not to use char codes
      for each state attribute, for example.

   b. Rather than showing each of the current attributes of the
      search state explicitly and directly, and enabling them as
      toggle/cycle buttons, just present them in the lighter menu
      (together with their key bindings, of course).

      Currently, the lighter menu for Isearch is just this, which
      is not very useful (which BTW is capitalized inconsistently):
        * Turn Off minor mode
        * Help For minor mode
      It would be better to put it to good use, including showing
      all attributes of the current search state and provided
      toggles for them.

   I think this would show users at all times the most important
   aspects of the search state, and it would give them quick
   access to more info about the state as well as a way to change
   attributes individually.

   All of this is easy to implement, I believe.  If there is
   interest I can throw together a patch.  But it's better at
   this stage to discuss more, I think.  More and better ideas
   are surely still to come.

[-- Attachment #2: throw-isearch-case-insensitive.png --]
[-- Type: image/png, Size: 1846 bytes --]

[-- Attachment #3: throw-isearch-wrapped.png --]
[-- Type: image/png, Size: 1719 bytes --]

[-- Attachment #4: throw-isearch-overwrapped.png --]
[-- Type: image/png, Size: 1722 bytes --]

[-- Attachment #5: throw-isearch-case-sensitive.png --]
[-- Type: image/png, Size: 1691 bytes --]

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

[Drew Adams]

> a. Indicate a few of the aspects of the state directly.
>    I gave the example of `Isearch' vs `ISEARCH' for case
>    sensitivity.  Wrapping and overwrapping can be indicated
>    using an overline and an overline and underline, respectively.
>    (See attachments.)  Regexp search might be shown as `Rsearch'
>    (and `RSEARCH') or as `Isearch*' (and `ISEARCH*').

You can try it out, to get an idea, by loading isearch+.el:
http://www.emacswiki.org/emacs/download/isearch%2b.el

(That will also make other changes to Isearch, but at least
you can see the above suggestion.)

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

>    We want to be able to show such things either (a) on demand or
>    (b) directly-&-always.  And we want to give users a way to
>    toggle each attribute individually (toggle if binary, cycle if
>    multi-valued).

Do we want to go down this path?


[-- Attachment #2: search.png --]
[-- Type: image/png, Size: 42461 bytes --]

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

[Drew Adams]

> >    We want to be able to show such things either (a) on demand or
> >    (b) directly-&-always.  And we want to give users a way to
> >    toggle each attribute individually (toggle if binary, cycle if
> >    multi-valued).
> 
> Do we want to go down this path?

IMO, no.  I made that point when I said that that is the kind of
UI that other apps use, and which can allow you to unambiguously
search, for example, for `foo' only within a code segment (e.g.
inline code) and not within the accompanying text - or vice versa.

We should (and we do) provide the same power from the keyboard,
with interactive search.  (I have nothing against *also* offering
a dialog-box interface, but that should not be the main approach
or the goal.)

What I meant in the text cited is that we can indicate the exact
current search state and let users modify it interactively:

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.

   With multiple state qualities (and we already have a few), it can
   be more useful to provide a state-info key that shows you more
   info on demand.

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.  We can easily show
   case, regexp, wrapping, and overwrapping now - you can see an
   example in Isearch+.

3. Toggling of individual state attributes.  One suggestion is to
   use the lighter (minor mode) menu for this.  For those who
   want to use the keyboard and not bother with a menu, we can
   provide toggle keys - put them all on the same prefix key, for
   instance.  (And of course the menu would show the keys bound
   to the same actions.)

   Another suggestion wrt individual toggles was to have a one-char
   button for each in the mode line.  This would not be my choice,
   I think, but it is another possibility.

In sum, I'd suggest that we stick close to the traditional Emacs
design: provide keyboard toggle keys, pop up info windows, etc.
And I'd suggest using the lighter to (a) indicate some state and
(b) provide a menu that gives you more info and lets you change
state.

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

[Eli Zaretskii]

> Date: Mon, 29 Jun 2015 15:26:53 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, bruce.connor.am@gmail.com,
>         kaushal.modi@gmail.com, stephen@xemacs.org, emacs-devel@gnu.org,
>         monnier@iro.umontreal.ca
> 
> 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?

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

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

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

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

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  stephen@xemacs.org,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca
> Date: Tue, 30 Jun 2015 01:03:53 +0300
> 
> >    We want to be able to show such things either (a) on demand or
> >    (b) directly-&-always.  And we want to give users a way to
> >    toggle each attribute individually (toggle if binary, cycle if
> >    multi-valued).
> 
> Do we want to go down this path?

Maybe we do.  Are there good alternatives, when there are so many
non-orthogonal options?

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

[Oleh Krehel]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Do we want to go down this path?
>
> Maybe we do.  Are there good alternatives, when there are so many
> non-orthogonal options?

I have a good alternative for swiper.el (my isearch-replacement package
in GELPA).

Unlike the current isearch, which recently started displaying
"Char-fold I-search: " instead of the much better default "I-search: ",
swiper displays only "97 pattern: ", where "97" is the current number
of matches.

To see more options, I can press "C-o" to bring up a hydra - a keyboard
oriented menu, which is also a package of mine in GELPA. Pressing "C-o"
again hides this information.

I attach 3 screenshots.
First one: I only press "C-s" (`swiper') to get a minimal interface.
Second one: I press "C-o" to show me the options panel, which also
doubles as a command-mode:

- "C-n" becomes "j"
- "C-p" becomes "k"
- "M-<" becomes "h"
- "M->" becomes "l"

It's possible to toggle the matching function with "m", and the state
will be re-displayed to let the user know that the matcher has changed.
It's possible to re-size the minibuffer with "<" and ">".

Third one: I've re-sized the minibuffer to become smaller with "<<" and
changed the matcher to fuzzy with "m" (notice the number of candidates
grew from 97 to 543).

I could now dismiss the menu with "i" or "C-o" and go back to a minimal
interface, with the changes that I made.


[-- Attachment #2: swiper-example-1.png --]
[-- Type: image/png, Size: 101843 bytes --]

[-- Attachment #3: swiper-example-2.png --]
[-- Type: image/png, Size: 103119 bytes --]

[-- Attachment #4: swiper-example-3.png --]
[-- Type: image/png, Size: 97132 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1378 bytes --]


I'd like to also emphasize that the whole menu string is displayed with
the `lv-message' function, which mirrors `message', except it uses an
equivalent of the Echo Area above the actual Echo Area.  This removes
the drawback of the 2-second delay whenever new messages need to be
displayed in the minibuffer, and also it doesn't get overwritten by
other messages.

Hydra has a pretty easy interface, similar to `easy-menu-define', to
define this menu (here ^ are just alignment chars):

(defhydra hydra-ivy (:hint nil
                     :color pink)
  "
^^^^^^          ^Yes^     ^No^     ^Maybe^
^^^^^^^^^^^^^^---------------------------------------
^ ^ _k_ ^ ^     _f_ollow  _i_nsert _c_: calling %s(if ivy-calling \"on\" \"off\")
_h_ ^+^ _l_     _d_one    _o_ops   _m_: matcher %s(if (eq ivy--regex-function 'ivy--regex-fuzzy) \"fuzzy\" \"ivy\")
^ ^ _j_ ^ ^     ^ ^       ^ ^      _<_/_>_: shrink/grow window
"
  ;; arrows
  ("h" ivy-beginning-of-buffer)
  ("j" ivy-next-line)
  ("k" ivy-previous-line)
  ("l" ivy-end-of-buffer)
  ;; actions
  ("o" keyboard-escape-quit :exit t)
  ("C-g" keyboard-escape-quit :exit t)
  ("i" nil)
  ("C-o" nil)
  ("f" ivy-alt-done :exit nil)
  ("C-j" ivy-alt-done :exit nil)
  ("d" ivy-done :exit t)
  ("C-m" ivy-done :exit t)
  ("c" ivy-toggle-calling)
  ("m" ivy-toggle-fuzzy)
  (">" ivy-minibuffer-grow)
  ("<" ivy-minibuffer-shrink))

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

[Drew Adams]

> > Do we want to go down this path?
> 
> Maybe we do.  Are there good alternatives, when there are so many
> non-orthogonal options?

Being able to call up such a dialog box, to set several attributes
at once for the current context (i.e., as opposed to setting a
static and persistent user option), is a plus.  Just as it is
for setting the default attribute preferences (i.e., one or more
user options).

But such a dialog box should not be the only way to change
individual attribute values.  That can be done quickly using
toggle commands and/or toggle menu items.

Being able to change multiple search attributes at once, as in
a dialog box is useful.  So is being able to quickly change any
of them individually.

When you say "non-orthogonal", presumably you are suggesting that
changing one attribute automatically either changes some others
or restricts some others.  Which such search attributes did you
have in mind?

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

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

> When you say "non-orthogonal", presumably you are suggesting that
> changing one attribute automatically either changes some others
> or restricts some others.  Which such search attributes did you
> have in mind?

I don't know which eli had in mind but:
Word search is non orthogonal to symbol search (I guess they're different
values of the same attribute).
Char folding, word/symbol searching, and regexp searching are all non
orthogonal due to implementation details.

[-- Attachment #2: Type: text/html, Size: 566 bytes --]

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

[Drew Adams]

>> When you say "non-orthogonal", presumably you are suggesting that
>> changing one attribute automatically either changes some others
>> or restricts some others.  Which such search attributes did you
>> have in mind?
>
> I don't know which eli had in mind but:
> 
> Word search is non orthogonal to symbol search (I guess they're
> different values of the same attribute).

If they are different values of the same attribute then this is
not a case of non-orthogonal attributes.  Cycling among the values
of that attribute (or choosing one of the values in some other way)
should be sufficient.

> Char folding, word/symbol searching, and regexp searching are all
> non orthogonal due to implementation details.

Please elaborate.  Search is either literal or regexp (and we can
add other pattern-matching search types).  Again, different values
of the same attribute.  Word/symbol/whatever: see above.

Char folding?  Do you mean that if you are folding wrt one
equivalence class then either you cannot also be folding wrt
another class or folding of the other changes somehow?  Please
explain.

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

[Artur Malabarba]

>> Char folding, word/symbol searching, and regexp searching are all
>> non orthogonal due to implementation details.
>
> Please elaborate.  Search is either literal or regexp (and we can
> add other pattern-matching search types).  Again, different values
> of the same attribute.  Word/symbol/whatever: see above.
>
> Char folding?  Do you mean that if you are folding wrt one
> equivalence class then either you cannot also be folding wrt
> another class or folding of the other changes somehow?  Please
> explain.
I mean they're not orthogonal with respect to each other (in the
current implementation). That is:
If you turn on word or symbol search, it turns off regexp searching
and char folding.
If you turn on char folding, it turns off regexp, word and symbol searching.
If you turn on regexp, it turns off char-folding, and word and symbol
and searching.

This is not a fundamental limitation, they're not different values of
the same option. This is a consequence of the current implementation.

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

[Eli Zaretskii]

> Date: Mon, 29 Jun 2015 21:39:23 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: drew.adams@oracle.com, bruce.connor.am@gmail.com, kaushal.modi@gmail.com,
>         stephen@xemacs.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> 
> But such a dialog box should not be the only way to change
> individual attribute values.

I still don't understand why not.  We do use something similar in
Customize buffers.

> That can be done quickly using toggle commands and/or toggle menu
> items.

How is menu different from a dialog (to which you objected, AFAIU)?

> Being able to change multiple search attributes at once, as in
> a dialog box is useful.  So is being able to quickly change any
> of them individually.

The dialog doesn't require that you change all of them, so I don't see
any contradiction.

> When you say "non-orthogonal", presumably you are suggesting that
> changing one attribute automatically either changes some others
> or restricts some others.  Which such search attributes did you
> have in mind?

Searching for regexps, words, and symbols are at least somewhat
exclusive.  Similarly the various folding options.

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

[Drew Adams]

> > But such a dialog box should not be the only way to change
> > individual attribute values.
> 
> I still don't understand why not.  We do use something similar in
> Customize buffers.

Why should it be the only way?  Why shouldn't you be able to hit
a key, as you do now, to toggle case sensitivity?  Why should you
be required to open a dialog box and make a change there, just to
toggle case sensitivity?

I see nothing wrong with providing users, as we have long done
for case sensitivity, with some simple toggle keys.  Nothing
obliges us to provide a toggle/cycle key for each search attribute.
But nothing should prevent us from providing any that we think are
useful/important.

The Customize UI is OK for what it is used for.  It is hardly a
model that we should adopt as the *only* way to modify search
behavior on the fly.

> > That can be done quickly using toggle commands and/or toggle menu
> > items.
> 
> How is menu different from a dialog (to which you objected, AFAIU)?

I did not object, as I've said multiple times now.  Are you
listening?  It's not all-or-none, one-or-the-other, black-or-white.

Ask yourself why we have an `Options' menu in addition to Customize?
Or why we have the key binding `C-\' in addition to menu item
Options > Multilingual Environment > Toggle Input Method?

> > Being able to change multiple search attributes at once, as in
> > a dialog box is useful.  So is being able to quickly change any
> > of them individually.
> 
> The dialog doesn't require that you change all of them, so I don't
> see any contradiction.

You are inventing claims of contradiction.  You seem to want to see
things in black&white terms, all or nothing.

Being able to hit `M-c' during Isearch is a quick way to toggle
case sensitivity.  That doesn't mean that you shouldn't be able
to use a dialog box instead to do that, if you prefer.  Why make
addition of the latter exclude the possibility of the former?

> > When you say "non-orthogonal", presumably you are suggesting that
> > changing one attribute automatically either changes some others
> > or restricts some others.  Which such search attributes did you
> > have in mind?
> 
> Searching for regexps, words, and symbols are at least somewhat
> exclusive.  Similarly the various folding options.

See what I wrote.  Regexp, word, and symbol search (and other
possibilities perhaps to come) are exclusive, just as case-folding
on and case-folding off are exclusive.  Because they are exclusive,
they can be cycled as values of the same search attribute.

So OK, they are not orthogonal.  But yes, because of the way in
which they are not orthogonal choosing one or the other is simple.
We don't _require_ a dialog box to handle this non independence.

Your question wrt using a dialog box was this: "Are there good
alternatives, when there are so many non-orthogonal options?"

Groups such as {Regexp, word, symbol} do not present a conundrum
that requires a dialog box as its solution.

But again, I repeat that it is not about choosing between two
exclusive alternatives: dialog box vs something else.  We can
have a dialog box for heavy lifting (and also for light lifting,
for those who prefer it), and we can also have alternatives for
light lifting - e.g., toggling or cycling a search attribute.

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.

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

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 10:14:14 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> 	kaushal.modi@gmail.com, stephen@xemacs.org, juri@linkov.net
> 
> You seem to be trying to pick a fight, BTW.

Not anymore.

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

[Artur Malabarba]

2015-06-27 23:48 GMT+01:00 Juri Linkov <juri@linkov.net>:
> Whether to display verbose indicators (like currently are used, e.g.
> “Regexp I-search”) or 1-letter cryptic ones (e.g. “I-search(r/c/')”
> like in C-mode with its indicators such as “C/lahw”) is a matter of taste
> and could be customizable.

Here's a suggestion on how verbose toggles could be done, following
Kaushal's previous mention of multi-line echo areas.
It shows the state of all toggles on a line above the prompt. This is
given the usual `minibuffer-prompt' face and it stays fixed while the
user is typing/searching, so it's not a distraction.

-------- the usual modeline here ---------
case-fold: ON   regexp: OFF  word: ON   symbol: OFF  lax-space: ON
char-fold: OFF  invisible: ON
Isearch:

We can discuss which toggles to display by default, of course, this is
just an example.

---
 lisp/isearch.el | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 45c6d97..b0f4321 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2521,6 +2521,26 @@ If there is no completion possible, say so and
continue searching."
          (isearch-message-suffix c-q-hack)))
     (if c-q-hack m (let ((message-log-max nil)) (message "%s" m)))))

+(defcustom isearch-show-toggles t
+  "Non-nil means to list options above input prompt."
+  :type 'boolean
+  :version "25.1")
+
+(defun isearch--describe-toggles ()
+  "Return a propertized description of isearch toggles."
+  (concat
+   (mapconcat (lambda (x) (propertize (concat (car x) ": " (if (cadr
x) "ON " "OFF"))
+                                 'face 'minibuffer-prompt))
+              `(("case-fold" ,isearch-case-fold-search)
+                ("regexp"    ,isearch-regexp)
+                ("word"      ,(eq isearch-word t))
+                ("symbol"    ,(eq isearch-word #'isearch-symbol-regexp))
+                ("lax-space" ,isearch-lax-whitespace)
+                ("char-fold" ,(eq isearch-word #'character-fold-to-regexp))
+                ("invisible" ,isearch-invisible))
+              "  ")
+   "\n"))
+
 (defun isearch-message-prefix (&optional ellipsis nonincremental)
   ;; If about to search, and previous search regexp was invalid,
   ;; check that it still is.  If it is valid now,
@@ -2569,8 +2589,9 @@ If there is no completion possible, say so and
continue searching."
             (concat " [" current-input-method-title "]: "))
              ": ")
            )))
-    (propertize (concat (upcase (substring m 0 1)) (substring m 1))
-        'face 'minibuffer-prompt)))
+    (concat (when isearch-show-toggles (isearch--describe-toggles))
+            (propertize (concat (upcase (substring m 0 1)) (substring m 1))
+                        'face 'minibuffer-prompt))))

 (defun isearch-message-suffix (&optional c-q-hack)
   (concat (if c-q-hack "^Q" "")
-- 
2.4.4

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

[Eli Zaretskii]

> Date: Sun, 28 Jun 2015 11:47:22 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>,
> 	"Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Kaushal <kaushal.modi@gmail.com>
> 
> Here's a suggestion on how verbose toggles could be done, following
> Kaushal's previous mention of multi-line echo areas.
> It shows the state of all toggles on a line above the prompt. This is
> given the usual `minibuffer-prompt' face and it stays fixed while the
> user is typing/searching, so it's not a distraction.

An alternative idea is not to show _any_ toggles, and provide a
separate key to display it if the user so wants.

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

[Kaushal]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Thanks for the implementation! I'll check it out tomorrow.

--
Kaushal Modi
On Jun 28, 2015 10:37 AM, "Eli Zaretskii" <eliz@gnu.org> wrote:

> > Date: Sun, 28 Jun 2015 11:47:22 +0100
> > From: Artur Malabarba <bruce.connor.am@gmail.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>,
> >       "Stephen J. Turnbull" <stephen@xemacs.org>,
> >       Stefan Monnier <monnier@iro.umontreal.ca>, Kaushal <
> kaushal.modi@gmail.com>
> >
> > Here's a suggestion on how verbose toggles could be done, following
> > Kaushal's previous mention of multi-line echo areas.
> > It shows the state of all toggles on a line above the prompt. This is
> > given the usual `minibuffer-prompt' face and it stays fixed while the
> > user is typing/searching, so it's not a distraction.
>
> An alternative idea is not to show _any_ toggles, and provide a
> separate key to display it if the user so wants.
>

[-- Attachment #2: Type: text/html, Size: 1569 bytes --]