blocker: Autoload hosts if empty.

[aartaka]

This ensures that the hostlist file is created if it doesn't exists and that hosts are fetched if they weren't.

Closes #3218.

Discussion

We have to integrate blocker-mode with Nfiles to avoid this type of problems. But it's quite a legacy by now, and our users are likely depending on some interfaces that blocker-mode provides, so I'm not sure we're safe to make the change.

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.
    • @aadcg, tests fail on my machine due to some symbols from nyxt/web-extensions and nyxt/renderer/gtk being undocumented. How to proceed?

[aadcg]

We have to integrate blocker-mode with Nfiles to avoid this type of problems. But it's quite a legacy by now, and our users are likely depending on some interfaces that blocker-mode provides, so I'm not sure we're safe to make the change.

Can you please open an issue and mark it with the 4-series tag?

I think the fix proposed in this PR is suitable for the 3 series.

[aartaka]

Can you please an issue and mark it with the 4-series tag?

See #3248.

I think the fix proposed in this PR is suitable for the 3 series.

Yes, it's backwards-compatible.

---

On a separate note: marking PR as a "changes requested" blocks any action on it until you approve it. I'm not sure, but it might even block other maintainers from merging. Which kinda is a bus factor thing. So we should probably avoid "changes requested". Especially given that our review is quite comprehensive already and that we don't merge if there's any unaddressed commentary.

[jmercouris]

@aadcg status?

[aadcg]

• @aadcg, tests fail on my machine due to some symbols from nyxt/web-extensions and nyxt/renderer/gtk being undocumented. How to proceed?

I don't think that's related to this PR. Please open an issue on the topic, but notice that the CI passes.