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: `isearch-allow-scroll' - a misnomer and a bad design Date: Tue, 13 Sep 2011 14:04:00 -0700 Message-ID: <7E2EE144B11D413583E1E659CDE15186@us.oracle.com> References: <20110909215255.GD2733@acm.acm><7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com><20110911103940.GA3246@acm.acm><3C4B7E318EB04AE4B7DB9FD0E4C67629@us.oracle.com><20110911173012.GA3088@acm.acm><20110912093651.GA3249@acm.acm> <20110913142732.GB3081@acm.acm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1315947869 21212 80.91.229.12 (13 Sep 2011 21:04:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2011 21:04:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: , "'Alan Mackenzie'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 13 23:04:24 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R3a9W-0005ST-Vi for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 23:04:23 +0200 Original-Received: from localhost ([::1]:58601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3a9R-0001rm-U4 for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 17:04:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3a9P-0001rg-MS for emacs-devel@gnu.org; Tue, 13 Sep 2011 17:04:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3a9O-0001Jp-9y for emacs-devel@gnu.org; Tue, 13 Sep 2011 17:04:15 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:30062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3a9O-0001Jc-4o; Tue, 13 Sep 2011 17:04:14 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8DL47P2028596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2011 21:04:09 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8DL46nM018621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 21:04:07 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DL41Gu030490; Tue, 13 Sep 2011 16:04:01 -0500 Original-Received: from dradamslap1 (/10.159.52.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 14:04:00 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: AcxyUHCp64tUnz3CQXGwBgiQMuOreAAAL2tA X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E6FC549.0183:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:144000 Archived-At: > I don't think there will be any inconvenience at all. > Unless the user sets the option, isearch will behave > exactly as it has done. > > If the default is the current behavior, I guess the other > option can't hurt. As a famous person is wont to say, why not poll the users about the default behavior? We can at least discuss it here. (But the important thing is of course to give users the option.) Unlike Richard, I am in favor of passing `C-u' through (e.g. to a command on `isearch-mode-map') by default, that is, _not_ making it exit Isearch. Yes, that would be a change from past behavior. It would have the advantage that a library can bind a command in `isearch-mode-map', and its users need not customize the new Isearch option in order to let that command receive `C-u' during Isearch. They would not need to customize anything - the command/key would just work as advertised, including wrt a prefix arg. Users of such a library/command have presumably already made the choice to use it. Why should the library have to add to the command's doc that if you want to use a prefix argument with it (in Isearch) then you have to customize option `isearch-blah'? Where else do we not allow a command on a keymap to see a prefix arg used with its key? Why should this not be the default behavior for Isearch, too? To me, this is all the more important because, as some have pointed out in the past, `isearch-mode-map' is already pretty full. Letting a command bound in that map use a prefix arg has the effect of putting multiple commands on the same key, distinguished by the prefix arg. That's a good thing. I suspected from the beginning that Richard might want `C-u' to exit Isearch (he has indicated before that he generally likes Control keys to exit), which is why I proposed making the behavior fix optional. Until Richard spoke up, my impression was that the consensus of those speaking about the issue seemed to be to let `C-u' pass through (not exit Isearch), by default. Maybe, maybe not. At any rate, Alan's first patch presumably tried to implement that behavior (without any user choice), but when he added the option in his second patch, he made the default behavior exit Isearch. It should still be an open question, so far, what the default behavior will be. The only arguments I've seen are (a) what I say above versus (b) tradition (no change in the default behavior). That is essentially (a) providing consistency with other keymaps versus (a) keeping the same inconsistency we've enjoyed in the past. Any other arguments wrt the default value?