[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: propose adding Icicles to Emacs
From: |
Richard Stallman |
Subject: |
Re: propose adding Icicles to Emacs |
Date: |
Wed, 13 Jun 2007 12:22:44 -0400 |
I'd propose adding Icicles first as an optional library, without trying to
integrate any of it deeply with Emacs. Later, we could look into a possible
tighter integration.
That is a very bad idea. "Temporary" solutions tend to become
permanent, and to prevent that from occurring requires insistence. No
software developer should install code meant to be temporary unless it
is essential to do so. Icicles features are nice, but installing them
is not essential.
Therefore we will put the code into the form we want to keep permanently
and then install it.
> Why does it do this?
Because those replacements are enhanced versions. They are typically
multi-commands that 1) keep the same behavior as the original, as long as
you don't use any special Icicles minibuffer bindings, but also 2) let you
take advantage of those minibuffer bindings (e.g. `C-RET') to get the
multi-command behavior.
Let's suppose I can magically implement multi-command behavior without
the need to define separate multi-commands to do it. (I think I can,
and I explained how.)
Is there any other reason in icicles to define new commands
to replace the existing ones?
If so, what is it? Maybe I can find a better way to implement that,
too.
The need to replace commands is a complexity, and the code will
be much better if we avoid that complexity.
Yes, you must define a new command, in order to adapt a given existing
command to multi-command use. This is a good thing, as some commands might
not lend themselves well to multi-command use (i.e. it might make no sense
for them, adding nothing).
That is no argument against making multi-command behavior magic.
Just respond, "If it isn't useful there, don't use it there."
And, more often, it is appropriate for some
commands to have a slightly different action function for candidates during
completion than after completion (for instance, because the
buffer/window/frame context or the use context might be different).
This might be a real issue. Can you please give an example or two?
If Icicles does not break anything, and it does not have a lasting effect
when you leave Icicle mode, then I think how it is implemented should not be
a concern.
That is true if you distribute it separately.
If it is part of Emacs, that changes everything.
We want Emacs to be modular. My proposed implememtation
of multi-command behavior is totally modular. I think we
can make it work with NO changes in any specific command.
The macro expansion of a multi-command defined using #1 or #2 is quite
complex. Some of its definition implements context management (window,
frame, buffer), and some of it implements treatment of possible errors from
application of the action function. For example, the original buffer,
window, or frame, to which we often want to return, might have been deleted
by application of the action to a particular candidate (e.g. if the action
is to kill the buffer, and the candidate acted on is the original buffer).
And we usually want to keep the focus after action application on the
minibuffer's frame, so that we can possibly keep using `C-RET' etc. on other
candidates.
The code in call-interactively may need to deal with such cases. I
think it can do so in ways that are independent of the specific
command that was run.
Wrt prefix args: C-u is treated specially during completion, so that, for
instance, you can apply it to individual candidates that you act on using
`C-RET'. That is, you can use a different prefix argument each time you act
on a candidate, if you like.
I just assumed it was the other way. We could handle the prefix this
way just as easily.
Remember, that, by default, you can act on the
same candidate multiple times. Sometimes that makes sense, sometimes it does
not.
Can you give me an example where it does not make sense?
2. It's appropriate, for many commands, to specialize the action behavior
during completion. See the commands that explicitly bind
`icicle-candidate-action-fn', as opposed to just using
`icicle-define-command'. Command `icicle-search', for instance, could not be
defined using `icicle-define-command'.
Can you please explain an example of this specialization?
Then I can think about its consequences.
- RE: propose adding Icicles to Emacs, (continued)
- RE: propose adding Icicles to Emacs, Davis Herring, 2007/06/21
- Re: propose adding Icicles to Emacs, Lennart Borgman (gmail), 2007/06/21
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/21
- RE: propose adding Icicles to Emacs, Davis Herring, 2007/06/21
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/21
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/24
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/15
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/15
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/15
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/13
- Re: propose adding Icicles to Emacs,
Richard Stallman <=
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/13
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/14
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/14
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/15
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/15
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/16
- Re: propose adding Icicles to Emacs, Juri Linkov, 2007/06/17
- RE: propose adding Icicles to Emacs, Drew Adams, 2007/06/17
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/18
- Re: propose adding Icicles to Emacs, Richard Stallman, 2007/06/11