emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: propose adding Icicles to Emacs


From: Drew Adams
Subject: RE: propose adding Icicles to Emacs
Date: Fri, 15 Jun 2007 14:04:49 -0700

>     Are you sure that that code cannot be made modular enough to be added,
>     without breaking the basic design and starting over from scratch?
>
> I am absolutely sure that my implementation of multi-command behavior
> is much cleaner.  Replaceing a standard command is undesirable, so I
> would like to minimize the number of commands that we need to replace.

Which command replacement are we talking about? I already detailed what
would be needed for `completing-read' and all of the other functions Icicles
that redefines. Those things I mentioned that cannot be foregone would need
to be done anyway, irrespective of multi-commands.

Apparently I still haven't made myself clear: Icicles replaces no commands.
It simply _rebinds_ some keys (and only if a user asks it to). This is about
command remapping, which is about key bindings. There is nothing unclean
about command remapping.

I think you mean to say that your approach would provide some multi-command
behavior without the need to define some multi-commands. I agree that that
would be a good thing, if that's what you're referring to here by "commands
that we need to replace."

I just want to be clear that we do _not_ need to replace any commands. _If_
you want `find-file' to act as a multi-command, then, in Icicles, you need
to define a multi-command for that. In your approach, IIUC, `find-file'
itself (and all commands that use completion in their interactive specs)
would automatically be a multi-command. And, as I've said before, that is a
good thing: I support your idea, IIUC.

>     > The only purpose that I know of for defining Icicle-find-file is to
>     > implement multi-command behavior.  Is there any other reason?
>
>     No, that is correct - it is the only reason.
>
> That's what I thought.  Therefore, my approach to multi-command
> behavior will eliminate the need for many of Icicle's substitutes for
> standard commands.

See above. You are phrasing the situation wrong (Icicles does not need to
substitute any standard commands), but I have no problem with what I think
you're really trying to say (see above).

> So I propose two things to be done in parallel:
>
> * Implement multi-command behavior at the level of Fcall_interactively.
>
> * Make a version of Icicles that doesn't define Icicle-find-file
> and the other simple replacements (which are just for the purpose
> of the multi-command feature).

Sounds good to me.

>     #1 is necessary to enable `C-RET', that is, to make it a
>     multi-command at all. With your implementation of
>     multi-commands, some such variable would
>     still be necessary in the general case, to override use of
>     the command body for the action function - that is, to
>     provide a different action from what the command itself
>     performs when you finally choose a candidate once and for
>     all.
>
> Can you explain some _specific_ reasons why that is needed?
> Becuase it seems to me we can probably do without it.

We can do without anything, of course. I already explained this and gave
examples. If you want to forego such features and have only a limited form
of multi-commands, then that's your decision.

I argued for adopting your implementation approach but also letting people
bind the 4 kinds of actions around any calls to completion functions (e.g.
`completing-read'): 1) action, 2) alternative action, 3) deletion, 4)
candidate help.

IIUC, your implementation limits a multi-command to using completion in the
`interactive' spec, and (so far), it does not let you provide specific
functions for the 4 possible multi-command actions.

>     One use case is defining a command that is itself called when defining
>     another command. The first command might define a default
>     action function if `icicle-candidate-action-fn' is nil when it is
>     called. The second command can bind the action function to
>     override the default in the command it calls. (There was an
>     example of this, but I no longer have one to point to.)
>
> That is rather abstract and I find I just can't follow it.

`icicle-search' provides for this, but there is today no command defined
using `icicle-search' that takes advantage of it. This is what `icicle
search' does:

(let ((icicle-candidate-action-fn
       (or icicle-candidate-action-fn 'icicle-search-action))
      (icicle-candidate-help-fn 'icicle-search-help)
      (icicle-update-input-hook
       (list 'icicle-search-highlight-all-input-matches)))

The binding of `icicle-candidate-action-fn' here lets a caller of
`icicle-search' bind its own action function, to override the default one,
`icicle-search-action'. There was a command that did that previously, but
there is none currently.

You can also see here an example of binding a candidate-help function that
is specific to this command (`icicle-search'). Icicles provides help on
individual candidates you choose (e.g. with `C-M-RET'), and a default help
function does that. It works quite well for lots of kinds of candidates, but
you might want, in your command, to define a specialized help function -
that's what `icicle-search' does: `icicle-search-help'.

>     2. `icicle-candidate-alternative-action-fn' - an alternative
>        action function
>     3. `icicle-delete-candidate-object' - a deletion action

And I forgot to list:

4. `icicle-candidate-help-fn' - a candidate help function.

> The easiest way to handle these is to use properties of the
> command symbol, `minibuffer-alt-action', `minibuffer-delete-action'.
> So we could do
>
>  (put 'find-file 'minibuffer-delete-action 'delete-file)
>
> S-delete would be defined to look for that property on this-command
> to decide what to do.
>
> We could implement the equivalent of `icicle-candidate-action-fn'
> easily in the same way.

Yes, that works too. I considered that, but I decided that binding was more
flexible, allowing more control over scope (overriding etc.).






reply via email to

[Prev in Thread] Current Thread [Next in Thread]