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: Sat, 10 Sep 2011 11:03:31 +0900 Message-ID: <87y5xxcfws.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1315620233 31688 80.91.229.12 (10 Sep 2011 02:03:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2011 02:03:53 +0000 (UTC) Cc: 'Alan Mackenzie' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 10 04:03:49 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 1R2Cv4-0003CU-8t for ged-emacs-devel@m.gmane.org; Sat, 10 Sep 2011 04:03:46 +0200 Original-Received: from localhost ([::1]:55193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Cv3-0001KJ-GQ for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 22:03:45 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Cv0-0001K3-Hl for emacs-devel@gnu.org; Fri, 09 Sep 2011 22:03:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2Cuz-0001Mi-69 for emacs-devel@gnu.org; Fri, 09 Sep 2011 22:03:42 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:33577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Cuy-0001MY-ML for emacs-devel@gnu.org; Fri, 09 Sep 2011 22:03:41 -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 DA2EB970771; Sat, 10 Sep 2011 11:03:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D39901A2789; Sat, 10 Sep 2011 11:03:31 +0900 (JST) In-Reply-To: <7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com> 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:143838 Archived-At: Drew Adams writes: > Right, but my real point is not about the names but about freeing > up the two pass-through behaviors (one for specific commands, the > other for `C-u') from their coupling to scrolling. Alan's point is that this is a YAGNI. It's incumbent on you to show it's actually a YIDNI ("yes, I *do* need it" in this concrete use case). [Perhaps you've already done that, but with all the repetition and philosophical BS, and disingenuous claims about not wanting to belabor dead horses that were bred and born earlier in your own post before you beat them into submission with freshly cooked linguine, I don't remember any more, and tl;wr2x ("too long; won't read two times").] > And even if that were also the case, nothing in fact prevents using > an inappropriate command this way. There are lots of inappropriate things that can be done with Emacsen. Most are in the class "you did WHAT? (mutter mutter you idiot)", most of the rest are "oh; well, don't do that, then", and a few are in the class of "attractive nuisance". Only the last class should be checked for. > Dunno. That would probably be OK for me, but I can imagine RMS or > others chiming in that they are used to having `C-u' immediately > exit Isearch. Having an option means not disturbing the general, > traditional behavior. Despite what I wrote above, this is not on the face of it a YAGNI. On the other hand, it doesn't need to be a customization at first. Only once it appears that there are many users who do like the behavior, and many who don't, does it need to be a visible customization. > Currently, it is all or nothing: all scroll commands plus any > others that might have property `isearch-scroll' or else none of > them. Er, isn't that precisely why this is enabled via a property? If you really need flexible control, you could turn the value into a context descriptor (in XEmacs, a "specifier"; more generally, an alist with keys some kind of test and values boolean). (See above for "YAGNI and YIDNI", though.) > Especially if we open this up to intentionally be about > pass-through in general and not just scrolling, users should have a > way to easily pick and choose which commands are affected by it. Not so fast. "Easy pick-and-choose" for users is definitely a YAGNI on the face of it. Use case? > > > Instead of a Boolean option (`isearch-allow-scroll'), users > > > should have an option that specifies the affected commands. Bad idea. You already have the property, and this proposed option requires developers of custom scroll commands (etc) to know about isearch, which really would be unfortunate. > > > 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. > > > > Pretty much all standard commands that can be "scrolling" commands > > already are. Let me know if there are any I have missed. > > I know. My question was why. Because the feature really *is* about scrolling, not just about some scroll commands inter alia. Some users use isearch in a way that is facilitated by scrolling commands which don't exit[1] isearch mode. It would be really really annoying if *some* of your (perhaps custom) scrolling commands worked but *others* did not. *This is a general property of scrolling commands*: they're all useful, or not, in the same sets of contexts for any given user. Rather than force users to add their custom commands to all such contexts, the 'scroll-command property makes it possible to get scrolling command behavior in all contexts, including ones you don't know about and haven't been written yet anyhow. > IOW, instead of having Isearch automatically recognize property > `scroll-command', just use property `isearch-scroll' for all > pertinent commands (even if they already have property > `scroll-command'). To belabor that point, that's a bad idea. *If* there are other classes like scrolling commands that the user really thinks of as a single parametrized command (ie, (defun scroll-command (direction distance target-of-point) ...)), they should get their own property so that users can set that property on custom commands in that class and automatically get appropriate behavior in any context that respects that property. Then for the miscellaneous commands, the `isearch-scroll' property is useful (it should be renamed to something like `isearch-inhibit-exit'). Footnotes: [1] Please don't call this "pass-through" in the code. It's not clear what is being "passed" or what it goes "through" or what "catches" it once it "gets through".