buffer name completion is case-sensitive now

buffer name completion is case-sensitive now

[Drew Adams]

Sometime between April 19 and May 4, at least on Windows, buffer-name completion
seems to have been changed to become case-sensitive.

I have been annoyed by this, and I just got a message from an Icicles user who
complained of the same thing, thinking it had something to do with Icicles.

Was this change intentional? I didn't notice any discussion of it here, and I
can find nothing in NEWS about it? I'm surprised no one has mentioned this yet.

To me, this is a bug. If this is intentional, however, count me as one vote
against it. If the decision is final, then how about at least adding a user
option to deal with this? Users should not need to redefine `read-buffer' or
commands that use buffer-name completion, just to bind `completion-ignore-case'
to non-nil.

Re: buffer name completion is case-sensitive now

[John Paul Wallington]

On 8 Jun 2008, at 17:40, Drew Adams wrote:

> Sometime between April 19 and May 4, at least on Windows, buffer- 
> name completion
> seems to have been changed to become case-sensitive.
>
> I have been annoyed by this, and I just got a message from an  
> Icicles user who
> complained of the same thing, thinking it had something to do with  
> Icicles.
>
> Was this change intentional? I didn't notice any discussion of it  
> here, and I
> can find nothing in NEWS about it? I'm surprised no one has  
> mentioned this yet.

The change is experimental rather than final.  I've documented it in  
NEWS for now.

>
> To me, this is a bug. If this is intentional, however, count me as  
> one vote
> against it. If the decision is final, then how about at least adding  
> a user
> option to deal with this? Users should not need to redefine `read- 
> buffer' or
> commands that use buffer-name completion, just to bind `completion- 
> ignore-case'
> to non-nil.

With the introduction of `read-file-name-completion-ignore-case'  
there's less need to have an MS-Windows specific
default value of `completion-ignore-case'.  However, buffer names --  
particularly those that are based upon filenames -- would probably  
benefit from case-insensitivity in completion, at least on systems  
with case insensitive file systems.  Are there any other examples  
where case sensitivity is problematic?

RE: buffer name completion is case-sensitive now

[Drew Adams]

> > Sometime between April 19 and May 4, at least on Windows, buffer- 
> > name completion seems to have been changed to become
> > case-sensitive.
> >
> > I have been annoyed by this, and I just got a message from an  
> > Icicles user who complained of the same thing, thinking it had
> > something to do with Icicles.
> >
> > Was this change intentional? I didn't notice any discussion of it  
> > here, and I can find nothing in NEWS about it? I'm surprised no
> > one has mentioned this yet.
> 
> The change is experimental rather than final.  I've documented it in  
> NEWS for now.

So I guess you are saying that this change was intentional, not accidental (not
a bug).

No discussion here (AFAICT)? How do such "experiments" get implemented without
any proposal and discussion? 

This changes long-standing standard Emacs behavior. It should be reverted.

> > To me, this is a bug. If this is intentional, however, count me as  
> > one vote against it. If the decision is final, then how about at 
> > least adding a user option to deal with this? Users should not
> > need to redefine `read-buffer' or commands that use buffer-name
> > completion, just to bind `completion-ignore-case' to non-nil.
> 
> With the introduction of `read-file-name-completion-ignore-case'  
> there's less need to have an MS-Windows specific
> default value of `completion-ignore-case'.

