Feat: allow save_key to be a function

[aarondill]

trafficstars

I'd like to assign a function that returns the root to save_key. This would allow me to use LSP to return the root instead of only cwd and git_root. The new type of save_key would be

---@type string|fun(): string?

if the function returns nil, use the CWD as the root, else use the returned value

[otavioschwanck]

I'd like to assign a function that returns the root to save_key. This would allow me to use LSP to return the root instead of only cwd and git_root. The new type of save_key would be

---@type string|fun(): string?

if the function returns nil, use the CWD as the root, else use the returned value

You can define the save_key on lua/arrow/save_keys.lua and open an PR to arrow. This way, others will can use too.

The reason that save_key is not free is because it can be very sensitive (and break other parts if not well implemented)

[aarondill]

@otavioschwanck id like to use the algorithm defined in this file (taken from folke/LazyVim), which I feel is slightly out of scope for any PR here.

perhaps if we allowed save_key to be an array, we could use each in turn and fallback to cwd if all fail. ie, {"lsp", "git", { "markers", {listOfMarkers} }, "cwd" }

which would call

save_key.lsp()
save_key.git()
--same as: save_key.markers({listOfMarkers)
save_key.markers(unpack({listOfMarkers})
save_key.cwd()

this could then also allow users to supply a function for each marker, which would then be called.

basically, if save_key is a string, wrap it in a table (to make other processing easier) for each save_key, if it's a string, index the save_key.lua module for the function, if it's a function, call it, if it's a table (assuming variable t), call t[1](unpack(t, 2)), allowing the users to pas options.

I could then add the lsp, and markers keys to save_key.lua