Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Disabling Problem reports for specific files and/or folders #46

Open
martinwiesmann opened this issue Nov 4, 2024 · 8 comments
Labels
type: feature New feature or request

Comments

@martinwiesmann
Copy link

Description

There should be an option to exclude a specific file or a whole folder from the problem reporting. This file/folder can still be in the IDL path and could/should still be parsed by the extension.

Additionally, there should be an option to exclude a specific file or a whole folder from parsing. This file/folder can still be in the IDL path, e.g. as a subfolder of a path given to IDL path.

Why it Matters

I am working on a part of a huge IDL library (solarsoft), and thus I need this whole library in my IDL path due to its dependencies of my part of the library to other parts of the library. So, I would like the entire library to be parsed, but I only want problems from my part of the library to be reported.

I develop my part of the library outside of the library itself, in its own git repository, and I only sync my repository to the library when I am happy with the current code. I.e. the code that I really want to get problem reports for is in another path than the library, but also in the IDL path.
That means, I would like to exclude my part of the library from parsing altogether since when it is parsed, I get a whole bunch of 'duplicate' warnings, which I don't want. Furthermore, the extension reports problems from my part of the library that is in the library and not updated.

I am sure I am not the only one with this problem.

Suggested Behavior

Add two options to the extension settings.

  • 'Exclude file/path from reporting problems'
  • 'Exclude file/path from being parsed'

Both options would act very similarly as e.g. idl.IDL.path. That means one could 'Add items' which would be paths to a file or folder and possibly use the '+' syntax to include subdirectories.

Alternate Behavior

I know it is possible to disable a file from reporting problems by adding a comment line with the comment 'idl-disable'.
But this is not practical for mainly two reasons: The library consists of thousands of files and I only have control over a small portion of the library.

Even if I could implement this solution, I would still like to exclude subfolders of the IDL path from being parsed.

@martinwiesmann martinwiesmann added the type: feature New feature or request label Nov 4, 2024
@martinwiesmann
Copy link
Author

Sorry, these should probably be two separate feature requests. But they are related and I guess the implementation of those would be very similar.

@martinwiesmann
Copy link
Author

I also saw the option idl.problems.includeProblemsFromIDLPath but I haven't found out what this does.

@znorman-harris
Copy link
Contributor

Thanks for reporting this!

First, for the preference you found, the VSCode UI (and hover help in the JSON settings editor) should give you the description of each setting.

For reporting problems, I think it probably makes sense to add a new setting that can exclude reporting problems for specific folders without having to change code. I think file-specific exclusions might be a little too much detail/control here and I think we would want this to behave the same way as IDL's search path (i.e. "+" to exclude a folder and subdirectories from being reported). I can poke at a new setting for this which shouldn't be too hard to get together.

For excluding folders from the parsing path, I'm not sure what to think about that just yet. However, if you want to bypass the default behavior, you can manually control IDL's path using the environment launch setting that we provide in the extension. This way IDL will know about the code/path, but VSCode won't parse/report it

I think this might work to solve your second problem.

Here's where you can find it:

image

@martinwiesmann
Copy link
Author

Thanks for your quick reply.

Ok, now I get it with the IDL_PATH and this setting. In my case, this doesn't help me though, since what I want to exclude is a subdirectory of a directory I want to have parsed (but not reported :) ). But never mind this feature request (about excluding paths from being parsed), this does not have a high priority, and I think I know how to work around this problem. I.e. I don't include the whole library, but only the subdirectories minus the one I do not want. A bit more complicated but works fine.

But adding a setting to exclude directories from being reported would still be very nice to have. A file-specific exclusion is probably overkill, I agree. At least, I won't need this kind of specificity, excluding directories would be good enough.

@znorman-harris
Copy link
Contributor

Even though your request may be specific to your large code base, I would still like to leave this feature request open in case other people have the same request.

If you have a way to workaround it for now, I'll put this on the back burner. If that changes, feel free to reach out again and we can see if we can solve the problem for you.

@martinwiesmann
Copy link
Author

Yes, I do have a workaround, so this feature isn't a high priority. But I appreciate that you want to leave this feature request open.

@martinwiesmann
Copy link
Author

I see a new option in the settings that seems to be for this feature. But it doesn't seem to work (yet).

idl.problems.excludeProblemsForPath

@znorman-harris
Copy link
Contributor

Ah, whoops! I thought I had done that on one of the branches, but that looks like it snuck in to develop and the release.

But good eye! That was me mocking up the parts and pieces for your original feature request.

I'll add that to my list to get wrapped up in the next few weeks and it will actually work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants