From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Exposing Isearch toggleable options Date: Sun, 1 Nov 2015 08:01:30 -0800 (PST) Message-ID: <1bb5e765-6599-4076-b9c7-11b416a48db7@default> References: <87611q7c3f.fsf@mail.linkov.net> <877fm5tefl.fsf@mail.linkov.net> <87wpu3x4p4.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1446393721 25918 80.91.229.3 (1 Nov 2015 16:02:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Nov 2015 16:02:01 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com, Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 01 17:01:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zsv4i-0003mI-Tn for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 17:01:45 +0100 Original-Received: from localhost ([::1]:37829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsv4i-0005Rp-Gi for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 11:01:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsv4e-0005RZ-O2 for emacs-devel@gnu.org; Sun, 01 Nov 2015 11:01:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zsv4b-00028H-Hm for emacs-devel@gnu.org; Sun, 01 Nov 2015 11:01:40 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsv4b-00028D-AY for emacs-devel@gnu.org; Sun, 01 Nov 2015 11:01:37 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA1G1Vsj024284 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Nov 2015 16:01:31 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA1G1UfT030072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Nov 2015 16:01:30 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA1G1Uqb016892; Sun, 1 Nov 2015 16:01:30 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193066 Archived-At: > > 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. >=20 > 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.=20 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 > > =E2=80=9CC/lah ,=E2=80=9D (note the space character inside, indicating = Word mode). > > In Isearch doing the same will show something like =E2=80=9CIsearch/c' = w=E2=80=9D > > (case-sensitive char-folded lax-whitespace word search). >=20 > 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 =E2=80=9C[C-h] H= elp=E2=80=9D > > permanently or when paused to look at the highlighted search results. >=20 > 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.