Re: Refreshing Info nodes

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> +  ;; This is not interactive because you shouldn't be turning this
>>> +  ;; mode on and off.  You can corrupt things that way.
>>> +  ;;
>>> +  ;; Now it's derived mode, so therefore it is interactive.
>> 
>> These two pieces are contradictory, please clarify.  BTW, we should
>> change archive-mode to use buffer-swap-text like we did for tar-mode,
>> which should address this risk of corruption.

> Done. I am investigating possibility of using swap-buffer with
> archive-mode.

Great, but note that it's a separate issue to the one of using special-mode.

> BTW: Maybe we should think about merging (at least reusing bits & pieces
> and making user interface more consistent) tar-mode <-> archive-mode?

Yes, bringing them closer would be good, indeed.

> - changing `image-mode' to something else and wrapping the rest into
> `defun' (ad-hoc solution, which I like at least)

This solution you like least is the right one: image-mode should really
be a command that sets the major-mode to image-mode, not a command that
tries it and does something else if it can't be done.  I.e. we need
a separate command to do the "check if image-mode can be used, and call
image-mode if possible".

> Ideally in case of saving previous mode we should have a stack for this
> (even better, stack with functions that restore previous state, but this
> might be an overkill).

The user might want to switch in a circular rather than stack fashion.
Since we don't know how best to solve this general case, we stick to the
only really use case we know, where the user switches between two modes
(the doc-view/image-mode and the "see raw data" mode (can be
fundamental-mode, ps-mode, c-mode, ...)).

> (define-derived-mode my-major-mode special-mode 
>                                   :keymap 
>                                   (("n" . 'my-next-page)
>                                    ("C-s" . 'my-search))
>                                    ...)

We could, but a separate variable isn't that much hassle.

> (define-derived-mode my-major-mode special-mode 
>                                   :keymap 'my-major-mode-map
>                                    ...)

This would encourage the use of non-standard naming, so I'd rather not
go down that road.

> As you notice I also think that defining key-maps should be easier.
> Generally maybe we should do what's been done with `easy-menu' for maps.

As you may have noticed in easy-mmode-define-keymap, I've toyed with
this idea in the past.  Maybe a `defkeymap' macro would be good, indeed,
but it's not that important, I think.

> +(define-derived-mode archive-mode special-mode "Archive mode"
[...]
>  ;; Archive mode is suitable only for specially formatted data.
>  (put 'archive-mode 'mode-class 'special)

The above line is made redundant by deriving from special-mode.

> +(define-derived-mode bookmark-edit-annotation-mode nil "Edit Bookmark Annotation"
[...]
>    (run-mode-hooks 'text-mode-hook))

This run-mode-hooks is a good hint that the mode should actually derive
from text-mode-hook.

>  (put 'occur-mode 'mode-class 'special)
> -(defun occur-mode ()
> +(define-derived-mode occur-mode special-mode "Occur"

Here also, the `put' is now redundant.


        Stefan