unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'John Paul Wallington' <jpw@pobox.com>,
	'Richard G Riley' <rileyrgdev@googlemail.com>,
	'Emacs-Devel' <emacs-devel@gnu.org>
Subject: Re: buffer name completion is case-sensitive now
Date: Sun, 08 Jun 2008 20:24:06 +0200	[thread overview]
Message-ID: <85hcc39455.fsf@lola.goethe.zz> (raw)
In-Reply-To: <85lk1f94vr.fsf@lola.goethe.zz> (David Kastrup's message of "Sun,  08 Jun 2008 20:08:08 +0200")

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




  parent reply	other threads:[~2008-06-08 18:24 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-08 16:40 buffer name completion is case-sensitive now Drew Adams
2008-06-08 17:29 ` John Paul Wallington
2008-06-08 17:48   ` Drew Adams
2008-06-08 18:08     ` David Kastrup
2008-06-08 18:19       ` Richard G Riley
2008-06-08 18:29         ` David Kastrup
2008-06-08 18:32           ` Richard G Riley
2008-06-08 19:03             ` Miles Bader
2008-06-08 19:17             ` Eli Zaretskii
2008-06-08 19:55               ` Richard G Riley
2008-06-08 18:32           ` İsmail Dönmez
2008-06-08 18:48             ` Eli Zaretskii
2008-06-08 18:24       ` David Kastrup [this message]
2008-06-08 19:21         ` Drew Adams
2008-06-08 19:53           ` Drew Adams
2008-06-08 21:21             ` John Paul Wallington
2008-06-08 23:49             ` case-insensitive if no insensitive dups? Drew Adams
2008-06-09  0:01               ` Drew Adams
2008-06-09  1:46               ` Stefan Monnier
2008-06-09  6:38                 ` Drew Adams
2008-06-08 18:13     ` buffer name completion is case-sensitive now Miles Bader
2008-06-08 18:22       ` Óscar Fuentes
2008-06-08 19:01         ` Miles Bader
2008-06-08 19:20       ` Drew Adams
2008-06-08 18:28     ` Eli Zaretskii
2008-06-08 19:21     ` John Paul Wallington
2008-06-08 19:38       ` Drew Adams
2008-06-08 21:01         ` Óscar Fuentes
2008-06-08 21:15           ` Óscar Fuentes
2008-06-08 20:51       ` Juanma Barranquero
2008-06-09  1:47       ` Stefan Monnier
2008-06-09  6:43         ` Drew Adams
2008-06-10  1:11           ` Stefan Monnier
2008-06-10  1:29             ` Richard G Riley
2008-06-10  2:39               ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85hcc39455.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=jpw@pobox.com \
    --cc=rileyrgdev@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).