-
Notifications
You must be signed in to change notification settings - Fork 133
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
pass fzf query or cmd match to editor environment #361
Conversation
0cd2b38
to
93ee42e
Compare
@mickael-menu i think this is now ready for review |
This pull request has been automatically marked as stale because it has not had recent activity. |
Hi @khimaros , just to update you, it would seem that your pr caught mickaël at the tail end of his passing on of zk. See the readme for the notice. Thanks for the pr, once we're out of maintenance mode, let's look at this again :) |
@tjex thank you and looking forward to it |
This pull request has been automatically marked as stale because it has not had recent activity. |
@tjex FYI |
Is it ok if we close this for now? So we don't keep getting pinged by the github-actions notifier? We've still got some bugs to sort out and I'm also leaving on holiday from tomorrow for a month. |
This pull request has been automatically marked as stale because it has not had recent activity. |
i've rebased this pull request on main. i think this is still a valuable addition to zk and i use it as part of my daily note taking workflow. |
Thanks for pinging back. I've had a look through and a think, and I'm unsure whether the added complexity in the code base is merited for this feature to be implemented in the main fork. Specifically, I'm thinking of:
While opening at a specific line is useful, I feel that doing so from the CLI isn't so broadly needed when the term can be quickly searched for in the file, post opening. Additionally, I would think that the majority of users will be using zk from within an editor whereby LSP and grep tooling (telescope.nvim etc) provides a lot of power already. Do @zk-org/maintainers have any contrary thoughts? |
So what is the use case here? You run |
@mcDevnagh my use case was to have vim automatically jump to the line that was selected in zk. however, the way i implemented this is flexible and could be used for other purposes. background: #330 |
This pull request has been automatically marked as stale because it has not had recent activity. |
final ping @mcDevnagh |
@zk-org/maintainers If you need to alter the stale/triage rules, it's here: zk/.github/workflows/triage.yml Line 29 in 578894f
Note that PRs are never automatically closed, only issues, so IMHO that's fine to leave it tagged as stale until someone decides to address it. |
This pull request has been automatically marked as stale because it has not had recent activity. |
@khimaros I think it's gotten to the point now where we should pass on this PR. From my side, I'm resistant to merging it as it introduces a fair amount of instability in the codebase / user config by a) adding an extra argument to I say "not much value gain" because there is also a PR over on zk-nvim (zk-org/zk-nvim#171) which is implementing a grep feature that also uses Furthermore, on a more stickler note, notes in Zettelkaten notes should be atomic, meaning there shouldn't be much text and therefore it shouldn't be hard to find the word or phrase which resides inside the returned note. I tried to have it otherwise by pinging the other maintainers, but in the end it looks like my call... Sorry! But thanks so much for the idea and patience. |
developed this as a way of scratching a personal itch: #330
see the updates to
docs/tool-editor.md
for sample usagei'm happy to incorporate feedback to make sure this fits cleanly