Entering filenames with spaces

Entering filenames with spaces

[David Reitter]

On June 25, I suggested to map the space bar to the space character  
in the minibuffer (instead of minibuffer-complete-word). IIRC, people  
seemed to agree and some said that they wouldn't use minibuffer- 
complete-word anyways - especially for filenames it seems to be clear  
that minibuffer-complete-word makes no sense.
Inputting a space in a file name, however, is a pretty common thing  
to do nowadays.

It seems like the suggestion has been forgotten. It'd be good if  
somebody took out this define-key or did whatever is needed! 

Re: Entering filenames with spaces

[James Cloos]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> IIRC, people seemed to agree and some said that they wouldn't
David> use minibuffer- complete-word anyways - especially for
David> filenames it seems to be clear that minibuffer-complete-word
David> makes no sense.  Inputting a space in a file name, however, is
David> a pretty common thing to do nowadays.

I hope a setting will be left to allow either option.  I almost never
have to hit C-q<SPACE> to enter a space in a filename, but regularly
use the spacebar to complete filenames.  Of course those not used to
working mostly at shell prompts, and therefore more used to useing
spaces in filenames will obviously have different habits....

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

Re: Entering filenames with spaces

[Lennart Borgman]

James Cloos wrote:

>I hope a setting will be left to allow either option.  I almost never
>have to hit C-q<SPACE> to enter a space in a filename, but regularly
>use the spacebar to complete filenames.  Of course those not used to
>working mostly at shell prompts, and therefore more used to useing
>spaces in filenames will obviously have different habits....
>  
>
And some of those use Tab for file name completion - in the "shell" too ;-)

Re: Entering filenames with spaces

[James Cloos]

>>>>> "Lennart" == Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

Lennart> And some of those use Tab for file name completion - in the
Lennart> "shell" too ;-)

Yup.  It is just hard to even /contemplate/ changing a 19 year old
habit. :)

-JimC

Re: Entering filenames with spaces

[David Reitter]

On 12 Aug 2005, at 11:26, James Cloos wrote:

>>>>>> "Lennart" == Lennart Borgman <lennart.borgman. 
>>>>>> 073@student.lu.se> writes:
>>>>>>
>
> Lennart> And some of those use Tab for file name completion - in the
> Lennart> "shell" too ;-)
>
> Yup.  It is just hard to even /contemplate/ changing a 19 year old
> habit. :)

Well, I use tab to do that all the time. Interestingly, it is bound  
to minibuffer-complete, as opposed to SPC, which is bound to  
minibuffer-complete-word.
Don't know if that makes a difference for file names.

Either way, I guess it is reasonable to give priority to the native  
character, i.e. space. If someone wants to map SPC to whatever, they  
can to that by adding the key to the keymap - right?

-- D

RE: Entering filenames with spaces

[Drew Adams]

    David> IIRC, people seemed to agree and some said that they wouldn't
    David> use minibuffer- complete-word anyways - especially for
    David> filenames it seems to be clear that minibuffer-complete-word
    David> makes no sense.  Inputting a space in a file name, however, is
    David> a pretty common thing to do nowadays.

    I hope a setting will be left to allow either option.  I almost never
    have to hit C-q<SPACE> to enter a space in a filename, but regularly
    use the spacebar to complete filenames.  Of course those not used to
    working mostly at shell prompts, and therefore more used to useing
    spaces in filenames will obviously have different habits....

I agree: This should be an option. On the other hand, David has a good
point.

Completion should, other things being equal, be done by keys that are not
normally printable or self-insertable. Using TAB for completion is good,
because TAB in Emacs is generally not just self-insert - it's bound to a
command to indent properly.

But SPACE is present in filenames, and it could also be present in other
minibuffer input strings (completing-read etc. could be called by any
function, to complete any string). The arguments that I see for making this
optional (that is, not getting rid of space completion altogether) are 1)
habit and 2) SPACE is a very convenient key to hit. #2 is important, IMO.

For those who want to use something besides SPC for word completion, a good
candidate is a left-hand key that is normally a prefix key, and that doesn't
have much use in the minibuffer - a key such as C-SPC or C-z (C-x could
still be useful in the minibuffer in C-x C-x, and perhaps C-c should still
be reserved for users).

