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: Displaying the state of isearch toggles [was Re: ASCII-folded search] Date: Tue, 30 Jun 2015 10:14:14 -0700 (PDT) Message-ID: References: <> <<831tgv7vbr.fsf@gnu.org>> <> <<87h9pq18ae.fsf@mail.linkov.net>> <> <<837fql44s9.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1435684504 18358 80.91.229.3 (30 Jun 2015 17:15:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jun 2015 17:15:04 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, kaushal.modi@gmail.com, stephen@xemacs.org, juri@linkov.net To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 30 19:14:51 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 1Z9z7N-000494-KO for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 19:14:45 +0200 Original-Received: from localhost ([::1]:47966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9z7M-0005lB-U9 for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 13:14:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9z76-0005l4-LI for emacs-devel@gnu.org; Tue, 30 Jun 2015 13:14:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9z74-0002YE-Vd for emacs-devel@gnu.org; Tue, 30 Jun 2015 13:14:28 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9z70-0002Oi-Rr; Tue, 30 Jun 2015 13:14:23 -0400 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 t5UHEF3b010816 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jun 2015 17:14:16 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5UHEFUe018564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jun 2015 17:14:15 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t5UHEEpC022816; Tue, 30 Jun 2015 17:14:15 GMT In-Reply-To: <<837fql44s9.fsf@gnu.org>> 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:187686 Archived-At: > > I have nothing against *also* offering a dialog-box interface, > > but that should not be the main approach or the goal. >=20 > 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. >=20 > 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. >=20 > 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 =3D' 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. >=20 > 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. >=20 > 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? =20 > > In sum, I'd suggest that we stick close to the traditional > > Emacs design: provide keyboard toggle keys, pop up info > > windows, etc. >=20 > 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.