`with-no-warnings' suppresses all compilation warnings.
I would like to add `with-fewer-warnings' (or some similar name) that
suppresses only some warnings.
Eg (with-fewer-warnings '(obsolete cl-functions) ...)
would not warn about obsolete things or cl-functions in the body. The
possible arguments are the members of byte-compile-warnings.
I can implement this if it is considered worth it (it's very similar
to with-no-warnings).
with-suppressed-warnings sounds like a better name to me.
would not warn about obsolete things or cl-functions in the body. The
possible arguments are the members of byte-compile-warnings.
I can implement this if it is considered worth it (it's very similar
to with-no-warnings).
I think it isn't worth doing, because it would only gain you very much
if you put a lot of code inside with-no-warnings; we avoid doing that.
> I think it isn't worth doing,
(I'd already done it, locally, before posting.)
> because it would only gain you very much if you put a lot of code
> inside with-no-warnings; we avoid doing that.
Perhaps because it is such a blunt instrument. This would make it a
bit less blunt. I don't claim this is important, but it is easy to
implement.
Example usage:
In the _implementation_ of an obsolete feature, it's ok to use an
obsolete variable and there is no need to be warned about it being
obsolete. However, you should still be warned about the variable not
being defined, in case you remove it altogether but forget to update
the code that uses it.
> Perhaps because it is such a blunt instrument. This would make it a
> bit less blunt. I don't claim this is important, but it is easy to
> implement.
> In the _implementation_ of an obsolete feature, it's ok to use an
> obsolete variable and there is no need to be warned about it being
> obsolete. However, you should still be warned about the variable not
> being defined, in case you remove it altogether but forget to update
> the code that uses it.
Actually, I think I agree (I hate with-no-warnings), but it should be
even more precise, and specify which obsolete warning to silence.
Stefan
> Actually, I think I agree (I hate with-no-warnings), but it should be
> even more precise, and specify which obsolete warning to silence.
Do you mean, specify precisely which obsolete variable/function(s) not
to warn about? That's probably doable via
byte-compile-not-obsolete-vars/funcs, I'll have a look.
A syntax like this?
(with-suppressed-warnings
'((obsolete read-file-name-predicate ...) cl-functions ...)
body)
Although the motivation for this was not _just_ obsolete warnings, and
it might not be so simple to extend your request to eg specific free
variables.
> Do you mean, specify precisely which obsolete variable/function(s) not
> to warn about? That's probably doable via
> byte-compile-not-obsolete-vars/funcs, I'll have a look.
> A syntax like this?
> (with-suppressed-warnings
> '((obsolete read-file-name-predicate ...) cl-functions ...)
> body)
Yes, something like that. Also the `cl-functions' is too broad and
should not be allowed.
> Although the motivation for this was not _just_ obsolete warnings, and
> it might not be so simple to extend your request to eg specific free
> variables.
I didn't say it was easy.
BTW, maybe a good way to do it is to implement this in the function
that outputs the warnings: currently it just received some kind of
string, which is not very amenable to what we want, but if you change it
to take a more structured description of the warning, then it might be
doable (tho maybe it won't happen at the right place, I don't know).
Stefan