unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: bruce.connor.am@gmail.com, Juri Linkov <juri@linkov.net>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: RE: Exposing Isearch toggleable options
Date: Sun, 1 Nov 2015 08:01:30 -0800 (PST)	[thread overview]
Message-ID: <1bb5e765-6599-4076-b9c7-11b416a48db7@default> (raw)
In-Reply-To: <CAAdUY-KcFtSne0fAaBTsCFOEFNiv-=QNKWtBNmUe1a8R899ukQ@mail.gmail.com>

> > Instead of the Help buffer we could open a Customizable-like buffer
> > with widget-type fields, thus in addition to *showing* the current
> > search options and info about keys to change them, also allow
> > *changing* the current search options.
> 
> Sounds like a good addition.

Not to me, it doesn't.  A widget-filled buffer is a step
backward in this context, IMO.

Isearch options/state should be togglable on the fly, using
Isearch keys.  *Help* can and should describe the options, and
it can remind users about customizing them.

The latter is not strictly needed as an extra reminder, because
simply mentioning each option in *Help* provides a link to its
detailed help, which in turn includes a link to customize it.

The tiny grain of sense in that suggestion is that Isearch can
indicate, on an ongoing basis (not just on demand, in a separate
*Help* or "Customizable-like" buffer), the current search state,
including the states of individual Isearch options.

1. Indicating the current state is one thing, and important.
2. Keys to change the current state are another thing.
3. Help reminding you about those keys is a third thing.

#1 should be indicated continually (e.g., in the mode-line),
at least for the most important aspects of the state.

#2 (the keys) should be available at all times and easily
discoverable.

But #3, reminders about Isearch keys, do not need to be
visible continually, and should not claim screen real
estate that way. #3 should be available on demand -
preferably by simply hitting the help key, `C-h'.  (If
necessary, the single key `C-h' could be mentioned in the
mode-line.)

A *Help* buffer is the logical choice for #3.  It should be
what users already expect or come to expect as the first
detailed help about something.  Widgety Customize-like
buffers should not become the new normal for that first-stop
help role.

Emacs should continue to teach users to ask for, get, and use
*Help*-style help.  It automatically provides links to more
detailed help about Isearch options, keys, etc., and to
customization of options.  There is no need to throw another
style of first-stop help in their face, for Isearch. 

A user can always keep the *Help* buffer displayed, if s?he
likes (separate window or frame).  On-demand (not immediately
and constantly in-your-face).  But keep it around as long as
you want.

And a user can easily rename the *Help* buffer, so that it
does not interfere with other *Help* displays.

[I bind a key to `rename-buffer'.  And my advised version of
`rename-buffer' provides (lax) completion for the buffer name.
I think it would be good for vanilla Emacs to do likewise (and
to mention the key concisely in *Help* or its mode-line).]

> >> 3. Display an information similar to the prompt I originally
> >> suggested, but on the mode-line.
> >
> > We already have a precedent in C mode with mode-line like
> > “C/lah ,” (note the space character inside, indicating Word mode).
> > In Isearch doing the same will show something like “Isearch/c' w”
> > (case-sensitive char-folded lax-whitespace word search).
> 
> While that's a fine addition to the current situation. I'm
> specifically trying to expose the keys you use to change isearch
> options. I suppose we could display those in a help-echo hint on those
> mode-line abbreviations, but I prefer to make it very clear to the
> user that they can type a key to see options.

See above.  The mode-line is precious, and it has limited
space.  Isearch *in particular* should use it to show the
current state, not to remind users of Isearch keys.
Isearch is becoming richer all the time, with more and more
keys that perform actions.  The mode-line is a poor design
choice for reminders about Isearch keys.

And again, prominent reminders of Isearch keys should not
privilege the keys to change option values.  Just because
we (Artur/Bruce - which do you prefer, BTW?) recently added
another (very welcome) toggle, char folding, that is not a
reason that option toggling should suddenly be considered
the only, or even the most, important kind of Isearch
action to remind users about.

