[Top][All Lists]

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

Re: overwriting c catchup shortcut in Group buffer

From: Emanuel Berg
Subject: Re: overwriting c catchup shortcut in Group buffer
Date: Mon, 11 May 2015 02:00:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Stefan Huchler <> writes:

> fly-keys is a modal mode you have a key to activate
> it and one to deactivate it, in other modes you can
> type the letter c as example, and in command mode
> you use it for previous-line.
> So I think there is your frequent change?

I mean if you were to frequently edit the code and
thus there would be a need to (re)evaluate it, you
would save some keystrokes by putting the hook updater
(add-hook) and the defun (i.e. the to-be definition of
the hook) in the same construct (the progn) so it
would only take one evaluation to do both. But it is
unrelated to this issue, it doesn't matter if there is
a progn there or not as for the behavior of the
software in execution...

>> It works for me, so perhaps your mode, whatever it
>> is, resets the keymap after that?
> ok then I add that to the bugtracker to the author
> or fly-keys, just wondered why it did work for
> Summary mode so I thought I just picked the wrong
> hook map.

I don't see why you should need hooks to set keys for
stuff that you use everyday and this `require' at
initialization and do not have loaded on-the-fly at
invocation time of some related command.

I do this for Gnus group, summary, and article modes.
`require' and then set the keymap.

If it is done in hooks, that means the same thing
would be evaluated many, many times an Emacs session.
Much better to load it, then set it, and then keep the
settings happily ever after.

Does it work without that mode? I don't see why it
shouldn't. You can also examine all the hooks of the
mode. Is there something *else* there that overrides
the desired settings?

underground experts united

reply via email to

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