From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Alan Mackenzie' <acm@muc.de>, emacs-devel@gnu.org
Subject: RE: `isearch-allow-scroll' - a misnomer and a bad design
Date: Sat, 10 Sep 2011 11:03:31 +0900 [thread overview]
Message-ID: <87y5xxcfws.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <7002A9DA9A804F0B9F6F251FD3A2B263@us.oracle.com>
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".
next prev parent reply other threads:[~2011-09-10 2:03 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 20:38 `isearch-allow-scroll' - a misnomer and a bad design Drew Adams
2011-09-09 21:52 ` Alan Mackenzie
2011-09-09 23:07 ` Drew Adams
2011-09-10 0:58 ` Stefan Monnier
2011-09-10 7:48 ` Drew Adams
2011-09-10 11:28 ` Alan Mackenzie
2011-09-10 16:44 ` Drew Adams
2011-09-10 11:47 ` Juri Linkov
2011-09-10 12:13 ` Alan Mackenzie
2011-09-10 2:03 ` Stephen J. Turnbull [this message]
2011-09-10 11:10 ` Alan Mackenzie
2011-09-10 16:43 ` Drew Adams
2011-09-10 19:04 ` Alan Mackenzie
2011-09-10 20:22 ` PJ Weisberg
2011-09-10 23:06 ` Stephen J. Turnbull
2011-09-11 0:47 ` Drew Adams
2011-09-11 10:39 ` Alan Mackenzie
2011-09-11 16:54 ` Drew Adams
2011-09-11 17:30 ` Alan Mackenzie
2011-09-11 18:53 ` Drew Adams
2011-09-12 2:46 ` Richard Stallman
2011-09-12 9:36 ` Alan Mackenzie
2011-09-13 1:39 ` Richard Stallman
2011-09-13 14:27 ` Alan Mackenzie
2011-09-13 20:05 ` Richard Stallman
2011-09-13 21:04 ` Drew Adams
2011-09-13 22:52 ` Juri Linkov
2011-09-14 0:32 ` Daniel Colascione
2011-09-14 0:41 ` Drew Adams
2011-09-14 14:10 ` Richard Stallman
2011-09-14 14:35 ` PJ Weisberg
2011-09-15 4:11 ` Richard Stallman
2011-09-14 14:44 ` Drew Adams
2011-09-18 2:52 ` Richard Stallman
2011-09-19 19:08 ` chad
2011-09-20 15:16 ` Richard Stallman
2011-09-20 19:17 ` Michael Welsh Duggan
2011-09-20 19:59 ` Dani Moncayo
2011-09-21 1:22 ` Stefan Monnier
2011-09-21 14:51 ` Richard Stallman
2011-09-21 15:01 ` Dani Moncayo
2011-09-21 15:10 ` Drew Adams
2011-09-21 16:35 ` Stephen J. Turnbull
[not found] ` <E1R6Tii-0000zy-Jw@f!! encepost.gnu.org>
2011-09-21 20:48 ` Richard Stallman
2011-09-21 21:13 ` Drew Adams
2011-09-22 13:58 ` Richard Stallman
2011-10-08 21:13 ` Drew Adams
2011-09-22 5:33 ` Stephen J. Turnbull
2011-09-22 13:59 ` Richard Stallman
2011-09-22 10:35 ` Alan Mackenzie
2011-09-22 21:44 ` Richard Stallman
2011-09-22 22:23 ` PJ Weisberg
2011-09-23 12:30 ` Richard Stallman
2011-09-21 9:04 ` Alan Mackenzie
2011-09-21 9:27 ` Dani Moncayo
2011-09-21 9:29 ` chad
2011-09-21 13:22 ` Drew Adams
2011-09-21 14:50 ` Richard Stallman
2011-09-12 14:59 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5xxcfws.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=acm@muc.de \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.