> >> In items 1 and 2, we could display the indicators on an idle
> >> timer if preferred.
> >> Here's what the minibuffer might look like in that situation:
> >> Isearch: search string                            [C-h] Help
> >
> > I doubt that users might want to see the same reminder “[C-h] Help”
> > permanently or when paused to look at the highlighted search results.
> 
> You see that `Isearch: ' prompt every time you hit C-s, and that's
> right beside the text you're typing. This Help reminder would be off
> to the right edge (so it's far from the text you're typing). Besides,
> if you just type C-h once, you'll see a buffer explaining (among other
> things) how to disable this reminder.

I agree that putting such a reminder in the echo area
would not be a step forward.



  reply	other threads:[~2015-11-01 16:01 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29  0:20 Exposing Isearch toggleable options Artur Malabarba
2015-10-29  0:27 ` Juri Linkov
2015-10-29  0:38   ` Artur Malabarba
2015-10-29 23:58     ` Juri Linkov
2015-10-30  3:00       ` Random832
2015-10-30  9:48         ` Oleh Krehel
2015-10-30  9:56       ` Artur Malabarba
2015-10-30 10:42         ` Artur Malabarba
2015-10-30 11:03           ` Marcin Borkowski
2015-10-30 11:56             ` Artur Malabarba
2015-10-30 15:17               ` Marcin Borkowski
2015-10-30 12:01           ` Kaushal Modi
2015-10-30 12:21             ` Oleh Krehel
2015-10-30 14:07             ` Random832
2015-10-30 14:52               ` Kaushal Modi
2015-10-30 14:29           ` Oleh Krehel
2015-10-31  0:27           ` Juri Linkov
2015-11-01 12:42             ` Artur Malabarba
2015-11-01 16:01               ` Drew Adams [this message]
2015-11-01 19:34                 ` Artur Malabarba
2015-11-02  0:20                   ` Drew Adams
2015-11-02 20:19                     ` John Wiegley
2015-11-04 11:51                       ` Artur Malabarba
2015-11-04 15:39                         ` John Wiegley
2015-11-05  0:24                         ` Juri Linkov
2015-11-05  0:55                           ` Artur Malabarba
2015-11-05  0:59                             ` Dmitry Gutov
2015-11-05 22:44                               ` Richard Stallman
2015-11-05 22:44                             ` Richard Stallman
2015-11-05 23:28                               ` Alan Mackenzie
2015-11-06 21:40                                 ` Richard Stallman
2015-11-06  2:15                               ` John Wiegley
2015-11-06 13:48                               ` Stephen Leake
2015-11-06 13:56                                 ` Gian Uberto Lauri
2015-11-06 15:27                                   ` Ashton Kemerling
2015-11-06 15:44                                   ` John Wiegley
2015-11-07  1:32                                     ` Xue Fuqiao
2015-11-06 15:54                               ` Dmitry Gutov
2015-11-06 16:04                                 ` Artur Malabarba
2015-10-29  1:19 ` Drew Adams
2015-10-29 10:10   ` Artur Malabarba
2015-10-29 14:02     ` Drew Adams
2015-10-29 21:42       ` Artur Malabarba
2015-10-29  5:53 ` John Wiegley
2015-10-29  9:29   ` Nicolas Petton
2015-10-29 10:34     ` Artur Malabarba
2015-10-29 10:50       ` Nicolas Petton
2015-10-29 11:18         ` Kaushal Modi
2015-10-29 17:53     ` John Wiegley
2015-10-29 10:30   ` Artur Malabarba
2015-10-29 10:49   ` Oleh Krehel
2015-10-29 20:52     ` Rasmus
2015-10-29 21:27       ` Drew Adams
2015-10-29 16:18   ` Eli Zaretskii
     [not found]   ` <<8337wt3axe.fsf@gnu.org>
2015-10-29 17:19     ` Drew Adams
2015-10-29 18:33   ` Aldric Giacomoni
2015-10-29 18:54     ` John Wiegley
2015-10-29 19:14     ` Óscar Fuentes
2015-10-29 21:27       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1bb5e765-6599-4076-b9c7-11b416a48db7@default \
    --to=drew.adams@oracle.com \
    --cc=bruce.connor.am@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).