pass fzf query or cmd match to editor environment

[khimaros]

developed this as a way of scratching a personal itch: https://github.com/mickael-menu/zk/discussions/330

see the updates to docs/tool-editor.md for sample usage

i'm happy to incorporate feedback to make sure this fits cleanly

[khimaros]

@mickael-menu i think this is now ready for review

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[tjex]

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. The project is currently being transferred over to a new group of maintainers.

See the readme for the notice. Thanks for the pr, once we're out of maintenance mode, let's look at this again :)

[khimaros]

@tjex thank you and looking forward to it

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[khimaros]

@tjex FYI

[tjex]

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. If you'd like to make a case for it getting merged in the meantime, you could try pinging one of the other maintainers, but we have all agreed to not look at any new features until the bugs are sorted.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[khimaros]

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.

[tjex]

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:

• requiring the passing of an empty string as a second argument in NewEditor(opt.NullString, "") and container.NewNoteEditor(notebook, "")
• changing test cases
• requiring the setting of a bash script as editor for this to work

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?

[mcDevnagh]

So what is the use case here? You run zk edit -i type in a query, and then you receive that query as an OS environment variable?

[khimaros]

@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: https://github.com/zk-org/zk/discussions/330

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[khimaros]

final ping @mcDevnagh

[mickael-menu]

@zk-org/maintainers If you need to alter the stale/triage rules, it's here: https://github.com/zk-org/zk/blob/578894f45b0e8d117f29077fe5d376d6ad838eca/.github/workflows/triage.yml#L29

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.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[tjex]

@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 NewEditor() that will seemingly only be required once (in edit.go) and b) the implementation on the user side with the script is quite involved and very prone to user side issue. So for both code and user config, I see quite a bit of potential for issue and setup / maintenance work with not much value gain.

I say "not much value gain" because there is also a PR over on zk-nvim (https://github.com/zk-org/zk-nvim/pull/171) which is implementing a grep feature that also uses zk list --match in the back end. So the functionality will be effectively the same, albeit the user needs to already be in the editor (and it's neovim specific).

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.