Same extension, multiple filetypes

[sashaweiss]

Hello! Love the concept of vivid - big value add in a compact tool.

I was planning to open a PR adding entries in the filetype database for common iOS files, e.g. .pbxproj Xcode project files (and others). While exploring that, however, I realized that .m, the extension for Objective-C implementation files, was already used in the default filetype database for Matlab files.

How will vivid handle the same file extension being associated with multiple filetypes, e.g. if I added an entry for Objective-C files ending in .m? What behavior would we want to see for that kind of conflict?

One workaround would be for me to maintain my own custom filetype database with Matlab removed in favor of ObjC, but since this is a scenario that I can imagine coming up in other scenarios as well I'm curious if this is something you'd like to handle in a specific way. Happy to contribute the changes if there's action to be taken, if that helps.

Thanks in advance!

[sharkdp]

Thank you for reporting this.

How will vivid handle the same file extension being associated with multiple filetypes, e.g. if I added an entry for Objective-C files ending in .m?

I don't really have a good answer. The LS_COLORS format is pretty limited, so the only information we really have is that a filename ends with .m. There is no further inspection to somehow confirm whether it's an Objective C file or a Matlab file.

How would vivid handle it currently? I don't know, to be honest 😄. Would have to test it myself.

What behavior would we want to see for that kind of conflict?

Good question. I don't really know how to resolve the conflict. Luckily, for this particular example here, both files are in the programming.source category. As long as we don't apply different styles to different languages, it won't really matter. But obviously, there could be other extension conflicts.

[sashaweiss]

For the moment, I'm just using a custom config I forked from the default that removes the Matlab category and adds an ObjC category - which works well enough for me.

Everything I've come up with to work around this ends up with some set of similar tradeoffs - at some level, since there's no way to differentiate beyond the filetype there's going to have to be a default and anyone for whom the default doesn't work will have to override it (e.g., what I've done). And that's probably fine 😛

One easy improvement here might be to have the set of defaults, and allow a per-user config that allows overriding/adding specific keys, rather than the per-user config having to specify all the otherwise-default keys. In my case, I'd love to keep my config mostly in-sync with the latest release, but override just the .m and maybe add some niche extensions I work with.

If you're open to that config option, and can provide some guidance as to how that config option should be exposed (i.e., if we want vivid to be able to take both a full "this is my custom config, use it and skip the defaults" and "this is my override of the default config" option), I'd be happy to look into implementing that change. For example, maybe vivid checks for a filetypes.yml to use as a "whole config", and for an overrides.yml that is intended to supplement the defaults?

[sharkdp]

One easy improvement here might be to have the set of defaults, and allow a per-user config that allows overriding/adding specific keys, rather than the per-user config having to specify all the otherwise-default keys. In my case, I'd love to keep my config mostly in-sync with the latest release, but override just the .m and maybe add some niche extensions I work with.

That would be great, I agree.

If you're open to that config option, and can provide some guidance as to how that config option should be exposed (i.e., if we want vivid to be able to take both a full "this is my custom config, use it and skip the defaults" and "this is my override of the default config" option), I'd be happy to look into implementing that change. For example, maybe vivid checks for a filetypes.yml to use as a "whole config", and for an overrides.yml that is intended to supplement the defaults?

I like that. An alternative could be to have a special key in filetypes.yml. Something like:

include: default # here, we could include other `yml` files or use "default" for the builtin config

# everything that follows would update/override the existing config:

programming:
  source:
    objective_c: [.m]
    matlab: [.matlab, .mn]

or:

overrides:
  programming:
    source:
      objective_c: [.m]
      matlab: [.matlab, .mn]

I think I would prefer approach (1) overrides.yml or (2) include statement, with no clear preference for one or the other.