Plugin idea: a 'thing-list' concept for arbitrary lists with similar semantics as qf/loc lists

[bew]

Name idea: thinglist, with commands prefixed with TL.

👉 Similar to a quickfix/location list, I'd like a kind of thinglist for things that are not files, but:

• just a bunch of lines
• OR just a list of some data which can be rendered as a list of lines

And I'd like to be able to:

• have it as a simple editable buffer, so I can run normal commands and do anything with it
• filter the whole content in some way (see #62)
• use it as part of a custom behavior, for example to filter/order/.. the arglist (see https://github.com/bew/dotfiles/issues/54#issuecomment-846091985) (=> would be awesome: modify a list with a bool operation of another list (OR / AND), for example to filter rg matches to only files changed between 2 commits, or the worktree, or ..... ❤️)
• use helper cmds to trivially create a list, like: TLnormal nmap (or even TL nmap to get a thinglist of all nmap commands.
• can have independent thinglists 'instances' with varying lifecycle (these must be named, otherwise the global one is used). To illustrate, custom-quickfixlist and custom-loclist would be 2 independent thinglists. (There could be a default one named lists which could be used to manage the thinglist instances 🤔)

With semantics and features similar to the qf/loc lists:

• open/close
• last-10 history (or more, configurable)
• arbitrary info with rendering function (in newer nvim)
• lists unique ID (different from the list number), these are ref-counted (if a window uses it,
• can be global (like qf list) or local (like loc list)
• (in the same idea of ☝️), it can be copied to a new window, from the last window (should be configurable..)
• TODO: what is :h quickfix-changedtick ? How can I use it?

(It should be possible to reimplement them in the thinglist system)

---

Potentially existing better implementation of the qf/loc list: https://github.com/kevinhwang91/nvim-bqf 👍

[bew]

To be able to re-order a list, and not loose the association between the data and the rendered line, we can assign a row id to each line, which should be placed somewhere in the rendered line.

The text of the id is row-id:00042, the id is padded with zeros, to ensure something that should be aligned vertically, stays aligned with the row-id added to the line.

The row-id is a single WORD, so it's easy to skip with W,B, E or gE vim motions (in macros, normal commands, ..).

Like:

row-id:01| some first line
row-id:02| some second line
...
row-id:42| the last line, answering every question...

To make sorting with :sort work on the content and not the ids, the row-id can be moved to the end:

some first line |row-id:01
...

The position of the row-id can be changed with a keybinding, and can be set by the line-rendering function.

NOTE: https://github.com/stevearc/oil.nvim does a great job at hiding the initial /042 ID prefix of every lines 👀

[bew]

NOTE: for thinglist without a special data payload, this card can probably be skipped.

~~ Line formatting with an associated data payload

Data to single-line-content formatting is done only once (you can request a redraw manually though, if you changed the associated data in some way and want to refresh the displayed line).

NOTE: arbitrary editing of the line will not change the underlying data, it looks too complex for little benefit (but I'm open for ideas 🤔). NOTE: BUT thinglists with an associated data payload per line may not be that common, maybe we can keep things simple and only think about complex workflow with associated data later?

~~ Idea for line formatting function as a template

When the associated data is a vim dictionary (or similar), a simple rendering helper can be used, like:

" Given associated data that looks like:
let data = {"content": "line content!", "status": "working"}

" Get a line formatter function of the data from a template:
let content_rendering_func = some_helper("{.content} [{.status}]")

" Render the line with it:
let line_content = content_rendering_func(data)
echo plugin_line_rendering_func(line_content, "row-id:1")

You get:

row-id:1| line content! [working]

The "rendering_function" is only for the line content (not the row-id) And then the final rendering function of the plugin that will take that line content and add the row-id at the (currently) wanted position (with fallbacks).

content_rendering_func will be executed once and cached for every line. The cache can be invalidated by requesting a refresh/redraw. Then every time needed the plugin_line_rendering_func will use the cached line content, and (if editing/reordering is enabled) add the row-id formatted and at the (currently) wanted position (TL option rowid_position (either line_start or line_end)).

[bew]

I want to list the various workflows I want, from simplest to complex (order not that important).

~~ Workflow for manipulating the arglist

TODO