From: "Drew Adams" <drew.adams@oracle.com>
To: "'Alan Mackenzie'" <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: RE: `isearch-allow-scroll' - a misnomer and a bad design
Date: Sat, 10 Sep 2011 17:47:51 -0700 [thread overview]
Message-ID: <BEB3EA23684C4277891247FB3CCE7E47@us.oracle.com> (raw)
In-Reply-To: <20110910190420.GB2400@acm.acm>
> > Well, yes and no. Yes, in general Isearch tries to prevent exit.
>
> Dash it, Drew, you can try a man's patience. It was me who programmed
> the device, me who first used "scrolling command", so I get to define
> what it means. I know you don't like the term,
I have nothing against the term. If that's what it does.
My (minor/FYI/heads-up) about the terminology was simply this: I don't think
that the code actually enforces anything about scrolling. I understand that
scrolling was the motivation and is still your intention. But IIUC (and I could
be wrong) the actual behavior does not look at scrolling - it looks only at
whether a given command has the property `isearch-scroll' or `scroll-command'.
> but if you can't bring yourself to use it as I've defined it,
> please suggest another term for it.
I suggested a few alternatives, actually, and I even gave a nod to one that ST
suggested (although I don't think it is accurate).
But I don't really care about this. Call it what you like.
> If we can't agree on terminology, then there's not much
> point trying to carry out a discussion.
So let's agree. You win. And in fact I've used your terminology since the
beginning, although I did put it in quotes: "scrolling command".
> > But if a command wants to exit, it can do so:
>
> > (defun foo ()
> > (interactive)
> > (isearch-done)
> > (message "WWWWWWWW")(sleep-for 2)
> > (forward-char 2))
>
> > That's what I do now, to exit Isearch and invoke Icicles
> > search. In this case, I use only `C-u' pass-through, not
> > command pass-through.
>
> What exactly do you mean by "command pass-through"?
I mean that I do not put property `isearch-scroll' or `scroll-command' on my
command, so it does not get treated as a "scrolling command".
What I do do is take advantage of the fact that if `isearch-allow-scroll' is
non-nil then a command invoked from Isearch can have a prefix arg passed to it
(instead of exiting Isearch).
And what I am asking for is to let users take advantage of this "`C-u'
pass-through" _without_ also having to set `isearch-allow-scroll' to non-nil and
consequently open the flood gates to scrolling within Isearch.
IOW, I want to be able to pass a prefix arg to a command that I invoke from
Isearch, without having to allow scrolling. End of story - you can forget the
rest if it's distracting you from that request.
> > ;; Bound to `S-TAB' in Isearch.
>
> OK. Things bound in the isearch-mode-map are a different
> kettle of fish entirely from scrolling commands.
That's the kettle I'm actually interested in, personally.
> > (defun icicle-search-w-isearch-string (&optional use-context-p)
> > (interactive "P")
> > (isearch-done)
> > (if (not use-context-p)
> > (icicle-search (point-min) (point-max)
> > (icicle-isearch-complete-past-string) t)
> > (let ((regexp (icicle-search-read-context-regexp)))
> > (kill-new (icicle-isearch-complete-past-string))
> > (icicle-search (point-min) (point-max) regexp t))))
>
> > > Their "isearch behaviour" is part of isearch. These commands
> > > operate precisely the same way, regardless of
> > > whether they're called from isearch or not.
>
> > The fact that you want some particular command to not exit
> > Isearch is part of the behavior you want for _that command_.
>
> I couldn't disagree more, if we're talking about something like
> `recenter-top-bottom'. If we're talking about a command bound in
> isearch-mode-map, like `icicle-s-w-i-s', then yes.
Well, we can disagree. And to me it's a detail, anyway. If it were I, I would
specify `recenter-top-bottom's Isearch behavior, etc. at the place where the
command is defined. And to me it doesn't matter which keymap(s) (if any) the
command is bound in.
I gave the analogy of thing-at-point behavior. Another analogy is
`delete-selection' behavior.
Sure, delete-selection behavior is currently specified for some commands in
delsel.el, and thing-at-point behavior is specified for some thing types in
thingatpt.el. But if you want to specify such behavior for your command `toto',
are you going to perform surgery on delsel.el, isearch.el, and thingatpt.el?
No, you're probably going to add the `put's that specify such behavior to your
library toto.el. That's all.
And I would probably just organize things like that from the start - if it were
I. But I'm not saying that Emacs needs to move such `put's out of delsel.el,
isearch.el, etc. and into the libraries that define the commands whose behavior
those `put's help contribute to defining. Let's forget about this disagreement.
> > > > > > 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.
>
> > You changed the subject. (1b) is about passing a _command_
> > through, not passing `C-u' through (see: "forgetting about `C-u'", above).
>
> I don't know what you mean. What is passing a command
> through what to what?
Forget the expression, if it's not clear. What I meant was applying property
`isearch-scroll' or `scroll-command' to a command's symbol. The resultant
behavior is what I was calling command pass-through.
It is something different from the `C-u' "pass-through" that happens _without_
using such a property, just by setting option `isearch-allow-scroll' to non-nil.
I suppose I should not have tried to talk about both features in the same mail,
but in my defense it is not I who mixed these two different creatures together.
;-) I tried to distinguish them and address each of them separately, but
apparently I did not succeed in making myself clear.
> > But what is important (to me) is that users must turn on
> > `isearch-allow-scroll' to enable the `C-u' pass-through.
> > They should not have to. I myself do not
> > want scrolling within Isearch (I want `C-v' to exit
> > Isearch, for example), yet I want to be able to use
> > `C-u S-TAB' from within Isearch.
>
> We're agreed on this point. My patch was trying to achieve that.
I'm glad we agree on the one thing I really care about. The rest was meant
mainly as an FYI that I think things could be cleaned up a bit - but I don't
really care if they are.
> > Nothing prevents a "scrolling command" (that is, a command
> > with property `isearch-scroll') from exiting Isearch - it is up
> > to the command.
>
> The definition of "scrolling command" prevents it.
What part of my `foo' example above (not the one below) was not clear? Try it.
Put property `isearch-scroll' on `foo' (making it a "scrolling command" in your
eyes), bind `foo' to a global key (e.g. (global-set-key "\C-f" 'foo)), and
invoke it from Isearch. For me it exits with no problem. What am I missing?
Where's the mysterious prevention?
> It would be profoundly bad programming practice for a random command
> to manipulate the internals of isearch. For a command on the
> isearch-mode-map (which cannot be a "scrolling command") it's a
> different matter.
Well, I won't argue it strongly, but I disagree. The feature that you so much
wanted to add to Isearch for scrolling commands might just as well be used by
some other command that does something just as benign. But you would anyway no
doubt see any such command through scrolling-colored glasses, and baptize it
kosher (ouch! sorry for such a meta4mix).
> > A user should be able to allow pass-through for some
> > commands and not others.
>
> Why? With the exception of the prefix-arg commands, you
> haven't made any strong case for this. Can you give an
> example of two scrolling commands, one of which a user would
> strongly want, the other strongly not want?
No, sorry, I just don't care. The only case I really care about is the
prefix-arg behavior.
If you don't see that the current code is not really about scrolling (or, if you
prefer, if I don't see that it really IS only about scrolling), then that's OK
with me - let's leave it at that. We agree about the important part: free
`C-u'!
> > Today, s?he can do that only by allowing all of them (non-nil
> > `isearch-allow-scroll') and then removing `isearch-scroll'
> > or `scroll-command' properties from the commands s?he does not
> > want to pass through.
>
> That is surely enough. I can't conceive of any situation where the
> binary choice is inadequate. What commands might a user want
> to separate out?
Dunno, Alan. And don't care. If there is some user who wants to allow
`recenter' but not `scroll-up' I guess we'll never know. You obviously like to
allow the whole lot, and I like to disallow the whole lot. And as I said, I
don't foresee my defining any "scrolling" commands that I will want to allow in
Isearch, so we can leave it as is.
> > > Try out this patch; I think it does what you want.
> > I don't think so. Am I missing something?
> No. I must have been missing something.
>
> > (defun foo (arg)
> > (interactive "P")
> > (isearch-done)
> > (message "arg: %S" arg)(sleep-for 2)
> > (forward-char 2))
> > (define-key isearch-mode-map "\C-f" 'foo)
>
> > Leave `isearch-allow-scroll' nil.
> > Now search and hit `C-u C-f'.
>
> > AFAICT, the `C-u' exits Isearch. It is not passed through to `foo'.
>
> OK. It was worth a try. :-)
And thanks for the try. I'm glad we agree that this is desirable.
next prev parent reply other threads:[~2011-09-11 0:47 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
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 [this message]
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=BEB3EA23684C4277891247FB3CCE7E47@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=acm@muc.de \
--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.