Customizing global-evil-search-highlight-persist doesn't work.

[olejorgenb]

Description

Customizing global-evil-search-highlight-persist doesn't work.

It's value is overwritten.

Reproduction guide

• Start Emacs
• M-x cusomize-variableglobal-evil-search-highlight-persist
• Restart emacs

Observed behaviour:
global-evil-search-highlight-persist is t. Checking the cusomization page says "CHANGED outside Customize."

Expected behaviour:
global-evil-search-highlight-persist should be nil

Discussion
I suspect that spacemacs-evil/init-evil-search-highlight-persist is the culprit. This function runs global-evil-search-highlight-persist

System Info

• OS: gnu/linux
• Emacs: 24.5.1
• Spacemacs: 0.105.11
• Spacemacs branch: develop (rev. 85fa271)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(spacemacs-helm auto-completion shell-scripts shell emacs-lisp common-lisp python git java nixos lua command-log colors
                (c-c   :variables c-c  -default-mode-for-headers 'c  -mode)
                semantic scheme org version-control my-rtags)

[TheBB]

Can't you just turn the mode off in dotspacemacs/user-config instead?

[olejorgenb]

Sure, but the variable is documented as being customizable, so I'd say it's a bug, although minor.

I can investigate a bit further. (If someone happens to know a good entry point/developer documentation of the loading process it would be helpful though)

[TheBB]

I'm leaning towards wontfix... you're not the first person to want to use customize for stuff that Spacemacs changes during startup, but the effort involved in checking literally every single variable we want to set or mode we want to enable is just not worth it for me.

[olejorgenb]

Ok. I'm not very invested in the customization system myself. But it seem like a decent system. I just found out that you can add comments too, removing one of my initial reservations towards it.

Naively it seems like something is wrong[1] with the process if this is a problem for every/most(?) customizable variable spacemacs changes though?

I guess the customization variables are set before the spacemacs init code runs? Or maybe it has something to do with autoloading?

M-x enable-theme<ret>user<ret> sets global-evil-search-highlight-persist back to its customized value.

So (again, naively) it seems like doing that at the end of the spacemacs loading process would work (at the expense of performance).

If it's still a wont-fix it should at least be documented that using the customization facilities are problematic. I didn't find anything in the docs when researching this problem, and there's no FAQ.

I can write a FAQ if someone can give some pointers at why the problem exists.

[1] either due to the customization facility, or the way spacemacs does thing

[TheBB]

Well, I don't give the official final word, of course.

The problem is that customize puts its stuff at the end of the dotfile, outside of any functions defined by Spacemacs. Therefore those settings are applied when the dotfile is loaded, which is very early in the load process. Whenever Spacemacs sets a variable, they are necessarily overridden.

Maybe a better solution would be to figure out how to tweak exactly where customize stores its stuff and when it loads them.

[syl20bnr]

The location of customized values is a discussion we already had previously and I was against moving it from the dotfile for various reasons that I'm not sure of now.

We could treat customized variables as artefacts but instead of putting them in .cache we can put them in private directory. It is easy to control the loading time of them, ideally just before user-config. Users are then free to put this file in their dotfiles repo if they want. It should also support the dotdirectory of course.

[edrex]

newb opinion: I like the idea of putting customized vars somewhere other that the dotfile (private dir). When i saw it getting modified automatically it kind of freaked me out.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!