Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Wrapping string breaks blame #9

Open
timsofteng opened this issue May 13, 2023 · 10 comments
Open

Wrapping string breaks blame #9

timsofteng opened this issue May 13, 2023 · 10 comments

Comments

@timsofteng
Copy link

Hello. When text is wrapped to the new line the blame of agitator is incorrect.

Expected behavior:
Empty lines oposite wrapped lines or so.

rec-2023-05-13-182554.mp4
@emmanueltouzery
Copy link
Owner

yes, i'm aware of that. I don't think it's fixable with the current approach of a split window to show the blame contents.
Maybe it could be doable with some virtual text or something, but I don't see how.

I'd guess other plugins offering a similar feature (for instance fugitive) have the same flaw probably.. if they don't I could try to check exactly how they did it.

@timsofteng
Copy link
Author

@emmanueltouzery Yeah. Fugitive works ok.

@emmanueltouzery
Copy link
Owner

hmm I just installed fugitive to check how it does it, but it seems to me to be the same as agitator, with the same flaws. I think it resets the word-wrapping in your buffer when you enable blame... but if you set it back then i can see the problem there too.
Make sure to enable word-wrapping in buffer and scroll to the end and you'll see that the end doesn't line up with fugitive as well.

Maybe agitator could disable word-wrap in your buffer when it's activated? That's probably the difference you see with fugitive, i think.

@timsofteng
Copy link
Author

@emmanueltouzery oh I'm sorry. You are right. Fugitive doesn't work too. I cannot remember why I thought it does.
Auto disable and enabling wrapping sounds good to me. I'm just afraid about auto enabling because someone may close agitator's window manually with :q or :bd and I have no ideas how to track it to reenable wrap behavior.
But in general this solution sounds totally good.

@emmanueltouzery
Copy link
Owner

yeah i'm not sure about re-enabling back wrapping. I'm thinking just disabling it when the blame is opened and then not touching it anymore.

@timsofteng
Copy link
Author

@emmanueltouzery
I find some implementation with z-index or so.

https://github.com/tanvirtin/vgit.nvim

Maybe it can help.

Alternatively we could open blame in the new tab.

@timsofteng
Copy link
Author

Hello. Any updates about this issue?

@emmanueltouzery
Copy link
Owner

emmanueltouzery commented Jul 15, 2023

I actually wrote a naive function to compute real line to screen line when there is word-wrapping. but this will break if the user later resizes the window... so i think this is just not worth doing. it'll always be possible to break it. I'll just disable wordwrap when blame is triggered. Just for future reference, the function was:

local function get_buf_line_to_win_line()
    local bufnr = vim.api.nvim_win_get_buf(0)
    local orig_view = vim.fn.winsaveview()

    local res = {}

    local line_count = vim.api.nvim_buf_line_count(bufnr)
    local cur_line = 1
    while cur_line <= line_count do
        vim.api.nvim_win_set_cursor(0, {cur_line, 0})
        res[cur_line] = vim.fn.winline()
        cur_line = cur_line + 1
    end

    vim.fn.winrestview(orig_view)
    return res
end

@timsofteng
Copy link
Author

@emmanueltouzery
Unfortunately break doesn't restore to wrap when I close blame. Totally unusable for me.

@emmanueltouzery
Copy link
Owner

i mentioned about that earlier, in #9 (comment)

probably the best is that you make your own keyboard shortcut on top of these functions here that remembers if line wrapping was set, disables it, calls this blame here, and sets back line wrapping if it was set before. you can totally do this outside of agitator.

maybe you can check what does fugitive do in this case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants