RE: Entering filenames with spaces

[Drew Adams]

    On 19 Oct 2005, at 03:43, Richard M. Stallman wrote:
    >
    >     Does a filename-minibuffer have an extra keymap?
    >
    > Not at present, but giving it its own keymap is the cleanest
    > way to do this job.

    OK, this is a simple patch now which allows for inputting spaces in
    filenames in the minibuffer, while keeping the binding of space to
    minibuffer-complete-word in other contexts. It introduces a new
    keymap, minibuffer-local-filename-completion-map.

Was this a final decision? If not, let me stir the pot a bit one more time.

Although I argued previously for the utility of SPC as a completion key, I
would prefer having SPC self-insert, if it would also mean keeping the
completion keys the same for file names and other names.

This change means one more keymap for programmers to bind to, if they change
or add minibuffer bindings, and (more importantly) it creates an
inconsistency in user behavior.

One argument that David R. made for having SPC self-insert was a blanket
argument for consistency.  I countered that the minibuffer is already a
special kind of buffer. I argued that "it is important to try to remain
consistent _within_ a given context (mode etc.); it is less important to
impose consistency across all contexts".

This change introduces inconsistency within the same context: minibuffer
completion. If the argument is to not have the minibuffer be so special,
well, this makes it even more special: _sometimes_ it is special.

I understand (I imagine) the reason for not changing SPC except for file
names - it's the same argument I made in general against changing SPC: the
large spacebar is a handy key for completing.

I'm guessing too (no reason was given, I believe) that the reason for having
two distinct behaviors is that SPC is used more often in file names than in
other names.  IOW, this is a compromise, which recognizes the advantages and
disadvantages of each approach, and tries to DTRT.

It's true that function names and variable names are normally spaceless, but
that's not true for buffer names, menu items, or names in general.
Completion is about completing input by matching it against _strings_
(including symbol names).  The completion mechanism is perfectly general,
and it could be argued that it should treat all strings equally. That is,
all printable chars should be self-insertable. I argued this for `?'
previously, but that was rejected.

Although I argued previously for keeping SPC for completion, I changed my
mind (and my icicles.el library), based on the change to self-insert that I
thought Emacs was making. As a result, I've been using SPC as self-insert
for some time now, and I admit that it has taken some getting used to - I
still occasionally try to use SPC to complete a command name.  But I'm happy
with the change - all printable chars self-insert. (The TAB key, as is usual
in Emacs, is an exception.)

I'm not happy, however, with a change that imposes a new
minibuffer-completion map on programmers and two distinct minibuffer
behaviors for SPC on users.  Could this decision please be reconsidered?