C-x C-b and C-x C-f bugging about confirmation

C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

Hi,

why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
open a new buffer/file?

Annoyed.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
> open a new buffer/file?

So as to help prevent doing it by mistake when you mistyped.
Set confirm-nonexistent-file-or-buffer to nil to get back the old
behavior (or just hit RET twice, of course).


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
>> open a new buffer/file?
>
> So as to help prevent doing it by mistake when you mistyped.
> Set confirm-nonexistent-file-or-buffer to nil to get back the old
> behavior (or just hit RET twice, of course).

I see, I didn't realize you intended to make it the default.

I don't think it's a good default.  With minibuffer completion, typing
mistakes don't happen all that often, and it can be disconcerting to
have a RET rejected.  You might argue that it's no big deal to type a
second RET, but it's similarly no big deal to kill the buffer and try
again in the very few occasions that you make a mistake.  So this looks
like creeping featuritis if it's enabled by default.

Furthermore, nothing else in the core Emacs code, AFAICT, uses a
"[Confirm]" message of this sort where you have to type RET twice to do
what you want.  In cases like this, we usually use y-or-n prompts
instead.  Thus, even if there is a good reason in this case to prompt
the user in this unusual way, it leaves the user confused about what to
do (especially since the "[Confirm]" message is so cryptic).

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I don't think it's a good default.  With minibuffer completion, typing
> mistakes don't happen all that often, and it can be disconcerting to
> have a RET rejected.  You might argue that it's no big deal to type a
> second RET, but it's similarly no big deal to kill the buffer and try
> again in the very few occasions that you make a mistake.  So this looks
> like creeping featuritis if it's enabled by default.

BTW, it's also worth pointing out that most programs don't prompt the
user specially when the user uses an "open file" feature to select a
non-existing file (think about the GTK "open file" dialog).  So people
don't expect to be prompted for such a reason.

Re: C-x C-b and C-x C-f bugging about confirmation

[Sam Steingold]

Chong Yidong wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
>>> open a new buffer/file?
>> So as to help prevent doing it by mistake when you mistyped.
>> Set confirm-nonexistent-file-or-buffer to nil to get back the old
>> behavior (or just hit RET twice, of course).
> 
> I see, I didn't realize you intended to make it the default.
> 
> I don't think it's a good default.  With minibuffer completion, typing
> mistakes don't happen all that often, and it can be disconcerting to
> have a RET rejected.  You might argue that it's no big deal to type a
> second RET, but it's similarly no big deal to kill the buffer and try
> again in the very few occasions that you make a mistake.

I often have dozens of buffers open, including "foo.lisp" and "foos/" and 
completion is not the panacea.
it IS a big deal to have to kill the buffer:
with confirm-nonexistent-file-or-buffer = t:
C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
with confirm-nonexistent-file-or-buffer = nil:
C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
==> foo.lisp

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Sam Steingold <sds@gnu.org> writes:

> I often have dozens of buffers open, including "foo.lisp" and "foos/"
> and completion is not the panacea.
> it IS a big deal to have to kill the buffer:
> with confirm-nonexistent-file-or-buffer = t:
> C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
> with confirm-nonexistent-file-or-buffer = nil:
> C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up
> . TAB RET ==> foo.lisp

Sure, there are usage patterns that are going to be helped by this
change in defaults; and there are usage patterns that are going to be
hindered.  But I don't think it's obvious that either dominate.  Because
of that, this feature's inconsistency with the old minibuffer behavior
indicates that the default should be nil, I think.  Unless someone can
come up with a better way to do this.

Another point: for find-file, we have C-x C-v (find-alternative-file),
which provides an easy way to revisit a file if you visited the wrong
one.  So for file-name-completion, at least, this feature is less than
necessary.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> have a RET rejected.  You might argue that it's no big deal to type a
> second RET, but it's similarly no big deal to kill the buffer and try
> again in the very few occasions that you make a mistake.  So this looks
> like creeping featuritis if it's enabled by default.

In my experience typos (most commonly after a TAB completion which
completed less than expected) are a lot more common than opening
a nonexistent file.  And hitting RET one more time is much less painful
than killing the new buffer and starting over (opening the buffer may
have created a frame, may have prompted the user for insertion of
a default template, and after killing the buffer you have to repeat the
previous command and retype the name all over again).
The trade off is blindingly clear to me.

My take on it is that if the feature had been the default from the
beginning, nobody would even contemplate adding
a `confirm-nonexistent-file-or-buffer' option just to save themselves
typing RET one extra time when creating a new file.

So while I understand that habit will make people complain, I think
those complaints will disappear quickly.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Ted Zlatanov]

On Fri, 21 Nov 2008 09:35:48 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
>> open a new buffer/file?

SM> So as to help prevent doing it by mistake when you mistyped.
SM> Set confirm-nonexistent-file-or-buffer to nil to get back the old
SM> behavior (or just hit RET twice, of course).

FWIW, I really like the new behavior.  It's much more common for me to
make a typo than to open a brand new file.

Ted

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> Date: Fri, 21 Nov 2008 11:08:49 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ams@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> it IS a big deal to have to kill the buffer:
> with confirm-nonexistent-file-or-buffer = t:
> C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
> with confirm-nonexistent-file-or-buffer = nil:
> C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
> ==> foo.lisp

Your argument is true only if one makes a mistake.  I don't think it
is true in general that there are more typing mistakes than correct
input.

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 21 Nov 2008 13:03:52 -0500
> Cc: ams@gnu.org, emacs-devel@gnu.org
> 
> > have a RET rejected.  You might argue that it's no big deal to type a
> > second RET, but it's similarly no big deal to kill the buffer and try
> > again in the very few occasions that you make a mistake.  So this looks
> > like creeping featuritis if it's enabled by default.
> 
> In my experience typos (most commonly after a TAB completion which
> completed less than expected) are a lot more common than opening
> a nonexistent file.

My experience is the other way around.

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> In my experience typos are a lot more common than opening a
> nonexistent file.

It's a matter of usage patterns.  For myself, this change will probably
be triggered hundreds or thousands of times for each mistake caught.

> (most commonly after a TAB completion which completed less than
> expected)

Hitting TAB after completion gives the message "[Sole completion]",
which tells you that you have what you want.

> My take on it is that if the feature had been the default from the
> beginning, nobody would even contemplate adding a
> `confirm-nonexistent-file-or-buffer' option just to save themselves
> typing RET one extra time when creating a new file.