FWIW - In my own library (http://www.emacswiki.org/cgi-bin/wiki/icicles.el),
I do this:

- Provide an option for the key sequence to use for word completion.
- Use SPC as the default value of that option (same behavior as usual).
- Bind C-SPC to a trivial command that does the same thing as `C-q SPC'.

This gives you the convenience of using the spacebar for word completion, a
more convenient way to insert a space (`C-SPC' is almost as convenient as
`SPC'), and lets you change things easily if you like.

Re: Entering filenames with spaces

[Andreas Schwab]

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

> This gives you the convenience of using the spacebar for word completion, a
> more convenient way to insert a space (`C-SPC' is almost as convenient as
> `SPC'), and lets you change things easily if you like.

Note that C-SPC (which is often the same as C-@ on text terminals) is
already bound to set-mark-command.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Entering filenames with spaces

[Drew Adams]

    > This gives you the convenience of using the spacebar for word
    > completion, a
    > more convenient way to insert a space (`C-SPC' is almost as
    > convenient as `SPC'), and lets you change things easily if you like.

    Note that C-SPC (which is often the same as C-@ on text terminals) is
    already bound to set-mark-command.

Yes, of course. But I don't use set-mark-command much in the minibuffer,
personally. I use the mouse to select text there (which I do seldom), and I
can use C-@ if I really need to set mark there.

Anyway, C-SPC is only one suggestion - I like it because it is convenient
(spacebar). Other possible bindings (such as C-z) for space insertion are
not much more convenient than C-q SPC, IMO.

The point is that users are free to get rid of the SPC bindings to
minibuffer-complete-word. I think that David was saying that he never uses
word completion - in that case, just removing the bindings suffices. Those
who do use it have several options, including the alternatives of binding it
to something else (to use SPC for inserting a space) and binding something
else to a command to insert a space. You could even do it one way for
file-name completion and the other way 'round for other completion...

Re: Entering filenames with spaces

[David Reitter]

On 12 Aug 2005, at 16:58, Drew Adams wrote:
>
> The point is that users are free to get rid of the SPC bindings to
> minibuffer-complete-word. I think that David was saying that he  
> never uses
> word completion - in that case, just removing the bindings  
> suffices. Those
> who do use it have several options, including the alternatives of  
> binding it
> to something else (to use SPC for inserting a space) and binding  
> something
> else to a command to insert a space. You could even do it one way for
> file-name completion and the other way 'round for other completion...

I think that would make a lot of sense.

Either way, I want to stress that the default binding of the space  
bar should be too insert a space. Think of a new user, or of a user  
like me who doesn't use a lot of spaces in file names. Don't pressure  
someone into googling for a solution for something as simple as that.  
It's not smart from a UI perspective to assign a highly application- 
specific function to a commonly used key with a fixed meaning, just  
because it's slightly more convenient to a small fraction of users  
instead of hitting Tab.

Remove the binding and allow specialist users who know what they are  
doing to add the binding with a simple define-key.
For non-filename minibuffers where spaces aren't inserted, I don't care.

By the way, mapping ESC to Meta is a very similar thing. Esc is meant  
to let the user "escape" the current situation. But the difference is  
that Esc for Meta is a burned-in, long-standing choice that a lot of  
people (consoles!) are used to, so there's no way one should change it.

-D

RE: Entering filenames with spaces

[Drew Adams]

    > The point is that users are free to get rid of the SPC bindings to
    > minibuffer-complete-word. I think that David was saying that he
    > never uses word completion - in that case, just removing the
    > bindings suffices. Those who do use it have several options,
    > including the alternatives of binding it to something else (to use
    > SPC for inserting a space) and binding something
    > else to a command to insert a space. You could even do it one way for
    > file-name completion and the other way 'round for other completion...

    I think that would make a lot of sense.

Yes, but you then seem to argue against it (?):

    Either way, I want to stress that the default binding of the space
    bar should be too insert a space. Think of a new user, or of a user
    like me who doesn't use a lot of spaces in file names. Don't pressure
    someone into googling for a solution for something as simple as that.
    It's not smart from a UI perspective to assign a highly application-
    specific function to a commonly used key with a fixed meaning, just
    because it's slightly more convenient to a small fraction of users
    instead of hitting Tab.

    Remove the binding and allow specialist users who know what they are
    doing to add the binding with a simple define-key.
    For non-filename minibuffers where spaces aren't inserted, I don't care.

Question: If you don't use word-completion anyway (you use only TAB, not
SPC, for completion, I believe), then why is the current situation a problem
for you? TAB will complete file names that contain spaces. Or are you
referring only to creating a _new_ file that has spaces in its name?

If so, then perhaps you could use, instead, the new command that we
discussed recently for creating a new file (I don't know its name, or even
if it was finally implemented). We discussed it in the context of the File
menu-bar menu, but it would presumably also be made available for use with
`M-x'.

IMO, `find-file*' should use completion, and the spacebar should, by
default, be bound to `minibuffer-word-complete'. The new `create-file'
command (or whatever it's called) could also use completion (to help with
creating files with similar names), but without binding SPC to
minibuffer-complete-word.

I just think that SPC is too convenient for completion to give it up (by
default) to space insertion. Our options include, in addition to what I
outlined earlier (and in order of increasing restrictiveness):

1. Remove SPC for word completion altogether.
2. Do so only for word completion of file names.
3. Do so only for word completion of file names for new file creation.

I think you're arguing for #1 or (as a concession to others) #2. Another
possibility (similar to #3) is to remove word completion altogether for file
creation (only) via `create-file', leaving only TAB (`minibuffer-complete').

You also argue that SPC for space insertion is natural and expected by
people, so it should be the default - non-novices can always rebind it.

There is lots that is unexpected or new in Emacs, and much of it is
desirable because it optimizes ease of use - IOW, some Emacs UI features are
new to people, but they are good. It is better to help new users to learn
the Emacs way of doing things, _if it is better_, than to cater to their
inferior UI habits. If we did not do this, Emacs would abandon all its C-,
M- etc. crazy key bindings that make novices roll their eyes at first sight.
The Emacs UI might seem odd, depending on what one is used to, but that
doesn't, by itself, mean that it is inferior.

The question then is whether or not SPC for completion is one of the "good"
UI features. I think it is, but you disagree. If (take a poll?) we do think
it is a good thing, then it should continue to be the default, but we can
always make it clearer to people how to change the behavior if they don't
like it.

This is a general problem that occurs: If the Emacs way is unexpected, but
superior, we need to 1) teach it to users and encourage them to adopt it,
but also 2) tell them how to obtain the inferior UI behavior that they may
be used to.

If we keep the default completion behavior, then we should definitely let
users know how to insert a space (C-q SPC or, perhaps, C-SPC). This
information should be up front, in the Info discussion of completion. It
could also be added to the *Completions* buffer header whenever SPC is
typed - that way, a newbie who types SPC trying to insert it in a file name
will soon learn how to insert a space.

Re: Entering filenames with spaces

[Lennart Borgman]

>For those who want to use something besides SPC for word completion, a good
>candidate is a left-hand key that is normally a prefix key, and that doesn't
>have much use in the minibuffer - a key such as C-SPC or C-z 
>  
>
C-z is a CUA key for undo and as such is it used in every w32 program.

Re: Entering filenames with spaces

[David Reitter]

On 12 Aug 2005, at 18:50, Drew Adams wrote:

>> The point is that users are free to get rid of the SPC bindings to
>> minibuffer-complete-word. I think that David was saying that he
>> never uses word completion - in that case, just removing the
>> bindings suffices. Those who do use it have several options,
>> including the alternatives of binding it to something else (to use
>> SPC for inserting a space) and binding something
>> else to a command to insert a space. You could even do it one way for
>> file-name completion and the other way 'round for other completion...
>>
>
>     I think that would make a lot of sense.
>
> Yes, but you then seem to argue against it (?):

You get me wrong: what makes a lot of sense is to do it "one way for  
file-name completion and the other 'round for other completion".

>
> Question: If you don't use word-completion anyway (you use only  
> TAB, not
> SPC, for completion, I believe), then why is the current situation  
> a problem
> for you? TAB will complete file names that contain spaces. Or are you
> referring only to creating a _new_ file that has spaces in its name?