Irrelevant. This is about completion of _buffer_ names, not file names. Try
completing `*m' to *Messages* now - doesn't work.

No one is questioning what `read-file-name' should do; this is about
`completing-read' with buffer names.

> However, buffer names -- particularly those that are based
> upon filenames -- would probably benefit from case-insensitivity
> in completion, at least on systems with case insensitive file
> systems.

"Probably"? That has been the behavior for decades. How can it be changed
willy-nilly, with no discussion?

> Are there any other examples  
> where case sensitivity is problematic?

Dunno what you mean. 

Are you proposing to also change the traditional behavior for other kinds of
completion?  I certainly hope other such changes won't be made. 

Or are you asking if the same improper behavior occurs now for more than just
buffer names? I've only noticed it wrt buffer names.

Please revert this "experimental" change.

Re: buffer name completion is case-sensitive now

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> This changes long-standing standard Emacs behavior. It should be
> reverted.

Everything except bug fixes changes long-standing standard Emacs
behavior.  Actually, even bug fixes do...

> "Probably"? That has been the behavior for decades. How can it be
> changed willy-nilly, with no discussion?

A rant is not a discussion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: buffer name completion is case-sensitive now

[Richard G Riley]

David Kastrup <dak@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> This changes long-standing standard Emacs behavior. It should be
>> reverted.
>
> Everything except bug fixes changes long-standing standard Emacs
> behavior.  Actually, even bug fixes do...
>
>> "Probably"? That has been the behavior for decades. How can it be
>> changed willy-nilly, with no discussion?
>
> A rant is not a discussion.

With all due respect, this is quite a fundamental change to the way a
major emacs UI component works. It should remain case insensitive IMO
and Drew's comments were hardly a rant.

Keep up the good work folks - emacs is a wonderful environment.

Re: buffer name completion is case-sensitive now

[David Kastrup]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> "Drew Adams" <drew.adams@oracle.com> writes:
>>
>>> "Probably"? That has been the behavior for decades. How can it be
>>> changed willy-nilly, with no discussion?
>>
>> A rant is not a discussion.
>
> With all due respect, this is quite a fundamental change to the way a
> major emacs UI component works.

On Windows and MacOS, nowhere else.  And the buffer system is not
operating system dependent.

> It should remain case insensitive IMO and Drew's comments were hardly
> a rant.

I suggest you read the whole of Drew's post through again.  There is
very little actual content (mostly repetitions in different words), and
quite loaded vocabulary.  Pretty much the definition of a rant.

> Keep up the good work folks - emacs is a wonderful environment.

As long as one does not have to read the developer list for working with
it...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: buffer name completion is case-sensitive now

[Richard G Riley]

David Kastrup <dak@gnu.org> writes:

> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> "Drew Adams" <drew.adams@oracle.com> writes:
>>>
>>>> "Probably"? That has been the behavior for decades. How can it be
>>>> changed willy-nilly, with no discussion?
>>>
>>> A rant is not a discussion.
>>
>> With all due respect, this is quite a fundamental change to the way a
>> major emacs UI component works.
>
> On Windows and MacOS, nowhere else.  And the buffer system is not
> operating system dependent.

I am sorry - I use Debian and it changed for me. Buffer selection was
always case insensitive for me before. At least I'm pretty sure it
was....

Re: buffer name completion is case-sensitive now

[Miles Bader]

Richard G Riley <rileyrgdev@googlemail.com> writes:
> I am sorry - I use Debian and it changed for me. Buffer selection was
> always case insensitive for me before. At least I'm pretty sure it
> was....

If it was, then it was you who made it so... that has never been the
default.

-Miles

-- 
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

Re: buffer name completion is case-sensitive now

[Eli Zaretskii]

> Date: Sun, 08 Jun 2008 20:32:46 +0200
> From: Richard G Riley <rileyrgdev@googlemail.com>
> Cc: 'Emacs-Devel' <emacs-devel@gnu.org>,
> 	Richard G Riley <rileyrgdev@googlemail.com>,
> 	Drew Adams <drew.adams@oracle.com>, 'John Paul Wallington' <jpw@pobox.com>
> 
> > On Windows and MacOS, nowhere else.  And the buffer system is not
> > operating system dependent.
> 
> I am sorry - I use Debian and it changed for me. Buffer selection was
> always case insensitive for me before. At least I'm pretty sure it
> was....

Well, then please tell in what version of Emacs is that, because in
Emacs 22.1 on Ubuntu it's case-sensitive.

Re: buffer name completion is case-sensitive now

[Richard G Riley]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 08 Jun 2008 20:32:46 +0200
>> From: Richard G Riley <rileyrgdev@googlemail.com>
>> Cc: 'Emacs-Devel' <emacs-devel@gnu.org>,
>> 	Richard G Riley <rileyrgdev@googlemail.com>,
>> 	Drew Adams <drew.adams@oracle.com>, 'John Paul Wallington' <jpw@pobox.com>
>> 
>> > On Windows and MacOS, nowhere else.  And the buffer system is not
>> > operating system dependent.
>> 
>> I am sorry - I use Debian and it changed for me. Buffer selection was
>> always case insensitive for me before. At least I'm pretty sure it
>> was....
>
> Well, then please tell in what version of Emacs is that, because in
> Emacs 22.1 on Ubuntu it's case-sensitive.

This is all very strange. I only noticed the case sensitive change
recently. I had never experienced it before. I am willing to believe
that something else I had loaded made if case insensitive - possibly
ido? But when I dumped IDO in favour of Icicles I noticed the case
sensitive behaviour.

Anyway, I will leave it to you more experienced sorts to figure out the
best way. But, fwiw, I feel it's better to have case insensitive buffer
selection. It just seems quicker and more appropriate.

Re: buffer name completion is case-sensitive now

[İsmail Dönmez]

Hi,

On Sun, Jun 8, 2008 at 9:29 PM, David Kastrup <dak@gnu.org> wrote:
> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> "Drew Adams" <drew.adams@oracle.com> writes:
>>>
>>>> "Probably"? That has been the behavior for decades. How can it be
>>>> changed willy-nilly, with no discussion?
>>>
>>> A rant is not a discussion.
>>
>> With all due respect, this is quite a fundamental change to the way a
>> major emacs UI component works.
>
> On Windows and MacOS, nowhere else.  And the buffer system is not
> operating system dependent.

Unlike Windows, MacOS allows you to format your disk as HFS+ case sensitive.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: buffer name completion is case-sensitive now

[Eli Zaretskii]

> Date: Sun, 8 Jun 2008 21:32:51 +0300
> From: "=?UTF-8?Q?=C4=B0smail_D=C3=B6nmez?=" <ismail@namtrac.org>
> Cc: Emacs-Devel <emacs-devel@gnu.org>
> 
> Unlike Windows, MacOS allows you to format your disk as HFS+ case sensitive.

Actually, Windows has an equivalent option as well, except that it
isn't done via formatting, but rather via a special flag passed to the
API that opens files.  So if we want Emacs on Windows to become
case-sensitive (personally, I don't think this is a good idea for a
number of gory technical reasons), we can do that.

Re: buffer name completion is case-sensitive now

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> This changes long-standing standard Emacs behavior. It should be
>> reverted.
>
> Everything except bug fixes changes long-standing standard Emacs
> behavior.  Actually, even bug fixes do...
>
>> "Probably"? That has been the behavior for decades. How can it be
>> changed willy-nilly, with no discussion?
>
> A rant is not a discussion.

More to the point: the behavior that you vociferate about is the
long-standing standard Emacs behavior with the exception of some
proprietary platforms.

So the question is why have an exception for that?  You bring up
basically two different cases:

a) file-name related buffers.  Do we want to have case-insensitive
completion on them?  When there is case insensitivity to get them, it
would seem like a plausible choice to have case insensitivity to get at
their buffers.  What when case sensitivity was involved in getting them?
Do we want to have buffer completion offer "Makefile" for "mak" even
then we are on a basically case sensitive system?

b) non file-name related buffers like *mail* and *Messages*.  Do we want
to have them share "*m" as prefix with regard to completion?

Overall, it seems to me like there might a case be made for having case
insensitivity all around.  However, this begs the question:

If "Makefile" and "makefile" and "Makefile.unix" and "makefile.dos" can
be different buffer names, how does case insensitive completion deal
with them nicely?

If it does, case insensitivity on buffer completion could probably be
picked to be the default independent of operating system.  I don't
really have an opinion whether I would like it or not.  So it is
something I'd not object to as an experimental setting (we are not even
in feature freeze mode, let alone default freeze mode).

But since the buffer system is not really tied into the file system, I
think it a reasonable hypothesis that the completion default should not
depend on the file system completion default.

I guess we already have Drew's vote about buffer name case sensitivity
on Windows in (even though he confuses "Windows" and "standard").  Other
opinions both of the proprietary case insensitive file system users as
well as others might be interesting.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: buffer name completion is case-sensitive now

[Drew Adams]

> But since the buffer system is not really tied into the file system, I
> think it a reasonable hypothesis that the completion default 
> should not depend on the file system completion default.

I agree.

> I guess we already have Drew's vote about buffer name case sensitivity
> on Windows in (even though he confuses "Windows" and "standard").

I think we should add a user option for this, similar to
`read-file-name-completion-ignore-case': `buffer-name-completion-ignore-case'.

