DRAFT: Multiple describe sources

[Ambrevar]

Description

Previously we had no way to describe unexported symbols, inherited symbols, etc.

We now use multiple sources for functions, variables, etc.

• 1 source for the "export Nyxt symbols" + "all nyxt-user symbols".
• 1 source for "Nyxt internals"
• 1 source for "exported symbols in non-nyxt packages".

Of course now it's trivial to create new sources with whatever listing we like (for instance "inherited symbols in all packages").

Bonus: New Status prompter attribute.

Fixes #2576.

Discussion

I've removed the universal argument, since it seems a bit redundant now. Having more sources is more powerful in my opinion.

Does anyone feel like universal should be re-introduced? If so, then we should probably add another flag for "nyxt internal symbols".

Checklist:

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

• [ ] 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).
  • [ ] I have added a migration.lisp entry for all compatibility-breaking changes.
• [ ] 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.)
  • [ ] New and existing unit tests pass locally with my changes.

[Ambrevar]

Note: It builds but I haven't had the time to test this yet. That said, do you like the API?

[aadcg]

Overall, I think this is a good move forward. I left some comments.

[aartaka]

I guess we don't need universal with such a solution!

[Ambrevar]

OK to merge?

[aadcg]

What's the status here?

[aartaka]

We take over this PR with @aadcg ;)

We'll address our review points, then make yet another round of review, and finally merge this on master. After that, I'll get on to integrating these sources (and the underlying symbol listings) everywhere in Nyxt introspection tools.

[aartaka]

@aadcg, I've made my changes there, you can get to yours :)

[aadcg]

@aartaka I believe commit 3dd84a71f is incomplete. Call describe-any and see that the following warnings are raised at the REPL:

WARNING: Error on separate prompter thread: Unknown &KEY argument: :VISIBILITY

[aartaka]

@aartaka I believe commit 3dd84a7 is incomplete. Call describe-any and see that the following warnings are raised at the REPL:

WARNING: Error on separate prompter thread: Unknown &KEY argument: :VISIBILITY

Should be fixed now.

[aartaka]

Ahhhhhh, now I see why it was initially called status in this PR: CLHS calls it that in find-symbol docs!

find-symbol string &optional package => symbol, status

Still, I find that name more confusing than useful, even though it's in CLHS. Because:

• CLHS itself only uses it once, as an identifier for the return value, and uses other words, like accessible and present in all the other contexts.
• status is already occupied by buffer and download slots.
• status is much more opaque than visibility, which is both:
  • a piece of recongiseable programming lingo, and
  • a good metaphor for symbol accessibility: you see it—you get it!

[aadcg]

I agree with your reasoning @aartaka.

I've made some minor changes. Care to have a final look?

[aadcg]

Ok to merge?

[aartaka]

Yes!

[aartaka]

Cool! Thanks <3

[Ambrevar]

Thanks for merging this, peeps! :)