Setting recurse_submodules = true for git_files picker breaks <leader>ff about lazyvim HOT 23 CLOSED

Better wait for maintainer's input regarding that, since I'm just a simple user.

from lazyvim.

LazyVim.pick automatically sets show_untracked to true if you don't pass explicit option via the keymap. So, either make a keymap for LazyVim.pick("auto", { show_untracked = false }) or use Telescope git_files if you don't want that behavior.

from lazyvim.

I see. Wouldn't it make more sense for LazyVim.pick to follow the options configured by the user for git_files though?

from lazyvim.

Makes sense. I feel the situation is quite inconsistent right now, because LazyVim.pick will honor the user setting the recurse_submodules option to true, but won't do so for the show_untracked option.

from lazyvim.

@mux

Can you try the following

-- ~/.config/nvim/lua/plugins/core.lua
return {
  {
    "dpetka2001/LazyVim",
    branch = "fix/telescope-show_untracked",
  },
}

Then open Lazy UI, press C to check for updates and U to apply updates. Then restart Neovim and see if you observe the same behavior. If it is to your liking I can submit a PR.

from lazyvim.

I just tried this and it did not fix the issue somehow? Something weird is going on because I added this to my telescope.lua configuration, and it also did not help:

keys = {
  { "<leader>ff", LazyVim.pick("auto", { show_untracked = false }), desc = "Find Files (Root Dir)" },
  { "<leader>fF", LazyVim.pick("auto", { root = false, show_untracked = false }), desc = "Find Files (cwd)" },
},

from lazyvim.

Strange for me it didn't show any error with this change, whereas with your initial telescope config it showed the error that you mentioned. Do you get the same error or something different?

from lazyvim.

Yeah something is off here. I get the exact same error. I have been double-checking to make sure I didn't do anything dumb but everything looks right. Updating with the fix plugin in core.lua worked for sure, I got a bunch of notifications because of file changes, and yet I have the exact same behavior as before. I am also curious to know if overriding the keymaps like I showed in my last message works for you? The reason this doesn't work might be the same reason why pulling in your plugin does not.

from lazyvim.

Ah, I believe I understand what is happening. I had removed show_untracked = false from my telescope configuration because it shouldn't technically be required since Telescope's default is false. So, I do not know LUA well, or its definition of truthiness and comparisons, but I assume that a nil value doesn't compare to equal with false, so opts.show_untracked ~= false would end up evaluating to true. I wonder if that is why the LazyVim picker also sets show_untracked to true; that would be the case if the opts dict is actually coming from the telescope configuration, but I am just widly guessing here, I need to check the code.

from lazyvim.

Following up on the above, trying a LUA expression evaluator online, I see that nil ~= false indeed evaluates to true. I am assuming that opts.show_untracked would be nil if the option is not set.

from lazyvim.

Does it work correctly if you put back show_untracked = false in your Telescope spec?

from lazyvim.

Yes it does. I just don't think that should be needed.

from lazyvim.

It should because the default behavior of LazyVim is to set it to true. And in my fix I only check if the user has explicitly set in his Telescope spec show_untracked = false, otherwise if he hasn't I leave the default LazyVim value untouched.

from lazyvim.

Yeah, that does makes sense if you are trying to preserve the current behavior of LazyVim. I am simply coming at this from another angle though, and saying that LazyVim should honor the Telescope defaults and the user overrides. I guess we will have to see what the maintainer thinks about it.

from lazyvim.

In other words, I personally feel that the most sensible fix would be to simply remove this line:

      opts.show_untracked = opts.show_untracked ~= false

But then again, I do not know the motivation for this behavior in the first place.

from lazyvim.

Yeah it's not my place to make decisions. I just tried to work around the problem for setting the value in the user configuration and LazyVim to respect that value and at the same time also respect the default LazyVim value if the user hasn't defined anything in his personal configuration.

from lazyvim.

Yeah, and thank you for that! By the way, did you get around to trying the keymaps override like I posted earlier? I am confused as to why this isn't working.

from lazyvim.

and saying that LazyVim should honor the Telescope defaults and the user overrides

Most Neovim distros are quite biased depending on each maintainer's experience and personal preferences. LazyVim already has a lot of default options changed regarding other plugins as well. So, in my personal opinion, I don't agree with it having to respect the plugins' default options (if it only had the plugins' default options, there would hardly be a need for configuration and it would be just a collection of plugins with defaults). It only has to respect the user's personal configuration settings and overrides. But that's just me and I don't expect everyone to agree with that take.

Regarding the keymaps, no I didn't try that. It's getting really late here, so I'm just gonna call it a night for today. Hopefully, the maintainer will shed more light to clear any questions you might have regarding LazyVim defaults, as it's not my place to give explanations about that other than my own personal opinion.

from lazyvim.

Leader ff automatically uses git files or find files. It works as it should. Closing.

from lazyvim.

@mux I tried the following configuration with default LazyVim configuration and it seems to work (I don't get any error when I press <leader>ff)

  {
    "nvim-telescope/telescope.nvim",
    opts = {
      pickers = {
        find_files = { follow = true },
        git_files = { show_untracked = false, recurse_submodules = true },
      },
    },
    keys = {
      { "<leader>ff", LazyVim.pick("auto", { show_untracked = false }) },
    },
  },

Although I believe that setting show_untracked = false in telescope.pickers.git_files is kind of redundant since you already define it in the keymap itself.

from lazyvim.

@folke Should I withdraw the PR I made, since the keymap works correctly? The PR is just for taking into account the option set in Telescope's spec in user configuration without the user having to define a different keymap or change the default ones. I don't know what the correct approach should be, should a user prefer such a behavior with show_untracked = false, recurse_submodules = true in Telescope spec.

from lazyvim.

@folke Thank you for getting back to us. I understand that <leader>ff is supposed to automtically use git_files or find_files depending on the circumstances and that is just fine. The problem I am describing here is that a perfectly legitimate git_files configuration by the user (setting recurse_submodules to true) leads to <leader>ff not working anymore. This leads to two questions:

1. Why would LazyVim honor the recurse_submodules setting and yet ignore show_untracked, forcing it to true and making <leader>ff impossible to use unless by remapping it completely? This is arguably a bug and the patch from @dpetka2001 fixes this.
2. Why is LazyVim forcing show_untracked to true in the first place when telescope defaults to false? I personally feel that it would make more sense to use the same defaults as telescope, although that is clearly debatable.

Even if LazyVim wants to continue forcing show_untracked to true for some reason, it should probably avoid getting in a situation where the picker just doesn't work anymore, by not setting show_untracked to true when recurse_submodules is.

@dpetka2001 You are correct - the keymap setting actually fixes <leader>ff, what I was observing is that selecting Find File in the menu after starting nvim without parameters shows the same problem and error message. I have no idea why would Find File in the menu would behave differently from <leader>ff but that is apparently the case.

from lazyvim.

@mux Yes on the dashboard menu it wouldn't work. That's because when we define a keymap we only pass the options we specify to that keymap alone. All other keymaps would behave with LazyVim defaults and that's what you observe I believe. If my PR gets accepted, I believe the user won't have to change all possible keymaps. He will just have to define in the Telescope spec show_untracked = false to override the default LazyVim behavior and that's all.

Hopefully the maintainer will accept my PR or maybe he will come up with an even better solution than mine, since my knowledge is quite limited if I may say so.

from lazyvim.