Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I might have overlooked, but is there something that prevents this logic to be applied to header files (if such avoidance even wanted)?
There is nothing like that. I wanted to avoid hard-coding header file extensions and without this we can't say if the current file is a header or a source.
I can imagine a header file foo.h that include a identically-named file, either using #include_next <foo.h> or with include path trickery.
This case isn't currently handled (not sure if it's common enough and also the consequences won't be too bad). Also I kind of assumed with the code that all the includes are uniquely named and don't do anything special about the duplicates. The first found header with the given name "wins".
Actually thinking about it, it might even make sense to sort tags of the corresponding source file earlier, when editing a header file. For example when I want to create a declaration in a header file it's likely to be a function that might be already implemented in the corresponding source file.
Makes sense, we'd just have to do this reverse-include thing to lookup sources. To find headers, we can use the header tags for includes from ctags but we don't have anything in the opposite direction.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.