bug#56459: 29.0.50; Edebug disables Eldoc

bug#56459: 29.0.50; Edebug disables Eldoc

[Max Brieiev]

1. emacs -Q

2. Instrument any function, e.g. in the scratch buffer type:

    (defun one () (+ 1))

and press C-u C-M-x

3. Run the function, e.g. M-: (one) RET

4. After Edebug reaches stop point, type E to enter eval list buffer

5. Observe that while you are typing any expression, eldoc does not
   display any hints in the echo area. (Same issue exists in any other
   elisp buffer with eldoc mode enabled, while Edebug is active.)

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Guix System

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
 SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
 --prefix=/gnu/store/gkk3pa8yb1b2fi5qjgdr99mnyqky2d7n-emacs-next-git.master
 --enable-fast-install --with-modules --with-cairo
 --disable-build-details'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: /home/max/.guix-profile/share/emacs/site-lisp:/gnu/store/gkk3pa8yb1b2fi5qjgdr99mnyqky2d7n-emacs-next-git.master/share/emacs/29.0.50/lisp
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  paredit-mode: t
  hl-line-mode: t
  global-corfu-mode: t
  corfu-mode: t
  marginalia-mode: t
  vertico-mode: t
  savehist-mode: t
  recentf-mode: t
  pixel-scroll-precision-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  hs-minor-mode: t

Load-path shadows:
/home/max/.emacs.d/elpa/transient-20220527.2213/transient hides /gnu/store/gkk3pa8yb1b2fi5qjgdr99mnyqky2d7n-emacs-next-git.master/share/emacs/29.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug rx mule-util cursor-sensor paredit-menu
paredit hideshow hl-line message yank-media puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
smtpmail sendmail rfc2047 rfc2045 ietf-drums gnus nnheader gnus-util
time-date mail-utils range mm-util mail-prsvr modus-operandi-theme
modus-themes pcase files-x consult-vertico consult compat-28 compat
bookmark text-property-search corfu orderless marginalia edmacro kmacro
vertico cus-edit pp cl-extra savehist recentf tree-widget wid-edit
pixel-scroll cua-base cus-load use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core guix-emacs corfu-autoloads eglot-autoloads
embark-consult-autoloads consult-autoloads embark-autoloads geiser-impl
help-fns radix-tree help-mode geiser-custom geiser-base ring
geiser-autoloads gif-screencast-autoloads js2-mode-autoloads
magit-autoloads git-commit-autoloads magit-section-autoloads
dash-autoloads marginalia-autoloads paredit-menu-autoloads
paredit-autoloads vertico-autoloads with-editor-autoloads info
compat-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
byte-opt gv bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 207102 11407)
 (symbols 48 16472 0)
 (strings 32 46004 1953)
 (string-bytes 1 1534072)
 (vectors 16 22677)
 (vector-slots 8 277940 20399)
 (floats 8 128 30)
 (intervals 56 559 0)
 (buffers 992 10))

bug#56459: 29.0.50; Edebug disables Eldoc

[Lars Ingebrigtsen]

Max Brieiev <max.brieiev@gmail.com> writes:

> 5. Observe that while you are typing any expression, eldoc does not
>    display any hints in the echo area. (Same issue exists in any other
>    elisp buffer with eldoc mode enabled, while Edebug is active.)

This is due to this code:

;; Check various conditions about the current environment that might make
;; it undesirable to print eldoc messages right this instant.
(defun eldoc-display-message-no-interference-p ()
  "Return nil if displaying a message would cause interference."
  (not (or executing-kbd-macro
           (bound-and-true-p edebug-active)

This was added by:

commit 03a9c6d06a177fd9026779bcb952f906a7743690
Author:     Noah Friedman <friedman@splode.com>
AuthorDate: Mon Jul 24 00:38:34 2000 +0000

    (eldoc-display-message-no-interference-p): Don't interfere with edebug.

But it doesn't say in what way it interferes with edebug -- and removing
that line, I don't really see any interference?  But eldoc messages
things slightly different now than two decades ago...

Anybody know what this code is trying to do?

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

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Cc: 56459@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 11 Jul 2022 12:49:12 +0200
> 
> Max Brieiev <max.brieiev@gmail.com> writes:
> 
> > 5. Observe that while you are typing any expression, eldoc does not
> >    display any hints in the echo area. (Same issue exists in any other
> >    elisp buffer with eldoc mode enabled, while Edebug is active.)
> 
> This is due to this code:
> 
> ;; Check various conditions about the current environment that might make
> ;; it undesirable to print eldoc messages right this instant.
> (defun eldoc-display-message-no-interference-p ()
>   "Return nil if displaying a message would cause interference."
>   (not (or executing-kbd-macro
>            (bound-and-true-p edebug-active)
> 
> This was added by:
> 
> commit 03a9c6d06a177fd9026779bcb952f906a7743690
> Author:     Noah Friedman <friedman@splode.com>
> AuthorDate: Mon Jul 24 00:38:34 2000 +0000
> 
>     (eldoc-display-message-no-interference-p): Don't interfere with edebug.
> 
> But it doesn't say in what way it interferes with edebug -- and removing
> that line, I don't really see any interference?  But eldoc messages
> things slightly different now than two decades ago...
> 
> Anybody know what this code is trying to do?

AFAIK nowadays 'message' displays echo-area messages in a way that
doesn't interfere with existing messages (it displays them in brackets
at the end of the existing text), so I think the original problem
should no longer exist.

Noah, can you verify that your original problem cannot be reproduced
if we remove the condition in eldoc-display-message-no-interference-p
that you added?

bug#56459: 29.0.50; Edebug disables Eldoc

[Noah Friedman]

Sorry I didn't see this message sooner.

I seem to recall that the eldoc messages (which would show up as you're
stepping through the debugger because point moves interactively) would
obsure the evaluation results that edebug prints for each sexp.  They both
use the echo area and they're both in the same recursive-edit level but the
echo area isn't currently active, so I'm not sure why `message' would
append below any existing message rather than replacing it.

If that's still the case, and I had to do it again I'd still prefer the
edebug messages over the eldoc ones when both are active at once.


In <83pmibzx0k.fsf@gnu.org> 2022-07-11 14:52:59+0300, Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: 56459@debbugs.gnu.org
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 11 Jul 2022 12:49:12 +0200
>> 
>> Max Brieiev <max.brieiev@gmail.com> writes:
>> 
>> > 5. Observe that while you are typing any expression, eldoc does not
>> >    display any hints in the echo area. (Same issue exists in any other
>> >    elisp buffer with eldoc mode enabled, while Edebug is active.)
>> 
>> This is due to this code:
>> 
>> ;; Check various conditions about the current environment that might make
>> ;; it undesirable to print eldoc messages right this instant.
>> (defun eldoc-display-message-no-interference-p ()
>>   "Return nil if displaying a message would cause interference."
>>   (not (or executing-kbd-macro
>>            (bound-and-true-p edebug-active)
>> 
>> This was added by:
>> 
>> commit 03a9c6d06a177fd9026779bcb952f906a7743690
>> Author:     Noah Friedman <friedman@splode.com>
>> AuthorDate: Mon Jul 24 00:38:34 2000 +0000
>> 
>>     (eldoc-display-message-no-interference-p): Don't interfere with edebug.
>> 
>> But it doesn't say in what way it interferes with edebug -- and removing
>> that line, I don't really see any interference?  But eldoc messages
>> things slightly different now than two decades ago...
>> 
>> Anybody know what this code is trying to do?
>
>AFAIK nowadays 'message' displays echo-area messages in a way that
>doesn't interfere with existing messages (it displays them in brackets
>at the end of the existing text), so I think the original problem
>should no longer exist.
>
>Noah, can you verify that your original problem cannot be reproduced
>if we remove the condition in eldoc-display-message-no-interference-p
>that you added?

bug#56459: 29.0.50; Edebug disables Eldoc

[Noah Friedman]

>Noah, can you verify that your original problem cannot be reproduced
>if we remove the condition in eldoc-display-message-no-interference-p
>that you added?

So in the current snapshot I'm running, 9dc0fdfdc1 (2022-07-02 07:04:32),
it looks like the check for edebug mode was removed already and the
behavior is still that only the edebug results are visible; that is,
eldoc's messages aren't covering up the edebug messages, but they aren't
showing up below them either and they're not even showing up in any mode
line.

So the practical upshot is, I see no change in behavior; whatever
motivated that change seems to be a non-issue now.

bug#56459: 29.0.50; Edebug disables Eldoc

[Lars Ingebrigtsen]

Noah Friedman <friedman@splode.com> writes:

> So in the current snapshot I'm running, 9dc0fdfdc1 (2022-07-02 07:04:32),
> it looks like the check for edebug mode was removed already

Sorry, I don't follow -- the code currently is

(defun eldoc-display-message-no-interference-p ()
  "Return nil if displaying a message would cause interference."
  (not (or executing-kbd-macro
           (bound-and-true-p edebug-active)
           ...

So the check for edebug is still there.

> and the behavior is still that only the edebug results are visible;
> that is, eldoc's messages aren't covering up the edebug messages, but
> they aren't showing up below them either and they're not even showing
> up in any mode line.
>
> So the practical upshot is, I see no change in behavior; whatever
> motivated that change seems to be a non-issue now.

If I remove that check, I don't see any problems -- stepping through the
code doesn't trigger eldoc, so there's no covering up of messages.  (But
moving the cursor after stepping triggers eldoc, but that seems fine.)

bug#56459: 29.0.50; Edebug disables Eldoc

[Noah Friedman]

In <87sfmg1bpf.fsf@gnus.org> 2022-08-01 12:48:28+0200, Lars Ingebrigtsen <larsi@gnus.org> writes:
>Noah Friedman <friedman@splode.com> writes:
>
>> So in the current snapshot I'm running, 9dc0fdfdc1 (2022-07-02 07:04:32),
>> it looks like the check for edebug mode was removed already
>
>Sorry, I don't follow -- the code currently is
>
>(defun eldoc-display-message-no-interference-p ()
>  "Return nil if displaying a message would cause interference."
>  (not (or executing-kbd-macro
>           (bound-and-true-p edebug-active)
>           ...
>
>So the check for edebug is still there.

My mistake; I was looking in the wrong place.

>If I remove that check, I don't see any problems -- stepping through the
>code doesn't trigger eldoc, so there's no covering up of messages.  (But
>moving the cursor after stepping triggers eldoc, but that seems fine.)

That seems right to me too, so I'd vote for removing it.

This also serves as a useful reminder to me that I ought to do a better job
describing interaction problems in the first place, because I am not likely
to remember the details 22 years later!

bug#56459: 29.0.50; Edebug disables Eldoc

[Lars Ingebrigtsen]

Noah Friedman <friedman@splode.com> writes:

>>If I remove that check, I don't see any problems -- stepping through the
>>code doesn't trigger eldoc, so there's no covering up of messages.  (But
>>moving the cursor after stepping triggers eldoc, but that seems fine.)
>
> That seems right to me too, so I'd vote for removing it.

So I've now done that in Emacs 29.

> This also serves as a useful reminder to me that I ought to do a better job
> describing interaction problems in the first place, because I am not likely
> to remember the details 22 years later!

Yeah, it's hard to remember to put the rationale behind a change into
the change log because my brain often goes "well, it's self evident
why!" and then 20 years later, it's not...

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

Hi Lars and others,

On 01/08/2022 13:48, Lars Ingebrigtsen wrote:
>> and the behavior is still that only the edebug results are visible;
>> that is, eldoc's messages aren't covering up the edebug messages, but
>> they aren't showing up below them either and they're not even showing
>> up in any mode line.
>>
>> So the practical upshot is, I see no change in behavior; whatever
>> motivated that change seems to be a non-issue now.
> If I remove that check, I don't see any problems -- stepping through the
> code doesn't trigger eldoc, so there's no covering up of messages.  (But
> moving the cursor after stepping triggers eldoc, but that seems fine.)

What I'm seeing now, is stepping through Edebug often does invoke Eldoc, 
which triggers messages which do override edebug evaluations.

Which seems like a problem previously solved by that check.

Not sure if I've just started seeing this recently due to some later 
change (but neither eldoc nor edebug's history show anything relevant), 
or if I'd just actively been ignoring this for half a year.

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Date: Tue, 28 Feb 2023 04:15:41 +0200
> Cc: max.brieiev@gmail.com, eliz@gnu.org, 56459@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> Hi Lars and others,
> 
> On 01/08/2022 13:48, Lars Ingebrigtsen wrote:
> >> and the behavior is still that only the edebug results are visible;
> >> that is, eldoc's messages aren't covering up the edebug messages, but
> >> they aren't showing up below them either and they're not even showing
> >> up in any mode line.
> >>
> >> So the practical upshot is, I see no change in behavior; whatever
> >> motivated that change seems to be a non-issue now.
> > If I remove that check, I don't see any problems -- stepping through the
> > code doesn't trigger eldoc, so there's no covering up of messages.  (But
> > moving the cursor after stepping triggers eldoc, but that seems fine.)
> 
> What I'm seeing now, is stepping through Edebug often does invoke Eldoc, 
> which triggers messages which do override edebug evaluations.
> 
> Which seems like a problem previously solved by that check.

Maybe.  I also sometimes see this, but just now trying Edebug on a
random function doesn't reproduce this.  Can you reproduce at will? if
so, can you show a recipe?

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

On 28/02/2023 15:04, Eli Zaretskii wrote:
>> Date: Tue, 28 Feb 2023 04:15:41 +0200
>> Cc:max.brieiev@gmail.com,eliz@gnu.org,56459@debbugs.gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>> Hi Lars and others,
>>
>> On 01/08/2022 13:48, Lars Ingebrigtsen wrote:
>>>> and the behavior is still that only the edebug results are visible;
>>>> that is, eldoc's messages aren't covering up the edebug messages, but
>>>> they aren't showing up below them either and they're not even showing
>>>> up in any mode line.
>>>>
>>>> So the practical upshot is, I see no change in behavior; whatever
>>>> motivated that change seems to be a non-issue now.
>>> If I remove that check, I don't see any problems -- stepping through the
>>> code doesn't trigger eldoc, so there's no covering up of messages.  (But
>>> moving the cursor after stepping triggers eldoc, but that seems fine.)
>> What I'm seeing now, is stepping through Edebug often does invoke Eldoc,
>> which triggers messages which do override edebug evaluations.
>>
>> Which seems like a problem previously solved by that check.
> Maybe.  I also sometimes see this, but just now trying Edebug on a
> random function doesn't reproduce this.  Can you reproduce at will? if
> so, can you show a recipe?

Sure:

1) Visit an .rb file (with ruby-mode).
2) Instrument ruby-smie-rules with edebug.
3) Switch to .rb file again and press TAB somewhere where it would call 
ruby-mode's indentation code.
4) Step through ruby-smie-rules with SPC, not too quickly.

That happens with 'emacs -Q', no extra setup needed.

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

reopen 56459
thanks

> Date: Tue, 28 Feb 2023 18:25:07 +0200
> Cc: larsi@gnus.org, friedman@splode.com, max.brieiev@gmail.com,
>  56459@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> Which seems like a problem previously solved by that check.
> > Maybe.  I also sometimes see this, but just now trying Edebug on a
> > random function doesn't reproduce this.  Can you reproduce at will? if
> > so, can you show a recipe?
> 
> Sure:
> 
> 1) Visit an .rb file (with ruby-mode).
> 2) Instrument ruby-smie-rules with edebug.
> 3) Switch to .rb file again and press TAB somewhere where it would call 
> ruby-mode's indentation code.
> 4) Step through ruby-smie-rules with SPC, not too quickly.
> 
> That happens with 'emacs -Q', no extra setup needed.

You are right.  It turns out we didn't see the ElDoc messages because
in many Lisp codes stepping with Edebug leaves point in places where
ElDoc has nothing to say.  But as soon as it does, it does say, and by
doing that overwrites the evaluation results in the echo area.

So I've now reverted that change, and I'm reopening the bug.  It will
have to be fixed in some other way.

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Cc: max.brieiev@gmail.com, larsi@gnus.org, 56459@debbugs.gnu.org,
>  friedman@splode.com
> Date: Wed, 01 Mar 2023 17:42:07 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> So I've now reverted that change, and I'm reopening the bug.  It will
> have to be fixed in some other way.

One possibility would be to show the ElDoc info on the mode line when
Edebug is active.  But the difficulty with that is to figure out how
to revert the mode line to the original shape when Edebug finishes.
We currently show the info on the mdoe line when the current buffer is
a minibuffer, and remove the info in minibuffer-exit-hook, but how to
do that in the Edebug case?

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

On 01/03/2023 17:49, Eli Zaretskii wrote:
>> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
>>   friedman@splode.com
>> Date: Wed, 01 Mar 2023 17:42:07 +0200
>> From: Eli Zaretskii<eliz@gnu.org>
>>
>> So I've now reverted that change, and I'm reopening the bug.  It will
>> have to be fixed in some other way.
> One possibility would be to show the ElDoc info on the mode line when
> Edebug is active.  But the difficulty with that is to figure out how
> to revert the mode line to the original shape when Edebug finishes.
> We currently show the info on the mdoe line when the current buffer is
> a minibuffer, and remove the info in minibuffer-exit-hook, but how to
> do that in the Edebug case?

edebug-mode-hook?

This seems to work:

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index 3f5cf0ad0dc..01b48b0f45b 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -296,9 +296,12 @@ eldoc-minibuffer-message
  This function displays the message produced by formatting ARGS
  with FORMAT-STRING on the mode line when the current buffer is a 
minibuffer.
  Otherwise, it displays the message like `message' would."
-  (if (minibufferp)
+  (defvar edebug-active)
+  (if (or edebug-active (minibufferp))
        (progn
-	(add-hook 'minibuffer-exit-hook
+        (add-hook (if (minibufferp)
+                      'minibuffer-exit-hook
+                    'edebug-mode-hook)
  		  (lambda () (setq eldoc-mode-line-string nil
  			      ;; https://debbugs.gnu.org/16920
  			      eldoc-last-message nil))

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Date: Wed, 1 Mar 2023 18:06:56 +0200
> Cc: max.brieiev@gmail.com, larsi@gnus.org, 56459@debbugs.gnu.org,
>  friedman@splode.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 01/03/2023 17:49, Eli Zaretskii wrote:
> >> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
> >>   friedman@splode.com
> >> Date: Wed, 01 Mar 2023 17:42:07 +0200
> >> From: Eli Zaretskii<eliz@gnu.org>
> >>
> >> So I've now reverted that change, and I'm reopening the bug.  It will
> >> have to be fixed in some other way.
> > One possibility would be to show the ElDoc info on the mode line when
> > Edebug is active.  But the difficulty with that is to figure out how
> > to revert the mode line to the original shape when Edebug finishes.
> > We currently show the info on the mdoe line when the current buffer is
> > a minibuffer, and remove the info in minibuffer-exit-hook, but how to
> > do that in the Edebug case?
> 
> edebug-mode-hook?

That's a starting point, but I don't think it's enough, because you
could switch to another buffer without exiting Edebug.  I tried
something like that and it didn't work well enough.  But maybe my
testing was incorrect, so if you are confident that this fixes the
problem, feel free to install (perhaps on master, though).

bug#56459: 29.0.50; Edebug disables Eldoc

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

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.

João

On Wed, Mar 1, 2023, 16:59 Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 1 Mar 2023 18:06:56 +0200
> > Cc: max.brieiev@gmail.com, larsi@gnus.org, 56459@debbugs.gnu.org,
> >  friedman@splode.com
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > On 01/03/2023 17:49, Eli Zaretskii wrote:
> > >> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
> > >>   friedman@splode.com
> > >> Date: Wed, 01 Mar 2023 17:42:07 +0200
> > >> From: Eli Zaretskii<eliz@gnu.org>
> > >>
> > >> So I've now reverted that change, and I'm reopening the bug.  It will
> > >> have to be fixed in some other way.
> > > One possibility would be to show the ElDoc info on the mode line when
> > > Edebug is active.  But the difficulty with that is to figure out how
> > > to revert the mode line to the original shape when Edebug finishes.
> > > We currently show the info on the mdoe line when the current buffer is
> > > a minibuffer, and remove the info in minibuffer-exit-hook, but how to
> > > do that in the Edebug case?
> >
> > edebug-mode-hook?
>
> That's a starting point, but I don't think it's enough, because you
> could switch to another buffer without exiting Edebug.  I tried
> something like that and it didn't work well enough.  But maybe my
> testing was incorrect, so if you are confident that this fixes the
> problem, feel free to install (perhaps on master, though).
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3082 bytes --]

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 1 Mar 2023 18:25:04 +0000
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Max Brieiev <max.brieiev@gmail.com>, 
> 	Lars Ingebrigtsen <larsi@gnus.org>, 56459@debbugs.gnu.org, friedman@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.

Of course, I'm nowhere near being an expert on Edebug's internals, so
I might be missing something.

bug#56459: 29.0.50; Edebug disables Eldoc

[João Távora]

On Wed, Mar 1, 2023 at 6:42 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 1 Mar 2023 18:25:04 +0000
> > Cc: Dmitry Gutov <dgutov@yandex.ru>, Max Brieiev <max.brieiev@gmail.com>,
> >       Lars Ingebrigtsen <larsi@gnus.org>, 56459@debbugs.gnu.org, friedman@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

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

On 01/03/2023 18:57, Eli Zaretskii wrote:
>> Date: Wed, 1 Mar 2023 18:06:56 +0200
>> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
>>   friedman@splode.com
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>> On 01/03/2023 17:49, Eli Zaretskii wrote:
>>>> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
>>>>    friedman@splode.com
>>>> Date: Wed, 01 Mar 2023 17:42:07 +0200
>>>> From: Eli Zaretskii<eliz@gnu.org>
>>>>
>>>> So I've now reverted that change, and I'm reopening the bug.  It will
>>>> have to be fixed in some other way.
>>> One possibility would be to show the ElDoc info on the mode line when
>>> Edebug is active.  But the difficulty with that is to figure out how
>>> to revert the mode line to the original shape when Edebug finishes.
>>> We currently show the info on the mdoe line when the current buffer is
>>> a minibuffer, and remove the info in minibuffer-exit-hook, but how to
>>> do that in the Edebug case?
>> edebug-mode-hook?
> That's a starting point, but I don't think it's enough, because you
> could switch to another buffer without exiting Edebug.  I tried
> something like that and it didn't work well enough.  But maybe my
> testing was incorrect, so if you are confident that this fixes the
> problem, feel free to install (perhaps on master, though).

We could try to use more hooks, or give up and use post-command-hook.

Also switched to looking up edebug-mode instead of edebug-active because 
the latter is a global value.

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index 3f5cf0ad0dc..493ec18446f 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -296,13 +296,10 @@ eldoc-minibuffer-message
  This function displays the message produced by formatting ARGS
  with FORMAT-STRING on the mode line when the current buffer is a 
minibuffer.
  Otherwise, it displays the message like `message' would."
-  (if (minibufferp)
+  (defvar edebug-mode)
+  (if (or edebug-mode (minibufferp))
        (progn
-	(add-hook 'minibuffer-exit-hook
-		  (lambda () (setq eldoc-mode-line-string nil
-			      ;; https://debbugs.gnu.org/16920
-			      eldoc-last-message nil))
-		  nil t)
+        (add-hook 'post-command-hook #'eldoc-minibuffer--cleanup)
  	(with-current-buffer
  	    (window-buffer
  	     (or (window-in-direction 'above (minibuffer-window))
@@ -321,6 +318,14 @@ eldoc-minibuffer-message
            (force-mode-line-update)))
      (apply #'message format-string args)))

+(defun eldoc-minibuffer--cleanup ()
+  (defvar edebug-mode)
+  (unless (or edebug-mode (minibufferp))
+    (setq eldoc-mode-line-string nil
+          ;; https://debbugs.gnu.org/16920
+          eldoc-last-message nil)
+    (remove-hook 'post-command-hook #'eldoc-minibuffer--cleanup)))
+
  (make-obsolete
   'eldoc-message "use `eldoc-documentation-functions' instead." 
"eldoc-1.1.0")
  (defun eldoc-message (&optional string) (eldoc--message string))

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Date: Wed, 1 Mar 2023 21:19:05 +0200
> Cc: max.brieiev@gmail.com, larsi@gnus.org, 56459@debbugs.gnu.org,
>  friedman@splode.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > That's a starting point, but I don't think it's enough, because you
> > could switch to another buffer without exiting Edebug.  I tried
> > something like that and it didn't work well enough.  But maybe my
> > testing was incorrect, so if you are confident that this fixes the
> > problem, feel free to install (perhaps on master, though).
> 
> We could try to use more hooks, or give up and use post-command-hook.
> 
> Also switched to looking up edebug-mode instead of edebug-active because 
> the latter is a global value.

SGTM, thanks.

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

On 01/03/2023 21:25, Eli Zaretskii wrote:
> SGTM, thanks.

Only master, right?

bug#56459: 29.0.50; Edebug disables Eldoc

[João Távora]

> +  (defvar edebug-mode)
> +  (unless (or edebug-mode (minibufferp))

Doesn't it need sth like bound-and-true-p?

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

On 01/03/2023 21:58, João Távora wrote:
>> +  (defvar edebug-mode)
>> +  (unless (or edebug-mode (minibufferp))
> Doesn't it need sth like bound-and-true-p?

Fair question, I suppose it does.

bug#56459: 29.0.50; Edebug disables Eldoc

[Eli Zaretskii]

> Date: Wed, 1 Mar 2023 21:39:57 +0200
> Cc: max.brieiev@gmail.com, larsi@gnus.org, 56459@debbugs.gnu.org,
>  friedman@splode.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 01/03/2023 21:25, Eli Zaretskii wrote:
> > SGTM, thanks.
> 
> Only master, right?

Yes, please.

bug#56459: 29.0.50; Edebug disables Eldoc

[Dmitry Gutov]

Version: 30.1

On 02/03/2023 08:08, Eli Zaretskii wrote:
>> Date: Wed, 1 Mar 2023 21:39:57 +0200
>> Cc:max.brieiev@gmail.com,larsi@gnus.org,56459@debbugs.gnu.org,
>>   friedman@splode.com
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>> On 01/03/2023 21:25, Eli Zaretskii wrote:
>>> SGTM, thanks.
>> Only master, right?
> Yes, please.

Pushed, and closing again. :-)