Somehow marksman also does this?
As for treesitter (norg) it may be because treesitter includes the
newline and the next line indent until the next heading, so the line of
the next heading is included in the range of the previous heading. We
manually -1 on the range end line to fix it.
Closes#35
Previously the treesitter javascript parser would treat `<></>`
specially and emit a `jsx_fragment`. We were checking for this type here
(from symbols-outline.nvim), though we did not include `jsx_fragment` in
the parse_ts function to even look for it.
jsx_fragment was recently removed from treesitter parser to reduce
complexity, so we will treat all jsx_element's without a `name` field in
`jsx_opening_element` as the shorthand fragment.
Using "Fragment" as the name in this case makes it look exactly the same
as if the user used `<Fragment></Fragment>` instead.
The check for `jsx_fragment` is still kept in case an older version of
the parser is still used, it can probably be removed next year.
Ref:
- tree-sitter/tree-sitter-javascript#227
- Closes#3
- Ref: simrat39/symbols-outline.nvim#190
Norg contains indents and different types of verbatim tags, I was rather
lazy to read the spec properly and parse norg using regex line-by-line
like markdown, so used treesitter instead. The only requirement is the
`norg` parser for treesitter to be installed. Tested on nvim 0.7.2.
This should lead the way for supporting vimdoc files in a similar
manner.
Documentation for how external providers could look like as of now has
been added.
In the future we could let the provider determine what to do for each
keymap, such as `goto_location` and `toggle_preview`. This would allow
the zk extension[1] to work properly without having to override existing
functions (bad practice).
[1]: https://github.com/mickael-menu/zk-nvim/discussions/134
No more obnoxious '}' on the cmdline when pressing `?`!
scope:
- More type hints
- Added class Float for creating floating windows with size that fit the
content and position centered on the screen
- show_help action for outline window (key `?`) now uses a floating
window
- :OutlineStatus now provides better information, and shows content in a
floating window.
future:
- Floating window option configuration
- Provider priorities can now be configured through `providers.priority`
- Each provider can have a get_status() function that returns a string
for its status. For LSP it returns the client name.
- :OutlineStatus logic refactored, together with provider checking
functions in `providers/init.lua`
- Switch from vim.lsp.buf_get_clients to vim.lsp.get_active_clients
(former was deprecated)
- Fixed a careless mistake from symbols-outline that seems to be an
unreachable bug (lsp)
Scope:
- Parsing of symbol tree
- Producing the flattened tree
- Producing the lines shown in the outline based on the symbol tree
- API of exported functions for parser.lua and writer.lua
Note that the formatting of the outline remains the same as before.
Fixes:
- Guide highlights sometimes cover fold marker areas (may be related to
the issue brought up by @silvercircle on reddit)
- Guide highlights do not work when using guide markers of different
widths than the default (such as setting all markers to ascii chars)
All of these issues are now fixed after integrating the a parser
algorithm.
This commit introduces:
1. A better algorithm for flattening & parsing the tree in one go
2. `OutlineFoldMarker` highlight group
3. Fixed inconsistent highlighting of guides and legacy (somewhat weaker
code), through (1).
4. Minor performance improvements
5. Type hints for the symbol tree
6. Removed several functions from writer.lua and parser.lua due to them
being merged into writer.make_outline
This can be seen as a breaking change because functions that were
exported had altered behaviours. However I doubt these functions
actually have any critical use outside of this plugin, hence it isn't
really a breaking change as the user-experience remains the same.
The extraneous left padding on the outline window is now a relic of the
past 🎉
The old implementation, parser.get_lines used a flattened tree and was
inefficient, full of off-by-one corrections.
While trying to look for bug fixes in that function I realized it's the
sort of "if it works, don't touch it" portion of code.
Hence, I figured a complete rewrite is necessary.
Now, the function responsible for making the outline lines lives at
writer.make_outline. Building the flattened tree, getting lines, details
and linenos are now done in one go.
This is a tradeoff between modular design and efficiency.
parser.lua still serve important purposes:
- local parse_result function converts the hierarchical tables from
provider into a nested form tree, used everywhere in outline.nvim. The
type hint of the return value is now defined -- outline.SymbolNode
- preorder_iter is an iterator that traverses the aforementioned tree in
pre-order style. First the parents, all the childrens, and so on until
the last node of the root tree. This is used in writer.make_outline to
abstract a way the traversal code from the code of making the lines.
Thanks to stack overflow I did not have to consult a DS book to figure
out the cleanest way of this traversal method without using recursion.
This, of course, closes#14 on github.
Note that another minor 'breaking' change is that previously, hl for the
guides where grouped per-character, now they are grouped together for
all the guide markers in the same line. This should not be a problem for
those who only style the fg color for guide hl. However, if you're
styling the bg color, they will now take on that bg collectively rather
than individually.
This change eliminates future maintenance burden because controlling
per-character guide highlights requires careful avoidance of off-by-one
errors.
I have tested most common features to work as before.
I may have missed particular edge cases.
Please take note of "scope" at the top of this commit message.