Well, find-file starts a new file and you give it a name. Also, when  
you save the buffer, and it doesn't have a name yet (possible if  
buffer created in another way, with "new" in my own implementation),  
or when you "save" the buffer "as", you enter a file name.
Even when you want to enter a file name to load without using  
completion, you get inconsistent behavior: SPC behaves differently  
from 'a'. And it shouldn't.


> IMO, `find-file*' should use completion, and the spacebar should, by
> default, be bound to `minibuffer-word-complete'.

I respectfully agree for the UI reasons I mentioned before. Why not  
map 'x' to the completion function? After all, only a few file names  
have an 'x' in them!

> The new `create-file'
> command (or whatever it's called) could also use completion (to  
> help with
> creating files with similar names), but without binding SPC to
> minibuffer-complete-word.
>
> I just think that SPC is too convenient for completion to give it  
> up (by
> default) to space insertion. Our options include, in addition to  
> what I
> outlined earlier (and in order of increasing restrictiveness):
>
> 1. Remove SPC for word completion altogether.
> 2. Do so only for word completion of file names.
> 3. Do so only for word completion of file names for new file creation.
>
> I think you're arguing for #1 or (as a concession to others) #2.

I'm arguing for #2.

> Another
> possibility (similar to #3) is to remove word completion altogether  
> for file
> creation (only) via `create-file', leaving only TAB (`minibuffer- 
> complete').

So is find-file going to open only existing files from now on?

>
> There is lots that is unexpected or new in Emacs, and much of it is
> desirable because it optimizes ease of use - IOW, some Emacs UI  
> features are
> new to people, but they are good. It is better to help new users to  
> learn
> the Emacs way of doing things, _if it is better_, than to cater to  
> their
> inferior UI habits.

Sorry, but are you saying that entering a space with the space bar is  
an inferior UI habit?
Are you saying that consistency is an inferior UI habit too?


> The Emacs UI might seem odd, depending on what one is used to, but  
> that
> doesn't, by itself, mean that it is inferior.

I think that's too big a discussion to start. The Space bar is  
something so basic, you shouldn't redefine it, at least not by default.

> This is a general problem that occurs: If the Emacs way is  
> unexpected, but
> superior, we need to 1) teach it to users and encourage them to  
> adopt it,
> but also 2) tell them how to obtain the inferior UI behavior that  
> they may
> be used to.

Again, using Space to enter space characters can hardly be thought of  
as inferior. Similarly, using shorter key commands (one modifier, one  
key) to do stuff that I need often (like C-x C-f find-file, or save- 
buffer), and longer ones to do stuff that's less frequent (e.g. M-u  
upcase-word) is not inferior, but a smart move. Note that I'm not  
arguing to change these things now - we're creatures of habit, after  
all.

> If we keep the default completion behavior, then we should  
> definitely let
> users know how to insert a space (C-q SPC or, perhaps, C-SPC). This
> information should be up front, in the Info discussion of  
> completion. It
> could also be added to the *Completions* buffer header whenever SPC is
> typed - that way, a newbie who types SPC trying to insert it in a  
> file name
> will soon learn how to insert a space.

Jesus - more stuff to read for users.  Great. 

RE: Entering filenames with spaces

[Drew Adams]

    >For those who want to use something besides SPC for word completion, a
good
    >candidate is a left-hand key that is normally a prefix key, and that
doesn't
    >have much use in the minibuffer - a key such as C-SPC or C-z

    C-z is a CUA key for undo and as such is it used in every w32 program.

I have no stock in C-z. But how much do you use undo in the minibuffer?
Again, we're only speaking here of bindings in the _minibuffer completion_
keymaps - "no global bindings would be harmed in the process".

My point about C-z was that it is, a priori, a good idea to use:

1. a non-printing key sequence,
2. that is not likely to be useful in the minibuffer,
3. and that is convenient to type.

C-z fits this mould fairly well. You might disagree about #2 (or #3) for
C-z.

In any case, for the same reason that I think C-SPC is handy for inserting a
space, I would recommend C-SPC over C-z for word-completion (for those who
prefer to flip my recommendation to leave SPC bound to word completion).

Re: Entering filenames with spaces

[Lennart Borgman]

Drew Adams wrote:

>    C-z is a CUA key for undo and as such is it used in every w32 program.
>
>I have no stock in C-z. But how much do you use undo in the minibuffer?
>  
>
C-z is a very, very basic editing command and you would expect that to 
work anywhere in w32. Just like C-c, C-x and C-v. Cua-mode takes care of 
this in Emacs in a very good way in most situations. It works in the 
minibuffer too.

RE: Entering filenames with spaces

[Drew Adams]

    > There is lots that is unexpected or new in Emacs, and much of it is
    > desirable because it optimizes ease of use - IOW, some Emacs UI
    > features are new to people, but they are good. It is better to help
    > new users to learn the Emacs way of doing things, _if it is better_,
    > than to cater to their inferior UI habits.

    Sorry, but are you saying that entering a space with the space bar is
    an inferior UI habit?
    Are you saying that consistency is an inferior UI habit too?

Sorry, but am I saying that? I ask you - what did I say?

Nothing was said in that paragraph about spaces or space bars or
consistency. And, even in the general context discussed there, I mentioned
(and _emphasized_) the conditional: _IF_ a GIVEN Emacs UI behavior is
superior, THEN it is better to encourage its use than to abandon it, even if
it is new to people.

I was making the general argument that it is not enough to say that
something is new or unexpected in order to consider it bad - that doesn't
necessarily make it a good candidate for the scrap bin. I was countering
your too-simple argument that unexpected implies bad. Unexpected implies bad
if all other things are equal (maybe). If you want to apply this general
rule to a specific case, you need to show that its equality condition is
true.

I took the time to write the paragraph carefully (for you, not for me). You
can take the time to read it carefully, instead of taking the time to rebut
a straw-man of your own making.

Some features in the Emacs UI are not superior (still), alas, but many
features are superior. I raised the _question_ (not in the quoted paragraph)
whether using space bar to complete user input is a good idea. I suggested
that you take a poll (_if you_ want to change the status quo), and I gave my
personal opinion (not in the quoted paragraph): it _is_ a good idea overall
(and I gave some reasons). Just one vote.

