This adds a (hard?) requirement on a (Neovim-only) external plugin, which I don't think is acceptable...

I am making thisvery rough draft pull request as I have questions about what I am able to do and want to keep it out of discussions, as I see this being a long chain of replies.

No problem, feel free to work on the draft and ask for help while doing so.

This adds a (hard?) requirement on a (Neovim-only) external plugin, which I don't think is acceptable...

Does this become ahard requirement immediately? Wouldn't it only become a hard requirement if you actuallyloaded the module?

There is already anfzf-lua source for the TOC, which can be used as explained invimtex-fzf-lua.

I think we could add another TOC implementation that requires NUI, as long as it is only optionally loaded and it is properly explained with references in the docs. Similar to how I've added fzf-lua.

However, I do see that we might want to add more structure on the Lua side here. Currently, the fzf-lua feature is activated withrequire("vimtex.fzf-lua").run(). I guess it would be better to change it into e.g. this, so that we can have more options:

require("vimtex.toc.fzf-lua").run()-- and then perhaps, with this PRrequire("vimtex.toc.nui").run()

First, you should keep the main questions and thread as general comments to the PR. For comments on the code you should only discuss the specific code part and/or comment.

1. I use NixOS so I added a seperate nix branch that allows me to use direnv-nix with flakes, if you are willing to approve that(I have it a seperate branch for a reason and will open a seperate pr if approved).

Perhaps, but that would probably be better as a separate PR?

NB! You should have a space before the opening paranthesis:text (remarked), nottext(remark).

I understand not wanting to add something that you personally(I assume) dont use. Another problem is that the existence of a flake.nix in a vim plugin usually implies a way to use the flake in the nixos config for config; therefore, there is a possibility of a confusion for other nix users out there. I wouldtry and implement this though as it seems to not beextraordinarily difficult, probably just make an overlay. Although this could make me the de facto nix maintainer which is not something a responsibility I feel ready for. If you are willing to allow nix in this repo then there should be a discussion about which inputs, etc.

I don't mind adding useful things even if I don't use it, but it should be a rationally good choice. If you open a PR with the suggestion and explain what it is and what it does, then it will be easier to discuss it.

Personally, I don't use nix, but I usemise - it is awesome and satisfies most of my "reproducible environment" needs.

2. One problem with this code currently that jumps to mind is that it assumes thatvimtex#parser#toc outputs NuiTree.node which is almost certainly not the case. so that will be probably the bulk of this issue if Nui is used.

Yes, you will need to convert the output to whatever is needed for NuiTree.

3. my main use would be to pipe this to trouble.nvim(I am thinking probably either the location list or one of the other modes) so that will be my first target if it works, will then make it more general.

Ok!

What doesvimtex#parser#toc ouput exactly it seems to me to be a table of strings of some sort

It returns a list of dictionaries/tables. There's a spec for it here:

4. I also looked through trouble.nvim and saw no dependency on nui. so it is possible that I could write it to not require nui. As much as I respect folke, he seems to not do enough docs on what his code does, and why it is implemented that way for those who want to extend it. That is, his actual code is hard to parse for me. Then again it is possible that his code is self explanatory and I lack the experience for it to be so. Furthermore there seems to be radio silence from folke(I think he is on vacation so no shade) so I do not expect any commits from him in his repos anytime soon, let alone documentation commits.

Ok! I'm sorry I can't be much of a help here.

5. isvimtex#parser#toc# a command available to users somehow? if not how could we make it so. I am seeing a scenario where all I need to do is just use that parser and then pipe it to anything.

I'm not sure I quite understand what you are asking.vimtex#parser#toc is a function that is available for anyone to use. I'm not sure why we would want it to be a command? You can already just call the function and use the results for anything?

Are you still working on this/interested in following it up?

oh yeah sorry i was digging through trouble's code but found it hard to read, was waiting for folke to become active again so I could ask him how it was done. Then got distracted by other things. I think I might be able to ,for my own purposes, pipe the output of TOC to trouble but I havent used LaTeX in awhile.

also I was on a cruise so I didn't have internet for like 10 days

No problem; I'll leave this open for some more time, in case you should want to continue the work.

somy goal is to get it like trouble, where it should jump on cursor over. this might be an old question but why isnt loclist used for TOC? I have a few days to work on this before uni starts, and would like to try and make some progress on this.

somy goal is to get it like trouble, where it should jump on cursor over.

I'm not sure what that means, sorry.

this might be an old question but why isnt loclist used for TOC?

I don't think it ever came up, to be honest. Feel free to open a feature request. I don't think it would be too hard to use the loclist (or quickfix list, for that matter) for the TOC.

I have a few days to work on this before uni starts, and would like to try and make some progress on this.

Cool! I'll try (but can't guarantee) to be fast at replying to your questions.

by "get it like trouble" I am referring to thetrouble.nvim plugin. my inital goal(before even opening the discussion post) was to have better integration with it. If loclist is used this goal of trouble integration/likeness would be trivial to implement to the point of where it could just be an autocmd on the user side. That is, when LocList is opened, use Trouble. I will look into implementing this as part of this PR.
Additionally I came to the realization that nui.nvim is atad overkill for this purpose. As that plugin to me seems to be for drawing new things.

by "get it like trouble" I am referring to thetrouble.nvim plugin.

Ah, ok!

my inital goal(before even opening the discussion post) was to have better integration with it. If loclist is used this goal of trouble integration/likeness would be trivial to implement to the point of where it could just be an autocmd on the user side.

I see. Well, then I think this seems like a good approach.

Now, the main difference between the loclist and the quickfix list is that the loclist is local to each window, whereas there is just a single (active) quickfix list. I think you are right that it makes sense to use the loclist in this case.

That is, when LocList is opened, use Trouble. I will look into implementing this as part of this PR.

Ok, cool! I think a first step would be to create a function that fills the loclist based on toc entries. Something like this placed inautoload/vimtex/toc.vim:

function!vimtex#toc#loclist()abortif!has_key(b:vimtex,'toc') |return |endifletl:entries=vimtex#toc#get_entries()" prepare for setloclist hereletl:prepared=...callsetloclist(0,l:prepared,...)endfunction

Additionally I came to the realization that nui.nvim is atad overkill for this purpose. As that plugin to me seems to be for drawing new things.

Yes, I think you are right here.