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:17:04 -0700 (PDT) Message-ID: <573f390a-d000-4997-a4a8-1ce4c5c359c4@default> References: <> <<87h9pq18ae.fsf@mail.linkov.net>> <<83a8vh5316.fsf@gnu.org>> <<9da72b40-0236-4edd-983e-90c54ca7f827@default>> <<83616544o3.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 1435684665 21012 80.91.229.3 (30 Jun 2015 17:17:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jun 2015 17:17:45 +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:17:32 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 1Z9zA3-0005LD-Mk for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 19:17:31 +0200 Original-Received: from localhost ([::1]:47976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9zA3-000753-63 for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 13:17:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9z9o-00074p-IT for emacs-devel@gnu.org; Tue, 30 Jun 2015 13:17:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9z9n-0004C8-KO for emacs-devel@gnu.org; Tue, 30 Jun 2015 13:17:16 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:31019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9z9j-0004BL-HC; Tue, 30 Jun 2015 13:17:11 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5UHH5UV014429 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jun 2015 17:17:06 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t5UHH5Ci003192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jun 2015 17:17:05 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5UHH5GY004162; Tue, 30 Jun 2015 17:17:05 GMT In-Reply-To: <<83616544o3.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: userv0021.oracle.com [156.151.31.71] 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:187687 Archived-At: > > But such a dialog box should not be the only way to change > > individual attribute values. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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.