emacs-devel
[Top][All Lists]
Advanced

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

Re: setq's with missing final arguments.


From: Alan Mackenzie
Subject: Re: setq's with missing final arguments.
Date: Sun, 22 Nov 2015 19:44:44 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Eli.

On Sun, Nov 22, 2015 at 05:44:55PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Nov 2015 14:10:31 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: David Kastrup <address@hidden>, address@hidden

> > > The byte-compiler is not for imposing coding style.

> > That is why I proposed issuing a warning, not an error.  In the actual
> > case I found, it was indeed an error.  

> > > If it is wrong for setq to accept implit nil then it should be changed
> > > in setq and only then in the byte-compiler.

> > I would be happy enough for a missing final argument to setq to be an
> > error.  But until that stage is reached, I think issuing a warning is
> > appropriate.  But I disagree with you about priorities: it is more
> > important to catch the violations in our compiled code than worry about
> > the interpreted version.

> As long as 'setq' accepts this use case, it is not a violation.

It is a violation if it conceals errors.  This indeed is the case: in
.../lisp/emacs-lisp/bytecomp.el, in defun
byte-compile-file-form-autoload the following erroneous code exists:

         (setq byte-compile-noruntime-functions
               (delq funsym byte-compile-noruntime-functions)
               byte-compile-noruntime-functions)

.  The effect is to set byte-compile-noruntime-functions unconditionally
to nil.  The effect of that is to conceal some "function not defined \(at
runtime\)?" warnings in source files with `autoload' forms.

There are four other occurrences of missing values in `setq's throughout
the source (plus another one in .../obsolete).  They all look like
deliberate "coding style", though.  If it were up to me, I would put an
explicit nil in each of these four (or five) occurrences.

I have changed the warning's wording to be more "human": it now says:

    missing value for `foo' at end of setq

.  But I do say that this warning facility I have in my personal copy
should now be committed.  It is useful.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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