Allow non-matching input, but require confirmation

Allow non-matching input, but require confirmation

[Stefan Monnier]

Currently, the `require-match' argument allows three different behaviors:
1) nil = allow any non-matching input.
2) t   = only allow matching input.  Automatically complete
         without confirmation.
3) neither nil nor t =  only allow matching input, but require confirmation
         after automatic completion.

I'd like to add a fourth one:

4) confirm-only = allow any non-matching input but require confirmation
                  if the input is not a valid completion.

Also I propose to use it for reading the file name in `find-file'.


        Stefan

RE: Allow non-matching input, but require confirmation

[Herbert Euler]

>4) confirm-only = allow any non-matching input but require confirmation
>                   if the input is not a valid completion.

This strategy seems to encourage valid completions.  Namely, when
valid completions are avaliable and inputed, no confirmation is made.
Otherwise, confirmation is made.  If the input can complete to an
element of collection to make a valid completion, but is not a member
of collection, should we "encourage" the valid completion by
completing the input, or confirm the non-matching input as an invalid
completion?

Regards,
Guanpeng Xu

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: Allow non-matching input, but require confirmation

[Stefan Monnier]

> This strategy seems to encourage valid completions.  Namely, when
> valid completions are avaliable and inputed, no confirmation is made.
> Otherwise, confirmation is made.  If the input can complete to an
> element of collection to make a valid completion, but is not a member
> of collection, should we "encourage" the valid completion by
> completing the input, or confirm the non-matching input as an invalid
> completion?

No, we don't want to complete at all, we just want to let the user know when
he hits RET whether her input is in the list of completions or not.

For find-file, this amounts to warning the user that she's about to open
a non-existing file, which may be exactly what she wants to do, but may also
be just the result of a typo (in my case, in 90% of the cases, it's a TAB
expansion that completed to "foo." instead of one of foo.c or foo.h, in 9%
of the cases it's a typo and in the 1% percent it's really what I want to
do).


        Stefan

Re: Allow non-matching input, but require confirmation

[Herbert Euler]

>For find-file, this amounts to warning the user that she's about to open
>a non-existing file, which may be exactly what she wants to do, but may 
>also
>be just the result of a typo (in my case, in 90% of the cases, it's a TAB
>expansion that completed to "foo." instead of one of foo.c or foo.h, in 9%
>of the cases it's a typo and in the 1% percent it's really what I want to
>do).

I see.  This is indeed an improvement on usability.  If the input can
be completed more, perhaps we should not only confirm the user about
it is non-matching, but tell the user it can be completed (although
may not be unique) as well.

Regards,
Guanpeng Xu

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: Allow non-matching input, but require confirmation

[Davis Herring]

> Also I propose to use it for reading the file name in `find-file'.

Given the relative harmlessness of "creating" new files, and the relative
ease of C-x C-v, I suppose this should be customizable with
`confirm-new-files' or so, although I'm fine with that defaulting to t.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Allow non-matching input, but require confirmation

[Stefan Monnier]

>> Also I propose to use it for reading the file name in `find-file'.
> Given the relative harmlessness of "creating" new files, and the relative
> ease of C-x C-v, I suppose this should be customizable with
> `confirm-new-files' or so, although I'm fine with that defaulting to t.

My experience is that hitting RET RET is really not much of a problem
either, so I'm not convinced there's a need for such a config var.
But if the people want it, I'll grant it to them.


        Stefan

Re: Allow non-matching input, but require confirmation

[Richard Stallman]

    I'd like to add a fourth one:

    4) confirm-only = allow any non-matching input but require confirmation
		      if the input is not a valid completion.

That seems good.

    Also I propose to use it for reading the file name in `find-file'.

Let's make this a user option.  Then we can try it out
as an experiment.

Re: Allow non-matching input, but require confirmation

[Stefan Monnier]

>     I'd like to add a fourth one:
>     4) confirm-only = allow any non-matching input but require confirmation
> 		      if the input is not a valid completion.

> That seems good.

>     Also I propose to use it for reading the file name in `find-file'.

> Let's make this a user option.  Then we can try it out
> as an experiment.

Installed.


        Stefan