[Feature request] Project settings and custom telescope commands

[ybbond]

hi, is there config to add default args for FlutterRun? Also, is there a way to add custom menu to aforementioned FlutterRun (with default args) for Telescope?

I currently use these configuration to achieve what I wanted:

in the config for flutter-tools.nvim

on_attach = function(client, bufnr)
  -- .....
  require('flutter-tools.utils').command("FlutterAgentStart", [[lua require('flutter-tools.commands').run_command('--flavor=staging --no-sound-null-safety')]])
  -- .....
end

I copied the whole flutter-tools's file menu.lua, then added these lines:

      {
        id = "flutter-tools-run-agent",
        label = "Flutter tools: Start Agent",
        hint = "Start the Agent App project",
        command = function() require("flutter-tools.commands").run_command('--flavor=staging --no-sound-null-safety') end,
      },

then added my own telescope folder in:

lua
|- configs
|- telescope
    |- _extensions
        |- flutter.lua

Is there "better" way to achieve this? If there is currently none, this is a feature request 😄

Thanks before!

[akinsho]

Hi @ybbond,

Nope there currently isn't a way to do this, I discussed this a little bit over in ~#71~ https://github.com/akinsho/flutter-tools.nvim/issues/70#issuecomment-873615994. It isn't immediately clear how to do this easily tbh so I'm open to suggestions or PRs. I'm wary of adding in the wrong mechanism for this that would need to be deprecated later. For example vscode has a launch.json which a user can create per directory and so that informs what gets added to the run command etc. The problem with that is I'd have to create a custom per project config finding mechanism and avoid taken names like launch.json in case a user's project has one but they didn't intent to use it. Which feels like quite a bit of a scope creep into project settings territory for just one language specific plugin.

Alternatively it could be added to user's config but this then means it isn't project specific so you'd see run commands for other projects whilst in non-applicable projects. The solution could potentially be to namespace them under a particular directory in the config but then a user would have to add their project directory paths into their nvim config which is messy and maybe shares work information they don't want to share.

So TLDR, I'm not sure how to solve this problem.

[akinsho]

@Charly6596 do you happen to have any thoughts? I guess one thing could be to try and mirror the behaviour or reading values out of the launch.json although another completely hypothetical solution is I believe there's a stealth nvim plugin being worked on that will allow setting project based config for lsp more easily. It might be also worth waiting to see if that gets released since if there was a single plugin that all other plugins could depend on e.g. we had our own common format like coc-settings.json then I could reliably read that.

[Charly6596]

@akinsho hmm that nvim plugin sounds interesting +1 to waiting for it I can't think about a clean solution either. Reading values from a launch.json file is fine I guess, but I prefer a more common/standard approach. Using my own r command in my config worked for me so far, the same as what @ybbond did

[ybbond]

sorry just get back to this.

The problem that I can think with vscode's in-project-directory specific configuration is too scattered. Sublime's specific configuration that doesn't need (but can) to be inside the project directory is better, but still too scattered for me. Both vscode and sublime has approach 'one file configuration per one project'.

I personally like the approach mentioned in https://github.com/akinsho/flutter-tools.nvim/issues/70#issuecomment-873615994. It makes the configuration has a single source of truth, and easier to maintain because it's in a single file.

[akinsho]

So I'm going to wait a little for the possible project/workspace plugin that might be being developed to get released. I don't actually like the idea of putting project specific configuration in your dotfiles, I think this leaks potentially private information regarding a user's projects or means adding not globally relevant information to a user's dotfiles. I think the config in directory thing is a well known mechanism, and I'd rather use something like that.

[ybbond]

@akinsho that makes sense, I respect your decision.

I guess it leaves us to the "custom command" part? You're welcome to focus this issue on the project specific part

[akinsho]

@ybbond I think those would be intertwined right, since the need for a custom command relates to a project specific requirement. It needs a bit of thought in general, since I'm not sure what the best interface will be. I would rather users didn't end up specifying like 7 different variants of flutter run for a bunch of different projects, whereas they could configure a project and its run args or something. A naive solution would be to specify some list of custom commands in a user's config with the necessary metadata and then just merge those with the existing list when telescope is opened, but I'd rather get it right and not be iterating or dealing with bugs or requests for ages.