feat: support starting plugin with Leet cmd

[willothy]

Still testing this, there may be edge cases I haven't found yet, but it seems to be working well.

Changes:

• :Leet / :Leet menu now start the plugin if it wasn't already initialized.
• Added :Leet exit, which behaves exactly like the exit button in the menu
• The menu creates its own buffer and window to avoid hijacking existing ones.
• When exiting from the menu, if started via cmd all question tabs are closed but nvim does not exit.
  • If started from the commandline, the behavior has not changed - nvim will still exit.
• should_skip always returns false if the plugin was initialized by the :Leet command.

I have updated the readme but am unable to update the CN docs :)

closes #50

[kawre]

Just to be sure, you are fine with having to launch a new instance of neovim when using leetcode.nvim?. If that's the case then we don't really have to do deal with the Leet exit stuff.

You could just check during the execution of :Leet command, if there are any buffers that are listed, if yes then do not initialize and otherwise close all buffers and open leetcode.nvim menu.

This should make leetcode.nvim able to initialize when you boot into alpha-nvim or dashboard-nvim, because those plugins don't create any listed buffers if i remember correctly.

    for _, buf_id in pairs(vim.api.nvim_list_bufs()) do
        local bufinfo = vim.fn.getbufinfo(buf_id)
        if bufinfo.listed == 1 and #bufinfo.windows > 0
            ...
        end
    end

[willothy]

Just to be sure, you are fine with having to launch a new instance of neovim when using leetcode.nvim?.

Yes, that's totally fine by me! I think the current behavior should stay the same, I don't want to break anyone's config or introduce unexpected behavior.

If that's the case then we don't really have to do deal with the Leet exit stuff.
You could just check during the execution of :Leet command, if there are any buffers that are listed, if yes then do not initialize and otherwise close all buffers and open leetcode.nvim menu.

I initially thought this as well, but I think it's useful to have when launching with the cmd so that users can easily close the menu and all questions and return the user to their previous buffer:

2024-01-22.21-55-49.mp4

This should make leetcode.nvim able to initialize when you boot into alpha-nvim or dashboard-nvim, because those plugins don't create any listed buffers if i remember correctly.

    for _, buf_id in pairs(vim.api.nvim_list_bufs()) do
        local bufinfo = vim.fn.getbufinfo(buf_id)
        if bufinfo.listed == 1 and #bufinfo.windows > 0
            ...
        end
    end

Good idea! I'll make sure to check for unlisted buffers and avoid creating a new window, though creating a separate scratch buffer for the menu is still a good idea imo to avoid affecting buffers manged by other plugins.

Edit: Actually I don't think this is needed, since we do a full teardown of all windows when initializing the UI. Where do you think it's needed?

Initializing from Alpha works fine for me, though it can't be automatically returned to when exiting because it shuts itself down on BufLeave.

[kawre]

Ok, so I think we should settle on launch from dashboard plugins being the only option apart from arg. Trying to integrate into an existing session would really over complicate this plugin to the levels I'm not comfortable with.

I think the best way to achieve this would be to have initial Leet command that would attempt to start the plugin, if it hasn't already(because if it did, Leet would get overridden later on in the code to the actual functionality).

function leetcode.setup(cfg)
    config.apply(cfg or {})

    vim.api.nvim_create_user_command("Leet", require("leetcode.command").start_with_cmd, {
        bar = true,
        bang = true,
        desc = "Open leetcode.nvim",
    })

    local group_id = vim.api.nvim_create_augroup("leetcode_start", { clear = true })
    vim.api.nvim_create_autocmd("VimEnter", {
        group = group_id,
        pattern = "*",
        nested = true,
        callback = function() leetcode.start(true) end,
    })
end

Then in start_with_cmd() you would try to start the plugin with a false flag indicating that it was not started on VimEnter. Then by that flag you can perform two kinds of should_skip() operations.

• first would be the default one with arg.
• second would only start if current neovim sessions doesn't contain any listed buffers. So in theory this should only happen when neovim was booted into a dashboard plugin.

