Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest to support BCP #8

Open
thawk opened this issue May 5, 2021 · 4 comments
Open

Suggest to support BCP #8

thawk opened this issue May 5, 2021 · 4 comments

Comments

@thawk
Copy link

thawk commented May 5, 2021

Currently, vim-rfc supports RFCs and STDs. According to Best current practice - Wikipedia, there're BCPs, which refers to the most recent revision of the RFC/STD.
I suggest to support BCPs.

@sigmavirus24
Copy link

Is there evidence this doesn't presently support BCPs?

@mhinz
Copy link
Owner

mhinz commented May 6, 2021

Yeah, only RFC and STDs so far.

But they really just get added as distinct entries, although STDs often refer to existing RFCs and vice versa (in that case they also have the same title):

    <std-entry>
        <doc-id>STD0006</doc-id>
        <title>User Datagram Protocol</title>
        <is-also>
            <doc-id>RFC0768</doc-id>
        </is-also>
    </std-entry>
[...]
    <rfc-entry>
        <doc-id>RFC0768</doc-id>
        <title>User Datagram Protocol</title>
        <is-also>
            <doc-id>STD0006</doc-id>
        </is-also>
    </rfc-entry>

Treating BCP entries as distinct makes even less sense, since they don't even have an own title anymore:

    <bcp-entry>
        <doc-id>BCP0006</doc-id>
        <is-also>
            <doc-id>RFC1930</doc-id>
            <doc-id>RFC6996</doc-id>
            <doc-id>RFC7300</doc-id>
        </is-also>
    </bcp-entry>

So, we'll need to come up with a good way to display these cross-references.

@sigmavirus24
Copy link

Ah, didn't realize vim-rfc was going through the xml for this too. Thanks for the illustration

@mhinz
Copy link
Owner

mhinz commented May 6, 2021

I feel urged to rework how this plugin works.

Nowadays, Vim/Nvim supports parsing JSON natively. The RFC index also changes really seldom.

What about just vendoring a properly parsed JSON cache file instead? Additionally, I'd put a Python script in the repo that's solely used for downloading the XML index file and building an updated JSON cache file from it.

For the user that would mean:

  1. No curl needed.
  2. No Python3 support in Vim needed.
  3. No cache file building.

Using the plugin for the first time in the Vim session, would make it load a huge glorius Vim dictionary from the JSON cache file.

The display wouldn't look different from what it looks right now. But entries with cross-references would be highlighted somehow or maybe a fancy Unicode character would make it clear that this entry has "more". Hitting <space> would then dynamically insert the cross-references below the current line (using the previously loaded Vim dictionary). Hitting <space> again would toggle it.

I could even add a GitHub Action that triggers via cron once a day, builds a cache file from a fresh index file and only if it differs to the vendored one, it automatically creates a new commit and pushes it. So, the users would always have an up-to-date cache file, as long as they keep their plugins updated.

Does this sound sane to you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants