From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#11378: 24.1.50; Suggestion: Let M-i in isearch cycle `search-invisible' Date: Wed, 29 May 2013 20:16:52 -0700 (PDT) Message-ID: <6dcc689e-53a8-4982-953c-1b21c11cec78@default> References: <87haw32hly.fsf@web.de> <87397m6oxf.fsf@mail.jurta.org> <87y5pcdzxx.fsf@mail.jurta.org> <874nqzgcuk.fsf@mail.jurta.org> <87vcjesccy.fsf@mail.jurta.org> <87lijtcx8m.fsf@mail.jurta.org> <87sj1811tq.fsf@mail.jurta.org> <87vc6222vi.fsf@mail.jurta.org> <084871f7-9554-450a-863f-52a5b251d7d0@default> <871u8pmmla.fsf@mail.jurta.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 1369883886 8110 80.91.229.3 (30 May 2013 03:18:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 03:18:06 +0000 (UTC) Cc: 11378@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 30 05:18:04 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1UhtNL-0006cL-F1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 05:18:03 +0200 Original-Received: from localhost ([::1]:49896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhtNK-00046U-Pu for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 May 2013 23:18:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhtN0-0003i6-0m for bug-gnu-emacs@gnu.org; Wed, 29 May 2013 23:17:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhtMv-0001qi-8j for bug-gnu-emacs@gnu.org; Wed, 29 May 2013 23:17:41 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhtMv-0001qc-4z for bug-gnu-emacs@gnu.org; Wed, 29 May 2013 23:17:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UhtOJ-0004e0-GU for bug-gnu-emacs@gnu.org; Wed, 29 May 2013 23:19:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 May 2013 03:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11378 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11378-submit@debbugs.gnu.org id=B11378.136988391917811 (code B ref 11378); Thu, 30 May 2013 03:19:02 +0000 Original-Received: (at 11378) by debbugs.gnu.org; 30 May 2013 03:18:39 +0000 Original-Received: from localhost ([127.0.0.1]:41238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UhtNr-0004d0-EI for submit@debbugs.gnu.org; Wed, 29 May 2013 23:18:38 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39168) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UhtNn-0004cY-3i for 11378@debbugs.gnu.org; Wed, 29 May 2013 23:18:32 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4U3GsTa014052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 03:16:55 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4U3Grtb001233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 03:16:54 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4U3Gq8X015405; Thu, 30 May 2013 03:16:52 GMT In-Reply-To: <871u8pmmla.fsf@mail.jurta.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74653 Archived-At: > > A major difference is that my code does not hesitate to use the > > command to toggle the user option value. I realize you consider > > that a no-no. I think that commands to toggle user options are > > often a plus, not a minus. (Think minor-mode variables, if that helps. > > Or think of toggling an option via the options menu.) >=20 > Most togglable search variables should preferably have two versions > anyway: the default value (persistent in case of `defcustom') used > initially for every new search (and often consulted in toggling > commands to get the initial default value) and a transient value > used in the currently active search. >=20 > This is what `case-fold-search' and `isearch-case-fold-search' > already do and this is a flexible approach. I intend to > implement the same approach for other search variables as well, > e.g. adding `search-filter-predicates' to hold the default value > for `isearch-filter-predicates'. The prefix `search-' is more > appropriate for such variables when they are used outside of isearch. > So `isearch-filter-predicates' could be used to incrementally > add/remove filters in isearch-mode, but to use `search-filter-predicates' > in `query-replace', etc. I understand that approach. I disagree, that's all. I believe it is good to be able to toggle the option value (what you call the default value) on the fly (during a search) in this case, and thus change the behavior for subsequent searches as well (until toggled again). That is a more useful UI, IMO, in this case and in many others. I am not sure what I think about case-fold-search. Generally I think the usual approach makes more sense for it. But there is an argument to be made for it too to "stay put" across searches. Partly, such "sticky" behavior requires clear feedback to the user so s?he is aware of the curren= t "mode" of behavior. It is simple enough to toggle back again. Even for a one-off search using a different "mode" from usual, it just means two toggles instead of one. And if you perform multiple searches in different modes (a mix: some case-sensitive, some not), then the sticky/modal behavior typically means less toggling. I still use the usual approach for case-fold-search, because (a) I am used to it and (b) I use case-insensitive search rarely. But in Icicles I have a similar toggle for completion, and it is sticky/modal. Again, good feedback wrt the current behavior is more important for the sticky behavior: you are not always thrown back into some default behavior. Ideally perhaps the choice of behavior itself would be up to the user, and perhaps even itself via a toggle. No, I don't mean ojust a single option value reflecting the choice, but the ability to toggle which behavior to use for any behavior choice (toggle or cycle). (No, I don't really expect others to agree.)