WRT consistency - There are good, general reasons for sacrificing some
consistency between behavior in the minibuffer and behavior in the average
text buffer. The existing inconsistency does not end with using SPC for
completion - the minibuffer is _not_ your average buffer. (That is not, in
itself, an argument for arbitrary inconsistency; it is only an argument
against blindly weilding the sword of consistency.)

It is important to try to remain consistent _within_ a given context (mode
etc.); it is less important to impose consistency across all contexts. The
devil is in the details - a general, blanket Consistency Crusade is not
convincing. As always: IMO only.

    > The Emacs UI might seem odd, depending on what one is used to, but
    > that doesn't, by itself, mean that it is inferior.

    I think that's too big a discussion to start.

Being odd is not, _by itself_, proof of inferiority. Does that assertion
need a big discussion? My point is that you need to prove more than mere
oddness, to demonstrate weakness.

    The Space bar is something so basic, you shouldn't redefine it,
    at least not by default.

As far as Emacs is concerned, it is you, not I, who proposes to redefine the
space bar in the minibuffer. I'm happy leaving it as a word completor.

    > If we keep the default completion behavior, then we should
    > definitely let users know how to insert a space (C-q SPC or,
    > perhaps, C-SPC). This information should be up front, in the
    > Info discussion of completion. It could also be added to the
    > *Completions* buffer header whenever SPC is typed - that way,
    > a newbie who types SPC trying to insert it in a file name
    > will soon learn how to insert a space.

    Jesus - more stuff to read for users.  Great.

What is your problem? I said, IF we keep the present behavior, THEN it would
good to let users know how to enter a space - precisely because of the
possible confusion (inconsistency) that you point out. That is your only
argument (consistency), so far. I support you in that, as far as it goes,
and this is my suggestion for dealing with it. If you can summon reasons why
more drastic surgery is called for, then please do.

You don't want to keep the present behavior. Fine; that's clear. But IF
deciders (RMS, poll, Godot, OBL, Le Pape, Rumsfeld, the Great Pumpkin,...)
decided to keep it, THEN would you be against helping users learn how to
enter a space? You might not especially like reading (see above), but others
might appreciate a one-line tip: "To insert a space, use `C-SPC'".

Re: Entering filenames with spaces

[Thien-Thi Nguyen]

David Reitter <david.reitter@gmail.com> writes:

> I respectfully agree for the UI reasons I mentioned before. Why not
> map 'x' to the completion function? After all, only a few file names
> have an 'x' in them!

traditionally, spaces in filenames break lots of unixoid tools, and were
thus generally shunned (finicky quoters excepted).  thus, any argument
based on favoring the many at the expense of the few will work both for
and against keeping the default binding, depending on the particulars of
the sampled demographic.  beware: that's what politicians do!

thi

Re: Entering filenames with spaces

[Juri Linkov]

> In any case, for the same reason that I think C-SPC is handy for
> inserting a space, I would recommend C-SPC over C-z for
> word-completion (for those who prefer to flip my recommendation
> to leave SPC bound to word completion).

To insert one space in the minibuffer, you can use M-SPC.  To insert
more spaces, you can give it a numeric argument.  However, this is
not much more convenient than C-q SPC.

If the consensus will be reached to get rid of the SPC bindings,
do not rebind it to C-z or to C-SPC.  C-z is too unnatural key for
this and by default it iconifies the frame.  C-SPC is useful in the
minibuffer to set mark.

A better replacement key binding for minibuffer-complete-word would be
S-TAB (but not M-TAB because it can be useful to complete symbols
in the minibuffer from the external table).

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

Re: Entering filenames with spaces

[David Kastrup]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> David Reitter <david.reitter@gmail.com> writes:
>
>> I respectfully agree for the UI reasons I mentioned before. Why not
>> map 'x' to the completion function? After all, only a few file names
>> have an 'x' in them!
>
> traditionally, spaces in filenames break lots of unixoid tools,

Wrong.  Spaces in filenames are no problem to pretty much _any_
"unixoid" tool.  The only place where they need escaping is in shells;
and if you use file name completion, it will be provided automatically
(i.e. by bash).

Since desktop environments become more and more common for unixoid
systems including free systems, spaces in file names become more and
more common as well: certainly more common than most other special
characters in file names.

> and were thus generally shunned (finicky quoters excepted).  thus,
> any argument based on favoring the many at the expense of the few
> will work both for and against keeping the default binding,

The "many" are not just Windows users (by the way: spaces need quoting
in the Windows command line, too).  They are all users that don't rely
on the command line for most of their work.  And that certainly
includes most users of free systems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Entering filenames with spaces

[James Cloos]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> I want to stress that the default binding of the
David> space bar should be too insert a space.

Just to be clear, and since I was among the first to reply, I do
agree that the default should be self-insert.

-JimC

Re: Entering filenames with spaces

[Richard M. Stallman]

It is not clear a priori which definition of SPC when reading file
names will please more users.  Some users like the completion
definition, while others find it gets it the way.

However, I tend to think that the completion definition is not
essential, and is better for advanced users, while it can screw
beginners who don't know enough to use C-q SPC.  Therefore,
I have concluded we should redefine SPC.

The various proposals for other ways to enter a space would not help.
None of them is self-evident, so they would only be good for advanced
users.  Their only advantage over C-q SPC would be greater ease
of typing, but not much.  And this case does not arise often enough
to make that ease of typing important.

Would someone like to implement this change, and ack to me?

Re: Entering filenames with spaces

[Thien-Thi Nguyen]

David Kastrup <dak@gnu.org> writes:

> Wrong.  Spaces in filenames are no problem to pretty much _any_
> "unixoid" tool.  The only place where they need escaping is in shells;
> and if you use file name completion, it will be provided automatically
> (i.e. by bash).

well, i consider the shell a unixoid tool (perhaps the quintessential
one, since with it you can compose even more tools).  in any case,
programs and scripts often invoke(d) the shell, passing it unprocessed
filenames, assuming that filenames don't have spaces.

the lack of quoting discipline in these programs' communications is a
self-reenforcing phenomenon.  cool-prog.sh can't handle spaces in
filenames but i find cool-prog.sh useful, so i don't use spaces in
filenames i pass it.  when writing my-hack (in whatever language), which
invokes cool-prog.sh, it's so much easier to propagate the ingrained
mindset.  etc.