But it has not been the default from the beginning, and it deviates from
established rules about how the minibuffer behaves.  One expects RET,
unlike TAB, to submit the minibuffer input.  (The only time RET doesn't
do that is in an "error situation"---a minibuffer is expects an exact
match and you haven't supplied that.)  Hence this double-RET behavior,
with its cryptic "[Confirm]" prompt, is jarring.

Re: C-x C-b and C-x C-f bugging about confirmation

[Alan Mackenzie]

Hi, Yidong and Stefan, and everybody else!

On Fri, Nov 21, 2008 at 12:07:53PM -0500, Chong Yidong wrote:
> Sam Steingold <sds@gnu.org> writes:

> > I often have dozens of buffers open, including "foo.lisp" and "foos/"
> > and completion is not the panacea.
> > it IS a big deal to have to kill the buffer:
> > with confirm-nonexistent-file-or-buffer = t:
> > C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
> > with confirm-nonexistent-file-or-buffer = nil:
> > C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up
> > . TAB RET ==> foo.lisp

> Sure, there are usage patterns that are going to be helped by this
> change in defaults; and there are usage patterns that are going to be
> hindered.  But I don't think it's obvious that either dominate.  Because
> of that, this feature's inconsistency with the old minibuffer behavior
> indicates that the default should be nil, I think.  Unless someone can
> come up with a better way to do this.

After a tab, how about prompting only when an incomplete completion has
just been <ret>ted?

I've not tried it, but I think having to type another <ret> would
irritate me quite a lot, even though I quite often hit <ret> on an
incomplete completion.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: C-x C-b and C-x C-f bugging about confirmation

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

Hi!

>> (most commonly after a TAB completion which completed less than
>> expected)

That happens to me quite a lot (each and every day), even though I use
iswitchb.  So I like the new behavior.

> Hitting TAB after completion gives the message "[Sole completion]",
> which tells you that you have what you want.

But you have to type TAB twice.  The first completes and only the second
one triggers the message.

Bye,
Tassilo

Re: C-x C-b and C-x C-f bugging about confirmation

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> So while I understand that habit will make people complain, I think
> those complaints will disappear quickly.

I've left this turned on, and will probably leave it on; hitting RET
twice is so easy that it's not really a big deal, and it's already saved
me from creating at least one buffer inadvertently.

It seems that this is a pretty good way of implementing this particular
feature (a y-n question, for instance would be far more annoying and
intrusive).

-Miles

-- 
Mad, adj. Affected with a high degree of intellectual independence; not
conforming to standards of thought, speech, and action derived by the
conformants [sic] from study of themselves; at odds with the majority; in
short, unusual. It is noteworthy that persons are pronounced mad by officials
destitute of evidence that they themselves are sane.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>> it IS a big deal to have to kill the buffer:
>> with confirm-nonexistent-file-or-buffer = t:
>> C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
>> with confirm-nonexistent-file-or-buffer = nil:
>> C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
>> ==> foo.lisp

> Your argument is true only if one makes a mistake.  I don't think it
> is true in general that there are more typing mistakes than
> correct input.

The issue is not "correct input" but "correct input that leads to the
creation of a new file".  Generally, when you're creating a new file,
you know it, so you hit RET RET right away.

It's kind of like creating two different commands: one for opening an
existing file and one for creating a new file, except the only different
between the two is that you hit RET for one and RET RET for the other.

Once you get used to it, you'll see it's completely painless, even if
you create a thousand files per hour and never make any typing error
when opening existing files.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>> In my experience typos are a lot more common than opening a
>> nonexistent file.
> It's a matter of usage patterns.  For myself, this change will probably
> be triggered hundreds or thousands of times for each mistake caught.

As explained to Eli, this is not a problem: you usually know that you're
creating a new file, so you'll just get used to hitting RET RET blindly
in those cases, as a matter of course.

>> (most commonly after a TAB completion which completed less than
>> expected)
> Hitting TAB after completion gives the message "[Sole completion]",
> which tells you that you have what you want.

I can assure you the situation I describe is real, I face it all
the time.  The situation you describe is when you hit TAB to check your
entry before hitting RET.  Maybe some people are patient enough to
do that.  Instead, I hit TAB to complete (not to check) and I hit RET
afterwards without even checking the result of TAB because I mistakenly
presume Emacs's completion can always read my mind.  I know I'm not
alone in this.
Not that it matters to this discussion anyway.

> But it has not been the default from the beginning, and it deviates from
> established rules about how the minibuffer behaves.  One expects RET,
> unlike TAB, to submit the minibuffer input.  (The only time RET doesn't
> do that is in an "error situation"---a minibuffer is expects an exact
> match and you haven't supplied that.)  Hence this double-RET behavior,
> with its cryptic "[Confirm]" prompt, is jarring.

It's a pretty minor difference.  As for [Confirm] being cryptic, we can
change it, of course, I don't care about the actual message, I just
reused the one used in the other similar case where RET needed to
complete the input: nobody complained about that one being cryptic, by
the way ;-)


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[mail]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> In my experience typos (most commonly after a TAB completion which
> completed less than expected) are a lot more common than opening
> a nonexistent file.  And hitting RET one more time is much less painful
> than killing the new buffer and starting over (opening the buffer may
> have created a frame, may have prompted the user for insertion of
> a default template, and after killing the buffer you have to repeat the
> previous command and retype the name all over again).
> The trade off is blindingly clear to me.
>

In my experience, I open non-existent files because I want to create a
new file, and I go to non-existent buffers, because I want a scratch
workspace, far more than I mistype a filename (I daresay that's never
happened...)

Re: C-x C-b and C-x C-f bugging about confirmation

[Miles Bader]

mail@justinbogner.com writes:
> In my experience, I open non-existent files because I want to create a
> new file, and I go to non-existent buffers, because I want a scratch
> workspace, far more than I mistype a filename (I daresay that's never
> happened...)

However the "overhead" of the new feature -- hitting RET again -- is
_very_ low, to the point where after the initial surprise you don't even
notice it.

I'd suggest using it for a while before judging.

-Miles

-- 
Politics, n. A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 21 Nov 2008 22:30:08 -0500
> Cc: ams@gnu.org, emacs-devel@gnu.org
> 
> > with its cryptic "[Confirm]" prompt, is jarring.
> 
> It's a pretty minor difference.  As for [Confirm] being cryptic, we can
> change it, of course

Yes, please change it, no matter what we decide in this discussion.
It is terrible from the HE point of view.  Something like

  [Type RET to create new file/buffer]

is needed, although this is quite long.

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 21 Nov 2008 22:23:18 -0500
> Cc: cyd@stupidchicken.com, ams@gnu.org, Emacs Devel <emacs-devel@gnu.org>
> 
> >> it IS a big deal to have to kill the buffer:
> >> with confirm-nonexistent-file-or-buffer = t:
> >> C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
> >> with confirm-nonexistent-file-or-buffer = nil:
> >> C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
> >> ==> foo.lisp
> 
> > Your argument is true only if one makes a mistake.  I don't think it
> > is true in general that there are more typing mistakes than
> > correct input.
> 
> The issue is not "correct input" but "correct input that leads to the
> creation of a new file".

That's what I meant by "correct input".

> Generally, when you're creating a new file, you know it, so you hit
> RET RET right away.

But I don't _want_ to hit RET RET.  I want just RET.

Re: C-x C-b and C-x C-f bugging about confirmation

[Gilaras Drakeson]

> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
> open a new buffer/file?

It also happens to me to mistype a buffer/file name, and I like the
current behaviour better than the old one. However I think it would make
a better habit to assign something like C-RET or M-RET to "force create
a new buffer/file", and always present a y-or-n-p for plain RET when the
entered buffer/file-name does not exist.

Also, maybe auto-insert can advise the y-or-n-p used there to something
that asks for:
y,e (empty, no auto-insert),
n (cancel),
a,i (for auto-insert), 
s (select which template to insert), 
? (help).

Gilaras

Re: C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

   > why on earth does C-x C-b and C-x C-f ask me to confirm when I
   > wish to open a new buffer/file?

   So as to help prevent doing it by mistake when you mistyped.  Set
   confirm-nonexistent-file-or-buffer to nil to get back the old
   behavior (or just hit RET twice, of course).

Opening a non-existing file, or non-existing buffer is a very common
business.  The current behaviour is not only annoying, but uninuitive,
what am I confirming when hitting RET a second time?  Why do I have to
confirm whatever I am confirming?

It has also two different behaviours depending on what you do, I
cannot think of many Emacs commands that have such a behaviour; I
cannot think of a single one infact.  If a question poped up _every_
time you opened a file, then I could actually understand that, since
then you can hard code your neuros to just always hit y to confirm.

This is to much of a DWI(think you)M, and should be reverted back to
nil; those who wish to get extra questions will then know that they
get extra questions since they have explicitly asked for it.

Re: C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

   Chong Yidong wrote:
   > Stefan Monnier <monnier@iro.umontreal.ca> writes:
   > 
   >>> why on earth does C-x C-b and C-x C-f ask me to confirm when I wish to
   >>> open a new buffer/file?
   >> So as to help prevent doing it by mistake when you mistyped.
   >> Set confirm-nonexistent-file-or-buffer to nil to get back the old
   >> behavior (or just hit RET twice, of course).
   > 
   > I see, I didn't realize you intended to make it the default.
   > 
   > I don't think it's a good default.  With minibuffer completion, typing
   > mistakes don't happen all that often, and it can be disconcerting to
   > have a RET rejected.  You might argue that it's no big deal to type a
   > second RET, but it's similarly no big deal to kill the buffer and try
   > again in the very few occasions that you make a mistake.

   I often have dozens of buffers open, including "foo.lisp" and "foos/" and 
   completion is not the panacea.
   it IS a big deal to have to kill the buffer:
   with confirm-nonexistent-file-or-buffer = t:
   C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
   with confirm-nonexistent-file-or-buffer = nil:
   C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
   ==> foo.lisp

For the later example, if I open a file that I didn't intend to open,
I use C-x C-v (find-alternate-file) instead of killing the buffer, and
reopening the file.   

Maybe the tab completion could be better, having a modal very terse
confirmation question enabled by default, is not a good idea though;

Re: C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

   >> it IS a big deal to have to kill the buffer:
   >> with confirm-nonexistent-file-or-buffer = t:
   >> C-x b fo TAB [expands to "foo"] RET [confirm?] . TAB RET ==> foo.lisp
   >> with confirm-nonexistent-file-or-buffer = nil:
   >> C-x b fo TAB [expands to "foo"] RET [new buffer] C-x k RET C-x b Up . TAB RET 
   >> ==> foo.lisp

   > Your argument is true only if one makes a mistake.  I don't think
   > it is true in general that there are more typing mistakes than
   > correct input.

   The issue is not "correct input" but "correct input that leads to
   the creation of a new file".  Generally, when you're creating a new
   file, you know it, so you hit RET RET right away.

   It's kind of like creating two different commands: one for opening
   an existing file and one for creating a new file, except the only
   different between the two is that you hit RET for one and RET RET
   for the other.

But RET has never had that meaning, it is counter intuitive, nor is
the message clear as to what you are confirming.  RET means (or
atleast meant) "I am done, please do whatever I told you.".

I am also astounded that people just have gone about changing such a
common UI feature that affects _all_ users, without raising a vote
first.  Nor was there anything added to NEWS, or the docstring.

   Once you get used to it, you'll see it's completely painless, even
   if you create a thousand files per hour and never make any typing
   error when opening existing files.

It is not about getting used to it, one can get used to many annoying
things.  When you hit RET, you have finished a command.  This is no
longer the case; a clear (default) behaviour has now changed meaning
to mean anything.  It is also no longer clear what a command might do
or ask, it changes behaviour depending on the enviroment.

Making TAB expand to the first match, and then cycle through all
matches by hitting consequtive TABs is something that makes sense.


The current behaviour also makes it impossible to make a keyboard
macro that behaves well, you might be opening files that exist and do
not exist.  One of the nicest things about emacs has been that there
is a 1-1 correspondence between lisp functions, and key bindings.
E.g. C-x C-f FOO RET is basically the same as (find-file "FOO"), now
this is no longer the case, and this makes it impossible to make
keyboard macros.

Re: C-x C-b and C-x C-f bugging about confirmation

[Ulrich Mueller]

>>>>> On Sat, 22 Nov 2008, Stefan Monnier wrote:

>> Your argument is true only if one makes a mistake.  I don't think
>> it is true in general that there are more typing mistakes than
>> correct input.

> The issue is not "correct input" but "correct input that leads to
> the creation of a new file".  Generally, when you're creating a new
> file, you know it, so you hit RET RET right away.

... only to get a "File error: Process died" because the new file
would be on a remote machine and the second RET was typed at Tramp's
passphrase question. ;-)

