I have a case where the filename is critical for it to be recognized and I would like to have my language server report to the client if that file is incorrectly named as a diagnostic. However, it is not clear for me how I would do it in my case for multiple reasons. To describe my situation, I am working with the following:
debian/control. This file lists a number of "package names". As an example, it could have a package called foo.
debian/${NAME}.install. This is a auxiliary file related to the package with name ${NAME}. The file is optional, so it might be there or not. If the package is foo, then the filename should be debian/foo.install.
What I want, is to be able to warn the user if they typoed the filename of debian/${NAME}.install (they wrote debian/foo.intsall rather than debian/foo.install). The current behavior is that a typo causes the file to silently be ignored by the tools that would pick up these auxiliary files.
Unlikely Java, there is nothing in debian/foo.install that references the filename that I can report as an error, Java has the public class Foo of a Foo.java where I could attach the diagnostic and that is the solution I have seen so far, but it does not apply to my case (see Extra details below for the rationale). My "goto" solution so far is to create the diagnostic such that the range of the diagnostic covers the entire auxiliary file, but I am not sure if it is the proper way to do it or just a work around on my part. The other alternative would be an empty range, but I recall reading somewhere (cannot find the source) that the client then decides how to interpret that and VSCode as an example would look for a word at that position.
An alternative is to associate the diagnostic with the package name in debian/control, even though the problem is not the package name or its metadata. I am already using that technique for when a package is missing a mandatory field (similar to a class not implementing all the abstract methods it is required to do). Still, I would like the specification to be more clear on how to solve this case, since I doubt it will be the last of time I meet this problem.
Extra details
Note that there are multiple auxiliary files of the listed pattern (such as debian/${NAME}.docs, or debian/${NAME}.service, etc.) and for some of them, the content is required for follow a third party specification (the .service would be a systemd Service file). So it is not possible for me to dictate that the auxiliary files follow a particular syntax. Though, it is not a problem for my language server to work with different file formats since it is already a polyglot.
Hi
I have a case where the filename is critical for it to be recognized and I would like to have my language server report to the client if that file is incorrectly named as a diagnostic. However, it is not clear for me how I would do it in my case for multiple reasons. To describe my situation, I am working with the following:
debian/control. This file lists a number of "package names". As an example, it could have a package calledfoo.debian/${NAME}.install. This is a auxiliary file related to the package with name${NAME}. The file is optional, so it might be there or not. If the package isfoo, then the filename should bedebian/foo.install.What I want, is to be able to warn the user if they typoed the filename of
debian/${NAME}.install(they wrotedebian/foo.intsallrather thandebian/foo.install). The current behavior is that a typo causes the file to silently be ignored by the tools that would pick up these auxiliary files.Unlikely Java, there is nothing in
debian/foo.installthat references the filename that I can report as an error, Java has thepublic class Fooof aFoo.javawhere I could attach the diagnostic and that is the solution I have seen so far, but it does not apply to my case (seeExtra detailsbelow for the rationale). My "goto" solution so far is to create the diagnostic such that the range of the diagnostic covers the entire auxiliary file, but I am not sure if it is the proper way to do it or just a work around on my part. The other alternative would be an empty range, but I recall reading somewhere (cannot find the source) that the client then decides how to interpret that and VSCode as an example would look for a word at that position.An alternative is to associate the diagnostic with the package name in
debian/control, even though the problem is not the package name or its metadata. I am already using that technique for when a package is missing a mandatory field (similar to a class not implementing all the abstract methods it is required to do). Still, I would like the specification to be more clear on how to solve this case, since I doubt it will be the last of time I meet this problem.Extra details
Note that there are multiple auxiliary files of the listed pattern (such as
debian/${NAME}.docs, ordebian/${NAME}.service, etc.) and for some of them, the content is required for follow a third party specification (the.servicewould be a systemd Service file). So it is not possible for me to dictate that the auxiliary files follow a particular syntax. Though, it is not a problem for my language server to work with different file formats since it is already a polyglot.