Zk grep 2 (inheriting #171)

[riodelphino]

Initially, I added this sample code to implement the :ZkGrep command.

Then I merged the changes from #171 into the latest main branch, and extended it based on the above example.

Features:

• Grep with telescope and snacks.picker
• Highlighted entries for better readability
• Jumps directly to the matched line
• Above features are solved by using rg command, instead of zk list --format=oneline -m command. (to get lnum and col)

TODO:

• Sorting order is incorrect in snacks_picker
  Now score -> idx.
  Sorting by score -> title(filename) -> lnum -> col or modifying scoring directly is ideal.
  snacks_picker's sorting is difficult to understand, so I give up for now.
  This may helps (Japanese)

Thanks to @shfattig for providing a great foundation and roadmap for integrating grep into zk-nvim pickers.

[riodelphino]

ChangeLog:

• Use built-in hl groups 'TelescopeResults*' instead of custom 'ZkGrep*'
• Updated README.md to reflect these changes

Now using:

• TelescopeResultsIdentifier for title
• TelescopeResultsLineNr for lnum:col
• TelescopeResultsNormal for body text

To customize these highlights, you can add something like this to your config:

vim.api.nvim_create_autocmd('ColorScheme', {
  callback = function()
    vim.api.nvim_set_hl(0, 'TelescopeResultsIdentifier', { fg = '#E0B449', bold = true })
    vim.api.nvim_set_hl(0, 'TelescopeResultsLineNr', { fg = '#999999' })
    vim.api.nvim_set_hl(0, 'TelescopeResultsNormal', { fg = '#CCCCCC' })
  end,
})

[tjex]

This is awesome, thanks for the work. I really want to get grep functionality in here. I'm sad that #171 stalled out. Using zk's match was great because it's insanely fast (faster than rg), but without jumping to or highlighting the results, it came at a price.

All that being said, I have to prioritise bug fixes much more highly at the moment as until the start of July I need to finish my masters thesis, while working part time on the side. So just focusing on bug fixes of existing functionality keeps my other commitments manageable, while keeping the ship afloat here.

But I am totally in to get this merged, and will look at it when I can, but latest in July.
Unless one of the other maintainers pokes their head back in. But it's getting quieter and quieter.

[riodelphino]

Thank you for replying even though you're so busy.
And I'm glad that you see value in this.

Yes, zk list is probably quite fast.
If only that command could return lnum and col, it would be ideal.

Of course, please prioritize bug fixes — I’d be happy if you could take a look when you have some spare time.

In the meantime, I might continue adding commits here with further improvements.
See you in July or later!

Concerns (for future reference):

Currently, ZkGrep is integrated into ui.pick_notes().
However, this makes ui.pick_notes() more complex due to the added if-then-else logic.
I'm considering whether it would be better to create a separate function, such as ui.pick_grep_notes(), instead.

[riodelphino]

And now I'm looking into integrating grep with snacks.picker.
I had a hard time understanding snacks.nvim's code.
I'll probably add a commit soon.

[riodelphino]

Now I replaced lyaml totally with zk.api.list in Telescope and snacks_picker !
(Store notes from zk.api.list as M.notes_cache table.)

It's quite faster than lyaml version ^^

(Ready to be merged)

[riodelphino]

I've merged README.md updates from upstream.
No conflict, I guess.
(Finally this PR include purely grep feature only.)

[tjex]

The bash command like zk list --format json {file_path} | jq ... always returns JSON with Found {n} note text in the top or the bottom. It breaks JSON format.

The count is because less is being used as a pager to display the results. You need to pass the --quiet option.

[riodelphino]

The count is because less is being used as a pager to display the results. You need to pass the --quiet option.

Got it -- there's an option to hide the count!

[riodelphino]

Thanks for reviewing !

Additionally, I created PR in neo-tree-zk, for syncing upstream.
zk-org/neo-tree-zk.nvim#2

Though it took quite a while, it's pretty close to completion, too.

Anyway, please get some rest first @tjex ! ☺️

[tjex]

@WhyNotHugo Would you be able to give the code of this pr a look? Need your lua / nvim plugin competencies on this, it's a pretty big addition and would be great to get it right. Also as it's a long standing requested feature.

[WhyNotHugo]

I've only had a glance at a high level for now.

Do we need to use ripgrep for the search? zk itself seems to be capable of handling searches via zk list --match.

---

I'm not very familiar with snacks. Do we really need to introduce dependency on a specific picker implementation? Typically plugins use vim.ui.select, and let users register their own preferred picker (or use the default).

Folks who prefer snacks.picker can use:

require("snacks").setup({
  picker = {
    ui_select = true,
  },
})

Personally, I use fzf_lua:

require("fzf-lua").register_ui_select()

I'm sure there are other implementations out there too.

[riodelphino]

@WhyNotHugo Thanks a lot for your review and comment!

The main goals of this PR are:

• To display the note title in the grep picker (since filenames like eg8qha.md are not very readable).
• To enable jumping directly to the exact match position (lnum, col).
• To keep the flexibility of choosing a preferred picker, just like :ZkNote does.

Why ripgrep?

Do we need to use ripgrep for the search? zk itself seems to be capable of handling searches via zk list --match.

I completely agree that ideally we should rely on zk list --match for searching.
However, at the moment zk list doesn’t provide lnum or col of the match.

Because of that limitation, jumping directly to the match location wasn’t possible — the cursor always moved to the file top.

To work around this, I temporarily used ripgrep.

This makes it possible to get lnum/col and jump precisely to the right spot.

(Of course, once zk supports returning lnum/col, ripgrep can ne replaced.)

Dependency

I'm not very familiar with snacks. Do we really need to introduce dependency on a specific picker implementation? Typically plugins use vim.ui.select, and let users register their own preferred picker (or use the default).

zk-nvim already provides the mechanism for users to choose their prefered picker.

require("zk").setup({
  -- Can be "telescope", "fzf", "fzf_lua", "minipick", "snacks_picker",
  -- or select" (`vim.ui.select`).
  picker = "select",
  ...
}

With this setup, :ZkNote displays the file list using the selected picker, as you already know.

And this PR just reuses this contrivance as well as :ZkNote does.

So, actually it's not a strict dependency but a optional choice for users, I think.

Addtionally, currently this grep feature contains only telescope and snacks_picker.

I'm not familiar with fzf, so I hope someone else will fork and add it later.

No extra setup or codings

Folks who prefer snacks.picker can use:

require("snacks").setup({
  picker = {
    ui_select = true,
  },
})

Personally, I use fzf_lua:

require("fzf-lua").register_ui_select()

I'm sure there are other implementations out there too.

In the grep results, displaying filename might require only a little setup or coding.
However displaying note titles requires pretty much modifications.

With this PR, users can achieve that with no extra setup or coding.
Just using :ZkGrep or adding keymap.

I really like the philosophy behind zk, and I made this change to zk-nvim hoping that more people can use it easily and comfortably.

:ZkGrep screenshot:

[riodelphino]

I’ve merged the latest upstream main into this branch due to conflicts and avoiding deviation.
Is this the correct approach for a GitHub PR?
(I hope this doesn't cause any extra work for the reviewers..)

[tjex]

Yep, thats the correct process. And main is also correct (on zk, we have a dev branch which is the default for merges, but zk-nvim is still just main). I know this is taking ages to get this merged. Sorry for it and thanks for your patience.

@WhyNotHugo Do you think you'd have any time coming up to reassess now that riodelphino replied to your questions? I agree it would be great to use zk's match, but without line / location jumping, its not great. So it is good that we could switch out ripgrep for zk match (I haven't varified how much of a rewrite that would take though).