I find the new behaviour really annoying, please revert this to the
previous default.

Ulrich

Re: C-x C-b and C-x C-f bugging about confirmation

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> After a tab, how about prompting only when an incomplete completion has
> just been <ret>ted?

Whatever the outcome of the current little spat, I think this is a
clever idea, and it would be a good option to provide (maybe in addition
to the "full confirmation" option).

I think something like 95% of the incorrect buffer names I enter are due
to exactly this case:  TAB resulting in an incomplete completion,
followed by me hitting RET too quickly.  This actually happens to me
quite often.  I'll get used to a particular completion "always" working,
and then at some point a new buffer will cause that assumption to become
invalid.

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> But I don't _want_ to hit RET RET.  I want just RET.

This is a silly argument.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> Opening a non-existing file, or non-existing buffer is a very common
> business.  The current behaviour is not only annoying, but uninuitive,
> what am I confirming when hitting RET a second time?

Is that a rethorical question?  RET says "use this input", doesn't it?
So what you're confirm is that you indeed want to use this input.

[snip]

First try it for a month with an open mind.  Your reaction is
out of proportion of the actual impact of this change.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> I find the new behaviour really annoying, please revert this to the
> previous default.

I simply refuse to believe that it can be "really annoying" other than
for the fact that it's different.  So, try it with an open mind for
a month, and then come back.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> First try it for a month with an open mind.  Your reaction is
> out of proportion of the actual impact of this change.

