Insufficient documentation on *how* to change SPC behaviour in minibuffer

Insufficient documentation on *how* to change SPC behaviour in minibuffer

[Sivaram Neelakantan]

Hello,

In Emacs 22.1, the behaviour of SPC has changed to handle filenames
with spaces as is evident from the NEWS file.  The information about
keymaps is not sufficient to determine what needs to be done in order
to get the old behaviour of file name completion(if it's provided for
at all).

What customization should a user do to get the old behaviour?
,----[ NEWS ]
| ** When Emacs prompts for file names, SPC no longer completes the file name.
| This is so filenames with embedded spaces could be input without the
| need to quote the space with a C-q.  The underlying changes in the
| keymaps that are active in the minibuffer are described below under
| "New keymaps for typing file names".
`----

,----[ NEWS ]
| *** New keymaps for typing file names
| 
| Two new keymaps, `minibuffer-local-filename-completion-map'  and
| `minibuffer-local-must-match-filename-map', apply whenever
| Emacs reads a file name in the minibuffer.  These key maps override
| the usual binding of SPC to `minibuffer-complete-word' (so that file
| names with embedded spaces could be typed without the need to quote
| the spaces).
`----

In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENG
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Article

Minor modes in effect:
  show-paren-mode: t
  icomplete-mode: t
  erc-autojoin-mode: t
  erc-button-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-fill-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  display-time-mode: t
  delete-selection-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:

Recent messages:
Mark saved where search started
call-interactively: Buffer is read-only: #<buffer *info*>
Quit
Type C-x 1 to remove help window.  
Loading outline...done
Loading texmathp...done
Mark saved where search started [2 times]
Mark set
Making completion list...
Loading emacsbug...done


 sivaram
 -- 

Re: Insufficient documentation on *how* to change SPC behaviour in minibuffer

[Eli Zaretskii]

> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
> User-Mail-Address: nsivaram.net@gmail.com
> Date: Thu, 05 Jul 2007 23:53:17 +0530
> 
> In Emacs 22.1, the behaviour of SPC has changed to handle filenames
> with spaces as is evident from the NEWS file.  The information about
> keymaps is not sufficient to determine what needs to be done in order
> to get the old behaviour of file name completion(if it's provided for
> at all).
> 
> What customization should a user do to get the old behaviour?
> ,----[ NEWS ]
> | ** When Emacs prompts for file names, SPC no longer completes the file name.
> | This is so filenames with embedded spaces could be input without the
> | need to quote the space with a C-q.  The underlying changes in the
> | keymaps that are active in the minibuffer are described below under
> | "New keymaps for typing file names".
> `----

Thank you for your report.

I added this text to the above entry:

    If you want the old behavior back, put these two key bindings to your
    ~/.emacs init file:

      (define-key minibuffer-local-filename-completion-map
		  " " 'minibuffer-complete-word)
      (define-key minibuffer-local-must-match-filename-map
		  " " 'minibuffer-complete-word)

Does it give you enough information now?  Did the recipe work for you?

Re: Insufficient documentation on *how* to change SPC behaviour in minibuffer

[Sivaram Neelakantan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
>> User-Mail-Address: nsivaram.net@gmail.com

[...]

> Thank you for your report.
>
> I added this text to the above entry:
>
>     If you want the old behavior back, put these two key bindings to your
>     ~/.emacs init file:
>
>       (define-key minibuffer-local-filename-completion-map
> 		  " " 'minibuffer-complete-word)
>       (define-key minibuffer-local-must-match-filename-map
> 		  " " 'minibuffer-complete-word)
>
> Does it give you enough information now?  Did the recipe work for you?

Many thanks.  It does work as suggested with the above code snippet.
As for the documentation, well yes that would make sense.  But would
it be also useful to put it under Emacs-Minibuffer-Completion Commands
section in the info manual?  

Similar to the way, how Emacs recognises sentences (2 spaces vs
1aftera period) and how the manual explains how to switch from one to
the other, I think, there should be a similar explanation in the main
info manual.


 sivaram
 -- 

RE: Insufficient documentation on *how* to change SPC behaviour inminibuffer

[Drew Adams]

> > I added this text to the above entry:
> >
> >     If you want the old behavior back, put these two key
> >     bindings to your ~/.emacs init file:
> >
> >       (define-key minibuffer-local-filename-completion-map
> > 		  " " 'minibuffer-complete-word)
> >       (define-key minibuffer-local-must-match-filename-map
> > 		  " " 'minibuffer-complete-word)
> >
> > Does it give you enough information now?  Did the recipe work for you?
>
> Many thanks.  It does work as suggested with the above code snippet.
> As for the documentation, well yes that would make sense.  But would
> it be also useful to put it under Emacs-Minibuffer-Completion Commands
> section in the info manual?
>
> Similar to the way, how Emacs recognises sentences (2 spaces vs
> 1aftera period) and how the manual explains how to switch from one to
> the other, I think, there should be a similar explanation in the main
> info manual.

Rather than pepper the manual with this kind of thing, I'd rather see all
such ways to obtain previous-release behavior documented in a single place.

Re: Insufficient documentation on *how* to change SPC behaviour in minibuffer

[Eli Zaretskii]

> From: Sivaram Neelakantan <nsivaram.net@gmail.com>
> Date: Fri, 06 Jul 2007 23:33:00 +0530
> User-Mail-Address: nsivaram.net@gmail.com
> 
> As for the documentation, well yes that would make sense.  But would
> it be also useful to put it under Emacs-Minibuffer-Completion Commands
> section in the info manual?  
> 
> Similar to the way, how Emacs recognises sentences (2 spaces vs
> 1aftera period) and how the manual explains how to switch from one to
> the other, I think, there should be a similar explanation in the main
> info manual.

I don't think these two situations are similar.  One space after a
period that ends a sentence is a widely used convention that has its
roots in cultural differences that are outside Emacs's domain.  By
contrast, the key bindings in the minibuffer prompts for file names is
(a) purely an Emacs issue, and (b) we firmly believe that most people
will be happy with the new bindings (or else we wouldn't be making
them the default).

Re: Insufficient documentation on *how* to change SPC behaviour inminibuffer

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 6 Jul 2007 11:26:07 -0700
> 
> Rather than pepper the manual with this kind of thing, I'd rather see all
> such ways to obtain previous-release behavior documented in a single place.

There is such a place: the "Antinews" node in the manual.

RE: Insufficient documentation on *how* to change SPC behaviourinminibuffer

[Drew Adams]

> > Rather than pepper the manual with this kind of thing, I'd 
> > rather see all such ways to obtain previous-release behavior
> > documented in a single place.
> 
> There is such a place: the "Antinews" node in the manual.

I agree that that should be sufficient for this. 

Re: Insufficient documentation on *how* to change SPC behaviour inminibuffer

[Richard Stallman]

    > Rather than pepper the manual with this kind of thing, I'd rather see all
    > such ways to obtain previous-release behavior documented in a single place.

    There is such a place: the "Antinews" node in the manual.

The purpose of Antinews is to help people who use the new manual
with an older Emacs version.

Advice for imitating behavior of a feature in previous versions is
something entirely different.  The right place for that would be next
to the documentation of that feature.  Putting all those customizations
together is not particularly useful, so I think it is misguided.