proposal - minibuffer completion functions

proposal - minibuffer completion functions

[Drew Adams]

Resending -

--------
From: Drew Adams Sent: Thursday, March 20, 2008 10:32 AM

The change that I would like to see for minibuffer completion is just to have
`completing-read' and `read-file-name' do the following:

1. Retain their current signatures (arg lists) - no change.

2. Funcall the value of a global variable: `completing-read-fn' or
`read-file-name-fn', if non-nil, to perform the completion. Else call a default
completing function, `completing-read-default' or `read-file-name-default'.

That is, move the current behavior of `completing-read' and `read-file-name' to
new functions that perform that behavior as the default case. Change the current
completion functions to be just wrappers that call either the value of a
variable or the default function.

This simple change would keep the behavior we have now as the default. But it
would also allow flexibility for packages and users that want to use different
completion mechanisms, and it would help such packages play better together.


Example: Icicles (just an example that I'm familiar with) and Viper mode each
adapt `read-file-name', in different ways, for their own use. Icicles does this
by redefining `read-file-name' when in Icicle mode (it is restored when you
leave the mode). Viper does it by advising `read-file-name'. If you load Icicles
first, the two play well together; if you load Viper first, they do not,
obviously. Neither redefining nor advising is a great approach here, IMO.

With what I propose, a package can define its own completion function. That
function would have the same signature as `read-file-name' (or
`completing-read'), and it would bind or set its completion function as the
value of `read-file-name-fn', for use in some context (e.g. a minor mode).

This function definition for a package could then, to do part of its job, call
either `read-file-name-default' or the function that was the current value of
`read-file-name-fn' at the time of the package's own definition of that
variable. Or it could just do its own thing altogether, from scratch. That is,
the package's completion function could reuse the existing completion mechanism
(default or current) in some way, or it could ignore it altogether. This is
similar to the various defadvice possibilities (before, after, replace).

I think this would be a simple and clean way to provide flexibility for
minibuffer completion. It is an alternative to using advice that I think is
better, in this case.

You might ask why a package doesn't just define and then use its own completion
function - why have it make the standard `completing-read' or `read-file-name'
adopt the package's way of completing? The reason is that by going through the
standard Emacs completion functions as a dispatcher, all code that calls
`completing-read' or `read-file-name' can take advantage of the package's
completion mechanism.

This is why, for instance, Icicles redefines `completing-read', even though its
redefinition never calls the original `completing-read'. The idea is to let
users take advantage of Icicles completion everywhere that `completing-read' (or
`read-file-name') is used (while in Icicle mode). Your code need not be
rewritten to call `icicle-completing-read'; it is enough that it calls
`completing-read'.

Re: proposal - minibuffer completion functions

[Stefan Monnier]

> Example: Icicles (just an example that I'm familiar with) and Viper
> mode each adapt `read-file-name', in different ways, for their own
> use. Icicles does this by redefining `read-file-name' when in Icicle
> mode (it is restored when you leave the mode). Viper does it by
> advising `read-file-name'.  If you load Icicles first, the two play
> well together; if you load Viper first, they do not,
> obviously.  Neither redefining nor advising is a great approach
> here, IMO.

For what it's worth: in 99% of the cases, advising is superior
to redefining.  The above case is no exception.


        Stefan

RE: proposal - minibuffer completion functions

[Drew Adams]

> For what it's worth: in 99% of the cases, advising is superior
> to redefining.  The above case is no exception.

It's irrelevant to the proposal. Please read the proposal.

Re: proposal - minibuffer completion functions

[Stefan Monnier]

>> For what it's worth: in 99% of the cases, advising is superior
>> to redefining.  The above case is no exception.
> It's irrelevant to the proposal.  Please read the proposal.

Yes, it's a separate issue.  I was just pointing it out so that in the
future you'll hopefully use advice rather than redefinition.


        Stefan

RE: proposal - minibuffer completion functions

[Drew Adams]

> >> For what it's worth: in 99% of the cases, advising is superior
> >> to redefining.  The above case is no exception.
> >
> > It's irrelevant to the proposal.  Please read the proposal.
> 
> Yes, it's a separate issue.  I was just pointing it out so that in the
> future you'll hopefully use advice rather than redefinition.

I will not, for that application. I don't agree that advice is superior in that
case, but the details are not worth exploring here. I do sometimes use advice,
FWIW.

Re: proposal - minibuffer completion functions

[Juri Linkov]

> 2. Funcall the value of a global variable: `completing-read-fn' or
> `read-file-name-fn', if non-nil, to perform the completion. Else call a default
> completing function, `completing-read-default' or `read-file-name-default'.

We have already `read-file-name-function', `read-buffer-function',
but I can't find the same for `completing-read'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: proposal - minibuffer completion functions

[Drew Adams]

> > 2. Funcall the value of a global variable: `completing-read-fn' or
> >    `read-file-name-fn', if non-nil, to perform the completion. 
> >    Else call a default completing function,
> >    `completing-read-default' or `read-file-name-default'.
> 
> We have already `read-file-name-function', `read-buffer-function',
> but I can't find the same for `completing-read'.

Thank you, Juri. This is great news. I wasn't aware of `read-file-name-function'
(new with Emacs 22, apparently). 

There is apparently no `read-file-name-default', but the same effect can be had
by binding `read-file-name-function' to nil.

So now all we need is `completing-read-function'.