-
Notifications
You must be signed in to change notification settings - Fork 20
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
proposal: "frozen" file tags #118
Comments
To summarize this
Like that? |
@ColinKennedy Thanks for taking the time to summarize. To clarify:
Correct. A cursor position can be specified with
Correct. Grapple already allows names with (i.e.
A tree view would likely complicate things. It could likely remain a list view with a the cursor as an additional detail. For example (mockup), |
A list view would work, though it would be nice if users can customize where each piece of info goes per-row. For example I would prefer to have it be |
While I agree that providing formatting options would be useful, I think that might be better suited as a later feature. For now, there are already a couple options available in the settings (see |
I find myself looking into this issue every couple of months because it'll be so nice when implemented! |
I thought grapple.nvim already remembered cursor position (coming from reading this issue: #72). |
Heh PERFECT timing. I was at it yesterday to hack about in the grapple code to get exactly this feature going. I haven't yet been successful, and your implementation sounds great, because I was just toying with the autocmds. in #72 there is a workaround to remove the autocmds and to hodge podge some things, but it's not ideal, because if you remove the auto commands, you never get a cursor location saved since it's ONLY saved via autocmd for me, never when I first create the tag. |
Frozen Tags
Context
I have seen this suggestion/idea pop up many times across many different plugins which are attempting to make file/buffer navigation easier. It's even been requested here (#58 #65 #66). This seems to be some way to bridge the gap between harpoon-like file marking and
:h mark-motions
.For those unfamiliar, Vim marks allow you to do two things:
'a
(lowercase) marks to mark a specific location in some file, globally'A
(uppercase) to mark a specific location in a specific file, globallyGrapple compliments the above system by allowing users to "tag" a file, but not a specific location. Rather, the cursor is tracked and will be restored when the tag is selected. In addition, tags are scoped per-project instead of globally.
There is a gap, however. What if you want that tag to stop updating, temporarily? What if you want to tag a specific location, but keep it local to the project you're working on?
Proposal
I would like to propose the following: frozen tags. These would be similar to regular tags, but their cursor position would never update. In addition to never updating, there would be more than one allowed per file.
Although it would be recommended that a frozen tag be created with a name, it would not be required. Selection behaviour would still always prefer the non-frozen tag, if not specified.
NOTE: default behaviour would remain the same. Non-frozen (dynamic) tags would still be restricted to one-per-filepath and track the last known cursor location.
For example, creating a frozen tag would look something like this:
And to select a frozen tag:
You could convert a non-frozen tag into a frozen tag, creating a new file tag if it doesn't exist (this would likely be a simple wrapper around
Grapple.tag
):You could convert a frozen tag into a non-frozen tag, overwriting (or not) an existing non-frozen tag if one does exist (again, this would likely be a simple wrapper around
Grapple.tag
):Implementation
The implementation is a bit fuzzy right now, but
grapple.tag
would look a bit like this:And the
grapple.tag_container
would need to accommodate more than one file per tag. That would require some refactor work, but not be too difficult.The UI would need some experimentation to ensure it doesn't distract too much, add more overhead, or feel out-of-place.
The text was updated successfully, but these errors were encountered: