define-key versus evil-define-key

[Gordon Gustafson]

What do you want this hook to accomplish? Binding keys in a hook is
rarely the best way to accomplish things (will eval-after-load work?).

> But, after thinking about it a bit more, perhaps it's reasonable to use
> evil-define-key for a mode and evil-motion-state-local-map for a specific buffer?

Yes. This should be the main factor governing the choice. Don't dig
into implementation when you don't have to! :)

On 9/18/14, Nikolai Weibull <now at disu.se> wrote:
> On Thu, Sep 18, 2014 at 8:29 PM, Gordon Gustafson <gordon3.14 at gmail.com>
> wrote:
>> Most importantly, your first example binds "\C-b" in the CURRENT
>> BUFFER for ALL MODES, while your second example binds "\C-b" for ALL
>> BUFFERS in ONLY THE SPECIFIED MODE (sorry for the caps, don't mean to
>> yell :P).
>
> I assumed my intentions (of using it inside a hook function) would be
> clear, but that was perhaps a bit presumptuous.
>
>> This probably means that the different methods bind with different
>> precedence
>
> Yes, that seems reasonable, but it still doesn't make it clear whether
> it's preferable to use the local or the auxiliary map.  But, after
> thinking about it a bit more, perhaps it's reasonable to use
> evil-define-key for a mode and evil-motion-state-local-map for a
> specific buffer?
>
>> On 9/17/14, Nikolai Weibull <now at disu.se> wrote:
>>> Hi!
>>>
>>> What's the preferred way of adding keys to a given mode's map?
>>>
>>> Is
>>>
>>> (define-key evil-motion-state-local-map "\C-b"
>>> 'calendar-scroll-right-three-months)
>>>
>>> or
>>>
>>> (evil-define-key 'motion calendar-mode-map "\C-b"
>>> 'calendar-scroll-right-three-months)
>>>
>>> preferable?
>>>
>>> (From an ease-of-use perspective, the second is better, as it allows
>>> you to easily map more keys, but I'm wondering from a "the right way
>>> to do it" perspective.)
>>>
>>> _______________________________________________
>>> implementations-list mailing list
>>> implementations-list at lists.ourproject.org
>>> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
>>>
>>
>> _______________________________________________
>> implementations-list mailing list
>> implementations-list at lists.ourproject.org
>> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
>
> _______________________________________________
> implementations-list mailing list
> implementations-list at lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
>