WIP: per buffer bookmark

[xzbdmw]

Hello, should I clone the commit and open a new pr?

[otavioschwanck]

Hello, should I clone the commit and open a new pr?

create a new branch from this buffer. Do the stuff and then create a PR to this branch

[xzbdmw]

Sometimes after switching sessions I get this error:

   Error  17:19:41 msg_show.lua_error Error executing vim.schedule lua callback: ...azy/neovim-session-manager/lua/session_manager/utils.lua:65: /Users/xzb/.local/share/nvim/neovim-sessions/__Users__xzb__.local__share__nvim__lazy__nvim-cmp[25]..BufReadPost Autocommands for "*": Vim(append):Error executing lua callback: ...xzb/.local/share/nvim/lazy/arrow.nvim/lua/arrow/json.lua:175: trailing garbage at line 1 col 3

[otavioschwanck]

Sometimes after switching sessions I get this error:

   Error  17:19:41 msg_show.lua_error Error executing vim.schedule lua callback: ...azy/neovim-session-manager/lua/session_manager/utils.lua:65: /Users/xzb/.local/share/nvim/neovim-sessions/__Users__xzb__.local__share__nvim__lazy__nvim-cmp[25]..BufReadPost Autocommands for "*": Vim(append):Error executing lua callback: ...xzb/.local/share/nvim/lazy/arrow.nvim/lua/arrow/json.lua:175: trailing garbage at line 1 col 3

i will fix it, thanks.

About portal:

i decided not to use because:

• is hard to use delete mode
• no menu with the keys to help (its the signature of arrow)
• keys to change the buffers are not the index_keys.

im am already implementing something that will behave like Portal, but with arrow UX. At the end of day (Lisbon Time) i should have it here for review / tests

[xzbdmw]

Great to hear!

[otavioschwanck]

Great to hear!

Spoiler:

[otavioschwanck]

Already did the V0 of the feature.

It is working already but i need just do some enchantments before merge it:

[ ] - Add highlights to the actions buffer [ ] - Implement delete mode (super easy to do now) [ ] - Add arrows with the index in the buffer as a mark [ ] - Improve the actions buffer when no marks.

But its already usable and awesome to use! I will try to finish the rest at next week!

[xzbdmw]

buffer_leader_key set to ' is great paired with ; One problem is after closing preview cursor will jump to the left most window(vim default behaviour)

[otavioschwanck]

buffer_leader_key set to ' is great paired with ; One problem is after closing preview cursor will jump to the left most window(vim default behaviour)

i will fix that.

About the leader_key, here in brazil, the ' is a special key to create accent (like áéóóú) and need two key presses to really type, so i prefer to let the user decide what key he wants to use (and explain how to set)

[xzbdmw]

I’m working on adding extmark on signcoloum and tracking them. They are perfect by far, extmarks can even restore marks after undo, with conform.nvim, line information after formatting is reserved too. If delete mode is completed, combinded with line tracking, then it will be pretty nice and usable!(Also, context support is out of box if that pr merged)

[otavioschwanck]

I’m working on adding extmark on signcoloum and tracking them. They are perfect by far, extmarks can even restore marks after undo, with conform.nvim, line information after formatting is reserved too. If delete mode is completed, combinded with line tracking, then it will be pretty nice and usable!(Also, context support is out of box if that pr merged)

Hi @xzbdmw finished the UI part. (delete mode + highlights).

i think i found a bug on the update:

