bug#42777: 28.0.50; Obsolete eldoc-message function used in CEDET

[Lars Ingebrigtsen]

In semantic-idle-summary-idle-function:
cedet/semantic/idle.el:771:10: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.

In semantic-idle-summary-refresh-echo-area:
cedet/semantic/idle.el:802:13: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.

I guess this is the result of João's changes in July? I had a quick
peek at how to fix it, but it wasn't immediately obvious to me.


In GNU Emacs 28.0.50 (build 51, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
of 2020-08-09 built on xo
Repository revision: 1a845a672dc73c8e98e6cb9bb734616e168e60ba
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

[Stefan Kangas]

Post by Lars Ingebrigtsen
cedet/semantic/idle.el:771:10: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.
cedet/semantic/idle.el:802:13: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.
I guess this is the result of João's changes in July? I had a quick
peek at how to fix it, but it wasn't immediately obvious to me.

Copying in João Távora in the hope that the fix will be immediately
obvious to him.

[João Távora]

Post by Stefan Kangas

Post by Lars Ingebrigtsen
cedet/semantic/idle.el:771:10: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.
cedet/semantic/idle.el:802:13: Warning: ‘eldoc-message’ is an obsolete
function (as of eldoc-1.1.0); use ‘eldoc-documentation-functions’ instead.
I guess this is the result of João's changes in July? I had a quick
peek at how to fix it, but it wasn't immediately obvious to me.

Copying in João Távora in the hope that the fix will be immediately
obvious to him.

Lars, you want to fix the compilation warning or something else? The
function is obsolete, but it leep working. The only "fix" is to follow
the advice in the warning message. I don't know why this particular
compilation warning didn't pop up earlier, I don't recall it.

João

[Eli Zaretskii]

Date: Sun, 30 Aug 2020 15:58:13 +0200
perhaps Eli didn't do a "make bootstrap" to get all the warnings.

I never bootstrap, not on my main development system.

[João Távora]

Post by João Távora
Lars, you want to fix the compilation warning or something else? The
function is obsolete, but it leep working. The only "fix" is to follow
the advice in the warning message.

If the function is obsolete, all in-tree callers should be fixed.

...unless that code is used in another non emacs-master context. I
seem to recall that having happened with Gnus once. Let's hope
it's not the case of CEDET, in which case the solution is to shoosh
the byte-compiler in that particular spot.

I'm

not familiar enough with eldoc to do so, though.

No problem, I'll do it. It's not hard, though, and the docstrings
should guide anyone to do the same.

Post by João Távora
I don't know why this particular compilation warning didn't pop up
earlier, I don't recall it.

It's been there ever since you obsoleted eldoc-message, of course. :-)

This is odd because I did get a line from Eli to fix some compilation
after my changes, and these were not among them. I wonder if this file
is always byte-compiled.

Thanks,
João

[João Távora]

Post by João Távora
This is odd because I did get a line from Eli to fix some compilation
after my changes, and these were not among them. I wonder if this file
is always byte-compiled.

It is, but perhaps Eli didn't do a "make bootstrap" to get all the
warnings. (The CEDET files don't change that much these days, so
they're rarely re-compiled.)

Anyway, I just had a look at this. This isn't the normal situation of
an ElDoc user switching from the old "call eldoc-message directly"
protocol to the new callback-based protocol.

Rather, idle.el is mostly a reimplementation of ElDoc itself which uses
a substantial amount of ElDoc internals -- and repeats much of its code.
It is, in my opinion a file to be itself obsoleted. Anyway, the
solution with less risk here is to use with-supressed-warnings, which is
what the attached patch does.

João

[João Távora]

It is, but perhaps Eli didn't do a "make bootstrap" to get all the
warnings. (The CEDET files don't change that much these days, so
they're rarely re-compiled.)

Maybe also related to the fact the function is forward declared in
the file you pointed to.

João

[Stefan Kangas]

Post by João Távora
Rather, idle.el is mostly a reimplementation of ElDoc itself which uses
a substantial amount of ElDoc internals -- and repeats much of its code.
It is, in my opinion a file to be itself obsoleted.

I'm not familiar with idle.el, but I'd suggest to open a new bug report
to track that work.

Best regards,
Stefan Kangas

[Lars Ingebrigtsen]

Anyway, the solution with less risk here is to use
with-supressed-warnings, which is what the attached patch does.

Hm... I don't think that's a good idea. We shouldn't suppress warnings
that point to actual problems, like this one does: eldoc-message will be
going away some day, and then idle.el will stop working (without any
warning).

[João Távora]

Post by Lars Ingebrigtsen

Anyway, the solution with less risk here is to use
with-supressed-warnings

Hm... I don't think that's a good idea. We shouldn't suppress warnings

Post by Lars Ingebrigtsen
that point to actual problems, like this one does: eldoc-message will be
going away some day, and then idle.el will stop working (without any
warning).

Not without _any warning_. I'm only supressing the obsoletion warning. If
you remove a function you should in principle get another warning.

João

[Lars Ingebrigtsen]

Not without _any warning_. I'm only supressing the obsoletion warning. If you
remove a function you should in principle get another warning.

That's true, but only after removing it.

Suppressing obsoletion warnings in in-tree code is counter-productive,
in my opinion. (The exception is code in lisp/obsolete, of course.)

[João Távora]

Post by Lars Ingebrigtsen

Not without _any warning_. I'm only supressing the obsoletion warning. If you
remove a function you should in principle get another warning.

That's true, but only after removing it.
Suppressing obsoletion warnings in in-tree code is counter-productive,
in my opinion. (The exception is code in lisp/obsolete, of course.)

That's true. But look, the real underlying problem we have in our code
that there is code in CEDET's idle.el that needlessly duplicates and
uses implementation detail of the ElDoc infrastructure. The real fix to
this bug is _integration_, and integration is hard and takes time.

In parallel, in my opinion, there is little point in having 0 warnings
globally. Maybe that is the policy in the Emacs repo, but in my opinion
I'd rather investigate "positive deltas" in warning count. The warnings
in this case point and mark the problem described above. We could leave
them until someone (maybe CEDET's author) either does the integration
work, or moves idle.el to lisp/obsolete.

João

[Lars Ingebrigtsen]

Post by João Távora
That's true. But look, the real underlying problem we have in our code
that there is code in CEDET's idle.el that needlessly duplicates and
uses implementation detail of the ElDoc infrastructure. The real fix to
this bug is _integration_, and integration is hard and takes time.

Indeed. And meanwhile the warning should stay.

Post by João Távora
In parallel, in my opinion, there is little point in having 0 warnings
globally. Maybe that is the policy in the Emacs repo, but in my opinion
I'd rather investigate "positive deltas" in warning count.

No, that's not the policy, as far as I know: Warnings stay in until the
problem is fixed, one way or another.

[João Távora]

Post by Lars Ingebrigtsen

Post by João Távora
That's true. But look, the real underlying problem we have in our code
that there is code in CEDET's idle.el that needlessly duplicates and
uses implementation detail of the ElDoc infrastructure. The real fix to
this bug is _integration_, and integration is hard and takes time.

Indeed. And meanwhile the warning should stay.

We agree then.

Post by Lars Ingebrigtsen

Post by João Távora
In parallel, in my opinion, there is little point in having 0 warnings
globally. Maybe that is the policy in the Emacs repo, but in my opinion
I'd rather investigate "positive deltas" in warning count.

No, that's not the policy, as far as I know: Warnings stay in until the
problem is fixed, one way or another.

That's my view as well. So what's missing perhaps is that we close this
bug and open another bug, as was Stefan Kangas' suggestion, to track the
integration work. WDYT? Or maybe we should just leave this bug as that
record, since it's where all the investigation done so far is
registered anyway.

Joãp

[Stefan Kangas]

Post by João Távora
That's my view as well. So what's missing perhaps is that we close this
bug and open another bug, as was Stefan Kangas' suggestion, to track the
integration work. WDYT? Or maybe we should just leave this bug as that
record, since it's where all the investigation done so far is
registered anyway.

I don't have any strong feelings about it, but I think we could keep
this bug report as is.

My main concern was that this piece of information would be buried in a
long sub-thread of an unrelated issue. But that doesn't seem to be the
case here if obsoleting that file is indeed the solution we're going for.

[João Távora]

On Tue, Sep 1, 2020, 19:57 Stefan Kangas <***@marxist.se> wrote:

I don't have any strong feelings about it, but I think we could keep

Post by Stefan Kangas
this bug report as is.
My main concern was that this piece of information would be buried in a
long sub-thread of an unrelated issue. But that doesn't seem to be the
case here if obsoleting that file is indeed the solution we're going for.

I agree, though I wouldn't yet go as far as asserting with 100% confidence
that obsoleting idle.el entirely is what should be done, though it's a
possibility. Just that we have an integration problem with duplicate
functionality, duplicate code and shared internals. Maybe just fixing the
later is enough. Because other than that, I feel the whole of CEDET has
been pretty obsolete, de facto, for a while now.

João

[Lars Ingebrigtsen]

Maybe just fixing the later is enough. Because other than that, I feel
the whole of CEDET has been pretty obsolete, de facto, for a while
now.

This is somewhat off-topic, but I wonder why. I mean, I don't use it
myself, but I've tested it a bit now and then when fixing compilation
bugs and stuff, and it seems very cool. It does a lot of what the
now-very-popular LSP stuff does, but still nobody seems to give CEDET
any love these days...

[João Távora]

Post by Lars Ingebrigtsen

Maybe just fixing the later is enough. Because other than that, I feel
the whole of CEDET has been pretty obsolete, de facto, for a while
now.

This is somewhat off-topic, but I wonder why. I mean, I don't use it
myself, but I've tested it a bit now and then when fixing compilation
bugs and stuff, and it seems very cool. It does a lot of what the
now-very-popular LSP stuff does, but still nobody seems to give CEDET
any love these days...

CEDET was promising, I followed it closely around 2007-2011 but it never
delivered, IME. I remember being very frustrated by the inability to set up
a simple "find the definition". Some awkward thing called "senator" had to
be built, I think. Many (re)inventions there, as there were elsewhere (i.e.
SLIME): Emacs simply didn't have the infrastructure of Eldoc, Xref,
Flymake, etc that it does now.

Also it suffers from the problem of not being LSP :) CEDET is an
Emacs-specific protocol and an Emacs-specific toolkit to develop
language-specific tools that speak that protocol. LSP is an editor agnostic
and language agnostic protocol only. A very clever idea. You need
relatively little effort on both sides to get something really useful
going. And any effort you spend on one side is worth n-fold on the other
side. That is its winning formula.

João