Consistent filepath display and code cleanup.

[caojoshua]

Changes

1. Default overridable values for hide_filename, shorten_path, and tail_path
2. Consistent use of aforementioned values across entry makers
3. extract copy pasted path transformations into a common utility function

Caveats

• This will probably change filepath display for some pickers for many users.
• I tried some basic manual testing for many of the affected pickers, but may have missed some

Open Questions

• I am not sure how to deal with some of the existing pickers that have default values for shorten_path and tail_path
  • ie. lsp references sets shorten_path to true by default
  • IMO, these pickers should instead follow global values, and the user can just pass in options to override defaults as needed

[kkharji]

😟 enum, seriously. I don't see any value of enums vs strings. It will just break setups.

Strings doesn't require importing stuff and support future abstraction of configuration setup

[tjdevries]

I will send some comments maybe later today, but probably tomorrow. This isn't exactly what I meant. No worries though 😁

[tjdevries]

local make_enum = function(t)
  -- todo: enum maker... (i have implementation elsewhere)
  return t
end

local types = {}

types.FileDisplay = make_enum {
  HIDE_PATH = 1,
  SHORTEN_PATH = 2,
  TAIL_PATH = 4,
  ABSOLUTE_PATH = 8,
  -- ... future optiosn possible
}

require('telescope.builtin').find_files {
  -- This would make paths short & absolute
  file_display = types.FileDisplay.SHORTEN_PATH + types.FileDisplay.ABSOLUTE_PATH,
}

require('telescope.builtin').find_files {
  -- This would hide the path.
  -- It shouldn't matter what else you add here, as it will just hide the path.
  file_display = types.FileDisplay.HIDE_PATH,
}

-- This method lets us continue to add other options to the display without having to create
-- an ever growing number of fields and have people be confused about which one each does.

This is more along the lines of what I was thinking.

We can use bit flags to check whether a value is present or not and do things with it depending on how it works.

@tami5 does this make more sense?

[kkharji]

@tami5 does this make more sense?

😭 idk @tjdevries, I definitely prefer if file_display simply receive a list of strings, with strict checking of string keys, so e.g. a spelling mistakes of a key or non-existing key would error out.

Don't get me wrong I absolutely like enums, but for lua and configs; 1. I don't see any value in it, 2. it feels more robust and requires extra code, 3. why bother

Your call.

[caojoshua]

@tjdevries I personally would slightly lean towards @tami5 's opinion. As a telescope user, configs will be a little easier to have raw strings then getting the enum type. I can see both sides though, since enums are more "proper" and can help catch configuration errors. Either works for me, I can go with what the maintainers prefer.

[tjdevries]

How do you do this with strings: file_display = types.FileDisplay.SHORTEN_PATH + types.FileDisplay.ABSOLUTE_PATH,

Perhaps we just enumerate all the string options "shortened_absolute", "shortened_relative", etc.? It seems a bit difficult to check them all (and prone to error as time goes on).

[tjdevries]

Ah, so you're saying file_display = { "short", "absolute" } like this? I suppose I'm fine with that as long as we validate all the strings at start time. I don't mind it this way. (should also allow just passing one string: file_display = "hidden" as well, for ease of use and less confusion)

[caojoshua]

seems like @tjdevries, @Conni2461, and myself are in alignment to have the file_display be a list of strings(will probably actually rename to path_display). Should be a simple change, but won't get to it until later this week.

[caojoshua]

OK I actually just pushed a commit for using raw strings instead of enums. Apparently I don't know how to work with git well enough. I rebased against master and got a bunch of stuff not related to this PR. I'll try to figure it out tomorrow or the day after.

[caojoshua]

Cleaned things up and should be reviewable now.

[kkharji]

LGTM

[tjdevries]

Only other thing that I notice right away is that we should warn people if they pass something like shorten_path as a key (so check that it's not nil). If it's nil, you should advise them how to fix (by passing "shorten" or whatever).

[caojoshua]

Added more changes

• cleaned up a bunch of old path options. Tried to maintain current functionality. Seems fine with some testing on my end.
• I've noticed that for making paths relative, we sometimes get error viml functions must not be called in a lua loop callback. I've so far only noticed this for live_grep. I've commented out that section for now, and want to see if the reviewers better understand this problem.
• editing docs, including a link to this wiki

[l-kershaw]

Looks very useful 🙂

---

Only additional suggestion would be that I think we can remove get_default on line 7 of make_entry.lua as it is no longer used in that file. (Not sure why GitHub isn't letting me review that line but 🤷)

[caojoshua]

Any of the maintainers want to take a look at this?

[Conni2461]

I generated docs, written changelog and added the old options to deprecated file (because its a breaking change).
Also fixed an issue with hidden + tags.

I'll merge tomorrow, its too late for me now. :)

Thanks for adding the docs and all your work here @caojoshua 😃