Barry OReilly | 22 May 2012 00:59
Picon

Sequence of custom-set-variables and Evil init

I'm not sure whether to place the custom-set-variables call before or after initializing Evil.  Some customizations only work before Evil initialization, some after.

For example,
    (custom-set-variables
        '(evil-overriding-maps nil))
doesn't work correctly if after Evil init.

    (custom-set-variables
        '(evil-search-module (quote evil-search)))
doesn't work correctly if before evil init.

Which way is it supposed to be?  If I leave them separated, Emacs consolidates them into one again when I use its customization interface.

_______________________________________________
implementations-list mailing list
implementations-list <at> lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Frank Fischer | 23 May 2012 11:54
Picon

Re: Sequence of custom-set-variables and Evil init

On Mon, May 21, 2012 at 06:59:48PM -0400, Barry OReilly wrote:
> I'm not sure whether to place the custom-set-variables call before or after
> initializing Evil.  Some customizations only work before Evil
> initialization, some after.
> 
> For example,
>     (custom-set-variables
>         '(evil-overriding-maps nil))
> doesn't work correctly if after Evil init.
> 
>     (custom-set-variables
>         '(evil-search-module (quote evil-search)))
> doesn't work correctly if before evil init.
> 
> Which way is it supposed to be?  If I leave them separated, Emacs
> consolidates them into one again when I use its customization interface.

In general placing them after initializing evil is the way to do,
otherwise some variables could not be set because they require other
parts of evil to be present. But currently some customization
variables (like `evil-overriding-maps') need a much more sophisticated
set-function because their values are used in non-trivial ways. I'm
working on a patch but this customization-stuff is quite tricky so it
will take a few days.

In the meantime you could use (setq evil-overriding-maps nil) before
*loading* evil to achieve the same results (I think ;)).

Greetings,
Frank
Barry OReilly | 23 May 2012 16:36
Picon

Re: Sequence of custom-set-variables and Evil init

> In the meantime you could use (setq evil-overriding-maps nil) before
> *loading* evil to achieve the same results (I think ;)).

Do you mean after (require 'evil) and before (evil-mode 1)?  That
didn't work unfortunately.

Specifically, I have key bindings

(define-key evil-normal-state-map "o" nil)
(define-key evil-normal-state-map "O" nil)
(define-key evil-motion-state-map "o" 'next-buffer)
(define-key evil-motion-state-map "O" 'previous-buffer)

Which I want to work in all buffers, including buffer-menu.
Frank Fischer | 23 May 2012 17:24
Picon

Re: Sequence of custom-set-variables and Evil init

On Wed, May 23, 2012 at 10:36:23AM -0400, Barry OReilly wrote:
> > In the meantime you could use (setq evil-overriding-maps nil) before
> > *loading* evil to achieve the same results (I think ;)).
> 
> Do you mean after (require 'evil) and before (evil-mode 1)?  That
> didn't work unfortunately.

No, I mean before (require 'evil). The variables must be set to a
value before evil is loaded, then the defcustom directive should not
change that value and the initialization code should use the value set
by (setq ...).

> Specifically, I have key bindings
> 
> (define-key evil-normal-state-map "o" nil)
> (define-key evil-normal-state-map "O" nil)
> (define-key evil-motion-state-map "o" 'next-buffer)
> (define-key evil-motion-state-map "O" 'previous-buffer)
> 
> Which I want to work in all buffers, including buffer-menu.

I've just tested this with (setq ...) before (require 'evil) and it
seemed to work.

Frank
Frank Fischer | 25 May 2012 10:21
Picon

Re: Sequence of custom-set-variables and Evil init

I've added some commits (a95fc13) that should fix the initialization
of several customization variables, so the order of
custom-set-variables and (require 'evil) should be irrelevant now. If
there are further problems (maybe with other variables) please don't
hesitate to tell.

Frank

Gmane