I think everyone agrees that it's a useful feature.  There are lots of
features that I personally use, which are not enabled by default for
various good reasons.  Similarly, people have pointed out good reasons
not to make this particular feature the default (usage patterns for
which it badly non-optimal, keyboard macros, Tramp,...).

Re: C-x C-b and C-x C-f bugging about confirmation

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> I think everyone agrees that it's a useful feature.  There are lots of
> features that I personally use, which are not enabled by default for
> various good reasons.  Similarly, people have pointed out good reasons
> not to make this particular feature the default (usage patterns for
> which it badly non-optimal, keyboard macros, Tramp,...).

So if the final decision is to not make it the default, please
revert the associated entry in etc/NEWS to match the current behavior
(http://git.sv.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=15b0b39#patch2).

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 22 Nov 2008 22:39:35 -0500
> Cc: cyd@stupidchicken.com, ams@gnu.org, emacs-devel@gnu.org
> 
> > But I don't _want_ to hit RET RET.  I want just RET.
> 
> This is a silly argument.

This is an irrational and unfriendly way of having a conversation.

Re: C-x C-b and C-x C-f bugging about confirmation

[Juri Linkov]

> First try it for a month with an open mind.

I tried this feature with an open mind, and there is a case where
it fails for me.  I often create temporary buffers (usually with
short names like a1, a2, a3) to edit small pieces of text copied
from elsewhere (to copy them back after editing or save to a file).
To do this I quickly type `C-x b a3 RET C-y' to yank the text into
a new temporary buffer, but with confirm-nonexistent-file-or-buffer=t
the text gets yanked into the minibuffer.

OTOH, I never mistakenly switch to nonexistent buffers because when
I need to switch to an existing buffer, I check its name by reading it
in the minibuffer before typing RET.

So I guess a confirmation is useful only for people who too quickly
switch between buffers.  Trying to find a good default for everyone,
how about the following?  When a completion is incomplete, display
a message after TAB:

  Prompt: foo [Incomplete]

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

Re: C-x C-b and C-x C-f bugging about confirmation

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> When a completion is incomplete, display a message after TAB:
>
>   Prompt: foo [Incomplete]

The above might be a nice feature, but isn't really good enough.

Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
solution to this problem though.

-Miles

-- 
The trouble with most people is that they think with their hopes or
fears or wishes rather than with their minds.  -- Will Durant

Re: C-x C-b and C-x C-f bugging about confirmation

[Juri Linkov]

> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
> solution to this problem though.

I now see that Alan proposed to ask confirmation only after TAB RET.
This makes sense!  When I create new buffers, I type names without
completion.  It seems it's a very rare case to intentionally create
a new buffer after TAB RET, so no one will be annoyed by confirmation.

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

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
> solution to this problem though.

Yes, I think it's a good idea.

Semantically, it would tie the confirmation to a behavior of completion,
making the "[Confirm]" behavior of RET less unexpected.  Also, the
keyboard macro problem would be more or less bypassed since no one would
expect TAB to work reliably in a keyboard macro anyway.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>> > But I don't _want_ to hit RET RET.  I want just RET.
>> This is a silly argument.
> This is an irrational and unfriendly way of having a conversation.

Just read what you wrote: "I don't want to do that" is not much of
an argument.  Even if you add underscores.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>> When a completion is incomplete, display a message after TAB:
>> Prompt: foo [Incomplete]
> The above might be a nice feature, but isn't really good enough.

Indeed, usually I wouldn't need an [Incomplete] to know that the text is
incomplete.  The problem is that I hit RET before seeing the result of
the completion (and hence of the potential [Incomplete] message as well).

> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
> solution to this problem though.

Indeed, it would cover 99% of my cases.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
>> solution to this problem though.
>
> Indeed, it would cover 99% of my cases.

See attached patch (necessary doc changes not included).  Any
objections?

*** trunk/lisp/files.el.~1.1018.~	2008-11-22 16:48:15.000000000 -0500
--- trunk/lisp/files.el	2008-11-24 00:09:39.000000000 -0500
***************
*** 1104,1114 ****
--- 1104,1124 ----
  \f
  (defcustom confirm-nonexistent-file-or-buffer nil
    "If non-nil, confirmation is requested before visiting a new file or buffer.
+ If the value is `after-completion', confirmation is only
+ requested if the user calls `minibuffer-complete-and-exit'
+ immediately after `minibuffer-complete'.
  This affects commands like `switch-to-buffer' and `find-file'."
    :group 'find-file
    :version "23.1"
    :type 'boolean)
  
+ (defun confirm-nonexistent-file-or-buffer ()
+   (cond ((eq confirm-nonexistent-file-or-buffer 'after-completion)
+ 	 'confirm-after-completion)
+ 	(confirm-nonexistent-file-or-buffer
+ 	 'confirm)
+ 	(t nil)))
+ 
  (defun read-buffer-to-switch (prompt)
    "Read the name of a buffer to switch to and return as a string.
  It is intended for `switch-to-buffer' family of commands since they
***************
*** 1118,1124 ****
      (minibuffer-with-setup-hook
          (lambda () (setq minibuffer-completion-table rbts-completion-table))
        (read-buffer prompt (other-buffer (current-buffer))
!                    (if confirm-nonexistent-file-or-buffer 'confirm-only)))))
  
  (defun switch-to-buffer-other-window (buffer-or-name &optional norecord)
    "Select the buffer specified by BUFFER-OR-NAME in another window.
--- 1128,1134 ----
      (minibuffer-with-setup-hook
          (lambda () (setq minibuffer-completion-table rbts-completion-table))
        (read-buffer prompt (other-buffer (current-buffer))
!                    (confirm-nonexistent-file-or-buffer)))))
  
  (defun switch-to-buffer-other-window (buffer-or-name &optional norecord)
    "Select the buffer specified by BUFFER-OR-NAME in another window.
***************
*** 1241,1247 ****
  automatically choosing a major mode, use \\[find-file-literally]."
    (interactive
     (find-file-read-args "Find file: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(mapcar 'switch-to-buffer (nreverse value))
--- 1251,1257 ----
  automatically choosing a major mode, use \\[find-file-literally]."
    (interactive
     (find-file-read-args "Find file: "
!                         (confirm-nonexistent-file-or-buffer)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(mapcar 'switch-to-buffer (nreverse value))
***************
*** 1261,1267 ****
  expand wildcards (if any) and visit multiple files."
    (interactive
     (find-file-read-args "Find file in other window: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(progn
--- 1271,1277 ----
  expand wildcards (if any) and visit multiple files."
    (interactive
     (find-file-read-args "Find file in other window: "
!                         (confirm-nonexistent-file-or-buffer)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(progn
***************
*** 1284,1290 ****
  expand wildcards (if any) and visit multiple files."
    (interactive
     (find-file-read-args "Find file in other frame: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(progn
--- 1294,1300 ----
  expand wildcards (if any) and visit multiple files."
    (interactive
     (find-file-read-args "Find file in other frame: "
!                         (confirm-nonexistent-file-or-buffer)))
    (let ((value (find-file-noselect filename nil nil wildcards)))
      (if (listp value)
  	(progn
***************
*** 1309,1315 ****
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
--- 1319,1325 ----
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only: "
!                         (confirm-nonexistent-file-or-buffer)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
***************
*** 1326,1332 ****
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only other window: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
--- 1336,1342 ----
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only other window: "
! 			(confirm-nonexistent-file-or-buffer)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
***************
*** 1343,1349 ****
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only other frame: "
!                         (if confirm-nonexistent-file-or-buffer 'confirm-only)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
--- 1353,1359 ----
  Use \\[toggle-read-only] to permit editing."
    (interactive
     (find-file-read-args "Find file read-only other frame: "
!                         (confirm-nonexistent-file-or-buffer)))
    (unless (or (and wildcards find-file-wildcards
  		   (not (string-match "\\`/:" filename))
  		   (string-match "[[*?]" filename))
*** trunk/lisp/minibuffer.el.~1.60.~	2008-11-08 11:52:55.000000000 -0500
--- trunk/lisp/minibuffer.el	2008-11-24 00:15:57.000000000 -0500
***************
*** 578,584 ****
              (delete-region beg end))))
        (exit-minibuffer))
  
