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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#39169: closed (28.0.50; Confusing obsolete variable warnings
 in eieio-defclass-autoload)
Date: Wed, 06 Jan 2021 16:57:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 06 Jan 2021 17:56:27 +0100
with message-id <871reyats4.fsf <at> web.de>
and subject line Re: bug#39169: 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload
has caused the debbugs.gnu.org bug report #39169,
regarding 28.0.50; Confusing obsolete variable warnings in eieio-defclass-autoload
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
39169: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39169
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Confusing obsolete variable warnings in
 eieio-defclass-autoload
Date: Sat, 18 Jan 2020 10:57:24 +0100

Hello,

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.  They are obviously very confusing if
you don't know the background internals, unless you really have hit the
addressed case (and of course following the instruction is not
expedient).  And it's hard to get rid of them: because the
`make-obsolete-variable' are in the autoloads, not even a file-local
eieio-backward-compatibility setting helps.

Please reconsider how these warnings are implemented.  If no better
solution can be found, the warning message should at least be made more
meaningful and tell which case it addresses, and there should be a
(discoverable!) way to turn off these warnings (file locally).


TIA,

Michael.


In GNU Emacs 28.0.50 (build 23, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
 of 2020-01-17 built on drachen
Repository revision: 4d3ac4cddbe1960f5227d14bd0d357a7b19c1296
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12006000
System Description: Debian GNU/Linux bullseye/sid

[Message part 3 (message/rfc822, inline)]

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 39169-done <at> debbugs.gnu.org
Subject: Re: bug#39169: 28.0.50; Confusing obsolete variable warnings in
 eieio-defclass-autoload
Date: Wed, 06 Jan 2021 17:56:27 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I tried to add an appropriate test for the remaining case, please check
> the following patch (my first addition to the test suite) - is it what
> you had in mind? - where I also try to give a less confusing (but
> longer) compiler warning.  Does it look alright?

Installed.

Then we should be done here, and I'm closing this report.

Thanks to all,

Michael.

Previous Next

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