for _, buf_id in pairs(vim.api.nvim_list_bufs()) do
    local bufinfo = vim.fn.getbufinfo(buf_id)[1]
    if bufinfo and (bufinfo.listed == 1 and #bufinfo.windows > 0) then --
        return true
    end
end

And based on what leetcode.start() returns we can call cmd.menu()

[kawre]

Basically as long as you don't open any file it should work.
When opening alpha-nvim does your session manager open any additional buffers?

2024-01-23.15-36-20.mp4

[willothy]

I don't use dashboard plugins regularly... I don't see why that should be a requirement. It just adds more steps that are required before the plugin starts.

The only thing required to integrate into an existing session is to perform a full teardown when leetcode is initialized - it works exactly like normal from there except for the different exit behavior, which could be removed.

I think the best way to achieve this would be to have initial Leet command that would attempt to start the plugin, if it hasn't already(because if it did, Leet would get overridden later on in the code to the actual functionality).

That's basically what part of this PR does. The menu command starts the plugin the first time if it wasn't already started, and after that it just opens / returns to the menu.

second would only start if current neovim sessions doesn't contain any listed buffers. So in theory this should only happen when neovim was booted into a dashboard plugin.

Can definitely do this, but again I'm not sure why adding another requirement is necessary. I don't use dashboard plugins, I have Alpha installed but I rarely open it and I feel like I shouldn't need to open it just to open Leetcode.nvim...

Trying to integrate into an existing session would really over complicate this plugin to the levels I'm not comfortable with.

This plugin is already quite complex so I don't see much detriment to not locking users into a specific workflow for the sake of avoiding complexity. I understand if that's the route you want to take though, no worries! I am happy to close this and use my changes on my fork :)

When opening alpha-nvim does your session manager open any additional buffers?

It does not, but I also don't use it regularly.

[kawre]

You could try creating a plugin inside leetcode-plugins directory. This would load the required functions only when the plugin is enabled, the same way leetcode.cn plugin is done. It makes integrating stuff a lot easier.

[willothy]

You could try creating a plugin inside leetcode-plugins directory. This would load the required functions only when the plugin is enabled, the same way leetcode.cn plugin is done. It makes integrating stuff a lot easier.

Sorry I'm not quite sure why that would solve this problem, could you elaborate? It's not a standalone module like the leetcode.cn module...

[kawre]

Sorry I'm not quite sure why that would solve this problem, could you elaborate? It's not a standalone module like the leetcode.cn module...

It would just ensure that the original code base stays the same and the non standalone approach is loaded only when the plugin is enabled. So commands like Leet exit and other stuff will not be present in the default version.

For example I've commited the solution from my video into dev branch. cf86cc4

So now you could create a plugin that overrides those functions and adds a third condition

• first check if launched with args
• second check if inside a dashboard plugin and open a new buffer with leetcode.nvim menu
• thrid create a new tabpage and mount leetcode.nvim there

Then if someone also wants to use that approach they can just enable it inside plugin config.

[kawre]

to do that you would need to load plugins before leetcode.start b35e48c

[willothy]

Ah, I see. I'll look into implementing the changes that way.

[kawre]

Something like this ea579df. What's left is the Leet exit command and testing if it works correctly.

[willothy]

Cool, sounds good!

[willothy]

Looking at that though, I still think the menu needs to create and mange its own buffer. It is not reasonable to hijack a pre-existing file buffer.

I think this is good practice for any plugin so should be good for standalone mode as well. Since you've implemented most of this as a plugin, I'll remove the extra stuff from this PR but keep the menu changes, if that works?

[kawre]

It doesn't hijack a pre-existing file buffer. If neovim contains any listed buffers it creates a new tabpage with empty buffer and mounts menu there, otherwise it also creates a new buffer and does the same thing

    if not on_vimenter then --
        if buflisted then
            vim.cmd.tabe()
        else
            vim.cmd.enew()
        end
    end

[willothy]

It doesn't hijack a pre-existing file buffer. If neovim contains any listed buffers it creates a new tabpage with empty buffer and mounts menu there, otherwise it also creates a new buffer and does the same thing

    if not on_vimenter then --
        if buflisted then
            vim.cmd.tabe()
        else
            vim.cmd.enew()
        end
    end

Ah, I didn't see that that was added. Why not just create a new scratch buffer? Also, the menu cannot be reopened after it was closed.

[kawre]

Ah, I didn't see that that was added. Why not just create a new scratch buffer?

You mean why create a separate tabpage rather than a new buffer in both cases? Because tab pages guarantee a clean start without any existing buffers, so leetcode.nvim menu won't open in a split or something like that.

Also, the menu cannot be reopened after it was closed.

If you close it with :q then that's not really how this plugin is meant to be used

[kawre]

Unmounting still has to be changed because it doesn't remove questions from _Lc_questions and maybe some small readme adjustments to make it more clear.

Other than that i think it's working well, but since it's a niche usecase of this plugin imo, I'm not in a rush to marge this

[willothy]

Sounds good, I'll look into unmounting. No worries, I'm happy to use this branch for however long is needed.

[HakonHarnes]

Any updates on this? Seems like a useful feature!

[willothy]

Haven't looked at this in a few weeks, not sure when I'll get back to it tbh. I'll handle the merge conflicts today, but if someone else wants to finish this up, feel free :)

[kawre]

I will look into merging this tomorrow

[willothy]

Awesome, thanks!

[kawre]

@willothy can you check if Leet exit still crashed neovim?

[willothy]

@willothy can you check if Leet exit still crashed neovim?

Sorry, haven't been on github much in the past few days. I'll test this today :)

[willothy]

@kawre seems to be working well for me!