!      ((eq minibuffer-completion-confirm 'confirm-only)
        ;; The user is permitted to exit with an input that's rejected
        ;; by test-completion, but at the condition to confirm her choice.
        (if (eq last-command this-command)
--- 578,584 ----
              (delete-region beg end))))
        (exit-minibuffer))
  
!      ((eq minibuffer-completion-confirm 'confirm)
        ;; The user is permitted to exit with an input that's rejected
        ;; by test-completion, but at the condition to confirm her choice.
        (if (eq last-command this-command)
***************
*** 586,591 ****
--- 586,597 ----
          (minibuffer-message "Confirm")
          nil))
  
+      ((eq minibuffer-completion-confirm 'confirm-after-completion)
+       (if (eq last-command 'minibuffer-complete)
+ 	  (progn (minibuffer-message "Confirm")
+ 		 nil)
+ 	(exit-minibuffer)))
+ 
       (t
        ;; Call do-completion, but ignore errors.
        (case (condition-case nil

Re: C-x C-b and C-x C-f bugging about confirmation

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Just read what you wrote: "I don't want to do that" is not much of
 > an argument.  Even if you add underscores.

It may not be much of an argument, but in UI issues it's the only one
that matters, aside from technological feasibility.  Your argument
reduces to "I don't want to use C-x C-v," after all.

Re: C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

Please stop insisting that I, and other should try this.  That is not
how one carries a discussion.

The current behaviour breaks several tings,

0) TRAMP, now you do not know when you need to type RET**2, and have
   to look at the minibuffer.

1) Keyboard macro, you have no idea if a buffer or file exists, and
   have to explicitly do M-: (find-file "FOO") RET instead of the
   plain more logical C-x C-f FOO RET.

2) RET now has a unclear meaning, it is impossible to know if RET will
   ask you something, or not.

Please, just revert the current default to what it was perviously, and
stop insisting that people should try this.  Alan, I believe,
suggested a nice solution to the problem.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>> Just read what you wrote: "I don't want to do that" is not much of
>> an argument.  Even if you add underscores.
> It may not be much of an argument, but in UI issues it's the only one
> that matters, aside from technological feasibility.  Your argument
> reduces to "I don't want to use C-x C-v," after all.

No, my argument is based on frequency and amount of work&disruption of
each situation.  For pure personal preferences, I use `setq' in my .emacs.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

>>> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
>>> solution to this problem though.
>> 
>> Indeed, it would cover 99% of my cases.

> See attached patch (necessary doc changes not included).  Any
> objections?

>   (defcustom confirm-nonexistent-file-or-buffer nil
>     "If non-nil, confirmation is requested before visiting a new file or buffer.
> + If the value is `after-completion', confirmation is only
> + requested if the user calls `minibuffer-complete-and-exit'
> + immediately after `minibuffer-complete'.
>   This affects commands like `switch-to-buffer' and `find-file'."
>     :group 'find-file
>     :version "23.1"
>     :type 'boolean)
  
Looks OK, except that it needs to default to after-completion.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> The current behaviour breaks several tings,

I gave several advantages of using `confirm'.  I never claimed it's
perfect, just that its advantages outweigh (and by a large margin in my
experience) its disadvantages, based on frequency.
Listing disadvantages doesn't bring much to the discussion unless you
can argue that those are frequent.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Alfred M. Szmidt]

Alan purposed a good solution, and Chong Yidong implemented it.  Many
thanks to Alan and Chong for doing this.

Re: C-x C-b and C-x C-f bugging about confirmation

[mail]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Alan Mackenzie's tweak to the [Confirm] prompt seems like an excellent
>>>> solution to this problem though.
>>> 
>>> Indeed, it would cover 99% of my cases.
>
>> See attached patch (necessary doc changes not included).  Any
>> objections?
>
> Looks OK, except that it needs to default to after-completion.
>

Yes, the patch looks good, and after-completion seems like a sane
default.

Re: C-x C-b and C-x C-f bugging about confirmation

[Miles Bader]

Patch seems to work well.

I have a few of my own custom completion commands which I'd like to be
treated like`minibuffer-complete' for purposes of confirmation; any
objections to the following additional patch?

Thanks,

-Miles


2008-11-25  Miles Bader  <miles@gnu.org>

	* minibuffer.el (minibuffer-confirm-exit-commands): New variable.
	(minibuffer-complete-and-exit): Use it.

--- orig/lisp/minibuffer.el
+++ mod/lisp/minibuffer.el
@@ -542,6 +542,10 @@
       ;; through the previous possible completions.
       (setq completion-all-sorted-completions (cdr all)))))
 
