Internal define configuration

[aartaka]

Description

This allows for use of define-configuration in Nyxt code, making several things (define-modes in particular) simpler to do. See the discussion in https://github.com/atlas-engineer/nyxt/pull/3199/files#r1344010508 for the potential problems using define-configuration internally would cause.

Fixes #2877.

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

• Git hygiene:
  • I have pulled from master before submitting this PR
  • There are no merge conflicts.
• I've added the new dependencies as:
  • ASDF dependencies,
  • Git submodules,

    cd /path/to/nyxt/checkout
    git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

  • and Guix dependencies.
• My code follows the style guidelines for Common Lisp code. See:
  • Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
  • Google Common Lisp Style Guide
• I have performed a self-review of my own code.
• My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
• Documentation:
  • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
  • I have updated the existing documentation to match my changes.
  • I have commented my code in hard-to-understand areas.
  • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
    • Changelog update should be a separate commit.
  • I have added a migration.lisp entry for all compatibility-breaking changes.
  • (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
• Compilation and tests:
  • My changes generate no new warnings.
  • I have added tests that prove my fix is effective or that my feature works. (If possible.)
  • I ran the tests locally ((asdf:test-system :nyxt) and (asdf:test-system :nyxt/gi-gtk)) and they pass.

[jmercouris]

I see, so the idea is that we can add configuration for a given mode/class anywhere in the codebase?

As an example, in this case, you are using it to add several default modes to a context-buffer? This allows us to remove the resolve-sym hack to add the default modes for a context-buffer? This also allows us to load our files in a more flexible order then?

[aadcg]

I am not sure about the distinction between pre-customize-hook and customize-hook. What do we gain from it, and what would we loose without it?

[aartaka]

I am not sure about the distinction between pre-customize-hook and customize-hook. What do we gain from it, and what would we loose without it?

So imagine we set up some modes in Nyxt. I'm already doing this in this PR. And imagine that the user sets up their modes too—in their config. So we have several hook handlers customizing default-modes, for example. Now, the order of hook handlers is not guaranteed to be... ordered in any way. So, if the user removes some mode in their config, while we add this same mode, there might be different scenarios:

Nyxt enables A
Nyxt enables B
User disables A
User enables C
Enabled: B and c

or the actually problematic:

Nyxt enables B
User disables A
Nyxt enables A
User enables C
Enabled: A, B, and C

So we need to somehow prevent Nyxt from running config before the user one. Mainly so that user config can easily override the defaults. That's why there's pre-customize-hook—it runs before any user configuration and ensures that user code can override our config.

[aartaka]

I see, so the idea is that we can add configuration for a given mode/class anywhere in the codebase?

As an example, in this case, you are using it to add several default modes to a context-buffer? This allows us to remove the resolve-sym hack to add the default modes for a context-buffer? This also allows us to load our files in a more flexible order then?

Yes, yes, yes, and yes.

[aadcg]

@aartaka I see. But all user instances of define-configuration are invoked in the config files, i.e. they're evaluated after all internal Nyxt ones. That, in conjunction with the fact that the last instance of define-configuration is always honored (see PR #3163), seems to suggest that we may not need this separation. What am I missing?

[jmercouris]

I am OK with the use if the define-configuration internally, I think it is a smart strategy. I too would like to understand why we need another hook. If that can be clarified, I think this is a good improvement!

[aartaka]

aartaka I see. But all user instances of define-configuration are invoked in the config files, i.e. they're evaluated after all internal Nyxt ones. That, in conjunction with the fact that the last instance of define-configuration is always honored (see PR #3163), seems to suggest that we may not need this separation. What am I missing?

You're totally right, I'm just being overly cautious about the order of application. It shouldn't be a problem in most of the cases, so I'll remove the pre-customize-hook.

[aartaka]

pre-customize-hook removed in 2aa591e. Merging?

[aadcg]

Good piece of work, as it simplifies the internal logic.

I've left some comments. Note that the branch needs to be rebased onto master.

[aartaka]

Updated, rebased onto master, removed the changelog entry. Safe to merge (or just donate—it's a single commit now), I believe.

[aadcg]

Pushed with a minor commit message rephrasing. Thanks!