[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert Cochran
Subject: Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/
Date: Wed, 21 Feb 2018 18:51:46 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Robert Cochran <address@hidden>
>> Date: Wed, 21 Feb 2018 10:30:24 -0800
>> 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'm not sure why we'd want this by default,

Because that extra bit of correctness is always nice to have. Some
classes of warning could very well turn out to be the root of errors. I
especially think that files in the core ought to be subject to slightly
stricter quality control anyways. Honestly, the warnings that annoy me
the most are the deprecation warnings. IMO, *nothing* in core should be
using deprecated functions/variables so far as it can be helped. If it
were up to me, I'd refuse patches that didn't fix other files when
deprecating functions. I'm of the belief that it looks sloppy.

I personally do not think it is unreasonable to expect that files in the
core compile 100% clean.

> but in any case please don't do this with platform-specific files,
> like w32-fns.el or term/x-win.el, because these almost always cause
> legitimate warnings on platforms other than those for which they are
> written.

OK, no problem. Those can go into the pile of files that still need
b-c-e-o-w off for the time being. How can I determine which files are
platform specific (because I have no idea on how to determine this)?

~Robert Cochran

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]