[mini.pick] alignment with grep_live?

[pkazmier]

Now that we have alignment with buf_lines, I really want the same for grep_live. My first thought was to use mini.align. Why re-invent the wheel, right?

local show_align_on_nul = function(buf_id, items, query, opts)
  items = MiniAlign.align_strings(items, {
    justify_side = { "left", "right", "right" },
    merge_delimiter = { "", " ", "", " ", "" },
    split_pattern = "%z",
  })
  MiniPick.default_show(buf_id, items, query, opts)
end

MiniPick.registry.grep_live_align = function()
  MiniPick.builtin.grep_live({}, { source = { show = show_align_on_nul } })
end

Alas, it doesn't work because of vim.fn.strdisplaywidth on line 1549 in mini.align. It seems the NUL byte separator in the Lua string means that vim treats this as a blob instead, which is not compatible with that function. If I cheat and change that function to string.len, you can get an idea of what it would look like:

Anyone have any simple suggestions? Thanks!

---

Updated solution with monkey patching based on this comment:

local show_align_on_nul = function(buf_id, items, query, opts)
  -- HACK: `items` is an array of strings with \0 byte separators, cannot use strdisplaywidth.
  local original = vim.fn.strdisplaywidth
  vim.fn.strdisplaywidth = string.len
  items = MiniAlign.align_strings(items, {
    justify_side = { "left", "right", "right" },
    merge_delimiter = { "", " ", "", " ", "" },
    split_pattern = "%z",
  })
  vim.fn.strdisplaywidth = original
  MiniPick.default_show(buf_id, items, query, opts)
end

MiniPick.registry.grep_live_align = function()
  MiniPick.builtin.grep_live({}, { source = { show = show_align_on_nul } })
end

[echasnovski]

The simplest (and the hackiest) suggestion is to temporarily monkey patch vim.fn.strdisplaywidth = string.len.

The more proper suggestion would be to replace \0 with come rare character (or even '│' right away), align using replaced character as split pattern, and then replace them back to be \0.

---

Just a note: as grep_live is a fairly performance critical function, I don't think it having alignment option similar to MiniExtra.pickers.buf_lines is a good idea.

[pkazmier]

... I was convinced for second that performance was not worth it here. But only for a second 😅

A second? Well, that's an eternity compared to any perceived performance hit that may be incurred 😄

In all seriousness, I'm very sensitive to lag (recall our discussion on the synchronous fallback of mini.completion). If I noticed any compromise whatsoever on the user experience, I would abandon, but I honestly don't—perhaps a testament to the performance of mini.align?

[echasnovski]

... perhaps a testament to the performance of mini.align?

Yeah, maybe. But mostly because I missed that this is a show override which acts only on visible entries, which aren't that many. Yet it means another issue which I don't really like: alignment will change after query change and even scrolling.

I remembered the original reason on why alignment was not implemented in the first place: on wide file names it makes the matched line barely visible or completely invisible. Although most file matches are relative, it still has negative effect. The one counter measure for this is making picker occupy full instance width, though.

[pkazmier]

... alignment will change after query change and even scrolling.

This does not bother me nearly as much as the default behavior of not having any alignment though.

I remembered the original reason on why alignment was not implemented in the first place: on wide file names it makes the matched line barely visible or completely invisible. Although most file matches are relative, it still has negative effect. The one counter measure for this is making picker occupy full instance width, though.

Yes, that's still somewhat a problem with the default behavior. So, this morning I increased the width of this particular picker a bit. Curiously, when looking to find the default you use for width, what is the significance of 0.618? Without knowing the answer, I bumped the width to 0.816 as an homage to you 😄. I also tweaked my new picker to truncate directories from pathnames to help mitigate the width issue. While the pathname is truncated in the main picker list, one can always see the full pathname in the picker window title while previewing.

Since I use a non-ascii truncation indicator (…), my monkey patch of strdisplaywidth with string.len no longer worked. So, I had to revert to changing the NUL byte to some other somewhat unique separator, then align, then revert back. And, while this probably makes your brain scream due to inefficiency, it still works without noticeable delay and I didn't have to reimplement an alignment function.

local sep = package.config:sub(1, 1)
local function truncate_path(path)
  local parts = vim.split(path, sep)
  if #parts > 2 then
    parts = { parts[1], "…", parts[#parts] }
  end
  return table.concat(parts, sep)
end

local function map_gsub(items, pattern, replacement)
  return vim.tbl_map(function(item)
    item, _ = string.gsub(item, pattern, replacement)
    return item
  end, items)
end

local show_align_on_nul = function(buf_id, items, query, opts)
  -- Shorten the pathname to keep the width of the picker window to something
  -- a bit more reasonable for longer pathnames.
  items = map_gsub(items, "^%Z+", truncate_path)

  -- Because items is an array of blobs (contains a NUL byte), align_strings
  -- will not work because it expects strings. So, convert the NUL bytes to a
  -- unique (hopefully) separator, then align, and revert back.
  items = map_gsub(items, "%z", "#|#")
  items = MiniAlign.align_strings(items, {
    justify_side = { "left", "right", "right" },
    merge_delimiter = { "", " ", "", " ", "" },
    split_pattern = "#|#",
  })
  items = map_gsub(items, "#|#", "\0")

  -- Back to the regularly scheduled program :-)
  MiniPick.default_show(buf_id, items, query, opts)
end

MiniPick.registry.grep_live_align = function()
  MiniPick.builtin.grep_live({}, {
    source = { show = show_align_on_nul },
    window = { config = { width = math.floor(0.816 * vim.o.columns) } },
  })
end

[echasnovski]

Curiously, when looking to find the default you use for width, what is the significance of 0.618?

https://en.wikipedia.org/wiki/Golden_ratio

[dwoodwardgb]

Thank you so much @pkazmier !!! This is the one piece I was missing to get into Mini pick!

[abeldekat]

Very nice!