GNU bug report logs - #39169
28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 39169 <at> debbugs.gnu.org
Subject: bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload
Date: Mon, 24 Aug 2020 22:12:13 -0400

>> I'm currently developing a Gnu Elpa package that makes use of
>> `defclass'.  These lines in `eieio-defclass-autoload':
>>
>> #+begin_src emacs-lisp
>>       ;; turn this into a usable self-pointing symbol
>>       (when eieio-backward-compatibility
>>         (set cname cname)
>>         (make-obsolete-variable cname (format "use \\='%s instead" cname)
>>                                 "25.1"))
>> #+end_src
>>
>> (and eieio-backward-compatibility defaults to t) lead to the following
>> situation: when I have any class, for example, named `buffer-note', and
>> I have the generated autoloads loaded, whenever I use a variable with
>> the name `buffer-note' (which is a quite natural name for objects of
>> that class), I get tons of warnings saying:
>>
>> | buffer-note.el:136:11:Warning: `buffer-note' is an obsolete
>> |     variable (as of 25.1); use 'buffer-note
>>
>> The purpose of these warnings is a backward compatibility one, but it
>> shoots way over target: these warnings prevent me from using the class
>> name as a variable name - I keep renaming variables to prevent these
>> annoying warnings all the time.

Indeed that happens when you re-use the identifier `buffer-note` which has
a global binding and our obsolescence warning doesn't know how to
distinguish local bindings from global bindings.

But you could set `eieio-backward-compatibility` to nil.

> Yes, that does sound annoying.  eieio got a lot of warnings during the
> conversion to more normal cl-* functions the other year, so it made
> sense to add warnings like this during the rewrite.  But that's done
> now, so perhaps it makes sense to remove these over-enthusiastic
> warnings now?  Stefan?

You mean we should change the default of `eieio-backward-compatibility`
to nil?

Maybe you're right.

We're currently removing things that were made obsolete in Emacs-23,
whereas those were made obsolete in Emacs-25, but setting that var to
nil is not as drastic as removing those vars and functions, so it's
probably OK to do it already.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.