ENCHANT_CONFIG_DIR treatment

[shipmints]

I'd like to override ENCHANT_CONFIG_DIR in my Emacs config. I setenv this in early-init and I validate that this is set before package autoloads, certainly before jinx--load-module is called (I advised jinx--load-module to also illustrate that the env var is correctly set before its first call). I also validate that (fboundp #'jinx--mod-dict) is nil throughout the entire Emacs startup sequence until after emacs-startup-hook runs.

I do also observe that when the env var is set externally, it does take precedence, so I know libenchant honors the variable.

According to the libenchant source code, the value of the env var is dynamically applied at the point that a spelling provider is created.

I'm a bit puzzled since I expect libenchant to not be initalized until after jinx loads it and definitely by that time the env var is correctly set.

macos 12.7.5, emacs 29.3, latest jinx, latest enchant (via brew).

[minad]

You probably use setenv to alter the environment variable, which modifies the Emacs process-environment. But as far as I understand it doesn't modify the environment of the current Emacs process itself.

[shipmints]

FWIW, I just experimented with sponsoring on my own.

[minad]

Thanks. So to be clear, I am considering your contribution, otherwise we wouldn't have this conversation. However every contribution needs maintenance and curation. This means I have to rework your and similar contributions and bring them into a form which I find consider good for the project. This costs a lot of time. I am in a difficult personal situation right now - I don't want to go into details, but this leads to a scenario where I need more support and cannot give away my time for free. Now contrast this with the increase in user numbers of my packages, and the natural increase in feature requests which follows from that.

[shipmints]

Of course. I'm with you. I'm currently contributing to several open source projects that I also have to support (in fact, working on a tricky bug right this very second which is taking up more time than I'd prefer).

With specific regard to the jinx changes in question, I find them very small, easy to reason about, and an actual improvement to jinx considering the nature of dynamic module use. Please review the changes and accept them. If there's something you'd like me to change, I'm happy to do it. I'm also happy to help support these changes.

[shipmints]

Consider applying for a $$$ grant here https://floss.fund/blog/announcing-floss-fund/

[shipmints]

https://github.blog/news-insights/company-news/announcing-github-secure-open-source-fund/