I don't care much what the default value of that option would be. I'd vote for
t, but the important thing is to give users a way to get the behavior they want.



 

RE: buffer name completion is case-sensitive now

[Drew Adams]

I said:

> I think we should add a user option for this, similar to
> `read-file-name-completion-ignore-case': 
> `buffer-name-completion-ignore-case'.

Implementation of respect for such an option would likely be limited to
`read-buffer' and `interactive' buffer specs ("B" and "b").

Unlike the case for `read-file-name' and
`read-file-name-completion-ignore-case', it is impossible for `completing-read'
to reliably determine whether its completion candidates are (all) buffer names.

Re: buffer name completion is case-sensitive now

[John Paul Wallington]

On 8 Jun 2008, at 20:53, Drew Adams wrote:

> I said:
>
>> I think we should add a user option for this, similar to
>> `read-file-name-completion-ignore-case':
>> `buffer-name-completion-ignore-case'.
>
> Implementation of respect for such an option would likely be limited  
> to
> `read-buffer' and `interactive' buffer specs ("B" and "b").
>
> Unlike the case for `read-file-name' and
> `read-file-name-completion-ignore-case', it is impossible for  
> `completing-read'
> to reliably determine whether its completion candidates are (all)  
> buffer names.

Hm.  I guess people should call `read-buffer' when they want a buffer  
name and frob `read-buffer-function' to change its behaviour.  I'll  
propose a simple `read-buffer-completion-ignore-case' change in a  
minute.

