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


--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no

[Stefan Kangas]

Lars Ingebrigtsen <la...@gnus.org> writes:

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

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

[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. I don't know why this particular
compilation warning didn't pop up earlier, I don't recall it.

João

[Eli Zaretskii]

> From: Lars Ingebrigtsen <la...@gnus.org>
> Date: Sun, 30 Aug 2020 15:58:13 +0200
> Cc: 42...@debbugs.gnu.org, Stefan Kangas <ste...@marxist.se>
>
> 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]

On Sun, Aug 30, 2020 at 2:47 PM Lars Ingebrigtsen <la...@gnus.org> wrote:

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

 

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

Lars Ingebrigtsen <la...@gnus.org> writes:

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

On Sun, Aug 30, 2020 at 2:58 PM Lars Ingebrigtsen <la...@gnus.org> wrote:

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]

João Távora <joaot...@gmail.com> writes:

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

João Távora <joaot...@gmail.com> writes:

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

On Sun, Aug 30, 2020, 16:46 Lars Ingebrigtsen <la...@gnus.org> wrote:

João Távora <joaot...@gmail.com> writes:

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

João Távora <joaot...@gmail.com> writes:

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

Lars Ingebrigtsen <la...@gnus.org> writes:

> João Távora <joaot...@gmail.com> writes:
>
>> 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]

João Távora <joaot...@gmail.com> writes:

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

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

Lars Ingebrigtsen <la...@gnus.org> writes:
> João Távora <joaot...@gmail.com> writes:
>
>> 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.

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

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 <ste...@marxist.se> wrote:

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.

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]

João Távora <joaot...@gmail.com> writes:

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

On Wed, Sep 2, 2020, 14:38 Lars Ingebrigtsen <la...@gnus.org> wrote:

João Távora <joaot...@gmail.com> writes:

> 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