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: Fri, 9 Sep 2011 21:52:55 +0000 Message-ID: <20110909215255.GD2733@acm.acm> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1315605412 17489 80.91.229.12 (9 Sep 2011 21:56:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2011 21:56:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 09 23:56:48 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 1R2942-0002R7-9d for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 23:56:46 +0200 Original-Received: from localhost ([::1]:40042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2941-0000oG-HA for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 17:56:45 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R293y-0000nw-Ou for emacs-devel@gnu.org; Fri, 09 Sep 2011 17:56:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R293x-0000Sb-Kv for emacs-devel@gnu.org; Fri, 09 Sep 2011 17:56:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:33799 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R293x-0000SO-CO for emacs-devel@gnu.org; Fri, 09 Sep 2011 17:56:41 -0400 Original-Received: (qmail 94418 invoked by uid 3782); 9 Sep 2011 21:56:38 -0000 Original-Received: from acm.muc.de (pD9519E2E.dip.t-dialin.net [217.81.158.46]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 09 Sep 2011 23:56:37 +0200 Original-Received: (qmail 5972 invoked by uid 1000); 9 Sep 2011 21:52:55 -0000 Content-Disposition: inline In-Reply-To: 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:143831 Archived-At: Hi, Drew, I kind of feel myself being addressed here. :-) On Fri, Sep 09, 2011 at 01:38:16PM -0700, Drew Adams wrote: > 1. The doc for this option, as well as its name, give the impression that it is > about allowing scrolling. It is not. It is largely about scrolling. Try enabling the option and use , during an isearch. Or try C-l. The need to scroll during a search was what inspired the feature. > 1. For one thing, a non-nil value allows *any* command bound to a key in > `isearch-mode-map' to take advantage of a prefix arg. That is, `C-u' is passed > through to the command if the option value is non-nil. The command need not > have anything to do with scrolling. I'm not sure that's quite true. Or if it is, keys like C-s don't react to it. > And there are already at least two such vanilla commands: > `isearch-query-replace' and `isearch-query-replace-regexp' (`M-%', `C-M-%'). A > `C-u' changes the command behavior in a way that has nothing to do with > scrolling. It's good that the C-u works, though. ;-) > At a minimum, the doc should be adjusted. The option name should also be > changed to fit what it really does. What would you suggest? What does the option really do, in your judgement? Scrolling is an essential part of the option. > Likewise, the functions (e.g. `isearch-lookup-scroll-key') and other > code and doc strings in isearch.el that paint this feature as having to > do with scrolling. They're stricly internal functions, so changing their names/doc strings wouldn't be a big deal. > 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. 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. > 2. I would like to see us separate the treatment of a prefix arg - whether it > gets passed it through to a command or it exits Isearch - from the other > uses/effects of this option. I agree, that would be a good idea. It wouldn't take very much work. > IOW, I would like to be able to set some option to have Isearch pass `C-u' > through, and have that be independent of the setting of some other option that > controls whether scrolling (or some other behavior) is allowed. Even if > allowing scrolling (or whatever) might also require the ability to pass through > `C-u', that does not mean that being able to pass through `C-u' should allow > scrolling. It makes little sense to couple these two features. Need it be an option? Why not just let C-u through no matter what? > The query-replace commands are a good example, and users (such as yours truly) > might well want similar `C-u' pass-through for other commands, without also > wanting scrolling (or whatever). As a matter of interest, have you tried setting isearch-allow-scroll? If you have and didn't like it, what about it didn't you like? > 3. Wrt controlling which commands are affected by the option (i.e., forgetting > about `C-u' now): The current design makes the library designer responsible for > this choice, not the user. That is another flaw, IMO. A user should be able to > easily (using Customize, not just putting `put' here and there) choose which > commands are affected. I disagree totally here. The sophisticated user can set a suitable command to be a "scrolling" command. The unsophisticated user is going to get his Emacs into a thorough mess by messing around in this area. > Instead of a Boolean option (`isearch-allow-scroll'), users should have > an option that specifies the affected commands. (It could also > configure any specifics for each command, if there are such.) 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 :-). > 4. Why are there currently _two_ different properties that turn on this > sensitivity (i.e., "scrolling")? From the code comments: > ;; ... property called `isearch-scroll'. > ;; If a command's symbol has the value t for this property or for the > ;; `scroll-command' property, it is a scrolling command. I haven't a clue. I've no idea who put `scroll-command' in or why. > This means that if someone adds property `scroll-command' for some command then > it automatically acts as if s?he also added property `isearch-scroll'. Why > couple these two things? Why assume that every `scroll-command' command is also > one for which Isearch should allow scrolling. > All of this smacks of being a carryover from someone's (hi Alan) personal > customizations, rather than being thought out in terms of users in general. Pretty much all standard commands that can be "scrolling" commands already are. Let me know if there are any I have missed. Users capable of writing their own "scrolling" commands will be quite capable of putting the `isearch-scroll' property on them. (I have done this.) -- Alan Mackenzie (Nuremberg, Germany).