case-insensitive if no insensitive dups?

[Drew Adams]

Here's a crazy idea.

Whenever there are no completion candidates that differ only by case, treat
completion as case-insensitive. Even when the governing variables (e.g.
`case-fold-search', `completion-ignores-case') say it needs to be
case-sensitive. IOW, treat the variables as only a worst-case guideline.

Dunno how performant this would be in some cases, or even how feasible it would
be in some cases.

But where possible and performant, it could be handy. In cases where case
couldn't possibly make any difference, users would be able to complete without
bothering with the Shift key. Users could configure the variables, in effect, to
have case sensitivity turn on (only) whenever it makes sense.

On the other hand, a user might sometimes want to be able to test whether
particular case-sensitive candidates are available - s?he might then want to use
case-sensitive matching even when there weren't any alternative candidates with
the same spelling, modulo case.

Perhaps another user option? `completion-ignore-case-unless-dups-flag' or
whatever.

This idea could even be used beyond completion: `case-fold-generously' or
whatever. That is, let matching try to find a case-insensitive match, unless
that leads to some matches that differ only by case.

On the down side, such an approach might sometimes be confusing. Suppose the
first thing you type is `ab', and there are candidates `abcd' and `abcD'.
Assuming case sensitivity is required by the governing variables, it would be
imposed in this case, because of the insensitivity duplicates. If you then hit
`e', however, and there are only the matches `abexyz' and `abeLincoln', then
completion would automatically switch to being case-insensitive.

We could of course choose to never let your input affect things. That is, just
decide once and for all, based on the current domain of candidates, whether it
allows for case-insensitivity. In this case, the fact that your input is `abe'
(or anything else) would have no effect: completion would remain case-sensitive
because of the insensitivity duplicates `abcd' and `abcD'.

That would be quite conservative and much less handy, however. Personally, I'd
opt for allowing the potential confusion of an automatic switch from sensitive
to insensitive, because it would let me complete `*m' to `*Messages*' even if
there were also two buffers `foo' and `FoO'. (There could of course never be a
switch from insensitive to sensitive.)

