Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/

[Robert Cochran <robert+Emacs@cochranmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Now that the byte-compile-error-on-warn patch was merged (thanks by the
>> way!), this is the next step: I've marked most every file in lisp/
>> that currently byte-compiles without warnings with
>> 'byte-compile-error-on-warn: t' in its file local variables.
>
> I sometimes consider it preferable to keep a warning than to silence it
> (typically because I can't fix it (yet)).  This said, I'm fine with
> adding such annotations for those files which currently don't have warnings.

Yeah, right now it is only marking files that emit no warnings
whatsoever. I intend for this to be a situation similar to
lexical-binding, where it is enabled on a per file as they get cleaned
up and become warning-free.

I am trying to keep warnings from lingering. The
string-{to,as}-{multi,uni}byte family of functions have been deprecated
since June 2016, which are some of the functions I see the most in the
deprecation warnings. Stuff like that.

>> So, it's my understanding that there are some portions of what's in
>> emacs.git - org-mode being the prominent example in my mind - are simply
>> merges of a separate repository into emacs.git.
>
> You'll want to be super extra careful with files that are also
> distributed outside of Emacs, since they may emit warnings when compiled
> by a different version of Emacs (typically one that doesn't exist yet).

Hmm, sounds like its better to just not do that with files distributed
in parallel. I don't have a problem with that (most files is better than
no files after all), but I have no idea which ones are and are not 'core
only' files. Guidance requested.

Thanks,
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2