From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Displaying the state of isearch toggles [was Re: ASCII-folded search] Date: Tue, 30 Jun 2015 18:03:34 +0300 Message-ID: <837fql44s9.fsf@gnu.org> References: <831tgv7vbr.fsf@gnu.org> <87h9pq18ae.fsf@mail.linkov.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435676661 14766 80.91.229.3 (30 Jun 2015 15:04:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jun 2015 15:04:21 +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: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 30 17:04:04 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 1Z9x4t-00008j-9Z for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 17:04:03 +0200 Original-Received: from localhost ([::1]:47435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9x4n-0000r2-NR for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 11:03:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9x4R-0000Q9-Mw for emacs-devel@gnu.org; Tue, 30 Jun 2015 11:03:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9x4O-00037g-A9 for emacs-devel@gnu.org; Tue, 30 Jun 2015 11:03:35 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:58769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9x4N-00036d-OW for emacs-devel@gnu.org; Tue, 30 Jun 2015 11:03:32 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NQR00D00IR5LY00@mtaout25.012.net.il> for emacs-devel@gnu.org; Tue, 30 Jun 2015 17:59:18 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQR00ECNIYTD400@mtaout25.012.net.il>; Tue, 30 Jun 2015 17:59:18 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:187676 Archived-At: > Date: Mon, 29 Jun 2015 15:26:53 -0700 (PDT) > From: Drew Adams > Cc: Eli Zaretskii , 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.