The performance in the conservative case would be better, because the test would
only be made once (using all domain candidates); it wouldn't be updated for each
character you type (or when you hit `TAB', if there is no incremental
completion).

On the other hand, if the first few characters were allowed to be typed before
making any test, and if your input were used in the test, then performance would
be improved, due to the smaller search space.

To me, that would probably be the way to go: have either a minimum number of
chars (e.g. 1) or a tiny delay, after which your input would be matched against
the candidates to see whether or not matching could be insensitive. If the
minimum were 1 char, then typing `*' would limit the set of buffers to check for
duplicates to just a few. If a delay were used instead, then you might need to
type `*m' a little slowly, to automatically switch to case-insensitive matching
against `*Messages*'.

Just some food for thought.

RE: case-insensitive if no insensitive dups?

[Drew Adams]

I said:

> The performance in the conservative case would be better, 
> because the test would only be made once (using all domain
> candidates); it wouldn't be updated for each character you
> type (or when you hit `TAB', if there is no incremental
> completion).
> 
> On the other hand, if the first few characters were allowed 
> to be typed before making any test, and if your input were
> used in the test, then performance would be improved, due
> to the smaller search space.
> 
> To me, that would probably be the way to go: have either a 
> minimum number of chars (e.g. 1) or a tiny delay, after
> which your input would be matched against the candidates
> to see whether or not matching could be insensitive.

Sorry, for this part I was thinking of incremental completion, as in Icicles.
With vanilla Emacs completion, this would be under user control via TAB: wait
until s?he hits TAB to perform the test.

My remarks about min chars and a delay are pertinent for vanilla Emacs only in
the context of incremental matching, such as in incremental search. They don't
apply to completion. 

Re: case-insensitive if no insensitive dups?

[Stefan Monnier]

> Here's a crazy idea.
> Whenever there are no completion candidates that differ only by case, treat
> completion as case-insensitive. Even when the governing variables (e.g.

I don't consider myself as crazy, but I've already several times
considered doing just that.  I haven't tried to code it up yet, tho.


        Stefan

RE: case-insensitive if no insensitive dups?

[Drew Adams]

> > Here's a crazy idea.
> > Whenever there are no completion candidates that differ 
> > only by case, treat completion as case-insensitive.
> > Even when the governing variables (e.g.
> 
> I don't consider myself as crazy, but I've already several times
> considered doing just that.  I haven't tried to code it up yet, tho.

Glad to hear it. I will think about it also. Maybe one of us (someone) will get
around to trying something out.

Some care needs to be taken to allow user control over this, IMO - exceptions,
etc. The last thing we would want is something that doesn't let you impose
case-sensitive matching when you are sure that is what you want. IOW, we
shouldn't assume you necessarily want generous matching - you might sometimes
want completion to fail if there is no case-sensitive match.

Re: buffer name completion is case-sensitive now

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> With the introduction of `read-file-name-completion-ignore-case'  
>> there's less need to have an MS-Windows specific
>> default value of `completion-ignore-case'.
>
> Irrelevant. This is about completion of _buffer_ names, not file names. Try
> completing `*m' to *Messages* now - doesn't work.
>
> No one is questioning what `read-file-name' should do; this is about
> `completing-read' with buffer names.

Emacs has always been case-sensitive by default on most platforms.

Why should it be any different on windows?

-Miles

-- 
Opportunity, n. A favorable occasion for grasping a disappointment.

Re: buffer name completion is case-sensitive now

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Emacs has always been case-sensitive by default on most platforms.

"most platforms" are those with case-sensitive file systems, right?

> Why should it be any different on windows?

Because Windows' file system is not case-sensitive?

-- 
Oscar

Re: buffer name completion is case-sensitive now

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> Emacs has always been case-sensitive by default on most platforms.
>
> "most platforms" are those with case-sensitive file systems, right?
>
>> Why should it be any different on windows?
>
> Because Windows' file system is not case-sensitive?

As jpw mentioned, filename completion is  handled separately.

The issue (apparently; I have have misread something) is other types of
completion.

-Miles

-- 
Marriage, n. The state or condition of a community consisting of a master, a
mistress and two slaves, making in all, two.

RE: buffer name completion is case-sensitive now

[Drew Adams]

> >> With the introduction of `read-file-name-completion-ignore-case'  
> >> there's less need to have an MS-Windows specific
> >> default value of `completion-ignore-case'.
> >
> > Irrelevant. This is about completion of _buffer_ names, not 
> > file names. Try completing `*m' to *Messages* now - doesn't work.
> >
> > No one is questioning what `read-file-name' should do; this is about
> > `completing-read' with buffer names.
> 
> Emacs has always been case-sensitive by default on most platforms.

My bad; I mistakenly thought that was not the case. 

I used to use Emacs on UNIX a lot, and I still use it sometimes on GNU/Linux,
but I forgot and didn't notice, respectively.

The behavior change I noted was for Windows.

> Why should it be any different on windows?

No good reason that I'm aware of.

It would be good to give users on all platforms an easy way to control the
behavior. E.g. a user option for buffer-name completion case sensitivity.

Re: buffer name completion is case-sensitive now

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 8 Jun 2008 10:48:18 -0700
> Cc: 'Richard G Riley' <rileyrgdev@googlemail.com>,
> 	'Emacs-Devel' <emacs-devel@gnu.org>
> 
> > With the introduction of `read-file-name-completion-ignore-case'  
> > there's less need to have an MS-Windows specific
> > default value of `completion-ignore-case'.
> 
> Irrelevant. This is about completion of _buffer_ names, not file names. Try
> completing `*m' to *Messages* now - doesn't work.
> 
> No one is questioning what `read-file-name' should do; this is about
> `completing-read' with buffer names.

Buffer-name completion was case-insensitive on Windows because there
was no mechanism to request case-insensitive file-name completion
except making _all_ completions case-insensitive.  Now there _is_ a
way to request that for file names only.

I'm not saying that I'm necessarily in favor of the change, I'm just
explaining what John was saying, because it's not ``irrelevant''.

> > Are there any other examples  
> > where case sensitivity is problematic?
> 
> Dunno what you mean. 
> 
> Are you proposing to also change the traditional behavior for other kinds of
> completion?  I certainly hope other such changes won't be made. 
> 
> Or are you asking if the same improper behavior occurs now for more than just
> buffer names? I've only noticed it wrt buffer names.
> 
> Please revert this "experimental" change.

Please at least explain why you think buffer-name completion should be
case-insensitive, on Windows or elsewhere.  Otherwise, this is not a
rational discussion, and will lead nowhere.

Re: buffer name completion is case-sensitive now

[John Paul Wallington]

Drew Adams wrote:

> So I guess you are saying that this change was intentional, not  
> accidental (not
> a bug).
>
> No discussion here (AFAICT)? How do such "experiments" get  
> implemented without
> any proposal and discussion?

I proposed the change on emacs-devel on April 26th 2008 and Stefan  
gave it the go-ahead:
http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01877.html

> This changes long-standing standard Emacs behavior. It should be  
> reverted.

Well, that's a matter of opinion.  The default value of `completion- 
ignore-case' is nil for all other systems bar MS-Windows.  I agree  
with you that buffer names are another case, in addition to filenames,  
where MS-Windows systems should do case-insensitive completion.  I  
think that Emacs on MS-Windows has historically had an exceptional  
default value of t for `completion-ignore-case' precisely to handle  
filename and buffer name completion and that its effect on other  
completions was largely coincidental.  I would like to avoid all  
completion being case-insensitive on MS-Windows.

RE: buffer name completion is case-sensitive now

[Drew Adams]

> > No discussion here (AFAICT)? How do such "experiments" get  
> > implemented without any proposal and discussion?
> 
> I proposed the change on emacs-devel on April 26th 2008 and Stefan  
> gave it the go-ahead:
> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01877.html

Sorry, I didn't notice it. I remember reading that, but I didn't grasp the
consequences.

> > This changes long-standing standard Emacs behavior. It should be  
> > reverted.
> 
> Well, that's a matter of opinion. The default value of `completion- 
> ignore-case' is nil for all other systems bar MS-Windows. 

I was mistaken; I forgot about the behavior on non-Windows platforms.

> I agree with you that buffer names are another case, in addition
> to filenames, where MS-Windows systems should do case-insensitive
> completion.

Actually, I think that buffer-name completion and file-name completion should be
treated independently, regardless of the platform.

I think that users should be able to configure their preference for buffer-name
completion, just as they can for file-name completion.

> I think that Emacs on MS-Windows has historically had an exceptional  
> default value of t for `completion-ignore-case' precisely to handle  
> filename and buffer name completion and that its effect on other  
> completions was largely coincidental.

I agree.

> I would like to avoid all completion being case-insensitive on
> MS-Windows.

I would like to give control over that to users, via an option - regardless of
the platform.

Re: buffer name completion is case-sensitive now

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > No discussion here (AFAICT)? How do such "experiments" get  
>> > implemented without any proposal and discussion?
>> 
>> I proposed the change on emacs-devel on April 26th 2008 and Stefan  
>> gave it the go-ahead:
>> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01877.html
>
> Sorry, I didn't notice it. I remember reading that, but I didn't grasp the
> consequences.

Same here.

[snip]

>> I agree with you that buffer names are another case, in addition
>> to filenames, where MS-Windows systems should do case-insensitive
>> completion.
>
> Actually, I think that buffer-name completion and file-name completion
> should be treated independently, regardless of the platform.

I differ. For an Emacs hacker, `buffer' and `file' are clearly distinct
concepts, but for your average newbie a buffer is just the place where
you edit the file. For him, the name of the buffer is just the file
name, and he expects to refer to it the same way he refers to files. If
he is accustomed to a case-insensitive file system, having to think
about the case of the buffer name is an annoyance.

> I think that users should be able to configure their preference for
> buffer-name completion, just as they can for file-name completion.

Right, and I would add that the defaults should adapt to user
expectations on each platform, if possible.

[snip]

-- 
Oscar

Re: buffer name completion is case-sensitive now

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Actually, I think that buffer-name completion and file-name completion
>> should be treated independently, regardless of the platform.
>
> I differ.
[snip]

Sorry. Wrong interpretation of Drew's words. I agree that buffer name
and file name should have their own completion settings.

-- 
Oscar

Re: buffer name completion is case-sensitive now

[Juanma Barranquero]

On Sun, Jun 8, 2008 at 21:21, John Paul Wallington <jpw@pobox.com> wrote:

> [...] buffer names are another case, in addition to filenames,
> where MS-Windows systems should do case-insensitive completion.

+1

  Juanma

Re: buffer name completion is case-sensitive now

[Stefan Monnier]

> Well, that's a matter of opinion.  The default value of `completion-
> ignore-case' is nil for all other systems bar MS-Windows.  I agree with you
> that buffer names are another case, in addition to filenames,  where
> MS-Windows systems should do case-insensitive completion.  I  think that

Given the fact that buffer-names are generally derived directly from
file-names, I suggest we change read-buffer to obey
read-file-name-completion-ignore-case.


        Stefan

RE: buffer name completion is case-sensitive now

[Drew Adams]

> > Well, that's a matter of opinion.  The default value of `completion-
> > ignore-case' is nil for all other systems bar MS-Windows. I agree
> > with you that buffer names are another case, in addition to
> > filenames,  where MS-Windows systems should do case-insensitive
> > completion. I  think that
> 
> Given the fact that buffer-names are generally derived directly from
> file-names, I suggest we change read-buffer to obey
> read-file-name-completion-ignore-case.

For the record, I disagree. I won't repeat all that was said, but some of us
have pointed out that the two kinds of object are different. Buffer names are
_not_ generally derived directly from file names.

> > Is it okay to install the following change?
> 
> I don't think we need yet-another configuration variable for that.
> We should just reuse read-file-name-completion-ignore-case.

Again, I disagree. A screw is not a nail, even if it is sometimes good enough to
just hammer it in.

Re: buffer name completion is case-sensitive now

[Stefan Monnier]

>> > Well, that's a matter of opinion.  The default value of `completion-
>> > ignore-case' is nil for all other systems bar MS-Windows. I agree
>> > with you that buffer names are another case, in addition to
>> > filenames,  where MS-Windows systems should do case-insensitive
>> > completion. I  think that
>> 
>> Given the fact that buffer-names are generally derived directly from
>> file-names, I suggest we change read-buffer to obey
>> read-file-name-completion-ignore-case.

> For the record, I disagree.

Duly noted...

> I won't repeat all that was said, but some of us have pointed out that
> the two kinds of object are different.  Buffer names are _not_
> generally derived directly from file names.

...but irrelevant if it doesn't come with more concrete arguments.


        Stefan

Re: buffer name completion is case-sensitive now

[Richard G Riley]

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

>>> > Well, that's a matter of opinion.  The default value of `completion-
>>> > ignore-case' is nil for all other systems bar MS-Windows. I agree
>>> > with you that buffer names are another case, in addition to
>>> > filenames,  where MS-Windows systems should do case-insensitive
>>> > completion. I  think that
>>> 
>>> Given the fact that buffer-names are generally derived directly from
>>> file-names, I suggest we change read-buffer to obey
>>> read-file-name-completion-ignore-case.
>
>> For the record, I disagree.
>
> Duly noted...
>
>> I won't repeat all that was said, but some of us have pointed out that
>> the two kinds of object are different.  Buffer names are _not_
>> generally derived directly from file names.
>
> ...but irrelevant if it doesn't come with more concrete arguments.
>
>
>         Stefan

It is very possible that I have lost the track here, but you are surely
not suggesting that buffer selection SHOULD be case sensitive? It
strikes me as rather unfriendly to say the least since many buffers are
application created in mixed case.

Re: buffer name completion is case-sensitive now

[Stefan Monnier]

> It is very possible that I have lost the track here,

Indeed you have ;-)


        Stefan