emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Refreshing Info nodes


From: Wojciech Meyer
Subject: Re: Refreshing Info nodes
Date: Mon, 13 Sep 2010 11:22:50 +0100

On Mon, Sep 13, 2010 at 11:11 AM, Stefan Monnier
<address@hidden> wrote:
>> 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.

I know.. and I thought I could look at it later.

>
>> 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".
>

OK.

>> 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, ...)).

Yes, I will do just major-mode swap for time being.

>
>> (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.

Actually that's what i though initially.

>
>> 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)

In the begining, I was not sure if i should leave those lines.

>
> 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.

That was my consideration too.

>
>>  (put 'occur-mode 'mode-class 'special)
>> -(defun occur-mode ()
>> +(define-derived-mode occur-mode special-mode "Occur"
>
> Here also, the `put' is now redundant.

Yes.

>
>
>        Stefan
>

Thank you,
I will send the final version soon.
Wojciech



reply via email to

[Prev in Thread] Current Thread [Next in Thread]