> Since desktop environments become more and more common for unixoid
> systems including free systems, spaces in file names become more and
> more common as well: certainly more common than most other special
> characters in file names.

no doubt.

> The "many" are not just Windows users (by the way: spaces need quoting
> in the Windows command line, too).  They are all users that don't rely
> on the command line for most of their work.  And that certainly
> includes most users of free systems.

of course, it is worth the effort to change things to be more robust.
iirc, first couple releases of osx had this very problem (among others).
apple had to invest engineer hours to fix it.

however, we are not talking about robustness per se; indeed, emacs can
handle spaces in filenames.  we are talking about the age-old class of
problem called "preferred default keybindings".  towards that end, i am
in favor of leaving SPC for completion, and adding a blurb and fragment
of ~/.emacs code to the manual explaining how to (1) self-insert SPC for
filenames; (2) arrange for (1) to be the default.

wherever the blurb lands, a pointer to it will surely find its way into
every faq and wiki searched by the desperately disenfranchised.  cue
next 20 messages: "but those people SHOULDN'T HAVE TO munge ~/.emacs for
such a simple thing!"  feh.

thi

Re: Entering filenames with spaces

[David Kastrup]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Wrong.  Spaces in filenames are no problem to pretty much _any_
>> "unixoid" tool.  The only place where they need escaping is in shells;
>> and if you use file name completion, it will be provided automatically
>> (i.e. by bash).
>
> however, we are not talking about robustness per se; indeed, emacs
> can handle spaces in filenames.  we are talking about the age-old
> class of problem called "preferred default keybindings".  towards
> that end, i am in favor of leaving SPC for completion, and adding a
> blurb and fragment of ~/.emacs code to the manual explaining how to
> (1) self-insert SPC for filenames; (2) arrange for (1) to be the
> default.

Please note that TAB is perfectly common for completion.  We currently
have the minibuffer bindings of minibuffer-complete on TAB, and
minibuffer-complete-word on space.  I severely doubt that anybody
really requires the latter over the former on a regular basis.

> wherever the blurb lands, a pointer to it will surely find its way
> into every faq and wiki searched by the desperately disenfranchised.
> 
> cue next 20 messages: "but those people SHOULDN'T HAVE TO munge
> ~/.emacs for such a simple thing!"  feh.

I don't think that our main priority for keybindings should be to
annoy people into reading the manual.  Even though the traditional
backspace (= C-h) binding on ttys did pretty much that, it was never
really a big selling point for Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Entering filenames with spaces

[Thien-Thi Nguyen]

David Kastrup <dak@gnu.org> writes:

> Please note that TAB is perfectly common for completion.

ok, noted.

> I don't think that our main priority for keybindings should be to
> annoy people into reading the manual.  Even though the traditional
> backspace (= C-h) binding on ttys did pretty much that, it was never
> really a big selling point for Emacs.

right.  we want to annoy them later, once they discover elisp and posit
some crazy feature like minibuffer-complete-word (bound to SPC), into
rereading these archives!  ok, i've done my part.  btw, looks like there
won't be 20 followups, after all; rms has decided to make the change.

thi

Re: Entering filenames with spaces

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Sat, 13 Aug 2005 10:40:34 -0400
> Cc: emacs-devel@gnu.org
> 
> However, I tend to think that the completion definition is not
> essential, and is better for advanced users, while it can screw
> beginners who don't know enough to use C-q SPC.  Therefore,
> I have concluded we should redefine SPC.

Please, let's have an option that would turn off this new behavior and
revert to the old one.  (It could be initially off, i.e. the new
behavior could be the default.)  I'm sure there are people who will be
pissed off by this change.

Re: Entering filenames with spaces

[Stefan Monnier]

>> However, I tend to think that the completion definition is not
>> essential, and is better for advanced users, while it can screw
>> beginners who don't know enough to use C-q SPC.  Therefore,
>> I have concluded we should redefine SPC.

> Please, let's have an option that would turn off this new behavior and
> revert to the old one.  (It could be initially off, i.e. the new
> behavior could be the default.)  I'm sure there are people who will be
> pissed off by this change.

