Re: completion-list-mode-map

Re: completion-list-mode-map

[Christoph Scholtes]

Hi Wojciech,

On Thu, Mar 17, 2011 at 12:53 PM, Wocjciech Meyer wrote:

 > I've already sent a patch to derive all the `special modes likes' from
 > `special-mode'.
 > Then, I needed a paperwork to sign and the whole thing got stalled
 > for 8 months.
 > Fortunately, I am able to submit the patch again, because the
 > process's ended and I can finally contribute to Emacs. If you could
 > put on hold your patch and be patient then this weekend I will
 > resubmit the patch.

With the code-freeze for Emacs 24 approaching, I was wondering if this 
patch ever got applied.

Thanks,
Christoph

Re: completion-list-mode-map

[Stefan Monnier]

>> I've already sent a patch to derive all the `special modes likes' from
>> `special-mode'.
>> Then, I needed a paperwork to sign and the whole thing got stalled
>> for 8 months.
>> Fortunately, I am able to submit the patch again, because the
>> process's ended and I can finally contribute to Emacs. If you could
>> put on hold your patch and be patient then this weekend I will
>> resubmit the patch.

> With the code-freeze for Emacs 24 approaching, I was wondering if this patch
> ever got applied.

Indeed I think it hasn't and I can't find it in my mailbox.  Can you
resend it.
Sorry for the hassle,


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

On 6/6/2011 9:31 AM, Stefan Monnier wrote:

> Indeed I think it hasn't and I can't find it in my mailbox.  Can you
> resend it.

Stefan,
Did you ever get the patch from Wojciech?

I would like to see this fixed for 24.1.

Thanks,
Christoph

Re: completion-list-mode-map

[Stefan Monnier]

>> Indeed I think it hasn't and I can't find it in my mailbox.  Can you
>> resend it.
> Did you ever get the patch from Wojciech?

No, but I also still don't see him in the list of copyright assignments,
so IIUC we're still waiting for his paperwork to go through.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

Stefan,

On 6/28/2011 9:04 PM, Stefan Monnier wrote:
>>> Indeed I think it hasn't and I can't find it in my mailbox.  Can you
>>> resend it.
>> Did you ever get the patch from Wojciech?
>
> No, but I also still don't see him in the list of copyright assignments,
> so IIUC we're still waiting for his paperwork to go through.

I am taking a look at this issue now since I want to get this fixed for 
Emacs 24.

There is a TODO item says "Convert modes that use view-mode to be 
derived from special-mode instead".

In order to figure out which modes need to be converted, is it OK to 
search for modes whose mode-class has been set to special?

For example:
(put 'completion-list-mode 'mode-class 'special)

Should all of these modes be derived from special-mode?

Christoph

Re: completion-list-mode-map

[Stefan Monnier]

> (put 'completion-list-mode 'mode-class 'special)
> Should all of these modes be derived from special-mode?

That's the idea, yes.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

On 7/2/2011 4:30 PM, Stefan Monnier wrote:
>> (put 'completion-list-mode 'mode-class 'special)
>> Should all of these modes be derived from special-mode?
>
> That's the idea, yes.

Thanks.

One more questions: do the keymaps for such special modes need to 
inherit from special-mode-map explicitly via

(set-keymap-parent map special-mode-map)

or is there implicit inheritance of the keymap when deriving from 
special mode?

Christoph

Re: completion-list-mode-map

[Stefan Monnier]

> or is there implicit inheritance of the keymap when deriving from
> special mode?

Yes, that inheritance is implicit (it's set up when the mode is
activated) unless the keymap already has a parent.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

On 7/2/2011 11:38 PM, Stefan Monnier wrote:
>> or is there implicit inheritance of the keymap when deriving from
>> special mode?
>
> Yes, that inheritance is implicit (it's set up when the mode is
> activated) unless the keymap already has a parent.

Thanks.

I started looking into this and it looks like it is more complicated 
than I thought. I grepped for `'mode-class 'special' and got a pageful 
of hits. Some of these modes are already derived from special modes, 
some are not. Looking at the ones that are not, I am wondering if they 
should be.

For example:

- arc-mode's mode-class is special. However, arc-mode is not derived 
from special-mode. Should it be?

- comint-mode is derived from fundamental-mode, but it's mode-class is 
also special. Should it be derived from special-mode instead?

In other cases modes derive from special-mode already, but the key map 
parent is not set to special-mode map. For example, tar-mode. Should the 
key map parent always be special-mode-map?

What prompted me to look into this in the first place was the 
inconsistent behavior of `q'/`z' when trying to quit/kill buffers. 
special-mode map defines `q' as quit-window and `z' as kill-this-buffer, 
but some keymaps define `q' as, for example, thumbs-kill-buffer. How do 
we handle these cases?

Thanks,
Christoph

Re: completion-list-mode-map

[Stefan Monnier]

>>> or is there implicit inheritance of the keymap when deriving from
>>> special mode?
>> Yes, that inheritance is implicit (it's set up when the mode is
>> activated) unless the keymap already has a parent.

> I started looking into this and it looks like it is more complicated than
> I thought. I grepped for `'mode-class 'special' and got a pageful of
> hits. Some of these modes are already derived from special modes, some are
> not. Looking at the ones that are not, I am wondering if they should be.

