From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design Date: Sat, 10 Sep 2011 11:10:54 +0000 Message-ID: <20110910111054.GA2460@acm.acm> References: <20110909215255.GD2733@acm.acm> <7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1315653296 8841 80.91.229.12 (10 Sep 2011 11:14:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2011 11:14:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 10 13:14:50 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 1R2LWL-00044u-FY for ged-emacs-devel@m.gmane.org; Sat, 10 Sep 2011 13:14:49 +0200 Original-Received: from localhost ([::1]:42971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2LWK-0004a6-OW for ged-emacs-devel@m.gmane.org; Sat, 10 Sep 2011 07:14:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2LWH-0004Zz-Lo for emacs-devel@gnu.org; Sat, 10 Sep 2011 07:14:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2LWG-0006da-9l for emacs-devel@gnu.org; Sat, 10 Sep 2011 07:14:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:31605 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2LWF-0006dT-W9 for emacs-devel@gnu.org; Sat, 10 Sep 2011 07:14:44 -0400 Original-Received: (qmail 16931 invoked by uid 3782); 10 Sep 2011 11:14:41 -0000 Original-Received: from acm.muc.de (pD9556A07.dip.t-dialin.net [217.85.106.7]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Sep 2011 13:14:39 +0200 Original-Received: (qmail 2932 invoked by uid 1000); 10 Sep 2011 11:10:54 -0000 Content-Disposition: inline In-Reply-To: <7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 193.149.48.1 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:143842 Archived-At: Hi, Drew. A bit of clarification: On Fri, Sep 09, 2011 at 04:07:02PM -0700, Drew Adams wrote: > That's my point. Like those commands, I want to make use of this `C-u' feature. > But I do not want to also allow scrolling during Isearch. [ .... ] > > What would you suggest? What does the option really do, in your > > judgement? Scrolling is an essential part of the option. > AFAICT, it does two things: > 1. It invokes any command that has property `isearch-scroll' or `scroll-command' > on its symbol - without necessarily exiting Isearch. NO NO NO!!! A "scrolling command" is a command which MOST DEFINITELY DOESN'T exit the isearch. This is the definition of "scrolling command" in isearch. With this in mind, please think through everything you've written. [ .... ] > 2. It passes a prefix arg through to any key (its command) that follows it. Bear in mind that C-u `universal-argument' is a scrolling command in its own right. So we can construe what you're asking for thusly: to have an option for a subset of scrolling commands to be executable in isearch > Neither of these has anything to do with scrolling, necessarily. Change the > names to remove `scroll' and you will see that. [ .... ] > (And the code that gives the scrolling commands their Isearch behavior should > not even be in isearch.el, IMO.) I'm not sure what you mean by this. Their "isearch behaviour" is part of isearch. These commands operate precisely the same way, regardless of whether they're called from isearch or not. [ .... ] > > > 1b. For another thing (i.e., forgetting about `C-u'), *any* > > > command can benefit from the same Isearch feature as a > > > scrolling command. It suffices to put a non-nil > > > `isearch-scroll' property on the command symbol. > > This isn't true. > It is true, AFAICT. Nothing prevents you from putting property `isearch-scroll' > on *any* command, to get Isearch to pass through to it. The current isearch, with isearch-allow-scroll set, will pass a C-u through to the next command regardless of whether that command is a scrolling command. > > Only commands which don't foul up the isearch can be > > permitted to use the feature. Only a few commands meet the criteria. > > `universal-argument' is such a command. > (It would be up to the command they are passed through to to decide whether to > exit. That would be something entirely new. It might involve such a command returning t/nil to instruct isearch to exit or not. But that would be a horrible kludge. (Every command being adjusted to do this? What about other uses of the return value? There are an awful lot of commands) > Granted that users might not want to mess around with the scrolling commands > (whether via `put' or Customize), perhaps you will recognize that a user might > want to not have Isearch pass through to some command that library `foo' thinks > it is a great idea to pass through to by default. You mean "pass through a C-u"? I don't see this at all. Perhaps you have a specific use case in mind. > > Again, familiarise yourself with just how restricted the permissible > > commands are. There's a list of criteria in isearch.el > > ~L1760 (think - number of yards in a mile :-). > I read that comment, and I read the code. You haven't given any hint that you've really understood these restrictions. Imagine a quasi-scrolling command that breaks one of them. Say, for example, it moves point. You would then be in the middle of an isearch with point not at the head of the current search string. I'm not saying that it wouldn't be possible to extend the semantics of isearch to make this valid, but it would be difficult. At least it might be technically possible but it most assuredly wouldn't be politically possible. > That said, I don't want to belabor this part. My main interest is in freeing up > `C-u', which you have already agreed to. [ .... ] > I would like to see `C-u' passed through - that's the main point. Either > systematically or optionally, but if optionally then separately from allowing > scrolling. Try out this patch; I think it does what you want. (It's obviously very rough code, in desperate need of refactoring, but it might work.) *** isearch.el~ 2011-09-04 15:31:05.000000000 +0000 --- isearch.el 2011-09-10 10:58:02.000000000 +0000 *************** *** 1966,1976 **** (apply 'isearch-unread keylist) (isearch-edit-string)) ;; Handle a scrolling function. ! ((and isearch-allow-scroll ! (progn (setq key (isearch-reread-key-sequence-naturally keylist)) ! (setq keylist (listify-key-sequence key)) ! (setq main-event (aref key 0)) ! (setq scroll-command (isearch-lookup-scroll-key key)))) ;; From this point onwards, KEY, KEYLIST and MAIN-EVENT hold a ;; complete key sequence, possibly as modified by function-key-map, ;; not merely the one or two event fragment which invoked --- 1966,1985 ---- (apply 'isearch-unread keylist) (isearch-edit-string)) ;; Handle a scrolling function. ! ((or ! (and isearch-allow-scroll ! (progn (setq key (isearch-reread-key-sequence-naturally keylist)) ! (setq keylist (listify-key-sequence key)) ! (setq main-event (aref key 0)) ! (setq scroll-command (isearch-lookup-scroll-key key)))) ! (progn ! (setq key (isearch-reread-key-sequence-naturally keylist) ! keylist (listify-key-sequence key) ! main-event (aref key 0) ! scroll-command (key-binding key)) ! (or (eq scroll-command 'universal-argument) ! (eq scroll-command 'negative-argument) ! (eq scroll-command 'digit-argument)))) ;; From this point onwards, KEY, KEYLIST and MAIN-EVENT hold a ;; complete key sequence, possibly as modified by function-key-map, ;; not merely the one or two event fragment which invoked -- Alan Mackenzie (Nuremberg, Germany).