isakbm / gitgraph.nvim

Git Graph plugin for neovim
MIT License
309 stars 7 forks source link

make git graph toggleable #9

Closed gennaro-tedesco closed 3 months ago

gennaro-tedesco commented 3 months ago

This plugin is an awesome piece of work, thank you for putting it together, it is really great!

I am addressing a comment I shared on reddit, and namely whether it would be possible to expose a toggleable interface for the graph rather than just require('gitgraph').draw({}).

P. S. I see you're a fellow theoretical physicist as well :)

isakbm commented 3 months ago

Could you describe in a bit more detail how toggling would work / behave?

isakbm commented 3 months ago

Here is how I use it and why I think one does not need a toggle.

  1. I am working in some file
  2. I do <leader>gl to view the log
  3. I go back to the file I was working in with ctrl + o (standard vim)
  4. I go back into the log view with <leader>gl which reuses automatically the still existing buffer
yuhsienchiang commented 3 months ago

I would like to share how I set up my keymaps to make it "toggleable".

I create functions to open, close, and toggle gitgraph in a seperate file (util/git.lua):

function M.gitgraph_draw()
    -- open gitgraph in a seperate tab
    if vim.bo.filetype == "gitgraph" then
        return
    end
    vim.cmd("tab split")
    require("gitgraph").draw({}, { all = true, max_count = 5000 })
end

function M.gitgraph_close()
    --- close the tab page if it is a gitgraph page
    if vim.bo.filetype == "gitgraph" then
        vim.cmd("tabclose")
    else
        return
    end
end

function M.gitgraph_toggle()
    -- toggle gitgraph
    if vim.bo.filetype == "gitgraph" then
        M.gitgraph_close()
    else
        M.gitgraph_draw()
    end
end

Then, in my keymaps file:

local Util_git = require("util.git")

vim.keymap.set("n", "<leader>ggg", Util_git.gitgraph_toggle, { desc = "GitGraph Toggle", silent = true, noremap = true })
vim.keymap.set("n", "<leader>ggd", Util_git.gitgraph_draw, { desc = "GitGraph Draw", silent = true, noremap = true })
vim.keymap.set("n", "<leader>ggq", Util_git.gitgraph_close, { desc = "GitGraph Close", silent = true, noremap = true })
gennaro-tedesco commented 3 months ago

Here is how I use it and why I think one does not need a toggle.

Yes, this is what I do as well and it's more than fine. However if you are switching among more than two buffers then I cannot seem to find the gitgraph buffer again in the list and one needs to open it again: what happens when you switch from the gitgraph onto another buffer by choosing among the buffer list? Does the graph buffer get deleted or does it stay in the background as hidden buffer or so?

gennaro-tedesco commented 3 months ago

I would like to share how I set up my keymaps to make it "toggleable".

I have a similar logic in place too, at the moment. In your case, however, the graph is closed only if you are on the active tab that displays the buffer (in which case you could just do a tabclose), and it doesn't if you are on a different filetype or tab altogether (because you don't loop through all possible existing filetypes displayed in the tabs) - or am I wrong?

isakbm commented 3 months ago

Here is how I use it and why I think one does not need a toggle.

Yes, this is what I do as well and it's more than fine. However if you are switching among more than two buffers then I cannot seem to find the gitgraph buffer again in the list and one needs to open it again: what happens when you switch from the gitgraph onto another buffer by choosing among the buffer list? Does the graph buffer get deleted or does it stay in the background as hidden buffer or so?

You might want to read up on buffers vs windows vs tabpages in vim. Buffers are just buckets for text basically, and they stay alive until something requests to close them. Switching to another buffer does not close the buffer, it only means that your window is now targeting (viewing) a different buffer. I have also specifically ensure that doing <leader>gl once more, reuses the existing buffer and updates it. What that means is simply that the current window is made to target the gitgraph buffer and subsequently the buffers content are updated.

isakbm commented 3 months ago

FYI @gennaro-tedesco gitgraph currently does not create any new windows or tabpages, it simply takes the current window and points it to the gitgraph buffer.

I like keeping things simple like this, as doing anything more than this is quite opinionated, so I would rather make it easy for you guys to do what you want.

We could add pre and post hooks perhaps, to give you more control over how the buffer is managed and or displayed.

I plan to make an example for how one could use such hooks to open the graph in a floating window instead for instance. But I won't bother with tabpages as I really dislike tabs 😅 , but I am more than happy to facilitate / guide how one might do it.

FWIW, tabpages remind me of the mess that one gets in web browsers (1000+ tabs), and also the mess that one gets in vscode ... keeping things minimalistic and simple in nvim is more my vibe.

gennaro-tedesco commented 3 months ago

Buffers are just buckets for text basically, and they stay alive until something requests to close them

Yes, however the git graph buffer does not appear in the buffer list via :ls (or equivalently :buffers), hence it either gets deleted or it is hidden - see demo below

https://github.com/user-attachments/assets/12dd6948-ef1f-4f92-b7e7-6698153eeeef

if gitgraph is the very previous buffer then I can indeed recall it with ctrl+^, but if it wasn't (say I have switched to some other buffers meanwhile) then it seems it's nowhere to be found. This is the reason why I was wondering if/how one can "toggle" it - as long as it appears in the buffer list then one can obviously switch to it at leisure while doing other operations and edits.

Can you reproduce such behaviour?

isakbm commented 3 months ago

Yes it's an unlisted or hidden buffer, perhaps that was a bad choice? Kind of like not cluttering the buffer list with buffers that are not files.

In my opinion we should continue to hide it, but try to understand what the bigger issue or problem that you are facing is.

I understand that you want something like some toggle, I just don't understand 100% how you want that to work, could you try to describe it as a "user story" ?

isakbm commented 3 months ago

The more detailed you are the better 🤞

isakbm commented 3 months ago

I mean if you really like it to not be hidden we could add a config toggle for that, but I think there is a nicer way than visualizing GUI elements in listed buffers (easily confused with files :( ) . There is a reason why vim has hidden unlisted buffers after all.

gennaro-tedesco commented 3 months ago

No absolutely, we don't have to make any change, I am just trying to understand the mechanics of such buffer, and now that you confirmed that it is indeed a hidden one the behaviour is clear.

I understand that you want something like some toggle, I just don't understand 100% how you want that to work, could you try to describe it as a "user story" ?

Initially I was manually wiping it off (:bd) (exactly to avoid the buffer to clutter the buffer list), which led me to think that instead of having to manually look for the filetype and delete the corresponding buffer accordingly, the plugin could provide this mechanism already. With the buffer being hidden and not cluttering the buffer list there is no such need anymore, hence as we saw nothing is really needed here after all.

To summarise: good that the buffer is hidden, from my end we could consider the issue closed :)

isakbm commented 3 months ago

Alright. Closing this issue for now then.

Please don't hesitate to come with further suggestions by opening new issues etc. I'm very willing to listen to input, but also want to make sure that we add things that are clearly needed and avoid adding too many smaller features, something that leads to hard to document and maintain plugins.