Handle C / C++ cases without .color_coded about color_coded HOT 3 CLOSED

@tony Thank you.

This is a more advanced feature which I didn't implement originally just out of simplicity. Agreed, now that color_coded has matured this much and has met such an audience, it's a good time to make it even more convenient.

First, I want to be very clear on how things currently work:

1. color_coded will search from the project directory up to / for a .color_coded file. This means that you can absolutely put one in $HOME and color_coded will find it as long as your project is underneath it.
2. Adding a .color_coded per project is only needed if each project has different flags. If you're operating on some common flags, use a common .color_coded file somewhere able all of the projects.
3. Finally, .color_coded files are language agnostic. This is the real issue with the current implementation. A shared .color_coded is allowed, as well as specializations, but there's no way to say "for a C project/file, do this; for a C++ one, do that."

I have considered how this would be implemented and my current idea works like this:

1. color_coded will look up once the closest .color_coded file, if any, for a given file type. These files will be differentiated by the extension of the .color_coded file. For example, your $HOME directory may have .color_coded.c and .color_coded.cpp for common C and C++ flags. When you're in a buffer, color_coded will give you the chance to use a .color_coded file specific to the file type.
2. To help preserve backward compatibility and offer a way of sharing flags between file types, the .color_coded file without an extension will cover all types. The final result of the flags ends up being: color_coded constants + .color_coded (if any) + .color_coded.filetype (if any).

The only issue I've foreseen with this design is the possibility of a global .color_coded getting in the way of a project using its own .color_coded.filetype files. The solution to this comes in two options:

1. Keep your global files generic
2. Define an empty .color_coded file, in whichever project, to prevent the usage of the global one

Now, as far as ultimate convenience goes, this still leaves one glaring issue unresolved: color_coded can't detect the flags of a project and generate the appropriate .color_coded files for you. I consider that a separate issue (see #15) and my primary directive for this issue is to ensure file types can have their own flags.

from color_coded.

Let's say I have the following project structure:

• Project A
  • .color_coded
  • some c++ files
  • Subproject B
    • .color_coded.c
    • some c files

If I open the c++ files in Subproject B, what will the flags look like? If the flags in the .color_coded file conflict with .color_coded.c, am I forced to create an empty .color_coded in Subproject B? This may break horribly if I have a .color_coded in my home directory and just forgot about it.

May I propose the following approach instead:

• Search for any .color_coded files in the current directory
• If we find multiple, prefer the one with a matching file extension and fall back to .color_coded otherwise
• Stop the search once a matching file is found
• Should there be no files matching the aforementioned criteria, go up one level and repeat

from color_coded.

@tony This is now implemented! The logic works very similarly to how @UnrealQuester described above and I'd love to hear back after you've given it some testing. See the updated README for more info.

from color_coded.