Re: SPC no longer completes when minibuffer-completing-file-name is t
* minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. BTW, shouldn't exactly the same change be made also for `Vminibuffer_local_must_match_filename_map'? Indeed, I missed that one. Could someone install that change? Thanks, Stefan PS: BTW multiple-inheritance for keymaps would make this redundancy unnecessary. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SPC no longer completes when minibuffer-completing-file-name is t
Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. BTW, shouldn't exactly the same change be made also for `Vminibuffer_local_must_match_filename_map'? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: SPC no longer completes when minibuffer-completing-file-name is t
Stefan Monnier [EMAIL PROTECTED] wrote: Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Not when trying to complete: when hitting SPC. It used to be that SPC tried to complete, but now (when entering file names), it doesn't complete any more. Use TAB. Thanks. At first I was incredulous to hear it but then I found this in NEWS which explains the rationale. ** 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. In your opinion, should we be setting minibuffer-completing-file-name to t when calling completing-read to complete mail folders? I suspect that we do since folders are essentially files and can also contain spaces (I just checked--MH doesn't appear to barf if you create a folder with spaces). If not, what would we need to do to get the proper character to highlight? If minibuffer-completing-file-name is nil, then the highlighting is one character to the right of where it should be. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SPC no longer completes when minibuffer-completing-file-name is t
Stefan Monnier [EMAIL PROTECTED] wrote: In your opinion, should we be setting minibuffer-completing-file-name to t when calling completing-read to complete mail folders? Yes. It's also obeyed by partial-completion-mode. Thank you. I'll update the MH-E manual accordingly. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
SPC no longer completes when minibuffer-completing-file-name is t
[Resending without a Mail-Followup-To and with a Subject :-(. If you responded to the previous copy, you may have to resend it to emacs-pretest-bug@gnu.org if this address wasn't a recipient.] Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \+\ is allowed to be a folder name corresponding to `mh-user-path'. (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp ^[+/]) (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SPC no longer completes when minibuffer-completing-file-name is t
Satyaki Das [EMAIL PROTECTED] wrote: On 12/7/05, Bill Wohler [EMAIL PROTECTED] wrote: In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I remember adding the binding of minibuffer-completing-file-name because it was needed for proper highlighting of the next character to enter in CVS Emacs. If that isn't needed anymore we can remove it. I'm glad you remembered! Now that you mention it, that variable does have an effect on the highlighting. If it's there the highlighting is correct (I can still complete with TAB, just not with SPC); if it isn't, the highlighting is one character to the right of where it should be. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
