[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defcla
From: |
Stefan Monnier |
Subject: |
bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload |
Date: |
Mon, 24 Aug 2020 22:12:13 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
>> 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
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Lars Ingebrigtsen, 2020/08/24
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload,
Stefan Monnier <=
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Lars Ingebrigtsen, 2020/08/25
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Lars Ingebrigtsen, 2020/08/25
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Michael Heerdegen, 2020/08/26
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Lars Ingebrigtsen, 2020/08/27
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Michael Heerdegen, 2020/08/27
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Michael Heerdegen, 2020/08/27
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Michael Heerdegen, 2020/08/27
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Stefan Monnier, 2020/08/27
- bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload, Lars Ingebrigtsen, 2020/08/28