* Entering filenames with spaces @ 2005-08-08 11:22 David Reitter 2005-08-12 7:51 ` James Cloos 0 siblings, 1 reply; 45+ messages in thread From: David Reitter @ 2005-08-08 11:22 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-08 11:22 Entering filenames with spaces David Reitter @ 2005-08-12 7:51 ` James Cloos 2005-08-12 9:37 ` Lennart Borgman 2005-08-12 15:15 ` Drew Adams 0 siblings, 2 replies; 45+ messages in thread From: James Cloos @ 2005-08-12 7:51 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 7:51 ` James Cloos @ 2005-08-12 9:37 ` Lennart Borgman 2005-08-12 10:26 ` James Cloos 2005-08-12 15:15 ` Drew Adams 1 sibling, 1 reply; 45+ messages in thread From: Lennart Borgman @ 2005-08-12 9:37 UTC (permalink / raw) Cc: emacs-devel 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 ;-) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 9:37 ` Lennart Borgman @ 2005-08-12 10:26 ` James Cloos 2005-08-12 13:13 ` David Reitter 0 siblings, 1 reply; 45+ messages in thread From: James Cloos @ 2005-08-12 10:26 UTC (permalink / raw) Cc: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 10:26 ` James Cloos @ 2005-08-12 13:13 ` David Reitter 0 siblings, 0 replies; 45+ messages in thread From: David Reitter @ 2005-08-12 13:13 UTC (permalink / raw) Cc: Lennart Borgman, emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-08-12 7:51 ` James Cloos 2005-08-12 9:37 ` Lennart Borgman @ 2005-08-12 15:15 ` Drew Adams 2005-08-12 15:40 ` Andreas Schwab ` (2 more replies) 1 sibling, 3 replies; 45+ messages in thread From: Drew Adams @ 2005-08-12 15:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 15:15 ` Drew Adams @ 2005-08-12 15:40 ` Andreas Schwab 2005-08-12 15:58 ` Drew Adams 2005-08-12 19:23 ` Lennart Borgman 2005-08-13 14:40 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Andreas Schwab @ 2005-08-12 15:40 UTC (permalink / raw) Cc: emacs-devel "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." ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-08-12 15:40 ` Andreas Schwab @ 2005-08-12 15:58 ` Drew Adams 2005-08-12 16:26 ` David Reitter 0 siblings, 1 reply; 45+ messages in thread From: Drew Adams @ 2005-08-12 15:58 UTC (permalink / raw) > 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... ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 15:58 ` Drew Adams @ 2005-08-12 16:26 ` David Reitter 2005-08-12 17:50 ` Drew Adams 2005-08-13 12:11 ` James Cloos 0 siblings, 2 replies; 45+ messages in thread From: David Reitter @ 2005-08-12 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-08-12 16:26 ` David Reitter @ 2005-08-12 17:50 ` Drew Adams 2005-08-12 19:28 ` David Reitter 2005-08-13 12:11 ` James Cloos 1 sibling, 1 reply; 45+ messages in thread From: Drew Adams @ 2005-08-12 17:50 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 17:50 ` Drew Adams @ 2005-08-12 19:28 ` David Reitter 2005-08-12 21:47 ` Drew Adams 2005-08-13 0:55 ` Thien-Thi Nguyen 0 siblings, 2 replies; 45+ messages in thread From: David Reitter @ 2005-08-12 19:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-08-12 19:28 ` David Reitter @ 2005-08-12 21:47 ` Drew Adams 2005-08-13 0:55 ` Thien-Thi Nguyen 1 sibling, 0 replies; 45+ messages in thread From: Drew Adams @ 2005-08-12 21:47 UTC (permalink / raw) > 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'". ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 19:28 ` David Reitter 2005-08-12 21:47 ` Drew Adams @ 2005-08-13 0:55 ` Thien-Thi Nguyen 2005-08-13 8:27 ` David Kastrup 1 sibling, 1 reply; 45+ messages in thread From: Thien-Thi Nguyen @ 2005-08-13 0:55 UTC (permalink / raw) Cc: Emacs-Devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 0:55 ` Thien-Thi Nguyen @ 2005-08-13 8:27 ` David Kastrup 2005-08-13 16:48 ` Thien-Thi Nguyen 0 siblings, 1 reply; 45+ messages in thread From: David Kastrup @ 2005-08-13 8:27 UTC (permalink / raw) Cc: David Reitter, Emacs-Devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 8:27 ` David Kastrup @ 2005-08-13 16:48 ` Thien-Thi Nguyen 2005-08-13 17:51 ` David Kastrup 0 siblings, 1 reply; 45+ messages in thread From: Thien-Thi Nguyen @ 2005-08-13 16:48 UTC (permalink / raw) Cc: David Reitter, Emacs-Devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 16:48 ` Thien-Thi Nguyen @ 2005-08-13 17:51 ` David Kastrup 2005-08-13 21:14 ` Thien-Thi Nguyen 0 siblings, 1 reply; 45+ messages in thread From: David Kastrup @ 2005-08-13 17:51 UTC (permalink / raw) Cc: David Reitter, Emacs-Devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 17:51 ` David Kastrup @ 2005-08-13 21:14 ` Thien-Thi Nguyen 0 siblings, 0 replies; 45+ messages in thread From: Thien-Thi Nguyen @ 2005-08-13 21:14 UTC (permalink / raw) Cc: David Reitter, Emacs-Devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 16:26 ` David Reitter 2005-08-12 17:50 ` Drew Adams @ 2005-08-13 12:11 ` James Cloos 1 sibling, 0 replies; 45+ messages in thread From: James Cloos @ 2005-08-13 12:11 UTC (permalink / raw) Cc: David Reitter >>>>> "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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 15:15 ` Drew Adams 2005-08-12 15:40 ` Andreas Schwab @ 2005-08-12 19:23 ` Lennart Borgman 2005-08-12 19:51 ` Drew Adams 2005-08-13 14:40 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Lennart Borgman @ 2005-08-12 19:23 UTC (permalink / raw) Cc: emacs-devel >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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-08-12 19:23 ` Lennart Borgman @ 2005-08-12 19:51 ` Drew Adams 2005-08-12 20:22 ` Lennart Borgman 2005-08-13 6:11 ` Juri Linkov 0 siblings, 2 replies; 45+ messages in thread From: Drew Adams @ 2005-08-12 19:51 UTC (permalink / raw) >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). ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 19:51 ` Drew Adams @ 2005-08-12 20:22 ` Lennart Borgman 2005-08-13 6:11 ` Juri Linkov 1 sibling, 0 replies; 45+ messages in thread From: Lennart Borgman @ 2005-08-12 20:22 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 19:51 ` Drew Adams 2005-08-12 20:22 ` Lennart Borgman @ 2005-08-13 6:11 ` Juri Linkov 1 sibling, 0 replies; 45+ messages in thread From: Juri Linkov @ 2005-08-13 6:11 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-12 15:15 ` Drew Adams 2005-08-12 15:40 ` Andreas Schwab 2005-08-12 19:23 ` Lennart Borgman @ 2005-08-13 14:40 ` Richard M. Stallman 2005-08-14 3:48 ` Eli Zaretskii 2005-10-15 17:42 ` David Reitter 2 siblings, 2 replies; 45+ messages in thread From: Richard M. Stallman @ 2005-08-13 14:40 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 14:40 ` Richard M. Stallman @ 2005-08-14 3:48 ` Eli Zaretskii 2005-08-14 6:20 ` Stefan Monnier 2005-08-14 21:03 ` Richard M. Stallman 2005-10-15 17:42 ` David Reitter 1 sibling, 2 replies; 45+ messages in thread From: Eli Zaretskii @ 2005-08-14 3:48 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-14 3:48 ` Eli Zaretskii @ 2005-08-14 6:20 ` Stefan Monnier 2005-08-14 19:06 ` Eli Zaretskii 2005-08-14 21:03 ` Richard M. Stallman 1 sibling, 1 reply; 45+ messages in thread From: Stefan Monnier @ 2005-08-14 6:20 UTC (permalink / raw) Cc: rms, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-14 6:20 ` Stefan Monnier @ 2005-08-14 19:06 ` Eli Zaretskii 2005-08-15 7:58 ` Kim F. Storm 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2005-08-14 19:06 UTC (permalink / raw) Cc: emacs-devel > 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.) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-14 19:06 ` Eli Zaretskii @ 2005-08-15 7:58 ` Kim F. Storm 2005-08-15 19:35 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Kim F. Storm @ 2005-08-15 7:58 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-15 7:58 ` Kim F. Storm @ 2005-08-15 19:35 ` Eli Zaretskii 0 siblings, 0 replies; 45+ messages in thread From: Eli Zaretskii @ 2005-08-15 19:35 UTC (permalink / raw) Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-14 3:48 ` Eli Zaretskii 2005-08-14 6:20 ` Stefan Monnier @ 2005-08-14 21:03 ` Richard M. Stallman 1 sibling, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2005-08-14 21:03 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-08-13 14:40 ` Richard M. Stallman 2005-08-14 3:48 ` Eli Zaretskii @ 2005-10-15 17:42 ` David Reitter 2005-10-17 4:33 ` Richard M. Stallman 1 sibling, 1 reply; 45+ messages in thread From: David Reitter @ 2005-10-15 17:42 UTC (permalink / raw) Cc: Emacs-Devel ' [-- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-10-15 17:42 ` David Reitter @ 2005-10-17 4:33 ` Richard M. Stallman 2005-10-18 9:26 ` David Reitter 0 siblings, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2005-10-17 4:33 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-10-17 4:33 ` Richard M. Stallman @ 2005-10-18 9:26 ` David Reitter 2005-10-18 15:06 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: David Reitter @ 2005-10-18 9:26 UTC (permalink / raw) 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...) ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-10-18 9:26 ` David Reitter @ 2005-10-18 15:06 ` Drew Adams 2005-10-18 15:39 ` Stefan Monnier 2005-10-19 2:43 ` Richard M. Stallman 2 siblings, 0 replies; 45+ messages in thread From: Drew Adams @ 2005-10-18 15:06 UTC (permalink / raw) 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))) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-10-18 9:26 ` David Reitter 2005-10-18 15:06 ` Drew Adams @ 2005-10-18 15:39 ` Stefan Monnier 2005-10-19 2:43 ` Richard M. Stallman 2 siblings, 0 replies; 45+ messages in thread From: Stefan Monnier @ 2005-10-18 15:39 UTC (permalink / raw) Cc: Emacs-Devel ' > 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-10-18 9:26 ` David Reitter 2005-10-18 15:06 ` Drew Adams 2005-10-18 15:39 ` Stefan Monnier @ 2005-10-19 2:43 ` Richard M. Stallman 2005-11-05 15:02 ` David Reitter 2 siblings, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2005-10-19 2:43 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-10-19 2:43 ` Richard M. Stallman @ 2005-11-05 15:02 ` David Reitter 2005-11-05 16:34 ` Drew Adams 2005-11-07 15:34 ` Richard M. Stallman 0 siblings, 2 replies; 45+ messages in thread From: David Reitter @ 2005-11-05 15:02 UTC (permalink / raw) Cc: emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-11-05 15:02 ` David Reitter @ 2005-11-05 16:34 ` Drew Adams 2005-11-06 16:15 ` David Reitter ` (2 more replies) 2005-11-07 15:34 ` Richard M. Stallman 1 sibling, 3 replies; 45+ messages in thread From: Drew Adams @ 2005-11-05 16:34 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-05 16:34 ` Drew Adams @ 2005-11-06 16:15 ` David Reitter 2005-11-06 17:36 ` Richard M. Stallman 2005-11-07 14:34 ` Juri Linkov 2 siblings, 0 replies; 45+ messages in thread From: David Reitter @ 2005-11-06 16:15 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-05 16:34 ` Drew Adams 2005-11-06 16:15 ` David Reitter @ 2005-11-06 17:36 ` Richard M. Stallman 2005-11-07 1:48 ` Drew Adams 2005-11-07 14:34 ` Juri Linkov 2 siblings, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2005-11-06 17:36 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Entering filenames with spaces 2005-11-06 17:36 ` Richard M. Stallman @ 2005-11-07 1:48 ` Drew Adams 0 siblings, 0 replies; 45+ messages in thread From: Drew Adams @ 2005-11-07 1:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-05 16:34 ` Drew Adams 2005-11-06 16:15 ` David Reitter 2005-11-06 17:36 ` Richard M. Stallman @ 2005-11-07 14:34 ` Juri Linkov 2005-11-07 21:56 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Juri Linkov @ 2005-11-07 14:34 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-07 14:34 ` Juri Linkov @ 2005-11-07 21:56 ` Richard M. Stallman 0 siblings, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2005-11-07 21:56 UTC (permalink / raw) Cc: drew.adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-05 15:02 ` David Reitter 2005-11-05 16:34 ` Drew Adams @ 2005-11-07 15:34 ` Richard M. Stallman 2005-11-14 11:18 ` David Reitter 1 sibling, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2005-11-07 15:34 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-07 15:34 ` Richard M. Stallman @ 2005-11-14 11:18 ` David Reitter 2005-11-14 13:27 ` Stefan Monnier 0 siblings, 1 reply; 45+ messages in thread From: David Reitter @ 2005-11-14 11:18 UTC (permalink / raw) Cc: emacs-devel 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; ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Entering filenames with spaces 2005-11-14 11:18 ` David Reitter @ 2005-11-14 13:27 ` Stefan Monnier 0 siblings, 0 replies; 45+ messages in thread From: Stefan Monnier @ 2005-11-14 13:27 UTC (permalink / raw) Cc: rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2005-11-14 13:27 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-08-08 11:22 Entering filenames with spaces David Reitter 2005-08-12 7:51 ` James Cloos 2005-08-12 9:37 ` Lennart Borgman 2005-08-12 10:26 ` James Cloos 2005-08-12 13:13 ` David Reitter 2005-08-12 15:15 ` Drew Adams 2005-08-12 15:40 ` Andreas Schwab 2005-08-12 15:58 ` Drew Adams 2005-08-12 16:26 ` David Reitter 2005-08-12 17:50 ` Drew Adams 2005-08-12 19:28 ` David Reitter 2005-08-12 21:47 ` Drew Adams 2005-08-13 0:55 ` Thien-Thi Nguyen 2005-08-13 8:27 ` David Kastrup 2005-08-13 16:48 ` Thien-Thi Nguyen 2005-08-13 17:51 ` David Kastrup 2005-08-13 21:14 ` Thien-Thi Nguyen 2005-08-13 12:11 ` James Cloos 2005-08-12 19:23 ` Lennart Borgman 2005-08-12 19:51 ` Drew Adams 2005-08-12 20:22 ` Lennart Borgman 2005-08-13 6:11 ` Juri Linkov 2005-08-13 14:40 ` Richard M. Stallman 2005-08-14 3:48 ` Eli Zaretskii 2005-08-14 6:20 ` Stefan Monnier 2005-08-14 19:06 ` Eli Zaretskii 2005-08-15 7:58 ` Kim F. Storm 2005-08-15 19:35 ` Eli Zaretskii 2005-08-14 21:03 ` Richard M. Stallman 2005-10-15 17:42 ` David Reitter 2005-10-17 4:33 ` Richard M. Stallman 2005-10-18 9:26 ` David Reitter 2005-10-18 15:06 ` Drew Adams 2005-10-18 15:39 ` Stefan Monnier 2005-10-19 2:43 ` Richard M. Stallman 2005-11-05 15:02 ` David Reitter 2005-11-05 16:34 ` Drew Adams 2005-11-06 16:15 ` David Reitter 2005-11-06 17:36 ` Richard M. Stallman 2005-11-07 1:48 ` Drew Adams 2005-11-07 14:34 ` Juri Linkov 2005-11-07 21:56 ` Richard M. Stallman 2005-11-07 15:34 ` Richard M. Stallman 2005-11-14 11:18 ` David Reitter 2005-11-14 13:27 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.