feature request: add a per buffer bookmark supprt
xzbdmw opened this issue · comments
It will be cool to jump to buffer and then jump to bookmarks(narrowing scope to line) within this buffer in the same UI, mapped to a different toggle key, or just type ; and type any key to enter bookmark mode, since deleting, editing, and choosing bookmarks can have the same experience:)
If you are interested I can try to make a pr!
It will be cool to jump to buffer and then jump to bookmarks(narrowing scope to line) within this buffer in the same UI, mapped to a different toggle key, or just type ; and type any key to enter bookmark mode, since deleting, editing, and choosing bookmarks can have the same experience:) If you are interested I can try to make a pr!
It is like a marks, but just for the current buffer?
How could we show the lines on the arrow buffer?
Why not use just marks for this?
Its like this plugin?
https://github.com/toppair/reach.nvim (ReachOpen marks)
I Liked the idea, we could:
- Have a separate leader for buffer relative bookmarks
- We need the delete mode and the clear
- The indexes order should fallout the index_keys
- We can show the marked line dynamically (save only the line numbers for the cache)
I was wandering If I can use tresitter to keep mark position even line number changed，because marks contantly changed during editing is not that useful.
I was wandering If I can use tresitter to keep mark position even line number changed，because marks contantly changed during editing is not that useful.
Nice idea! I will try to do it over the weekend (or the next one)
I was wandering If I can use tresitter to keep mark position even line number changed，because marks contantly changed during editing is not that useful.
Hi, i tried to do with tree-sitter but i encountered a lot of challanges:
If the element is deleted, what should happen with the mark?
If the element is substituted, what should happen too?
Do you have any ideas of how to solve it? If you could do a simple POC (Prove of concept) with tree-sitter (Just a save / load position), i could implement it to arrow
My 2 cents (though I would personally not use a buffer-specific marks feature):
If the element is deleted, what should happen with the mark?
If the element is substituted, what should happen too?
In both cases the mark could be moved to the parent node?
Yes either delete or move to parent according to user settings, through treesitter we can display symbol types such as function or classes displayed in ui(context support is even better), I now have time to implement a demo.
Here is a demo, I used extmark to track the bookmarks and recorded the context with navic. Would you be interested in integrating it into the arrow UI? Currently, persistence functionality is not implemented and only applies to a single buffer
return {
"xzbdmw/bookmarktest",
dependencies = {
"SmiteshP/nvim-navic",
},
config = function()
require("bookmarktest").setup()
end,
}use mm to add a bookmark and ml to bring up a list with context
I was wandering If I can use tresitter to keep mark position even line number changed，because marks contantly changed during editing is not that useful.
Hi, i tried to do with tree-sitter but i encountered a lot of challanges:
If the element is deleted, what should happen with the mark? If the element is substituted, what should happen too?
Do you have any ideas of how to solve it? If you could do a simple POC (Prove of concept) with tree-sitter (Just a save / load position), i could implement it to arrow
for delete, add lines is tracked by extmarks, delete the marked line simply leave the mark with the orignal line, each time open the floating window I recaculate the linenumber to ensure correct jump.
Do you think it is possible to add real highlighting to context and line content?
Thought: maybe we can copy paste treesitter-context’s implementation of nesting and highlighting and show multiline per entry, since one buffer won’t have many marks, for me 2~3 is enough, I’ll read their implementations.
{ "xzbdmw/bookmarktest", dependencies = { "SmiteshP/nvim-navic", }, config = function() require("bookmarktest").setup() end, }
looks awesome. This weekend i will bring it to arrow
I have successfully obtained the highlighted code for the bookmarks line and context, which is heavily borrowed from treesitter-context. I am thinking that displaying the entire context where the bookmarks line is located from beginning to end should be more intuitive(with other lines darker like the image above,and use ... if there are too many lines). Now, each bookmark uses a buffer and a window. What do you think?
The code is a mess and have some bugs now but you can try the basic functionality(mm to mark ml show list and cr to jump)
I have successfully obtained the highlighted code for the bookmarks line and context, which is heavily borrowed from treesitter-context. I am thinking that displaying the entire context where the bookmarks line is located from beginning to end should be more intuitive(with other lines darker like the image above,and use ... if there are too many lines). Now, each bookmark uses a buffer and a window. What do you think? The code is a mess and have some bugs now but you can try the basic functionality(mm to mark ml show list and cr to jump)
i loved the separated windows. We could add the index at the title or something like that.
i already started doing the arrow code for the persist part. At the weekend i will create a draft PR for it (and we can start looking for bugs / fixing)
i loved the separated windows. We could add the index at the title or something like that.
i already started doing the arrow code for the persist part. At the weekend i will create a draft PR for it (and we can start looking for bugs / fixing)
That's great! Displaying a surrounding block is much simple and intuative compared to above approch, and navic is not needed any more.
To achieve this effect, too much code and complexity have been added. Another way is to open a real buffer in the window, set the cursor line to the line recorded in the bookmark, and have an optional dependency on treesitter-context. If the user needs it, activate the context for each window, but the problem is that treesitter-context always keeps only one floating window on the currently active buffer. I think there are some workarounds here but need some hack not in their public api, anyway, having real highlighting is good enough.
nvim-treesitter/nvim-treesitter-context#31 (comment)
@xzbdmw You might be interested in how portal.nvim accomplishes this 🙂 It could even be possible to leverage portal.nvim itself to do this for you?
@xzbdmw You might be interested in how portal.nvim accomplishes this 🙂 It could even be possible to leverage portal.nvim itself to do this for you?
Yes I tried it(I get the new idea there) but it lacks some ui to delete marks and swap order, possibly an action to expose some buffer marks globally, and some logic to persist marks per cwd. Perhaps we can reuse the api to open preview and add edit mode and delete mode in arrow?
By the way, it will be good to also have context support in https://github.com/cbochs/portal.nvim ,I'm looking to make a pr for muti-window support🙂
but it lacks some ui to delete marks and swap order, possibly an action to expose some buffer marks globally, and some logic to persist marks per cwd
That's what arrow is for 😉
Perhaps we can reuse the api to open preview and add edit mode and delete mode in arrow?
Hmm, it might be possible to turn this part of Portal.tunnel into it's own API function (maybe, Portal.preview)? If that can be done then, then it should be relatively easy if arrow.nvim provides the search query and manages closing the selecting/closing the windows.
By the way, it will be good to also have context support in https://github.com/cbochs/portal.nvim
That sounds like a great idea 👍
I'm looking to make a pr for muti-window support 🙂
Nice!
@xzbdmw i had implemented all the persist part of this feature here:
https://github.com/otavioschwanck/arrow.nvim/pull/25/files
Is possible to save, remove by index, clear, all by the buffer.
Also the save / load data is all on json, so we can expand this part: https://github.com/otavioschwanck/arrow.nvim/pull/25/files#diff-f6a5efa17b3949ec543c62aa762cedc52debd44b6376e3bd46d13be351618263R112 (Now is only saving the line)
From here we can decide what we need to persist and implement a way to show the buffer marks.
PS: i will only have time at the weekend again, so if you want to implement the UI part from now on, be free!
The Portal looks like a very nice idea
but it lacks some ui to delete marks and swap order, possibly an action to expose some buffer marks globally, and some logic to persist marks per cwd
That's what arrow is for 😉
Perhaps we can reuse the api to open preview and add edit mode and delete mode in arrow?
Hmm, it might be possible to turn this part of Portal.tunnel into it's own API function (maybe, Portal.preview)? If that can be done then, then it should be relatively easy if arrow.nvim provides the search query and manages closing the selecting/closing the windows.
By the way, it will be good to also have context support in https://github.com/cbochs/portal.nvim
That sounds like a great idea 👍
I'm looking to make a pr for muti-window support 🙂
Nice!
Managed to implement the multi window and waiting for review, I’d like to try integrate portal and arrow, If something needs to change I’ll open a pr there👀