+(defvar minibuffer-confirm-exit-commands '(minibuffer-complete)
+  "A list of commands which cause an immediately following
+`minibuffer-complete-and-exit' to ask for extra confirmation.")
+
 (defun minibuffer-complete-and-exit ()
   "Exit if the minibuffer contains a valid completion.
 Otherwise, try to complete the minibuffer contents.  If
@@ -595,7 +599,7 @@
      ((eq minibuffer-completion-confirm 'confirm-after-completion)
       ;; Similar to the above, but only if trying to exit immediately
       ;; after typing TAB (this catches most minibuffer typos).
-      (if (eq last-command 'minibuffer-complete)
+      (if (memq last-command minibuffer-confirm-exit-commands)
 	  (progn (minibuffer-message "Confirm")
 		 nil)
 	(exit-minibuffer)))


-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> I have a few of my own custom completion commands which I'd like to be
> treated like`minibuffer-complete' for purposes of confirmation; any
> objections to the following additional patch?

Looks good.  Please add minibuffer-complete-word in there as well.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Tue, 25 Nov 2008 13:03:54 +0900
> Cc: Juri Linkov <juri@jurta.org>, ams@gnu.org,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> I have a few of my own custom completion commands which I'd like to be
> treated like`minibuffer-complete' for purposes of confirmation; any
> objections to the following additional patch?

Are we going to continue to add new features, the freeze
notwithstanding?  If nothing else, this is a stab in the back of the
manual updating job, that is under way for at least two or three
weeks.

Re: C-x C-b and C-x C-f bugging about confirmation

[Romain Francoise]

These changes are apparently incompatible with partial completion
mode; opening a non-existing file is impossible with an Emacs built
a few minutes ago:

   1. emacs -Q
   2. M-x partial-completion-mode RET
   3. C-x C-f foo.txt RET

Hitting RET shows [No match] in the minibuffer instead of creating
the buffer.  It works with my previous Emacs (built 2008-11-21).

Re: C-x C-b and C-x C-f bugging about confirmation

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

> These changes are apparently incompatible with partial completion
> mode; opening a non-existing file is impossible with an Emacs built
> a few minutes ago:
>
>    1. emacs -Q
>    2. M-x partial-completion-mode RET
>    3. C-x C-f foo.txt RET
>
> Hitting RET shows [No match] in the minibuffer instead of creating
> the buffer.  It works with my previous Emacs (built 2008-11-21).

Should be fixed now, thanks.

Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier]

> These changes are apparently incompatible with partial completion
> mode; opening a non-existing file is impossible with an Emacs built
> a few minutes ago:

>    1. emacs -Q
>    2. M-x partial-completion-mode RET
>    3. C-x C-f foo.txt RET

BTW, while partial-completion-mode is not explicitly marked as obsolete
yet, I do consider it as obsolete.  If there's some particular reason
why you use it, I'd like to hear about it.


        Stefan

partial-completion-mode (was: C-x C-b and C-x C-f bugging about confirmation)

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> BTW, while partial-completion-mode is not explicitly marked as
> obsolete yet, I do consider it as obsolete.  If there's some
> particular reason why you use it, I'd like to hear about it.

The reason is that I've always used it, and I'm not aware of
built-in replacements for its features. :)

For example, it binds SPC in the minibuffer to a command which makes
completion *go forward* instead of just completing the current word,
which enables e.g. M-x f SPC lib RET to run find-library, M-x isp
SPC c SPC d for ispell-change-dictionary, etc.  I never use TAB for
completion in the minibuffer, SPC is much more convenient to type
(I use ido for buffer/file completion).

I also use the partial completion itself (I often use M-x kg RET for
kill-grep), but admittedly I think I could live without it.

Re: partial-completion-mode

[Stefan Monnier]

>> BTW, while partial-completion-mode is not explicitly marked as
>> obsolete yet, I do consider it as obsolete.  If there's some
>> particular reason why you use it, I'd like to hear about it.

> The reason is that I've always used it, and I'm not aware of
> built-in replacements for its features. :)

> For example, it binds SPC in the minibuffer to a command which makes
> completion *go forward* instead of just completing the current word,
> which enables e.g. M-x f SPC lib RET to run find-library, M-x isp
> SPC c SPC d for ispell-change-dictionary, etc.  I never use TAB for
> completion in the minibuffer, SPC is much more convenient to type
> (I use ido for buffer/file completion).

I just fixed a bug in minibuffer.el.
Now if you (setq completion-styles '(partial-completion)), your
M-x f SPC lib RET works just fine.  M-x isp SPC c SPC d won't quite
work: you need an extra SPC before the `c'.  Funnily enough, this
example only works with partial-completion-mode thanks to a bug
introduced in Emacs-21 (which causes some internal test to use the
whole minibuffer, including the prompt, to decide whether completion is
done).

BTW, using `-' (that's what I use) instead of SPC should work as well if
not better, with less magic.  But it's a bit more difficult to
type, admittedly.

> I also use the partial completion itself (I often use M-x kg RET for
> kill-grep), but admittedly I think I could live without it.

How do you get M-x kg RET to complete to kill-grep?  Doesn't work
for me.


        Stefan

Re: partial-completion-mode

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Now if you (setq completion-styles '(partial-completion)), your
> M-x f SPC lib RET works just fine.  M-x isp SPC c SPC d won't quite
> work: you need an extra SPC before the `c'.

Thanks, I'll give it a try.

> How do you get M-x kg RET to complete to kill-grep?  Doesn't work
> for me.

If you're starting from emacs -Q you need to load grep.el first, so
either use one of the autoloaded commands, or M-: (require 'grep).

Re: partial-completion-mode

[Stefan Monnier]

>> How do you get M-x kg RET to complete to kill-grep?  Doesn't work
>> for me.

> If you're starting from emacs -Q you need to load grep.el first, so
> either use one of the autoloaded commands, or M-: (require 'grep).

Oh, yes, now I see it.  Funny, I used partial-completion-mode but never
noticed this behavior.


        Stefan

Re: C-x C-b and C-x C-f bugging about confirmation

[Klaus Zeitler]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    Stefan> 
    Stefan> BTW, while partial-completion-mode is not explicitly marked
    Stefan> as obsolete yet, I do consider it as obsolete.

That is the first time I hear this. Is there another package with the
same or similar functionality? With this mode on, emacs would e.g.
expand p-m-c or even pmc to partial-completion-mode. I don't know
any other mode that can do this.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
One nice thing about egotists: they don't talk about other people.

Re: C-x C-b and C-x C-f bugging about confirmation

[Tassilo Horn]

Klaus Zeitler <kzeitler@alcatel-lucent.com> writes:

>     Stefan> BTW, while partial-completion-mode is not explicitly
>     Stefan> marked as obsolete yet, I do consider it as obsolete.
>
> That is the first time I hear this. Is there another package with the
> same or similar functionality?

Yes, the "normal mode of operation".

,----[ C-h v completion-styles RET ]
| completion-styles is a variable defined in `minibuffer.el'.
| Its value is 
| (partial-completion)
| 
| 
| Documentation:
| List of completion styles to use.
| 
| You can customize this variable.
| 
| This variable was introduced, or its default value was changed, in
| version 23.1 of Emacs.
`----

It defaults to (basic partial-completion).  I removed the basic
completion, because I didn't figure out how to trigger partial
completion then?  I think the docstring should mention that somehow.

,----[ C-h v completion-styles-alist RET ]
| completion-styles-alist is a variable defined in `minibuffer.el'.
| Its value is 
| ((basic completion-basic-try-completion completion-basic-all-completions)
|  (emacs22 completion-emacs22-try-completion completion-emacs22-all-completions)
|  (emacs21 completion-emacs21-try-completion completion-emacs21-all-completions)
|  (partial-completion completion-pcm-try-completion completion-pcm-all-completions))
| 
| 
| Documentation:
| List of available completion styles.
| Each element has the form (NAME TRY-COMPLETION ALL-COMPLETIONS)
| where NAME is the name that should be used in `completion-styles',
| TRY-COMPLETION is the function that does the completion, and
| ALL-COMPLETIONS is the function that lists the completions.
`----

Bye,
Tassilo

Re: C-x C-b and C-x C-f bugging about confirmation

[Klaus Zeitler]

>>>>> "Tassilo" == Tassilo Horn <tassilo@member.fsf.org> writes:
    Tassilo> 
    Tassilo> Yes, the "normal mode of operation".
    Tassilo> 
    Tassilo> ,----[ C-h v completion-styles RET ]
    Tassilo> 
    Tassilo> It defaults to (basic partial-completion).  I removed the basic
    Tassilo> completion, because I didn't figure out how to trigger partial
    Tassilo> completion then?

I must have missed it, when I glanced at the NEWS file for emacs 23.
I'll give this a try.

Thanks

Klaus




-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Sometimes I lie awake at night, and I ask, 'Where have I gone wrong?'
Then a voice says to me, 'This is going to take more than one night.

partial-completion-mode

[Romain Francoise]

complete.el has been moved to lisp/obsolete. As far as I know the
built-in partial completion features are still far from being a
replacement for partial-completion-mode, so I think it is premature
to obsolete it.

See previous discussion starting at:

    http://article.gmane.org/gmane.emacs.devel/106273

Re: partial-completion-mode

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The patch below lets you get the behavior you want by doing

>    (setq completion-word-extra-chars '(" " "-"))

Yes, that works for me, and I didn't know about the `initials'
style, that covers the other cases I was missing from p-c-m. So if
that patch goes in, no objection from me for obsoleting complete.el.
Thanks!