bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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