From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design Date: Sun, 11 Sep 2011 08:06:12 +0900 Message-ID: <874o0k576j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20110909215255.GD2733@acm.acm> <7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com> <20110910111054.GA2460@acm.acm> <20110910190420.GB2400@acm.acm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1315695991 4406 80.91.229.12 (10 Sep 2011 23:06:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2011 23:06:31 +0000 (UTC) Cc: Alan Mackenzie , Drew Adams , "emacs-devel@gnu.org" To: PJ Weisberg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 11 01:06:27 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 1R2Wcz-0007AH-4w for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2011 01:06:25 +0200 Original-Received: from localhost ([::1]:53875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Wcy-0004nk-Ko for ged-emacs-devel@m.gmane.org; Sat, 10 Sep 2011 19:06:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Wcw-0004ne-Pl for emacs-devel@gnu.org; Sat, 10 Sep 2011 19:06:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2Wcv-0000ie-VW for emacs-devel@gnu.org; Sat, 10 Sep 2011 19:06:22 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:52562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Wcv-0000iH-Na for emacs-devel@gnu.org; Sat, 10 Sep 2011 19:06:21 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7B08F9707A7; Sun, 11 Sep 2011 08:06:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6ECED1A278D; Sun, 11 Sep 2011 08:06:12 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta31) "ginger" 3bc58dc9d688 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:143862 Archived-At: PJ Weisberg writes: > The problem is that you've defined "scrolling command" to mean something > that has nothing to do with scrolling (i.e., commands which MOST DEFINITELY > DON'T exit isearch). No, that's completely wrong: there must be no buffer changes, no point movement, some other conditions. Exiting isearch or not is not part of the definition of "scrolling command". The fact that the current defintion doesn't mention "movement" of anything is a bit odd, indeed, but such things are occasionally useful. One might want to define an additional class of commands that satisfy those restrictions but aren't scrolling commands (ie, adjusting the position of the window with respect to the buffer). If so, define the classes (including adjusting the definition of "scrolling command") and adjust the code to recognize them. But: > This leads to ridiculous conclusions such as "C-u > `universal-argument' is a scrolling command in its own right." `universal-argument' is a meta-command, of which there are very few, so adding it (and other such meta-commands) ad hoc to "scrolling commands" might be the pragmatic way to handle it. What other commands conform to the restrictions that Alan stated? Of those, which would you like to add to the class that inhibit isearch's normal exit behavior? Are there whole classes of them that users would like to enable (or disable!) as a group, or a bunch of isolated commands that different users are likely to express varied willingness to enable them?