which event to use for an autocmd to run a callback?

[andreacfromtheapp]

Hi @MunifTanjim

ref: andreacfromtheapp/chuck-nvim#10
repo: https://github.com/gacallea/chuck-nvim

The following code runs fine if I invoke the function with a user command after vim is opened a chuck file but if I set autorun to true to invoke it at start of nvim (when opening a chuck file), the layout is created but none of the functions within the panes run.

-- this one creates the NUI layout and spawns the above
function M.chuck_ui(cmd, logfile)
  layout.chuck_layout:mount()
  layout.chuck_pane:on(events.BufEnter, function()
    start_chuck(cmd, logfile)
  end, { once = true })
  layout.shred_pane:on(events.BufEnter, function()
    shred_lines(logfile)
  end, { once = true })
  vim.cmd("wincmd w")

  layout.chuck_layout:update(layout.update_layout)
end

I have tried BufNew, BufAdd, VimEnter and more, to no avail. I'm out of ideas.

[andreacfromtheapp]

ps: if there is a way to run all code on layout:mount even better. the above doesn't seem right. it works but.

[andreacfromtheapp]

These things are not meant to be created once and stored in the module. Because once you close the layout/splits those instances of NuiSplit/NuiLayout becomes unusable.

this is not an issue, because the UI is created on demand and destroyed on exit only. see above screenie for "usage".

[MunifTanjim]

Basically the idea is to use "fixed splits" to represent data like this ui does:

You can absolutely do that with or without nui.nvim.

I see. I may have picked the wrong tool? (nothing against NUI, I may have misunderstood its nature).

nui.nvim is nothing but a convenient wrapper around Neovim's APIs. If you use it or not, you'll have to deal with the problems anyway.

When you open a split, nobody is gonna stop the user from going into that split and running :quit. How you handle that scenario is up to you.

this is not an issue, because the UI is created on demand and destroyed on exit only.

What happens when I quit the splits and run :ChuckLoop again?

---

Anyway, I really can't help you unless I have a minimal script that I can run to reproduce the bug. I can't manage the time to debug a whole new plugin...

If nui.nvim has any bug or if you have question about how to use nui.nvim, I'm happy to help. But I don't think your problems are related to nui.nvim, those are just general Neovim related problems.

[andreacfromtheapp]

All fair points. I should not burden you with my own learning. I may have overdone this whole plugin. Perhaps running those things in tmux is a better idea. I want to thank you for your time, patience, and support. I'll get back to this tomorrow with a fresh mind. Cause I may need to change a lot.

That said, I don't think it's possible to provide a minimal script without the chuck dependency. At least I wouldn't know what to provide at this stage of both my skills and plugin state. Perhaps using splits isn't ideal here. I tried "pure nvim" at first (split, vsplit and so on) but didn't like some things and looked for a tui and found nui.

Again, thank you so very much <3

[MunifTanjim]

Just as a closing note, I'm not entirely sure how chuck cli command works... but you should try to separate it from the UI concerns. UI (splits) can be closed and opened again and again. But I'd assume you don't want to run chunk cli command multiple times. Also in shred_lines, I assume you're trying to listen to changes in the log file... you shouldn't do that every time UI is opened, you only need to do that once.

Once you separate out those two concerns, a lot of the problems you're facing will disappear.

And about :terminal <cmd> it creates a new terminal buffer, you can store that terminal buffer number somewhere and then just change the buffer of the split to that terminal buffer when you re-open the UI.

[andreacfromtheapp]

@MunifTanjim yes!!! andreacfromtheapp/chuck-nvim@68811a3 -- will make a release and asciinema to add to the README so you can see it. One last thing I need to fix is that split doesn't "scroll" (to show last lines)

[andreacfromtheapp]

ps: not the best separation of concerns but at least it's something. I wanted to make it work first, and I'm now looking into turning those jobs to hidden buffers I can attach to.