Different command configurations for same extension

[DannyBen]

First of all, thanks for this tool - I am always looking for easy to use "watch and run" tools.

One thing that I think would be very helpful, is the ability to define different command templates for the same extension.

For example, the default for *.rb file would be - as it is now - ruby {{ file }}
But, sometimes I want to lint it with rubocop, so I would love to run gaze lint . and have it run the appropriate rubocop command.

As for the configuration format to support this, my first intuition is to have an additional optional config option:

- ext: .rb
  cmd: ruby "{{file}}"
- ext: .rb
  cmd: rubocop "{{file}}"
  name: lint   # <= this

Furthermore, it could be useful to run a specific "task" on multiple files with different extensions.
Imagine that you also have a lint option for other file types, you would be able to "enter lint mode" by running:

# only run commands named `lint` for any configured extension that changes in this dir
$ gaze lint .

Thoughts?

[wtetsu]

Thank you for using Gaze and for sharing your thoughtful suggestions.

Your proposal helped me understand the demand for supporting “different commands for the same extension.” While implementing such a feature is technically feasible, it introduces additional complexity to both the configuration and the overall user experience. To be honest, it’s challenging to envision a scenario where many users would incorporate name into their configurations and rely on it heavily when invoking the Gaze command. Furthermore, it raises questions like “How should the tool behave if multiple commands with the same ext+name exist?” or “What should happen if a non-existent name is specified at runtime?” These edge cases could make the behavior harder for users to predict and might lead to unintended confusion.

Conclusion

Instead of adding this feature, I recommend these simpler alternatives:

1. Use multiple configuration files: Specify a config file with the -f option.

gaze -f rubocop.yaml .

2. Invoke commands directly: Use the -c option to run custom commands.

gaze -c "rubocop {{file}}" .

If you run this command daily to the point where you feel the command is too long, it may be a sign to create an alias for it.
Thank you again for your thoughtful suggestion.

[DannyBen]

Hmm. No. :)

1. All these questions you asked, are product design questions, to which I think, there is a reasonable answer (see below).
2. As there are already quite a few "watch and run" tools, the strength of Gaze - in my view - is its ability to hide complexities behind a configuration. If I need to run a long command line, it already loses its appeal.

How should the tool behave if multiple commands with the same ext+name exist?

This is simple and has at least two routes:

1. Disallow such a config with an error / warning message.
2. Allow such a config, and select the first one that matches - with or without a warning.

What should happen if a non-existent name is specified at runtime?

Whatever happens at any CLI when an erroneous input is provided: Show an error message.

it introduces additional complexity to both the configuration and the overall user experience

Isn't this true for every feature?
The user experience should not be harmed at all by the addition of this feature, since:

1. People can still ignore the existence of the name attribute
2. The CLI will simply become gaze [NAME] PATH_TO_WATCH - which makes NAME optional, and therefore does not add any overhead to the users who want to avoid it.

All that said - it is of course your project and vision, so its your decision where it goes - but I thought gaze came very close to providing me with what I need, that I thought I should mention this feature, which is needed in my day to day use of file watchers.