[Feature] Ability to specify popup arguments from :Neogit command

[b0o]

I have been using Fugitive for years and have developed muscle memory for many of my Fugitive-based mappings. For example:

nmap <leader>gcc :Git commit --verbose<cr>
nmap <leader>gca :Git commit --verbose --all<cr>
nmap <leader>gcA :Git commit --verbose --amend<cr>

I would like to transition fully over to Neogit, but I want to keep my workflow more or less the same. I propose being able to pass arguments to Neogit popups directly from the command line, like so:

nmap <leader>gcc :Neogit commit -v c<cr>
nmap <leader>gca :Neogit commit -a -v c<cr>
nmap <leader>gcA :Neogit commit -v a<cr>

I imagine it would work like this:

If an argument is passed, it is pre-toggled in the Neogit popup.

If an action is passed, like c for commit or a for amend, the popup would not be displayed at all.

[CKolkey]

First off, thanks for the idea. However... Neogit isn't a fugitive replacement, in terms of how it's used. The two plugins have different intended modes of interaction. Neogit is a git client in the spirit of https://magit.vc/, driven by popup buffers. You miss out on so much by just invoking the popups directly, I don't want to make it so you can skip THOSE.

For example, almost all popups will consume whatever commit(s) are selected or under the cursor. You completely miss this if you invoke a popup directly.

Of course, this is not for everyone! So no worries there, but.. If you like fugitive, why not keep using it?

Also, there are some technical reasons this would be tough to accomplish, but, if you're really keen, you could call the actions directly neogit/lua/popups/*/actions.lua and pass a popup object that responds to :get_arguments(). That would have to return the table of arguments/options { "--verbose", "--all" }. Technically it's not public API, but it probably won't change ;)

[b0o]

Hey, thanks for the quick response.

You miss out on so much by just invoking the popups directly

Yeah, absolutely. I usually do use the popups, and I mostly interact with Neogit through the :Neogit buffer. But, sometimes, I stage hunks using gitsigns, and I know I want to go straight to creating a commit, so I habitually do <leader>gcc.

If you like fugitive, why not keep using it?

I started using Fugitive many years ago, and added Neogit about a year ago. I've slowly eliminated my use of Fugitive, and pretty much the only thing I use now are those mappings I mentioned in my previous message.

(Tangent: Recently, I installed noice, and now making commits with Fugitive has an annoying compatibility issue due to Fugitive using feedkeys() in one of its autocommands and noice renders the keys slowly into its command line. I'd like to ditch Fugitive at this point.)

I still think this is a worthwhile idea, but that's just me.

you could call the actions directly

Thanks for the idea, I'll try this out!

[b0o]

Got something working, thanks for your help!

local function neogit_action(popup, action, args)
  return function()
    require'plenary.async'.run(function()
      require('neogit.popups.' .. popup ..'.actions')[action] {
        get_arguments = function()
          return args
        end
      }
    end)
  end
end

vim.keymap.set('n', '<leader>gcc', neogit_action('commit', 'commit', {'--verbose'}))
vim.keymap.set('n', '<leader>gca', neogit_action('commit', 'commit', {'--verbose', '--all'}))
vim.keymap.set('n', '<leader>gcA', neogit_action('commit', 'commit', {'--verbose', '--amend'}))

[CKolkey]

You know what, I actually don't hate that. Nicely done. It might be a good jumping off point for #73

@gegoune, you raised that request, would something like this be of value?

[gegoune]

Yes! :) It would also help with briefly displaying popup when I know exactly what I want to do, like @b0o described:
<leader>gc, show popup, c instead of
<leader>gcc avoiding flushing popups. Would be nice to have.

[CKolkey]

hmmm. Yeah, populating the popup with a specified state as determined by the flags set is... tricky. Honestly not sure how to go about that with the current API, and I'm not especially keen on rewriting that.

But direct access to the actions is super doable, as illustrated above. It won't work for everything, as some args are actually handled internally and never reach the CLI (log --graph is one example). But it will cover a lot of cases.