Note: if a mode derives from special-mode, then it does not need the
(put 'foo-mode 'mode-class 'special).

> - arc-mode's mode-class is special. However, arc-mode is not derived from
> special-mode. Should it be?

The general rule should be that it is, but check that it's compatible.
Basically special-mode has a read-only buffer and some standard
key-bindings, so as long as there's no deep conflict in the key-bindings
and the mode is read-only, it should derive.
For this reason I think arc-mode should derive from special-mode.

> - comint-mode is derived from fundamental-mode, but it's mode-class is also
> special.  Should it be derived from special-mode instead?

Here on the other hand, we have some clear conflicts: comint-mode is not
read-only and can't bind `q' to quit-window and `g' to revert-buffer.
So I don't think it should inherit from special-mode.

> In other cases modes derive from special-mode already, but the key map
> parent is not set to special-mode map. For example, tar-mode.  Should the key
> map parent always be special-mode-map?

define-derived-mode will set the keymap parent to special-mode-map if
the mode's keymap doesn't already have a parent.

> What prompted me to look into this in the first place was the inconsistent
> behavior of `q'/`z' when trying to quit/kill buffers. special-mode map
> defines `q' as quit-window and `z' as kill-this-buffer, but some keymaps
> define `q' as, for example, thumbs-kill-buffer. How do we handle
> these cases?

(One of) the purposes of special-mode is to standardize key bindings, so
I think that thumbs-kill-buffer will have to go: it does something
similar to quit-window, and the differences are just an annoyance.
In other cases, the key-binding conflicts may need to be resolved by finding
new keys, rather than just ditching the old binding.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

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

On 7/6/2011 6:49 AM, Stefan Monnier wrote:

> Note: if a mode derives from special-mode, then it does not need the
> (put 'foo-mode 'mode-class 'special).

OK, I see some instances where this is still present although the mode 
is derived from special-mode. I assume those can be removed then?

> The general rule should be that it is, but check that it's compatible.
> Basically special-mode has a read-only buffer and some standard
> key-bindings, so as long as there's no deep conflict in the key-bindings
> and the mode is read-only, it should derive.

OK. I picked help-mode to start with, since the original item in TODO 
says modes using view-mode should be using special-mode now. See the 
attached patch for review.

> define-derived-mode will set the keymap parent to special-mode-map if
> the mode's keymap doesn't already have a parent.

There is multiple instances where the mode derives from special-mode, 
but the keymap parent is explicitly set to special-mode also. Should 
those be removed?

> (One of) the purposes of special-mode is to standardize key bindings, so
> I think that thumbs-kill-buffer will have to go: it does something
> similar to quit-window, and the differences are just an annoyance.
> In other cases, the key-binding conflicts may need to be resolved by finding
> new keys, rather than just ditching the old binding.

There is quite a few of these mode-specific functions. I will do a 
survey and see if any modes do special (as in unusual) things in these 
functions, which would not be covered by `quit-window'.

Christoph


[-- Attachment #2: help-mode.patch --]
[-- Type: text/plain, Size: 2970 bytes --]

=== modified file 'lisp/help-mode.el'
--- lisp/help-mode.el	2011-06-13 13:14:42 +0000
+++ lisp/help-mode.el	2011-07-10 02:25:19 +0000
@@ -34,14 +34,11 @@
 (eval-when-compile (require 'easymenu))
 
 (defvar help-mode-map
-  (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map button-buffer-map)
-
+  (let ((map (copy-keymap button-buffer-map)))
     (define-key map [mouse-2] 'help-follow-mouse)
     (define-key map "\C-c\C-b" 'help-go-back)
     (define-key map "\C-c\C-f" 'help-go-forward)
     (define-key map "\C-c\C-c" 'help-follow-symbol)
-    ;; Documentation only, since we use minor-mode-overriding-map-alist.
     (define-key map "\r" 'help-follow)
     map)
   "Keymap for help mode.")
@@ -266,37 +263,14 @@
   'help-function 'customize-create-theme
   'help-echo (purecopy "mouse-2, RET: edit this theme file"))
 \f
-;;;###autoload
-(defun help-mode ()
+(define-derived-mode help-mode special-mode "Help"
   "Major mode for viewing help text and navigating references in it.
 Entry to this mode runs the normal hook `help-mode-hook'.
 Commands:
 \\{help-mode-map}"
-  (interactive)
-  (kill-all-local-variables)
-  (use-local-map help-mode-map)
-  (setq mode-name "Help")
-  (setq major-mode 'help-mode)
-
-  (view-mode)
   (set (make-local-variable 'view-no-disable-on-exit) t)
-  ;; With Emacs 22 `view-exit-action' could delete the selected window
-  ;; disregarding whether the help buffer was shown in that window at
-  ;; all.  Since `view-exit-action' is called with the help buffer as
-  ;; argument it seems more appropriate to have it work on the buffer
-  ;; only and leave it to `view-mode-exit' to delete any associated
-  ;; window(s).
-  (setq view-exit-action
-	(lambda (buffer)
-	  ;; Use `with-current-buffer' to make sure that `bury-buffer'
-	  ;; also removes BUFFER from the selected window.
-	  (with-current-buffer buffer
-	    (bury-buffer))))
-
   (set (make-local-variable 'revert-buffer-function)
-       'help-mode-revert-buffer)
-
-  (run-mode-hooks 'help-mode-hook))
+       'help-mode-revert-buffer))
 
 ;;;###autoload
 (defun help-mode-setup ()
@@ -403,13 +377,6 @@
        (error "Current buffer is not in Help mode"))
      (current-buffer))))
 
-(defvar help-xref-override-view-map
-  (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map view-mode-map)
-    (define-key map "\r" nil)
-    map)
-  "Replacement keymap for `view-mode' in help buffers.")
-
 ;;;###autoload
 (defun help-make-xrefs (&optional buffer)
   "Parse and hyperlink documentation cross-references in the given BUFFER.
@@ -594,9 +561,6 @@
                                      (current-buffer)))
           (when (or help-xref-stack help-xref-forward-stack)
             (insert "\n")))
-        ;; View mode steals RET from us.
-        (set (make-local-variable 'minor-mode-overriding-map-alist)
-             (list (cons 'view-mode help-xref-override-view-map)))
         (set-buffer-modified-p old-modified)))))
 
 ;;;###autoload

Re: completion-list-mode-map

[Stefan Monnier]

>> Note: if a mode derives from special-mode, then it does not need the
>> (put 'foo-mode 'mode-class 'special).
> OK, I see some instances where this is still present although the mode is
> derived from special-mode. I assume those can be removed then?

Yes.

>> define-derived-mode will set the keymap parent to special-mode-map if
>> the mode's keymap doesn't already have a parent.
> There is multiple instances where the mode derives from special-mode, but
> the keymap parent is explicitly set to special-mode also.  Should those
> be removed?

They don't hurt.

>> (One of) the purposes of special-mode is to standardize key bindings, so
>> I think that thumbs-kill-buffer will have to go: it does something
>> similar to quit-window, and the differences are just an annoyance.
>> In other cases, the key-binding conflicts may need to be resolved by finding
>> new keys, rather than just ditching the old binding.
> There is quite a few of these mode-specific functions. I will do a survey
> and see if any modes do special (as in unusual) things in these functions,
> which would not be covered by `quit-window'.

Thanks.

Here are some comments about your patch:

> @@ -34,14 +34,11 @@
>  (eval-when-compile (require 'easymenu))
 
>  (defvar help-mode-map
> -  (let ((map (make-sparse-keymap)))
> -    (set-keymap-parent map button-buffer-map)
> -
> +  (let ((map (copy-keymap button-buffer-map)))
>      (define-key map [mouse-2] 'help-follow-mouse)
>      (define-key map "\C-c\C-b" 'help-go-back)

copy-keymap is usually a bad idea.  I guess you used it in order to
still be able to inherit from special-mode-map, but that's not needed
any more: I installed a week ago changes that add multiple-keymap
inheritance, so you should be able to do

    (set-keymap-parent map (make-composed-keymap button-buffer-map
                                                 special-mode-map))

to get the same result without copying any keymap.

> -  (interactive)
> -  (kill-all-local-variables)
> -  (use-local-map help-mode-map)
> -  (setq mode-name "Help")
> -  (setq major-mode 'help-mode)
> -
> -  (view-mode)
>    (set (make-local-variable 'view-no-disable-on-exit) t)

Why keep the view-no-disable-on-exit setting?

> -(defvar help-xref-override-view-map
> -  (let ((map (make-sparse-keymap)))
> -    (set-keymap-parent map view-mode-map)
> -    (define-key map "\r" nil)
> -    map)
> -  "Replacement keymap for `view-mode' in help buffers.")
> -
>  ;;;###autoload
>  (defun help-make-xrefs (&optional buffer)
>    "Parse and hyperlink documentation cross-references in the given BUFFER.
> @@ -594,9 +561,6 @@
>                                       (current-buffer)))
>            (when (or help-xref-stack help-xref-forward-stack)
>              (insert "\n")))
> -        ;; View mode steals RET from us.
> -        (set (make-local-variable 'minor-mode-overriding-map-alist)
> -             (list (cons 'view-mode help-xref-override-view-map)))
>          (set-buffer-modified-p old-modified)))))
 
Looks pretty good overall, thank you.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> OK, I see some instances where this is still present although the mode is
>> derived from special-mode. I assume those can be removed then?
>
> Yes.

OK. I will clean those up.

>> There is multiple instances where the mode derives from special-mode, but
>> the keymap parent is explicitly set to special-mode also.  Should those
>> be removed?
>
> They don't hurt.

OK.

> copy-keymap is usually a bad idea.  I guess you used it in order to
> still be able to inherit from special-mode-map, but that's not needed
> any more: I installed a week ago changes that add multiple-keymap
> inheritance

Excellent. That was exactly what I was trying to achieve.

> Why keep the view-no-disable-on-exit setting?

Oversight. Removed.

Here is the updated patch with Changelog entry.

Christoph


=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2011-07-06 22:43:46 +0000
+++ lisp/ChangeLog	2011-07-12 04:12:27 +0000
@@ -1,3 +1,12 @@
+2011-07-12  Christoph Scholtes  <cschol2112@googlemail.com>
+
+	* help-mode.el (help-mode-map): Add special-mode-map to parent map.
+	(help-mode): Derive help-mode from special-mode. Don't invoke
+	view-mode from help-mode.
+	(help-xref-override-view-map): Remove.
+	(help-make-xrefs): Remove minor-mode-overriding-map-alist since
+	view-mode is not used anymore.
+
 2011-07-06  Richard Stallman  <rms@gnu.org>
 
 	* mail/rmailmm.el (rmail-mime-process): Use markers for buf positions.

=== modified file 'lisp/help-mode.el'
--- lisp/help-mode.el	2011-06-13 13:14:42 +0000
+++ lisp/help-mode.el	2011-07-12 03:41:40 +0000
@@ -35,13 +35,12 @@
 
 (defvar help-mode-map
   (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map button-buffer-map)
-
+    (set-keymap-parent map (make-composed-keymap button-buffer-map
+                                                 special-mode-map))
     (define-key map [mouse-2] 'help-follow-mouse)
     (define-key map "\C-c\C-b" 'help-go-back)
     (define-key map "\C-c\C-f" 'help-go-forward)
     (define-key map "\C-c\C-c" 'help-follow-symbol)
-    ;; Documentation only, since we use minor-mode-overriding-map-alist.
     (define-key map "\r" 'help-follow)
     map)
   "Keymap for help mode.")
@@ -266,37 +265,13 @@
   'help-function 'customize-create-theme
   'help-echo (purecopy "mouse-2, RET: edit this theme file"))
 \f
-;;;###autoload
-(defun help-mode ()
+(define-derived-mode help-mode special-mode "Help"
   "Major mode for viewing help text and navigating references in it.
 Entry to this mode runs the normal hook `help-mode-hook'.
 Commands:
 \\{help-mode-map}"
-  (interactive)
-  (kill-all-local-variables)
-  (use-local-map help-mode-map)
-  (setq mode-name "Help")
-  (setq major-mode 'help-mode)
-
-  (view-mode)
-  (set (make-local-variable 'view-no-disable-on-exit) t)
-  ;; With Emacs 22 `view-exit-action' could delete the selected window
-  ;; disregarding whether the help buffer was shown in that window at
-  ;; all.  Since `view-exit-action' is called with the help buffer as
-  ;; argument it seems more appropriate to have it work on the buffer
-  ;; only and leave it to `view-mode-exit' to delete any associated
-  ;; window(s).
-  (setq view-exit-action
-	(lambda (buffer)
-	  ;; Use `with-current-buffer' to make sure that `bury-buffer'
-	  ;; also removes BUFFER from the selected window.
-	  (with-current-buffer buffer
-	    (bury-buffer))))
-
   (set (make-local-variable 'revert-buffer-function)
-       'help-mode-revert-buffer)
-
-  (run-mode-hooks 'help-mode-hook))
+       'help-mode-revert-buffer))
 
 ;;;###autoload
 (defun help-mode-setup ()
@@ -403,13 +378,6 @@
        (error "Current buffer is not in Help mode"))
      (current-buffer))))
 
-(defvar help-xref-override-view-map
-  (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map view-mode-map)
-    (define-key map "\r" nil)
-    map)
-  "Replacement keymap for `view-mode' in help buffers.")
-
 ;;;###autoload
 (defun help-make-xrefs (&optional buffer)
   "Parse and hyperlink documentation cross-references in the given BUFFER.
@@ -594,9 +562,6 @@
                                      (current-buffer)))
           (when (or help-xref-stack help-xref-forward-stack)
             (insert "\n")))
-        ;; View mode steals RET from us.
-        (set (make-local-variable 'minor-mode-overriding-map-alist)
-             (list (cons 'view-mode help-xref-override-view-map)))
         (set-buffer-modified-p old-modified)))))
 
 ;;;###autoload

Re: completion-list-mode-map

[Christoph Scholtes]

Sorry, does this look OK to commit?

Christoph

On 7/11/2011 10:20 PM, Christoph Scholtes wrote:

> Here is the updated patch with Changelog entry.
>
> === modified file 'lisp/ChangeLog'
> --- lisp/ChangeLog	2011-07-06 22:43:46 +0000
> +++ lisp/ChangeLog	2011-07-12 04:12:27 +0000
> @@ -1,3 +1,12 @@
> +2011-07-12  Christoph Scholtes<cschol2112@googlemail.com>
> +
> +	* help-mode.el (help-mode-map): Add special-mode-map to parent map.
> +	(help-mode): Derive help-mode from special-mode. Don't invoke
> +	view-mode from help-mode.
> +	(help-xref-override-view-map): Remove.
> +	(help-make-xrefs): Remove minor-mode-overriding-map-alist since
> +	view-mode is not used anymore.
> +
>   2011-07-06  Richard Stallman<rms@gnu.org>
>
>   	* mail/rmailmm.el (rmail-mime-process): Use markers for buf positions.
>
> === modified file 'lisp/help-mode.el'
> --- lisp/help-mode.el	2011-06-13 13:14:42 +0000
> +++ lisp/help-mode.el	2011-07-12 03:41:40 +0000
> @@ -35,13 +35,12 @@
>
>   (defvar help-mode-map
>     (let ((map (make-sparse-keymap)))
> -    (set-keymap-parent map button-buffer-map)
> -
> +    (set-keymap-parent map (make-composed-keymap button-buffer-map
> +                                                 special-mode-map))
>       (define-key map [mouse-2] 'help-follow-mouse)
>       (define-key map "\C-c\C-b" 'help-go-back)
>       (define-key map "\C-c\C-f" 'help-go-forward)
>       (define-key map "\C-c\C-c" 'help-follow-symbol)
> -    ;; Documentation only, since we use minor-mode-overriding-map-alist.
>       (define-key map "\r" 'help-follow)
>       map)
>     "Keymap for help mode.")
> @@ -266,37 +265,13 @@
>     'help-function 'customize-create-theme
>     'help-echo (purecopy "mouse-2, RET: edit this theme file"))
>   \f
> -;;;###autoload
> -(defun help-mode ()
> +(define-derived-mode help-mode special-mode "Help"
>     "Major mode for viewing help text and navigating references in it.
>   Entry to this mode runs the normal hook `help-mode-hook'.
>   Commands:
>   \\{help-mode-map}"
> -  (interactive)
> -  (kill-all-local-variables)
> -  (use-local-map help-mode-map)
> -  (setq mode-name "Help")
> -  (setq major-mode 'help-mode)
> -
> -  (view-mode)
> -  (set (make-local-variable 'view-no-disable-on-exit) t)
> -  ;; With Emacs 22 `view-exit-action' could delete the selected window
> -  ;; disregarding whether the help buffer was shown in that window at
> -  ;; all.  Since `view-exit-action' is called with the help buffer as
> -  ;; argument it seems more appropriate to have it work on the buffer
> -  ;; only and leave it to `view-mode-exit' to delete any associated
> -  ;; window(s).
> -  (setq view-exit-action
> -	(lambda (buffer)
> -	  ;; Use `with-current-buffer' to make sure that `bury-buffer'
> -	  ;; also removes BUFFER from the selected window.
> -	  (with-current-buffer buffer
> -	    (bury-buffer))))
> -
>     (set (make-local-variable 'revert-buffer-function)
> -       'help-mode-revert-buffer)
> -
> -  (run-mode-hooks 'help-mode-hook))
> +       'help-mode-revert-buffer))
>
>   ;;;###autoload
>   (defun help-mode-setup ()
> @@ -403,13 +378,6 @@
>          (error "Current buffer is not in Help mode"))
>        (current-buffer))))
>
> -(defvar help-xref-override-view-map
> -  (let ((map (make-sparse-keymap)))
> -    (set-keymap-parent map view-mode-map)
> -    (define-key map "\r" nil)
> -    map)
> -  "Replacement keymap for `view-mode' in help buffers.")
> -
>   ;;;###autoload
>   (defun help-make-xrefs (&optional buffer)
>     "Parse and hyperlink documentation cross-references in the given BUFFER.
> @@ -594,9 +562,6 @@
>                                        (current-buffer)))
>             (when (or help-xref-stack help-xref-forward-stack)
>               (insert "\n")))
> -        ;; View mode steals RET from us.
> -        (set (make-local-variable 'minor-mode-overriding-map-alist)
> -             (list (cons 'view-mode help-xref-override-view-map)))
>           (set-buffer-modified-p old-modified)))))
>
>   ;;;###autoload

Re: completion-list-mode-map

[Juanma Barranquero]

On Tue, Jul 12, 2011 at 05:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>    (set-keymap-parent map (make-composed-keymap button-buffer-map
>                                                 special-mode-map))

BTW, why is make-composed-keymap in C? I though we did in Elisp as
much as possible, and m-c-k is just

  (apply 'list 'keymap keymaps)

And, shouldn't it check that its arguments are really keymaps?

    Juanma

Re: completion-list-mode-map

[Stefan Monnier]

>>    (set-keymap-parent map (make-composed-keymap button-buffer-map
>>                                                 special-mode-map))

> BTW, why is make-composed-keymap in C?

Good question.  It's largely an accident.  That's code I wrote many
years ago.


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

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

I thought I had sent this updated patch to the list, but I can't seem to 
find it in my archives. So here it is again.

Thanks,
Christoph

[-- Attachment #2: special-mode_v2.patch --]
[-- Type: text/plain, Size: 3648 bytes --]

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2011-07-06 22:43:46 +0000
+++ lisp/ChangeLog	2011-07-12 04:12:27 +0000
@@ -1,3 +1,12 @@
+2011-07-12  Christoph Scholtes  <cschol2112@googlemail.com>
+
+	* help-mode.el (help-mode-map): Add special-mode-map to parent map.
+	(help-mode): Derive help-mode from special-mode. Don't invoke
+	view-mode from help-mode.
+	(help-xref-override-view-map): Remove.
+	(help-make-xrefs): Remove minor-mode-overriding-map-alist since
+	view-mode is not used anymore.
+
 2011-07-06  Richard Stallman  <rms@gnu.org>
 
 	* mail/rmailmm.el (rmail-mime-process): Use markers for buf positions.

=== modified file 'lisp/help-mode.el'
--- lisp/help-mode.el	2011-06-13 13:14:42 +0000
+++ lisp/help-mode.el	2011-07-12 03:41:40 +0000
@@ -35,13 +35,12 @@
 
 (defvar help-mode-map
   (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map button-buffer-map)
-
+    (set-keymap-parent map (make-composed-keymap button-buffer-map
+                                                 special-mode-map))
     (define-key map [mouse-2] 'help-follow-mouse)
     (define-key map "\C-c\C-b" 'help-go-back)
     (define-key map "\C-c\C-f" 'help-go-forward)
     (define-key map "\C-c\C-c" 'help-follow-symbol)
-    ;; Documentation only, since we use minor-mode-overriding-map-alist.
     (define-key map "\r" 'help-follow)
     map)
   "Keymap for help mode.")
@@ -266,37 +265,13 @@
   'help-function 'customize-create-theme
   'help-echo (purecopy "mouse-2, RET: edit this theme file"))
 \f
-;;;###autoload
-(defun help-mode ()
+(define-derived-mode help-mode special-mode "Help"
   "Major mode for viewing help text and navigating references in it.
 Entry to this mode runs the normal hook `help-mode-hook'.
 Commands:
 \\{help-mode-map}"
-  (interactive)
-  (kill-all-local-variables)
-  (use-local-map help-mode-map)
-  (setq mode-name "Help")
-  (setq major-mode 'help-mode)
-
-  (view-mode)
-  (set (make-local-variable 'view-no-disable-on-exit) t)
-  ;; With Emacs 22 `view-exit-action' could delete the selected window
-  ;; disregarding whether the help buffer was shown in that window at
-  ;; all.  Since `view-exit-action' is called with the help buffer as
-  ;; argument it seems more appropriate to have it work on the buffer
-  ;; only and leave it to `view-mode-exit' to delete any associated
-  ;; window(s).
-  (setq view-exit-action
-	(lambda (buffer)
-	  ;; Use `with-current-buffer' to make sure that `bury-buffer'
-	  ;; also removes BUFFER from the selected window.
-	  (with-current-buffer buffer
-	    (bury-buffer))))
-
   (set (make-local-variable 'revert-buffer-function)
-       'help-mode-revert-buffer)
-
-  (run-mode-hooks 'help-mode-hook))
+       'help-mode-revert-buffer))
 
 ;;;###autoload
 (defun help-mode-setup ()
@@ -403,13 +378,6 @@
        (error "Current buffer is not in Help mode"))
      (current-buffer))))
 
-(defvar help-xref-override-view-map
-  (let ((map (make-sparse-keymap)))
-    (set-keymap-parent map view-mode-map)
-    (define-key map "\r" nil)
-    map)
-  "Replacement keymap for `view-mode' in help buffers.")
-
 ;;;###autoload
 (defun help-make-xrefs (&optional buffer)
   "Parse and hyperlink documentation cross-references in the given BUFFER.
@@ -594,9 +562,6 @@
                                      (current-buffer)))
           (when (or help-xref-stack help-xref-forward-stack)
             (insert "\n")))
-        ;; View mode steals RET from us.
-        (set (make-local-variable 'minor-mode-overriding-map-alist)
-             (list (cons 'view-mode help-xref-override-view-map)))
         (set-buffer-modified-p old-modified)))))
 
 ;;;###autoload

Re: completion-list-mode-map

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> I thought I had sent this updated patch to the list, but I can't seem
> to find it in my archives. So here it is again.

With this change, `q' in help buffers runs quit-window, which does not
delete the window.  Currently, `q' in help buffers runs View-quit, which
deletes the window.

I'm not a big fan of View mode in general, but the View-quit behavior
seems a bit more convenient in the context of help mode.

Re: completion-list-mode-map

[Stefan Monnier]

>> I thought I had sent this updated patch to the list, but I can't seem
>> to find it in my archives. So here it is again.
> With this change, `q' in help buffers runs quit-window, which does not
> delete the window.  Currently, `q' in help buffers runs View-quit, which
> deletes the window.

I think both of these claims are only true in specific circumstances.
And indeed, it's not right to always delete the window, nor is it right
to never delete the window.
If you tell us when you saw which behavior, we might be able to fix
quit-window so it does the right thing.


        Stefan

Re: completion-list-mode-map

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I thought I had sent this updated patch to the list, but I can't seem
>>> to find it in my archives. So here it is again.
>> With this change, `q' in help buffers runs quit-window, which does not
>> delete the window.  Currently, `q' in help buffers runs View-quit, which
>> deletes the window.
>
> I think both of these claims are only true in specific circumstances.
> And indeed, it's not right to always delete the window, nor is it right
> to never delete the window.
> If you tell us when you saw which behavior, we might be able to fix
> quit-window so it does the right thing.
BTW could you disable this message:

Type "q" in help window to quit.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: completion-list-mode-map

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> With this change, `q' in help buffers runs quit-window, which does not
>> delete the window.  Currently, `q' in help buffers runs View-quit, which
>> deletes the window.
>
> I think both of these claims are only true in specific circumstances.
> And indeed, it's not right to always delete the window, nor is it right
> to never delete the window.
> If you tell us when you saw which behavior, we might be able to fix
> quit-window so it does the right thing.

emacs -Q
C-h k k    => help window pops up
C-x o
q          => help window deleted

Re: completion-list-mode-map

[Stefan Monnier]

>>> With this change, `q' in help buffers runs quit-window, which does not
>>> delete the window.  Currently, `q' in help buffers runs View-quit, which
>>> deletes the window.
>> I think both of these claims are only true in specific circumstances.
>> And indeed, it's not right to always delete the window, nor is it right
>> to never delete the window.
>> If you tell us when you saw which behavior, we might be able to fix
>> quit-window so it does the right thing.

> emacs -Q
> C-h k k    => help window pops up
> C-x o
> q          => help window deleted

OK, that's a bug/misfeature of quit-window which we should fix.
I.e. not an impediment to using quit-window.


        Stefan

Re: completion-list-mode-map

[martin rudalics]

 >> emacs -Q
 >> C-h k k    => help window pops up
 >> C-x o
 >> q          => help window deleted
 >
 > OK, that's a bug/misfeature of quit-window which we should fix.
 > I.e. not an impediment to using quit-window.

When the help window was reused, q restores its old buffer and its
positions wrt the window.  `quit-window' can't do that because it
doesn't know anything about the window's history.

This and some other quirks are avoided by `quit-restore-window'.

martin

Re: completion-list-mode-map

[Stefan Monnier]

>>> emacs -Q
>>> C-h k k    => help window pops up
>>> C-x o
>>> q          => help window deleted
>> 
>> OK, that's a bug/misfeature of quit-window which we should fix.
>> I.e. not an impediment to using quit-window.

> When the help window was reused, q restores its old buffer and its
> positions wrt the window.  `quit-window' can't do that because it
> doesn't know anything about the window's history.

> This and some other quirks are avoided by `quit-restore-window'.

The thing I don't understand is why we need quit-restore-window rather
than changing quit-window (to behave like quit-restore-window)?


        Stefan

Re: completion-list-mode-map

[martin rudalics]

 > The thing I don't understand is why we need quit-restore-window rather
 > than changing quit-window (to behave like quit-restore-window)?

You imagine me call a function with a -window postfix whose first
argument is KILL and whose second argument is the window?

martin

Re: completion-list-mode-map

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> You imagine me call a function with a -window postfix whose first
> argument is KILL and whose second argument is the window?

Any other reason?  If not, let's just rename quit-restore-window to
quit-window, and live with the non-optimal argument order as a
historical accident.

Re: completion-list-mode-map

[martin rudalics]

 > Any other reason?

Yes.  As a rule, window functions consider WINDOW nil as the selected
window.  `quit-window' doesn't.

 > If not, let's just rename quit-restore-window to
 > quit-window, and live with the non-optimal argument order as a
 > historical accident.

I'm afraid that `quit-window' aficionados might not be all too happy.
That function has a quite separate history and is mostly
`switch-to-buffer' optionally killing or burying the current buffer.

`quit-restore-window' OTOH does delete the window or the frame if it has
been specially created for displaying the buffer.

martin

Re: completion-list-mode-map

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> Any other reason?
>
> Yes.  As a rule, window functions consider WINDOW nil as the selected
> window.  `quit-window' doesn't.

The callers to quit-window will just have to deal with that.

> I'm afraid that `quit-window' aficionados might not be all too happy.
> That function has a quite separate history and is mostly
> `switch-to-buffer' optionally killing or burying the current buffer.

That is exactly the problem with `quit-window' that is being discussed
in this thread.

Re: completion-list-mode-map

[martin rudalics]

 >> That function has a quite separate history and is mostly
 >> `switch-to-buffer' optionally killing or burying the current buffer.
 >
 > That is exactly the problem with `quit-window' that is being discussed
 > in this thread.

All I found is that Scholtes said that

 > > Like I said, I noticed some inconsistencies with the behavior of buffers
 > > like completion, especially when it comes to quitting and/or killing the
 > > buffer. Most notably help-mode stands out since it has a view-mode minor
 > > mode, which maps `q' to `quit-window' and `z' to a scroll function. In
 > > special-mode buffers I can use `q' to quit (and bury) and `z' to kill,
 > > which is nice. help-mode requires me to set the view-exit-action to
 > > `kill' to achieve a similar result, but it is still inconsistent. Could
 > > we make help-mode derive its map from special-mode also? Or would this
 > > change the key bindings for help-mode too much?

So IIUC he wants the current behavior of `quit-window' extend to
help-mode as well.  OTOH my personal `special-mode-map' has

(defvar special-mode-map
   (let ((map (make-sparse-keymap)))
     (suppress-keymap map)
     (define-key map "q" 'quit-restore-window)
     ...
     (define-key map "z" 'kill-this-buffer)
     map))

so I don't know why you need to conflate the two functions.

martin

Re: completion-list-mode-map

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>>> That function has a quite separate history and is mostly
>>> `switch-to-buffer' optionally killing or burying the current buffer.
>>
>> That is exactly the problem with `quit-window' that is being discussed
>> in this thread.
>
> All I found is that Scholtes said that

No, I was referring to this:

>> emacs -Q
>> C-h k k    => help window pops up
>> C-x o
>> q          => help window deleted
>
> OK, that's a bug/misfeature of quit-window which we should fix.
> I.e. not an impediment to using quit-window.

Re: completion-list-mode-map

[martin rudalics]

 > No, I was referring to this:
 >
 >>> emacs -Q
 >>> C-h k k    => help window pops up
 >>> C-x o
 >>> q          => help window deleted
 >> OK, that's a bug/misfeature of quit-window which we should fix.
 >> I.e. not an impediment to using quit-window.

Yes.  But IIUC this should have beed seen in the context of making "q"
quit the window in `special-mode-map'.  And I said that `quit-window'
has its own live outside of `special-mode-map', something we probably
shouldn't touch.

That said I have no problems doing either of

(1) binding "q" in special-mode-map to `quit-restore-window', or

(2) renaming `quit-restore-window' to `quit-window', reverting its
     arguments order.

Personally I'd prefer (1) since it's cleaner, doesn't require any
changes to existing code, and doesn't affect people having bound
`quit-window' to some key in their .emacs.

martin

Re: completion-list-mode-map

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Yes.  But IIUC this should have beed seen in the context of making "q"
> quit the window in `special-mode-map'.  And I said that `quit-window'
> has its own live outside of `special-mode-map', something we probably
> shouldn't touch.
>
> That said I have no problems doing either of
>
> (1) binding "q" in special-mode-map to `quit-restore-window', or
>
> (2) renaming `quit-restore-window' to `quit-window', reverting its
>     arguments order.
>
> Personally I'd prefer (1) since it's cleaner, doesn't require any
> changes to existing code, and doesn't affect people having bound
> `quit-window' to some key in their .emacs.

Can you provide an example of a situation in which caller of quit-window
would not want the quit-restore-window behavior?

Re: completion-list-mode-map

[martin rudalics]

 > Can you provide an example of a situation in which caller of quit-window
 > would not want the quit-restore-window behavior?

With emacs -Q do C-x 2.  Doing

   M-x quit-window

now shows *Messages* in the window while

   M-x quit-restore-window

deletes the window.

martin

Re: completion-list-mode-map

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> Can you provide an example of a situation in which caller of quit-window
>> would not want the quit-restore-window behavior?
>
> With emacs -Q do C-x 2.  Doing
>
>   M-x quit-window
>
> now shows *Messages* in the window while
>
>   M-x quit-restore-window
>
> deletes the window.

This is going round in circles.  We know that quit-window and
quit-restore-window have different behaviors.  The statement we are
considering is whether all the users of quit-window would prefer the
behavior of quit-restore-window, in which case we should replace
quit-window with quit-restore-window.

If no one provides a good example, I'll go ahead and make the change.

Re: completion-list-mode-map

[Juri Linkov]

> This is going round in circles.  We know that quit-window and
> quit-restore-window have different behaviors.  The statement we are
> considering is whether all the users of quit-window would prefer the
> behavior of quit-restore-window, in which case we should replace
> quit-window with quit-restore-window.
>
> If no one provides a good example, I'll go ahead and make the change.

I agree that one function `quit-window' should be enough,
but I also think that "undisplaying" a buffer should be
customizable like displaying a buffer, so users could customize
a variable like `quit-window-alist' to restore the old behavior of
`quit-window' and to modify the new behavior of `quit-restore-window'
(renamed to `quit-window').  This also requires to change its
function signature to `(quit-window &optional WINDOW SPECIFIERS)'.

Re: completion-list-mode-map

[Štěpán Němec]

On Mon, 22 Aug 2011 11:00:18 +0200
Juri Linkov wrote:

> I agree that one function `quit-window' should be enough,
> but I also think that "undisplaying" a buffer should be
> customizable like displaying a buffer, so users could customize
> a variable like `quit-window-alist' to restore the old behavior of
> `quit-window' and to modify the new behavior of `quit-restore-window'
> (renamed to `quit-window').  This also requires to change its
> function signature to `(quit-window &optional WINDOW SPECIFIERS)'.

I'd appreciate that, too. See bug#4550, where Stefan didn't express much
sympathy for this, but let's hope he can be persuaded otherwise when
more people voice their support.

-- 
Štěpán

Re: completion-list-mode-map

[Stefan Monnier]

>> I agree that one function `quit-window' should be enough,
>> but I also think that "undisplaying" a buffer should be
>> customizable like displaying a buffer, so users could customize
>> a variable like `quit-window-alist' to restore the old behavior of
>> `quit-window' and to modify the new behavior of `quit-restore-window'
>> (renamed to `quit-window').

I tend to think that the behavior of quit-window can be specified when
displaying the buffer and/or creating the window, so that quit-window
does not require any buffer-specific customization.
But I could be persuaded otherwise, given some clear examples.

>> This also requires to change its function signature to `(quit-window
>> &optional WINDOW SPECIFIERS)'.

I don't see how this follows: quit-window is a command.  The few rare
times it's called from Elisp aren't important enough to warrant such
a change.

> I'd appreciate that, too. See bug#4550, where Stefan didn't express much
> sympathy for this, but let's hope he can be persuaded otherwise when
> more people voice their support.

As mentioned at a few other occasions, I'm fine with adding some kind of
bury-buffer-function that lets the user control whether to iconify or
delete a dedicated frame (or do something else entirely).
I'm just waiting for someone (e.g. Drew) to write the patch.


        Stefan

Re: completion-list-mode-map

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> I agree that one function `quit-window' should be enough,
> but I also think that "undisplaying" a buffer should be
> customizable like displaying a buffer, so users could customize
> a variable like `quit-window-alist' to restore the old behavior of
> `quit-window' and to modify the new behavior of `quit-restore-window'
> (renamed to `quit-window').  This also requires to change its
> function signature to `(quit-window &optional WINDOW SPECIFIERS)'.

We can save that for post-24.1.

Re: completion-list-mode-map

[martin rudalics]

> If no one provides a good example, I'll go ahead and make the change.

Please do whatever you consider appropriate.

martin

Re: completion-list-mode-map

[Christoph Scholtes]

Sorry, I have been out of the loop for a while.

Chong, thanks for committing the patch.

On 8/21/2011 2:26 PM, Chong Yidong wrote:

> This is going round in circles.  We know that quit-window and
> quit-restore-window have different behaviors.  The statement we are
> considering is whether all the users of quit-window would prefer the
> behavior of quit-restore-window, in which case we should replace
> quit-window with quit-restore-window.
>
> If no one provides a good example, I'll go ahead and make the change.

Sounds good to me.

Almost always, when typing q in *help* mode (or a special-mode for that 
matter) I want to kill the buffer also. I wish quit-window's default 
behavior was kill instead of bury, with C-u q burying the buffer. z 
kills the buffer, but it doesn't delete the window and its frame.

Christoph

Re: completion-list-mode-map

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> Almost always, when typing q in *help* mode (or a special-mode for
> that matter) I want to kill the buffer also. I wish quit-window's
> default behavior was kill instead of bury, with C-u q burying the
> buffer. z kills the buffer, but it doesn't delete the window and its
> frame.

For now, you will just have to advise quit-window, to make its KILL
argument always t.

Re: completion-list-mode-map

[Christoph Scholtes]

On 9/3/2011 12:33 PM, Chong Yidong wrote:

> For now, you will just have to advise quit-window, to make its KILL
> argument always t.

OK. Would this be the correct way to swap the kill/bury behavior?

(defadvice quit-window (before advise-quit-window activate)
   (if (ad-get-arg 0)
       (ad-set-arg 0 nil)
     (ad-set-arg 0 t)))

Thanks,
Christoph

Re: completion-list-mode-map

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> OK. Would this be the correct way to swap the kill/bury behavior?
>
> (defadvice quit-window (before advise-quit-window activate)
>   (if (ad-get-arg 0)
>       (ad-set-arg 0 nil)
>     (ad-set-arg 0 t)))

Yep.

Re: completion-list-mode-map

[Andreas Schwab]

Christoph Scholtes <cschol2112@googlemail.com> writes:

>   (if (ad-get-arg 0)
>       (ad-set-arg 0 nil)
>     (ad-set-arg 0 t)))
    (ad-set-arg 0 (not (ad-get-arg 0)))

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: completion-list-mode-map

[Stefan Monnier]

>> The thing I don't understand is why we need quit-restore-window rather
>> than changing quit-window (to behave like quit-restore-window)?
> You imagine me call a function with a -window postfix whose first
> argument is KILL and whose second argument is the window?

Nobody talked about calling this function (it's a command and is only
rarely called as a function; maybe these calls are bad ideas, actually,
tho I haven't checked).


        Stefan

Re: completion-list-mode-map

[martin rudalics]

 > Nobody talked about calling this function (it's a command and is only
 > rarely called as a function; maybe these calls are bad ideas, actually,
 > tho I haven't checked).

There are some 20 calls of `quit-window' in Emacs.  So it's probably
better to check.

martin

completion-list-mode-map

[Christoph Scholtes]

Is there a specific reason why `completion-list-mode-map' does not have
the parent map `special-mode-map'?

It seems a little inconsistent that other command like `h' or `?' are
not available in a completion-list buffer and `z' and `q' are redefined
in `completion-list-mode-map'.

Also, I changed the definition of `completion-list-mode-map' as follows:

(defvar completion-list-mode-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map special-mode-map)
    (define-key map [mouse-2] 'mouse-choose-completion)
[...]

and reloaded, even byte-recompiled simple.el, and ultimately restarted
Emacs but for some reason Emacs would still show the old version of the
map with `C-h v completion-list-mode-map'. Any idea why? Do other files
have to be regenerated to update the map?

Regards,
Christoph

Re: completion-list-mode-map

[Stefan Monnier]

> Is there a specific reason why `completion-list-mode-map' does not have
> the parent map `special-mode-map'?

Mostly that special-mode-map is "recent" and we haven't changed all the
code to use it yet.

> It seems a little inconsistent that other command like `h' or `?' are
> not available in a completion-list buffer and `z' and `q' are redefined
> in `completion-list-mode-map'.

> Also, I changed the definition of `completion-list-mode-map' as follows:

> (defvar completion-list-mode-map
>   (let ((map (make-sparse-keymap)))
>     (set-keymap-parent map special-mode-map)
>     (define-key map [mouse-2] 'mouse-choose-completion)
> [...]

You might instead define completion-list-mode to derive from
special-mode rather than nil.

> and reloaded, even byte-recompiled simple.el, and ultimately restarted
> Emacs but for some reason Emacs would still show the old version of the
> map with `C-h v completion-list-mode-map'. Any idea why?

Reloading simple.el doesn't do it, because `defvar' has no effect if the
variable is already defined (hitting C-M-x with point inside the defvar
OTOH has special code to redefine the variable).
Recompiling simple.el and restarting Emacs doesn't make a difference
betwen simple.elc is preloaded in the `emacs' executable, so you'd then
need to rebuild `emacs' (which is built by running `temacs', loading
some files and then "dumping" the result to the `emacs' file).


        Stefan

Re: completion-list-mode-map

[Christoph Scholtes]

On 3/16/2011 8:22 PM, Stefan Monnier wrote:

> Mostly that special-mode-map is "recent" and we haven't changed all the
> code to use it yet.

I see. I will provide a patch then.

Like I said, I noticed some inconsistencies with the behavior of buffers 
like completion, especially when it comes to quitting and/or killing the 
buffer. Most notably help-mode stands out since it has a view-mode minor 
mode, which maps `q' to `quit-window' and `z' to a scroll function. In 
special-mode buffers I can use `q' to quit (and bury) and `z' to kill, 
which is nice. help-mode requires me to set the view-exit-action to 
`kill' to achieve a similar result, but it is still inconsistent. Could 
we make help-mode derive its map from special-mode also? Or would this 
change the key bindings for help-mode too much?

> You might instead define completion-list-mode to derive from
> special-mode rather than nil.

Ok.

> Reloading simple.el doesn't do it, because `defvar' has no effect if the
> variable is already defined (hitting C-M-x with point inside the defvar
> OTOH has special code to redefine the variable).
> Recompiling simple.el and restarting Emacs doesn't make a difference
> betwen simple.elc is preloaded in the `emacs' executable, so you'd then
> need to rebuild `emacs' (which is built by running `temacs', loading
> some files and then "dumping" the result to the `emacs' file).

Thanks for the explanation. That makes sense now.

Christoph

Re: completion-list-mode-map

[Wojciech Meyer]

Hi Christoph,

Sorry hit the wrong button as I am forced to use gmail web interface
not Gnus :).
Now it's to the mailing list:

On Thu, Mar 17, 2011 at 5:00 AM, Christoph Scholtes
<cschol2112@googlemail.com> wrote:
> On 3/16/2011 8:22 PM, Stefan Monnier wrote:
>
>> Mostly that special-mode-map is "recent" and we haven't changed all the
>> code to use it yet.
>
> I see. I will provide a patch then.

I've already sent a patch to derive all the `special modes likes' from
`special-mode'.
Then, I needed a paperwork to sign and the whole thing got stalled for 8 months.
Fortunately, I am able to submit the patch again, because the process's ended
and I can finally contribute to Emacs. If you could put on hold your
patch and be
patient then this weekend I will resubmit the patch.

Thanks for consideration,
Wojciech