Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Display errors from git nicer (maybe parse them, or reduce the number of required interactions) #537

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
fnune opened this issue Jun 23, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@fnune
Copy link
Contributor

fnune commented Jun 23, 2023

Is your feature request related to a problem? Please describe.

When a git error happens, I intuitively already know what's up most of the time. If I don't, I only need one short line to understand it. However, Neogit displays (1) the raw error from git, and (2) yet another wrapped error from Neogit saying "git failed":

image

This also forces users to hit enter twice instead of maybe just once (or zero?).

Describe the solution you'd like

I'd like:

  • for these error messages to be smaller and to display more succinctly
  • for there to only be one "press Enter" dialog, or ideally zero (for example by showing a message in the status bar that doesn't require a keypress)
@ten3roberts
Copy link
Member

ten3roberts commented Jun 23, 2023

Do you by any chance have disable_builtin_notifications = true in your config?

The built-in notifications (or if if true nd using nvim-notify which I am) will display a toast that slides in in the corner and then disappears after a short while, without requiring user interaction.

I agree that parsing git errors would be preferred. It would have to be done on a case by case basis with some common cases, and falling back on the complete message if a known pattern didn't match.

There are frankly so many different ways git can fail, and I am not sure they are all documented or stable between versions.

If they are, or if there is a way to get a structured git error please do let me know, but for now I would consider making a simple pattern matcher for common errors like the common pull before push error and alike, and then progressively expand from there as we encounter more errors.

😊

Does that sound like a good idea?

@CKolkey
Copy link
Member

CKolkey commented Jun 23, 2023

I think that sounds pretty reasonable - match some common ones, and display the rest in full. And always show the full error in the log. ...After upstreaming everything else? :P

@fnune
Copy link
Contributor Author

fnune commented Jun 26, 2023

disable_builtin_notifications = true

I do have this. You're right that this reduces the number of required interactions. But I disabled them specifically because they take up too much space, and come in pairs.

@CKolkey
Copy link
Member

CKolkey commented Jun 26, 2023

This isn't really neogit related, but if you use something like nvim-notify, you can add this somewhere in your config (I have it as the init function in lazy)

  function()
    _G.old_print = print

    local notify = require("notify")
    vim.notify = notify

    print = function(...)
      local print_safe_args = {}
      local _ = { ... }
      for i = 1, #_ do
        table.insert(print_safe_args, tostring(_[i]))
      end

      notify(table.concat(print_safe_args, ' '), "info")
    end
  end

And then wherever you bind keys, set <esc> in normal mode to: "<esc>:lua require('notify').dismiss()<CR>".

The first one will intercept nearly all print() calls and display them as notifications. This also means they're viewable via :Notifications. The second one will allow you to dismiss notifications when you hit <esc>.

Again, not related to neogit, but handy ;)

@ten3roberts ten3roberts self-assigned this Jun 26, 2023
@ten3roberts ten3roberts added the enhancement New feature or request label Jul 5, 2023
@NeogitOrg NeogitOrg locked and limited conversation to collaborators Jan 14, 2025
@CKolkey CKolkey converted this issue into discussion #1633 Jan 14, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants