GNU bug report logs - #56459
29.0.50; Edebug disables Eldoc

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: max.brieiev <at> gmail.com, larsi <at> gnus.org, friedman <at> splode.com, 56459 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#56459: 29.0.50; Edebug disables Eldoc
Date: Wed, 1 Mar 2023 19:11:12 +0000

On Wed, Mar 1, 2023 at 6:42 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Wed, 1 Mar 2023 18:25:04 +0000
> > Cc: Dmitry Gutov <dgutov <at> yandex.ru>, Max Brieiev <max.brieiev <at> gmail.com>,
> >       Lars Ingebrigtsen <larsi <at> gnus.org>, 56459 <at> debbugs.gnu.org, friedman <at> splode.com
> >
> > I think there's a decent place in eldoc.el to do this check, though we should take care not to require
> > edebug.el in eldoc.el.
> >
> > I'll look at it later, but I think if one searches for the phrase "check if we have permission to mess with the
> > echo area at all", or something to that effect, one would see it.
>
> The condition which was misfiring is in
> eldoc-display-message-no-interference-p, which is called by that
> place.  So the problem is not _where_ to make the test, the problem is
> what should the test be to avoid overwriting Edebug evaluation results
> with ElDoc stuff.  I couldn't find an indication we could depend on to
> distinguish stepping through Lisp from typing in the buffer popped by
> 'E', for example.  Every test I tried either succeeded in both cases
> or failed in both cases.

Sorry, I misunderstood the problem.  In fact I didn't know about Edebug's
E at all.

João



--
João Távora

Previous Next

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