[mini.deps] How do you view commit messages?

[pkazmier]

I'm curious how others would view the full commit message for a commit on this screen:

For example, I saw the breaking change to mini.files this morning, so I wanted to see the details of the commit message, but was reminded that I don't know how to do so without resorting to opening up my web browser. Maybe I'm lazy, but that extra step is sometimes enough to dissuade me from doing so because it takes me out of vim.

Am I missing something obvious here? I scanned the discussions and issues but saw no mention of this. I feel like there should be another level of folding, hidden by default, that contains the body of the commit messages. Or, perhaps even better, integration with MiniGit.show_at_cursor()?

[echasnovski]

Am I missing something obvious here? I scanned the discussions and issues but saw no mention of this. I feel like there should be another level of folding, hidden by default, that contains the body of the commit messages. Or, perhaps even better, integration with MiniGit.show_at_cursor()?

No, you don't miss anything. The best one would probably be with 'mini.git' by yank plugin's path and then type :Git -C , <C-r>0, show <cword>.

Having this present directly and on different fold level is not the best design, because folds are not as popular as I'd like them (or how they deserve) to be.

The special case in MiniGit.show_at_cursor() is possible: filetype is distinctive enough, all the data are in the text (intentionally to account for this kind of task). I'll think if this is a good idea.

[abeldekat]

Most of the time, I would accept the update and use zoxide to cd into the mini.nvim folder. From there, I use lazygit.

Otherwise, I use the browser in a vimlike way.
Core component: sxhkdrc.
I have multiple firefox profiles with vimium installed. All profiles start with a simple custom local landing page containing bookmarks(hugo and python -m http.server under the hood).

[pkazmier]

Yeah, I just click the hyperlink in my terminal to the repo, then browse history from there. But it still just feels like way to much work when we have half the info already present on the screen and/or have cool tools like MiniGit.show_ at_cursor at our disposal.

[echasnovski]

@pkazmier, the MiniGit.show_at_cursor() now treats 'mini.deps' confirmation buffer specially. It shows the data of relevant commit based on the cursor line (i.e. no need to place cursor on the commit hash). That's a perk of owning the content on the buffer :)

Thanks again for the suggestion! This indeed fills the missing piece in 'mini.deps' workflow.

[pkazmier]

Thank you. I'm very excited to test it out. Having just updated everything, my first thought was to open DepsShowLog and see if it works in that buffer as well., but alas it does not. Would it be hard to add it there as well?

In the meantime, I just pushed back a few commits on a dep to test it out and it works well. This is perfect as now I'm able to stay in vim and see what is going on before updating deps. Thanks.

[echasnovski]

Thank you. I'm very excited to test it out. Having just updated everything, my first thought was to open DepsShowLog and see if it works in that buffer as well., but alas it does not. Would it be hard to add it there as well?

This by default does not work in the output of :DepsShowLog because the latter (deliberately) just shows a real file that is present on disk. It will be an extra hassle to write a robust predicate for this type of scenario. The easiest would be to just check if the buffer is for MiniDeps.config.path.log path, but maybe user wanted to have a backup? Besides, require('mini.deps').setup() could be not run and 'mini.deps' can be not a present module (as there are standalone repos). So I don't think it is worth it.

The most straightforward way to enable show_at_cusor() in the log is by executing noautocmd set ft=minideps-confirm after :DepsShowLog (noautocmd is needed to preserve highlighting).