if i have more the one mark after the current mark and i delete the lines around the marks, all marks get deleted. (happened once, i don't know how to reproduce)

Besides that, lets use for a week or two to make sure that it doesn't have bugs.

EDIT: Managed to reproduce:

[xzbdmw]

@otavioschwanck It seems an empty line is automatically deleted(with slightly delay)after you delete that function? seems like a format is performed so empty line is deleted, I can’t reproduce that. edit: there is another bug that two marks overlap at same line, we need to handle that. and the bug all marks disappear may also be related to overlap marks? https://github.com/otavioschwanck/arrow.nvim/assets/97848247/f3ea478b-810f-4b1d-b23c-1c7b4eaaa8ce

[otavioschwanck]

@otavioschwanck It seems an empty line is automatically deleted(with slightly delay)after you delete that function? seems like a format is performed so empty line is deleted, I can’t reproduce that. edit: there is another bug that two marks overlap at same line, we need to handle that. and the bug all marks disappear may also be related to overlap marks? https://github.com/otavioschwanck/arrow.nvim/assets/97848247/f3ea478b-810f-4b1d-b23c-1c7b4eaaa8ce

it was not related with overlaps. I will try to figure it out.

EDIT: The guilty is the format on save, idk why :(

EDIT 2: lua/arrow/buffer_persist.lua:14 is the guilty part of code. this update is just not working with format_on_save

EDIT 3:

if M.local_bookmarks[bufnr] ~= nil then
    for _, mark in ipairs(M.local_bookmarks[bufnr]) do
        for _, extmark in ipairs(extmarks) do
            local extmark_id, extmark_row, _ = unpack(extmark)
            if mark.ext_id == extmark_id and mark.line ~= extmark_row + 1 then
                mark.line = extmark_row + 1
            end
        end
    end
end

The problem comes from here

EDIT 4:

i change a function to not change the extmark if the extmark is on last line. it fexes the problem.

For some reason, the formatter call two update, one correctly and the other (after the format runs), with all extmarks on the last line. (my fix is partial, not the final).

[otavioschwanck]

@xzbdmw didn't managed to fix it. The problem is:

When format on save change the number of lines, all the extmarks are deleted (using formatter.nvim (async)).

i will try to fix again in the weekend.

[xzbdmw]

@otavioschwanck I found a related issue https://github.com/mhartington/formatter.nvim/issues/22 they just replace the entire buffer so extmarks is pushed to last line, I think it is not our problem, conform.nvim works fine. If built in marks can’t work, then no way our marks will work IMO.

A workaround maybe reset all these extmarks after formatting (don’t update them), add a freeze function so user can call freeze and format and then unfreeze in their autocmds, freeze just do nothing in update and unfreeze running tblfilter to remove lines above total line if formatting change the line count, but all marks will be shifted a little by this way, not their orignal lines. Do you think we should support the drawback of format.nvim?

[otavioschwanck]

@otavioschwanck I found a related issue mhartington/formatter.nvim#22 they just replace the entire buffer so extmarks is pushed to last line, I think it is not our problem, conform.nvim works fine. If built in marks can’t work, then no way our marks will work IMO.

A workaround maybe reset all these extmarks after formatting (don’t update them), add a freeze function so user can call freeze and format and then unfreeze in their autocmds, freeze just do nothing in update and unfreeze running tblfilter to remove lines above total line if formatting change the line count, but all marks will be shifted a little by this way, not their orignal lines. Do you think we should support the drawback of format.nvim?

lets wait formatter fix it, i will use conform too from now on, lets continue with the feature

[xzbdmw]

Sure, do you think we should add workspace bookmarks, an action to promote buffer marks into cwd scope, display a different highlight group to boarder and make it global accessible, by this way the importance of marks can be different, if it add too much complexity , we can just add a number after filename(file ui)show mark count

[otavioschwanck]

Sure, do you think we should add workspace bookmarks, an action to promote buffer marks into cwd scope, display a different highlight group to boarder and make it global accessible, by this way the importance of marks can be different, if it add too much complexity , we can just add a number after filename(file ui)show mark count

about workspace bookmarks or marks by cwd, i think doesn't make much sense since is file related (and file only exists in one place). Maybe the branch related stuff is useful, to have marks based on the branch i am working on. We can do it on a V2. Lets test it more.

I think the feature is awesome the way it are now, maybe just add it to statusline and thats it. At weekend i will prepare the README, add you as official arrow contributor (this is a big feature, you deserve), etc