I'd expect that people who use SPC for completion are pretty seasoned Emacs
users, so they shouldn't be too annoyed by having to add

   (define-key minibuffer-completion-map " " 'minibuffer-complete-word)

in their .emacs.  Adding an option for it would only be useful for people
who configure their Emacs exclusively with Custom.


        Stefan

Re: Entering filenames with spaces

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 14 Aug 2005 02:20:43 -0400
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> > Please, let's have an option that would turn off this new behavior and
> > revert to the old one.  (It could be initially off, i.e. the new
> > behavior could be the default.)  I'm sure there are people who will be
> > pissed off by this change.
> 
> I'd expect that people who use SPC for completion are pretty seasoned Emacs
> users, so they shouldn't be too annoyed by having to add
> 
>    (define-key minibuffer-completion-map " " 'minibuffer-complete-word)
> 
> in their .emacs.

You must be kidding!  Since when people who are accustomed to
SPC-completion are automatically supposed to be keymap wizards?  (I
wasn't talking about myself when I wrote the request above.)

Re: Entering filenames with spaces

[Richard M. Stallman]

    Please, let's have an option that would turn off this new behavior and
    revert to the old one.  (It could be initially off, i.e. the new
    behavior could be the default.)  I'm sure there are people who will be
    pissed off by this change.

The option will be to call define-key.

Re: Entering filenames with spaces

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> users, so they shouldn't be too annoyed by having to add
>> 
>>    (define-key minibuffer-completion-map " " 'minibuffer-complete-word)
>> 
>> in their .emacs.
>
> You must be kidding!  Since when people who are accustomed to
> SPC-completion are automatically supposed to be keymap wizards?  (I
> wasn't talking about myself when I wrote the request above.)

We would obviously document the new behaviour in NEWS, so we can just
include the above line as instructions how to restore the old behaviour.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Entering filenames with spaces

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Mon, 15 Aug 2005 09:58:36 +0200
> 
> >>    (define-key minibuffer-completion-map " " 'minibuffer-complete-word)
> >> 
> >> in their .emacs.
> >
> > You must be kidding!  Since when people who are accustomed to
> > SPC-completion are automatically supposed to be keymap wizards?  (I
> > wasn't talking about myself when I wrote the request above.)
> 
> We would obviously document the new behaviour in NEWS, so we can just
> include the above line as instructions how to restore the old behaviour.

It is IMHO insufficient to mention this in NEWS and hope that users
will look there for such recipes.  NEWS is not the regular place to
look for customization tips.

In addition, this particular keymap is somewhat obscure (even experts
such as Stefan make mistakes coming up with its correct name ;-).  The
User manual mentions it in one place, but doesn't really tell when it
is used (it refers to ``permissive completion'', which is not in the
index); that doesn't help users in finding what variable to hack and
how.

Re: Entering filenames with spaces

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On 13 Aug 2005, at 15:40, Richard M. Stallman wrote:

> However, I tend to think that the completion definition is not
> essential, and is better for advanced users, while it can screw
> beginners who don't know enough to use C-q SPC.  Therefore,
> I have concluded we should redefine SPC.
>
> Would someone like to implement this change, and ack to me?


Done. The patch is attached. Please apply if it's OK - I can't.
Maybe this needs to be documented in NEWS as well.

src/ChangeLog:

2005-10-15  David Reitter  <david.reitter@gmail.com>

         * minibuf.c (keys_of_minibuf): Do not map Space to  
minibuffer-complete-word.


lisp/ChangeLog:

2005-10-15  David Reitter <david.reitter@gmail.com>

         * complete.el (PC-bindings): Do not map Space to
         minibuffer-complete-word when restoring the keymap.




[-- Attachment #2: minibuffer-space.patch --]
[-- Type: application/octet-stream, Size: 1358 bytes --]

Index: src/minibuf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/minibuf.c,v
retrieving revision 1.286
diff -c -r1.286 minibuf.c
*** src/minibuf.c	30 Sep 2005 18:30:10 -0000	1.286
--- src/minibuf.c	15 Oct 2005 17:37:01 -0000
***************
*** 2890,2897 ****
  
    initial_define_key (Vminibuffer_local_completion_map, '\t',
  		      "minibuffer-complete");
-   initial_define_key (Vminibuffer_local_completion_map, ' ',
- 		      "minibuffer-complete-word");
    initial_define_key (Vminibuffer_local_completion_map, '?',
  		      "minibuffer-completion-help");
  
--- 2890,2895 ----
Index: lisp/complete.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/complete.el,v
retrieving revision 1.45
diff -c -r1.45 complete.el
*** lisp/complete.el	6 Aug 2005 22:13:42 -0000	1.45
--- lisp/complete.el	15 Oct 2005 17:37:01 -0000
***************
*** 150,156 ****
  	   ;; These bindings are the default bindings.  It would be better to
  	   ;; restore the previous bindings.
  	   (define-key completion-map "\t"	'minibuffer-complete)
- 	   (define-key completion-map " "	'minibuffer-complete-word)
  	   (define-key completion-map "?"	'minibuffer-completion-help)
  
  	   (define-key must-match-map "\t"	'minibuffer-complete)
--- 150,155 ----

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Entering filenames with spaces

[Richard M. Stallman]

    > However, I tend to think that the completion definition is not
    > essential, and is better for advanced users, while it can screw
    > beginners who don't know enough to use C-q SPC.  Therefore,
    > I have concluded we should redefine SPC.
    >
    > Would someone like to implement this change, and ack to me?


    Done. The patch is attached. Please apply if it's OK - I can't.
    Maybe this needs to be documented in NEWS as well.


Wait a minute!
The change I agreed to was only for file name reading.
The change you proposed would affect all kinds of completion.
I don't want to do that.

Re: Entering filenames with spaces

[David Reitter]

On 17 Oct 2005, at 05:33, Richard M. Stallman wrote:

> Wait a minute!
> The change I agreed to was only for file name reading.
> The change you proposed would affect all kinds of completion.
> I don't want to do that.

Uhh, sorry, that was a misunderstanding then.

If I had to design this from scratch, I probably wouldn't bind Space  
to a completion function in some cases, but not in others. It's more  
complicated for the user to "switch context", that is, to consider  
whether they are entering a file-name, or whether they are entering  
something like a symbol. The easier-to-remember usage paradigm would  
be to use Tab for completion everywhere.
But since people might be used to using Space, this might be a  
different story.

Could someone please tell me how this differentiation would best be  
implemented?
Does a filename-minibuffer have an extra keymap?
Or should Space be bound to some function that distinguishes the  
filename case from others? (a little awkward...)

RE: Entering filenames with spaces

[Drew Adams]

    Could someone please tell me how this differentiation would best be
    implemented?
    Does a filename-minibuffer have an extra keymap?
    Or should Space be bound to some function that distinguishes the
    filename case from others? (a little awkward...)

I use this to distinguish file-name completion. I too would like to know if
there is a better way.

(defun file-name-input-p ()
  "Return non-nil if expected input is a file name."
  (and (symbolp minibuffer-completion-table)
       (stringp minibuffer-completion-predicate)))

Re: Entering filenames with spaces

[Stefan Monnier]

> Could someone please tell me how this differentiation would best
> be  implemented?
> Does a filename-minibuffer have an extra keymap?
> Or should Space be bound to some function that distinguishes the filename
> case from others? (a little awkward...)
  
AFAIK the normal way to distinguish it is to check the variable
minibuffer-completing-file-name.


        Stefan

Re: Entering filenames with spaces

[Richard M. Stallman]

    Could someone please tell me how this differentiation would best be  
    implemented?
    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.

Making the command check and distinguish the two cases
would work, but it would be kludgy and would be hard for
users to customize.

Re: Entering filenames with spaces

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

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.


2005-11-05  David Reitter  <david.reitter@gmail.com>

	* commands.h (Vminibuffer_local_filename_completion_map):
	declare a new keymap for minibuffer completion in case of filenames.
	* keymap.c (syms_of_keymap): Declare (Lisp) and make new keymap.
	* minibuf.c (completing-read): Use a new keymap when deadling with
	filenames.
	(keys_of_minibuf): initialize the new keymap.
	

for etc/NEWS:

** Minibuffer changes:

*** For filenames, Space is not bound to completion any longer
Filenames with spaces can be input intuitively with the space bar now,
space is not bound to `minibuffer-complete-word' any longer.
A new key map minibuffer-local-filename-completion-map applies whenever
a file name is prompted for.



[-- Attachment #2: minibuffer-space.patch --]
[-- Type: application/octet-stream, Size: 3763 bytes --]

Index: src/minibuf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/minibuf.c,v
retrieving revision 1.290
diff -c -r1.290 minibuf.c
*** src/minibuf.c	24 Oct 2005 16:22:15 -0000	1.290
--- src/minibuf.c	5 Nov 2005 01:30:56 -0000
***************
*** 1747,1753 ****
      XSETFASTINT (histpos, 0);
  
    val = read_minibuf (NILP (require_match)
! 		      ? Vminibuffer_local_completion_map
  		      : Vminibuffer_local_must_match_map,
  		      init, prompt, make_number (pos), 0,
  		      histvar, histpos, def, 0,
--- 1747,1755 ----
      XSETFASTINT (histpos, 0);
  
    val = read_minibuf (NILP (require_match)
! 		      ? (NILP (Vminibuffer_completing_file_name) 
! 			 ? Vminibuffer_local_completion_map
! 			 : Vminibuffer_local_filename_completion_map)
  		      : Vminibuffer_local_must_match_map,
  		      init, prompt, make_number (pos), 0,
  		      histvar, histpos, def, 0,
***************
*** 2917,2922 ****
--- 2919,2929 ----
    initial_define_key (Vminibuffer_local_completion_map, ' ',
  		      "minibuffer-complete-word");
    initial_define_key (Vminibuffer_local_completion_map, '?',
+ 		      "minibuffer-completion-help");
+ 
+   initial_define_key (Vminibuffer_local_filename_completion_map, '\t',
+ 		      "minibuffer-complete");
+   initial_define_key (Vminibuffer_local_filename_completion_map, '?',
  		      "minibuffer-completion-help");
  
    initial_define_key (Vminibuffer_local_must_match_map, Ctl ('m'),
Index: src/commands.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/commands.h,v
retrieving revision 1.22
diff -c -r1.22 commands.h
*** src/commands.h	7 Aug 2005 12:33:16 -0000	1.22
--- src/commands.h	5 Nov 2005 01:30:56 -0000
***************
*** 37,42 ****
--- 37,45 ----
  /* keymap used for minibuffers when doing completion */
  extern Lisp_Object Vminibuffer_local_completion_map;
  
+ /* keymap used for minibuffers when doing completion in filenames*/
+ extern Lisp_Object Vminibuffer_local_filename_completion_map;
+ 
  /* keymap used for minibuffers when doing completion and require a match */
  extern Lisp_Object Vminibuffer_local_must_match_map;
  
Index: src/keymap.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keymap.c,v
retrieving revision 1.307
diff -c -r1.307 keymap.c
*** src/keymap.c	12 Sep 2005 10:26:35 -0000	1.307
--- src/keymap.c	5 Nov 2005 01:30:57 -0000
***************
*** 65,70 ****
--- 65,73 ----
  /* was MinibufLocalCompletionMap */
  Lisp_Object Vminibuffer_local_completion_map;
  
+ /* keymap used for minibuffers when doing completion in filenames */
+ Lisp_Object Vminibuffer_local_filename_completion_map;
+ 
  /* keymap used for minibuffers when doing completion and require a match */
  /* was MinibufLocalMustMatchMap */
  Lisp_Object Vminibuffer_local_must_match_map;
***************
*** 3774,3779 ****
--- 3777,3789 ----
  	       doc: /* Local keymap for minibuffer input with completion.  */);
    Vminibuffer_local_completion_map = Fmake_sparse_keymap (Qnil);
    Fset_keymap_parent (Vminibuffer_local_completion_map, Vminibuffer_local_map);
+ 
+   DEFVAR_LISP ("minibuffer-local-filename-completion-map", &Vminibuffer_local_filename_completion_map,
+ 	       doc: /* Local keymap for minibuffer input with completion for filenames.  */);
+   Vminibuffer_local_filename_completion_map = Fmake_sparse_keymap (Qnil);
+   Fset_keymap_parent (Vminibuffer_local_filename_completion_map, 
+ 		      Vminibuffer_local_map);
+ 
  
    DEFVAR_LISP ("minibuffer-local-must-match-map", &Vminibuffer_local_must_match_map,
  	       doc: /* Local keymap for minibuffer input with completion, for exact match.  */);

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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?

Re: Entering filenames with spaces

[David Reitter]

On 5 Nov 2005, at 16:34, Drew Adams wrote:

>     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.
...
>  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?

My main argument back then was to allow people to enter filenames  
with spaces, not consistency. Other keys have special meanings in the  
minibuffer, like up/down.

I fully agree with you that one should maintain consistent across all  
minibuffer inputs.
That was the first patch that I submitted, and some people didn't  
seem too happy...

A similar issue is the (seemingly fully unnecessary) binding of C-y  
in isearch, where yank needs to be re-bound to M-y. This is a good  
example of inconsistency without need. Streamlining the UI before the  
release might be a good idea. Otherwise one will end up with a  
situation where some people like to keep illogical UI behavior just  
because they've gotten used to it. The space bar in the minibuffer  
and C-y in isearch already seem to be such cases.

Re: Entering filenames with spaces

[Richard M. Stallman]

	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?

Yes.

RE: Entering filenames with spaces

[Drew Adams]

    	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?
    Yes.
OK.


Questions:

1. Is there no need for a `minibuffer-local-filename-must-match-map' too?
Some commands require an existing file name for a match; others let you
input any name.

2. Should the name be *-filename-* or *-file-name-*?  I see both spellings
in Emacs (try `apropos file-?name') - with many more occurrences of
`file-name'.

Is there a naming convention for when to use one or the other spelling? If
not, if the only reason there are two spellings is historical accident (I
don't know), then it would be good to choose one and stick to it. It makes
things like `apropos' easier to use.

Re: Entering filenames with spaces

[Juri Linkov]

> 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.

I think you are right.  This is not strictly filename specific.
Spaces and question marks can occur in non-file completion strings
including buffer names, Info index items, function names.
And these characters used for completion are not user-friendly:
just imagine an Emacs novice trying to find an Info index starting
with `?'.

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

Re: Entering filenames with spaces

[Richard M. Stallman]

It is pleasingly simple.  I have a few comments on details.

    +   initial_define_key (Vminibuffer_local_filename_completion_map, '\t',
    + 		      "minibuffer-complete");
    +   initial_define_key (Vminibuffer_local_filename_completion_map, '?',
			  "minibuffer-completion-help");

I think it would be cleaner to use Vminibuffer_local_completion_map
as this map's parent, and override only the SPC character.

    *** For filenames, Space is not bound to completion any longer

You need a period after that.  Also, it should be "SPC", not "Space".

    Filenames with spaces can be input intuitively with the space bar now,
    space is not bound to `minibuffer-complete-word' any longer.

That should be "SPC", not "space".  Also, it is a run-on sentence.

    A new key map minibuffer-local-filename-completion-map applies whenever
    a file name is prompted for.

That is passive--please rewrite it in the active voice.

Re: Entering filenames with spaces

[Richard M. Stallman]

    I think you are right.  This is not strictly filename specific.
    Spaces and question marks can occur in non-file completion strings
    including buffer names, Info index items, function names.

Yes, they can.  But entering these spaces is not a problem; just type
SPC.  As for question marks, entering them with C-q is not hard
either, on the rare occasions when it is needed.

There is no reason to consider such an incompatible change.
Let's not discuss that further.

Re: Entering filenames with spaces

[David Reitter]

On 7 Nov 2005, at 15:34, Richard M. Stallman wrote:

> It is pleasingly simple.  I have a few comments on details.
>
>     +   initial_define_key  
> (Vminibuffer_local_filename_completion_map, '\t',
>     + 		      "minibuffer-complete");
>     +   initial_define_key  
> (Vminibuffer_local_filename_completion_map, '?',
> 			  "minibuffer-completion-help");
>
> I think it would be cleaner to use Vminibuffer_local_completion_map
> as this map's parent, and override only the SPC character.


I take it that's done by binding it to self-insert-command, as in the  
new version below.
I can re-send the patch as attachment (with an unpleasant encoding)  
if needed.



Index: src/minibuf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/minibuf.c,v
retrieving revision 1.290
diff -c -r1.290 minibuf.c
*** src/minibuf.c	24 Oct 2005 16:22:15 -0000	1.290
--- src/minibuf.c	14 Nov 2005 11:16:16 -0000
***************
*** 1747,1753 ****
       XSETFASTINT (histpos, 0);

     val = read_minibuf (NILP (require_match)
! 		      ? Vminibuffer_local_completion_map
   		      : Vminibuffer_local_must_match_map,
   		      init, prompt, make_number (pos), 0,
   		      histvar, histpos, def, 0,
--- 1747,1755 ----
       XSETFASTINT (histpos, 0);

     val = read_minibuf (NILP (require_match)
! 		      ? (NILP (Vminibuffer_completing_file_name)
! 			 ? Vminibuffer_local_completion_map
! 			 : Vminibuffer_local_filename_completion_map)
   		      : Vminibuffer_local_must_match_map,
   		      init, prompt, make_number (pos), 0,
   		      histvar, histpos, def, 0,
***************
*** 2918,2923 ****
--- 2920,2928 ----
   		      "minibuffer-complete-word");
     initial_define_key (Vminibuffer_local_completion_map, '?',
   		      "minibuffer-completion-help");
+
+   initial_define_key (Vminibuffer_local_filename_completion_map, ' ',
+ 		      "self-insert-command");

     initial_define_key (Vminibuffer_local_must_match_map, Ctl ('m'),
   		      "minibuffer-complete-and-exit");
Index: src/keymap.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keymap.c,v
retrieving revision 1.308
diff -c -r1.308 keymap.c
*** src/keymap.c	9 Nov 2005 07:48:38 -0000	1.308
--- src/keymap.c	14 Nov 2005 11:16:16 -0000
***************
*** 65,70 ****
--- 65,73 ----
   /* was MinibufLocalCompletionMap */
   Lisp_Object Vminibuffer_local_completion_map;

+ /* keymap used for minibuffers when doing completion in filenames */
+ Lisp_Object Vminibuffer_local_filename_completion_map;
+
   /* keymap used for minibuffers when doing completion and require a  
match */
   /* was MinibufLocalMustMatchMap */
   Lisp_Object Vminibuffer_local_must_match_map;
***************
*** 3780,3785 ****
--- 3783,3796 ----
   	       doc: /* Local keymap for minibuffer input with  
completion.  */);
     Vminibuffer_local_completion_map = Fmake_sparse_keymap (Qnil);
     Fset_keymap_parent (Vminibuffer_local_completion_map,  
Vminibuffer_local_map);
+
+   DEFVAR_LISP ("minibuffer-local-filename-completion-map",
+ 	       &Vminibuffer_local_filename_completion_map,
+ 	       doc: /* Local keymap for minibuffer input with completion  
for filenames.  */);
+   Vminibuffer_local_filename_completion_map = Fmake_sparse_keymap  
(Qnil);
+   Fset_keymap_parent (Vminibuffer_local_filename_completion_map,
+ 		      Vminibuffer_local_completion_map);
+

     DEFVAR_LISP ("minibuffer-local-must-match-map",  
&Vminibuffer_local_must_match_map,
   	       doc: /* Local keymap for minibuffer input with completion,  
for exact match.  */);
Index: src/commands.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/commands.h,v
retrieving revision 1.22
diff -c -r1.22 commands.h
*** src/commands.h	7 Aug 2005 12:33:16 -0000	1.22
--- src/commands.h	14 Nov 2005 11:16:16 -0000
***************
*** 37,42 ****
--- 37,45 ----
   /* keymap used for minibuffers when doing completion */
   extern Lisp_Object Vminibuffer_local_completion_map;

+ /* keymap used for minibuffers when doing completion in filenames*/
+ extern Lisp_Object Vminibuffer_local_filename_completion_map;
+
   /* keymap used for minibuffers when doing completion and require a  
match */
   extern Lisp_Object Vminibuffer_local_must_match_map;

Re: Entering filenames with spaces

[Stefan Monnier]

> I take it that's done by binding it to self-insert-command, as in the  new
> version below.

Better bind it to nil instead.


        Stefan