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

Generalize wiki#toc#gather_entries #288

Closed
lervag opened this issue Apr 2, 2023 · 6 comments · Fixed by #295
Closed

Generalize wiki#toc#gather_entries #288

lervag opened this issue Apr 2, 2023 · 6 comments · Fixed by #295

Comments

@lervag
Copy link
Owner

lervag commented Apr 2, 2023

wiki#toc#gather_entries assumes ATX headers:

" Parse current header
let l:level = len(matchstr(l:line, '^#*'))
let l:header = matchlist(l:line, g:wiki#rx#header_items)[2]
let l:anchors[l:level] = l:header

wiki.vim is meant to be filetype agostic, thus this should be generalized to allow other formats, as suggested by @saccarosium in #287.

Proposal: Add an option g:wiki_toc_header_format to allow other header formats, e.g.:

*g:wiki_toc_header_format*
  Option to specify the header format used for parsing the table of contents.

  Possible values:

    atx ~
      Atx headers are probably the most common header type in Markdown files
      and look like this: >markdown

        # Header level 1

        ## Header level 2
<
    setext ~
      Setext headers are common in Markdown files and look like this: >markdown

        Header level 1
        ===

        Header level 2
        ---
<
    asciidoc ~
      AsciiDoc headers are used in AsciiDoc files. They look like this: >asciidoc

        = Document Title (level 0)

        == Level 1 Section title

        === Level 2 Section title
<

One problem with using a global option is that one may want wiki.vim to work with different filetypes. Thus, it should be possible to also override the global option in any relavant commands, e.g. WikiTocGenerate:

*<plug>(wiki-toc-generate)*
*WikiTocGenerate*
`:[range]WikiTocGenerate [header_format]
  Create/Update table of contents. The optional argument `header_format` allows
  to override the header format specified in |g:wiki_toc_header_format|.
@lervag
Copy link
Owner Author

lervag commented Apr 2, 2023

@saccarosium What do you think; would the above proposal work for you?

@saccarosium
Copy link
Contributor

saccarosium commented Apr 2, 2023

I was thinking more of an automatic behaviour based on the main filetype, the first in the g.wiki_filetypes table/dictionary. Contrary to links I think that headings are more "save" to make automatic guess. For example asciidoc heading will be always = or in orgmode *, is really necessary specify that I'm using asciidoc style heading if I choose asciidoc?

Having said that, I think that for markdown is mandatory having the option due to the infinity flavours and ways to do heading.

Could make the variable an set it automatically to the filetype.

@lervag
Copy link
Owner Author

lervag commented Apr 2, 2023

Yes, good point. I think my proposal can still hold, except with the following addendum:

*g:wiki_toc_header_format*
  Option to specify the header format used for parsing the table of contents.
  This is a dictionary that maps a filetype to a header format. The supported
  header formats are:

    ... (list of supported formats)

  Default value: >vim

    let g:wiki_toc_header_format = {
          \ 'md': 'atx',
          \ 'asciidoc': 'asciidoc',
          \ 'org': 'org',
          \}
<

What do you think? This seems to be quite flexible to me, and if we still allow to specify the header format with :WikiTocGenerate FORMAT, then I would think most people would be happy?

@saccarosium
Copy link
Contributor

What do you think? This seems to be quite flexible to me, and if we still allow to specify the header format with :WikiTocGenerate FORMAT, then I would think most people would be happy?

Yes indeed I think is looking very good.

@lervag
Copy link
Owner Author

lervag commented Apr 2, 2023

Then I'll start working on this as soon as I get the time.

@lervag
Copy link
Owner Author

lervag commented Apr 27, 2023

This is fixed by @saccarosium in #295. Thanks!

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

Successfully merging a pull request may close this issue.

2 participants