bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Hello,

I get errors when I click with mouse-2 on a date in the *Calendar* in a
frame that has no input focus.

Recipe from emacs -Q in X:

Enable debug-on-error if you want to get a backtrace.

C-x 5 2 (Open a second frame.)

Select it and M-x calendar RET

Select the first frame.

C-h k  and click with mouse-2 on a date in the calendar in the other
frame.

I get:

| Debugger entered--Lisp error: (wrong-type-argument listp #<frame *Calendar* 0x559da2103a80>)
|   posn-set-point(#<frame *Calendar* 0x559da2103a80>)
|   help--analyze-key([(switch-frame #<frame *Calendar* 0x559da2103a80>)] [(switch-frame #<frame *Calendar* 0x559da2103a80>)] nil)
|   #f(compiled-function (x) #<bytecode -0x894a393e330e3db>)(([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]))
|   mapcar(#f(compiled-function (x) #<bytecode -0x894a393e330e3db>) (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
|   describe-key((([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
|   funcall-interactively(describe-key (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
|   call-interactively(describe-key nil nil)
|   command-execute(describe-key)


C-h k seems only a random command suffering from this issue.  I
discovered the problem while choosing a date from the calendar for
org-capture.  mouse-2 gives these errors while mouse-1 seems to work.

Oh, it seems the Calendar part is not even necessary, the only important
thing seems to be that you click with mouse-2 into a frame that doesn't
have focus.  That already gives the error.

TIA,

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 02 Dec 2022 20:19:43 +0100
> 
> | Debugger entered--Lisp error: (wrong-type-argument listp #<frame *Calendar* 0x559da2103a80>)
> |   posn-set-point(#<frame *Calendar* 0x559da2103a80>)
> |   help--analyze-key([(switch-frame #<frame *Calendar* 0x559da2103a80>)] [(switch-frame #<frame *Calendar* 0x559da2103a80>)] nil)
> |   #f(compiled-function (x) #<bytecode -0x894a393e330e3db>)(([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]))
> |   mapcar(#f(compiled-function (x) #<bytecode -0x894a393e330e3db>) (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> |   describe-key((([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> |   funcall-interactively(describe-key (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> |   call-interactively(describe-key nil nil)
> |   command-execute(describe-key)
> 
> 
> C-h k seems only a random command suffering from this issue.  I
> discovered the problem while choosing a date from the calendar for
> org-capture.  mouse-2 gives these errors while mouse-1 seems to work.
> 
> Oh, it seems the Calendar part is not even necessary, the only important
> thing seems to be that you click with mouse-2 into a frame that doesn't
> have focus.  That already gives the error.

These commands seem to be trying to process a switch-frame event, not a
mouse-2 click event.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> Cc: 59785@debbugs.gnu.org
> Date: Fri, 02 Dec 2022 21:53:57 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Fri, 02 Dec 2022 20:19:43 +0100
> > 
> > | Debugger entered--Lisp error: (wrong-type-argument listp #<frame *Calendar* 0x559da2103a80>)
> > |   posn-set-point(#<frame *Calendar* 0x559da2103a80>)
> > |   help--analyze-key([(switch-frame #<frame *Calendar* 0x559da2103a80>)] [(switch-frame #<frame *Calendar* 0x559da2103a80>)] nil)
> > |   #f(compiled-function (x) #<bytecode -0x894a393e330e3db>)(([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]))
> > |   mapcar(#f(compiled-function (x) #<bytecode -0x894a393e330e3db>) (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> > |   describe-key((([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> > |   funcall-interactively(describe-key (([(switch-frame #<frame *Calendar* 0x559da2103a80>)] . [(switch-frame #<frame *Calendar* 0x559da2103a80>)]) ([(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward] . [(down-mouse-2 (#<window 14 on *Calendar*> 366 (527 . 85) 206302283 nil 366 (58 . 4) nil (5 . 13) (9 . 18))) Scroll\ forward])))
> > |   call-interactively(describe-key nil nil)
> > |   command-execute(describe-key)
> > 
> > 
> > C-h k seems only a random command suffering from this issue.  I
> > discovered the problem while choosing a date from the calendar for
> > org-capture.  mouse-2 gives these errors while mouse-1 seems to work.
> > 
> > Oh, it seems the Calendar part is not even necessary, the only important
> > thing seems to be that you click with mouse-2 into a frame that doesn't
> > have focus.  That already gives the error.
> 
> These commands seem to be trying to process a switch-frame event, not a
> mouse-2 click event.

One possible solution is to make help--binding-undefined-p drop switch-frame
events.  Can you try that?

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > These commands seem to be trying to process a switch-frame event, not a
> > mouse-2 click event.

Could be.

> One possible solution is to make help--binding-undefined-p drop switch-frame
> events.  Can you try that?

(How?)

But I don't think this is specific to help at all.  So I guess this is
the wrong place to look for a fix, or at least not the only one.

What I did when I discovered the issue did not involve help: I tried to
select a date in the pop-up calendar for org-capture.  It's hard to get
a backtrace for that scenario, though, but I can retry if that would
help.

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It's hard to get a backtrace for that scenario, though, but I can
> retry if that would help.

Here is it:

| Debugger entered--Lisp error: (wrong-type-argument listp #<frame  *Minibuf-1*      micha@drachen 0x5581c2f1bf78>)
|   (posn-col-row #<frame  *Minibuf-1*      micha@drachen 0x5581c2f1bf78>)
|   (#f(compiled-function () #<bytecode -0x1fa7ba0046068077>))
|   (internal--track-mouse #f(compiled-function () #<bytecode -0x1fa7ba0046068077>))
|   (mouse-drag-drag (down-mouse-2 (#<window 16 on *Calendar*> 317 (128 . 128) 6738998 nil 317 (9 . 4) nil (2 . 16) (14 . 28))))
|   (funcall-interactively mouse-drag-drag (down-mouse-2 (#<window 16 on *Calendar*> 317 (128 . 128) 6738998 nil 317 (9 . 4) nil (2 . 16) (14 . 28))))
|   (call-interactively mouse-drag-drag nil nil)
|   (command-execute mouse-drag-drag)
|   (#<subr read-string> "Date+time [2022-12-03]: " nil org-read-date-history nil nil)
|   (my-read-string--default-in-prompt-around-ad #<subr read-string> "Date+time [2022-12-03]: " nil org-read-date-history nil)
|   (apply my-read-string--default-in-prompt-around-ad #<subr read-string> ("Date+time [2022-12-03]: " nil org-read-date-history nil))
|   (read-string "Date+time [2022-12-03]: " nil org-read-date-history nil)
|   (org-read-date nil t nil nil)
|   (org-capture-fill-template)
|   (#f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0xbb89e6d6aa8f2f>) nil)
|   (apply #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0xbb89e6d6aa8f2f>) nil)
|   (my-org-capture--around-ad #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0xbb89e6d6aa8f2f>) nil)
|   (apply my-org-capture--around-ad #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0xbb89e6d6aa8f2f>) nil)
|   (org-capture nil)
|   (funcall-interactively org-capture nil)
|   (call-interactively org-capture nil nil)
|   (command-execute org-capture)

For that to happen the calendar must be in a different frame (different
from the one from where the command had been invoked and where the
active minibuffer is prompting).

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 12:58:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > These commands seem to be trying to process a switch-frame event, not a
> > > mouse-2 click event.
> 
> Could be.
> 
> > One possible solution is to make help--binding-undefined-p drop switch-frame
> > events.  Can you try that?
> 
> (How?)

By adding the switch-frame event to the condition in that function.  If this
is not sufficient to explain my intent, please ask more specific questions.

> But I don't think this is specific to help at all.  So I guess this is
> the wrong place to look for a fix, or at least not the only one.

If I'm right, and the problem is that we feed the switch-frame event to
functions that don't expect it, then I'm not sure I understand what
alternative you have in mind.  Low-level code which delivers the events
cannot possibly know whether the application expects to see switch-frame
events or not and whether it is prepared to deal with such events.  So it
cannot filter them out.

Or maybe I'm missing something here.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 13:04:18 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > It's hard to get a backtrace for that scenario, though, but I can
> > retry if that would help.
> 
> Here is it:
> 
> | Debugger entered--Lisp error: (wrong-type-argument listp #<frame  *Minibuf-1*      micha@drachen 0x5581c2f1bf78>)
> |   (posn-col-row #<frame  *Minibuf-1*      micha@drachen 0x5581c2f1bf78>)
> |   (#f(compiled-function () #<bytecode -0x1fa7ba0046068077>))
> |   (internal--track-mouse #f(compiled-function () #<bytecode -0x1fa7ba0046068077>))
> |   (mouse-drag-drag (down-mouse-2 (#<window 16 on *Calendar*> 317 (128 . 128) 6738998 nil 317 (9 . 4) nil (2 . 16) (14 . 28))))

Does the below fix this problem, per chance?

diff --git a/lisp/subr.el b/lisp/subr.el
index 21f4309..dc219a4 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -1729,7 +1729,7 @@ posn-col-row
      ((eq area 'horizontal-scroll-bar)
       (cons (scroll-bar-scale pair (window-width window)) 0))
      (t
-      (if use-window
+      (if (and (windowp frame-or-window) use-window)
           (cons (/ (car pair) (window-font-width window))
                 (/ (cdr pair) (window-font-height window)))
         ;; FIXME: This should take line-spacing properties on

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Or maybe I'm missing something here.

You missed that my knowledge in this field is inferior.  Sending me
diffs for me to test is better.

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does the below fix this problem, per chance?
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 21f4309..dc219a4 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -1729,7 +1729,7 @@ posn-col-row
>       ((eq area 'horizontal-scroll-bar)
>        (cons (scroll-bar-scale pair (window-width window)) 0))
>       (t
> -      (if use-window
> +      (if (and (windowp frame-or-window) use-window)
>            (cons (/ (car pair) (window-font-width window))
>                  (/ (cdr pair) (window-font-height window)))
>          ;; FIXME: This should take line-spacing properties on

Half: it improves the behavior but I still get the error.  The
improvement is that I can successfully select a date in the calendar
despite the error - that was not possible without that change.  So I
guess the error now happens at some other place, and this was not the
root, or not the only root.

I also tested this:

modified   lisp/mouse-drag.el
@@ -287,8 +287,10 @@ mouse-drag-drag
       (while (progn
 	       (setq event (read--potential-mouse-event)
 		     end (event-end event)
-		     row (cdr (posn-col-row end))
-		     col (car (posn-col-row end)))
+		     row (and (not (eq (car-safe event) 'switch-frame))
+                              (cdr (posn-col-row end)))
+		     col (and (not (eq (car-safe event) 'switch-frame))
+                              (car (posn-col-row end))))
 	       (or (mouse-movement-p event)
 		   (eq (car-safe event) 'switch-frame)))
 	;; Scroll if see if we're on the edge.

It actually had the exact same effect.

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

On December 3, 2022 5:07:53 PM GMT+02:00, Michael Heerdegen <michael_heerdegen@web.de> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does the below fix this problem, per chance?
> >
> > diff --git a/lisp/subr.el b/lisp/subr.el
> > index 21f4309..dc219a4 100644
> > --- a/lisp/subr.el
> > +++ b/lisp/subr.el
> > @@ -1729,7 +1729,7 @@ posn-col-row
> >       ((eq area 'horizontal-scroll-bar)
> >        (cons (scroll-bar-scale pair (window-width window)) 0))
> >       (t
> > -      (if use-window
> > +      (if (and (windowp frame-or-window) use-window)
> >            (cons (/ (car pair) (window-font-width window))
> >                  (/ (cdr pair) (window-font-height window)))
> >          ;; FIXME: This should take line-spacing properties on
> 
> Half: it improves the behavior but I still get the error.  The
> improvement is that I can successfully select a date in the calendar
> despite the error - that was not possible without that change.  So I
> guess the error now happens at some other place, and this was not the
> root, or not the only root.
> 
> I also tested this:
> 
> modified   lisp/mouse-drag.el
> @@ -287,8 +287,10 @@ mouse-drag-drag
>        (while (progn
>  	       (setq event (read--potential-mouse-event)
>  		     end (event-end event)
> -		     row (cdr (posn-col-row end))
> -		     col (car (posn-col-row end)))
> +		     row (and (not (eq (car-safe event) 'switch-frame))
> +                              (cdr (posn-col-row end)))
> +		     col (and (not (eq (car-safe event) 'switch-frame))
> +                              (car (posn-col-row end))))
>  	       (or (mouse-movement-p event)
>  		   (eq (car-safe event) 'switch-frame)))
>  	;; Scroll if see if we're on the edge.
> 
> It actually had the exact same effect.
> 
> Michael.
> 

Do you get the exact same error and the same backtrace?  If the backtrace is different, please post it.

Thanks.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Do you get the exact same error and the same backtrace?  If the
> backtrace is different, please post it.

I got the org-capture issue suppressed by doing this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: drag.diff --]
[-- Type: text/x-diff, Size: 3336 bytes --]

*** /tmp/ediffrfOigd	2022-12-03 18:09:46.243866776 +0100
--- /home/micha/software/emacs/lisp/mouse-drag.el	2022-12-03 18:02:14.743207682 +0100
***************
*** 283,316 ****
  	  window-last-col (- (window-width) 2))
      (track-mouse
        ;; Set 'track-mouse' to something neither nil nor t (Bug#51794).
!       (setq track-mouse 'drag-dragging)
!       (while (progn
! 	       (setq event (read--potential-mouse-event)
! 		     end (event-end event)
! 		     row (cdr (posn-col-row end))
! 		     col (car (posn-col-row end)))
! 	       (or (mouse-movement-p event)
! 		   (eq (car-safe event) 'switch-frame)))
! 	;; Scroll if see if we're on the edge.
! 	;; FIXME: should handle mouse-in-other window.
! 	(cond
! 	 ((not (eq start-window (posn-window end)))
! 	  t) ; wait for return to original window
! 	 ((<= row 0) (mouse-drag-repeatedly-safe-scroll -1 0))
! 	 ((>= row window-last-row) (mouse-drag-repeatedly-safe-scroll 1 0))
! 	 ((and col-scrolling-p (<= col 1)) (mouse-drag-repeatedly-safe-scroll 0 -1))
! 	 ((and col-scrolling-p (>= col window-last-col)) (mouse-drag-repeatedly-safe-scroll 0 1))
! 	 (t
! 	  (setq scroll-delta (- row start-row)
! 		start-row row)
! 	  (if col-scrolling-p
! 	      (setq scroll-col-delta (- col start-col)
! 		    start-col col))
! 	  (if (or (/= 0 scroll-delta)
! 		  (/= 0 scroll-col-delta))
! 	      (progn
! 		(setq have-scrolled t)
! 		(mouse-drag-safe-scroll scroll-delta scroll-col-delta)))))))
      ;; If it was a click and not a drag, prepare to pass the event on.
      ;; Is there a more correct way to reconstruct the event?
      (if (and (not have-scrolled)
--- 283,319 ----
  	  window-last-col (- (window-width) 2))
      (track-mouse
        ;; Set 'track-mouse' to something neither nil nor t (Bug#51794).
!        (setq track-mouse 'drag-dragging)
!        (while (progn
! 	        (setq event (read--potential-mouse-event)
! 		      end (event-end event)
! 		      row (and (not (eq (car-safe event) 'switch-frame))
!                                (cdr (posn-col-row end)))
! 		      col (and (not (eq (car-safe event) 'switch-frame))
!                                (car (posn-col-row end))))
!                 (or (mouse-movement-p event)
! 		    (eq (car-safe event) 'switch-frame)))
! 	 ;; Scroll if see if we're on the edge.
! 	 ;; FIXME: should handle mouse-in-other window.
! 	 (cond
!           ((eq (car-safe event) 'switch-frame))
! 	  ((not (eq start-window (posn-window end)))
! 	   t) ; wait for return to original window
! 	  ((<= row 0) (mouse-drag-repeatedly-safe-scroll -1 0))
! 	  ((>= row window-last-row) (mouse-drag-repeatedly-safe-scroll 1 0))
! 	  ((and col-scrolling-p (<= col 1)) (mouse-drag-repeatedly-safe-scroll 0 -1))
! 	  ((and col-scrolling-p (>= col window-last-col)) (mouse-drag-repeatedly-safe-scroll 0 1))
! 	  (t
! 	   (setq scroll-delta (- row start-row)
! 		 start-row row)
! 	   (if col-scrolling-p
! 	       (setq scroll-col-delta (- col start-col)
! 		     start-col col))
! 	   (if (or (/= 0 scroll-delta)
! 		   (/= 0 scroll-col-delta))
! 	       (progn
! 		 (setq have-scrolled t)
! 		 (mouse-drag-safe-scroll scroll-delta scroll-col-delta)))))))
      ;; If it was a click and not a drag, prepare to pass the event on.
      ;; Is there a more correct way to reconstruct the event?
      (if (and (not have-scrolled)

[-- Attachment #3: Type: text/plain, Size: 1199 bytes --]


With that the issue is gone.

The help related problem seems to be different indeed, and is not fixed
by the above, or by your change.  I don't get a different backtrace as
before.  And AFAIU changing `help--binding-undefined-p' is not enough:
the call is wrapped around the code that errors.  I didn't try it but
verified with the tracer that it is not called before the error occurs
(i.e., it's never called due to the error), and reading the code also
suggests that this is too simple.

I don't know the logic of this code so I don't want to propose a
patch.  It seems we must filter out that event but at some other place.

I'm not sure if your change in subr.el had an effect or it was an
illusion, maybe the effect differs each time, depending if I move the
mouse while clicking or whatever.  I don't understand why it should have
an effect.  Maybe it catched something happening later, dunno.  Could
retry if you think it's worth it.

Ok, so we have now different scenarios and different proposed cures.
What concretely would help further?  Did you try to reproduce the
problem btw?  I don't feel like I'm the best choice to work on this, I
do know only partially what I am doing.

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I'm not sure if your change in subr.el had an effect or it was an
> illusion, maybe the effect differs each time, depending if I move the
> mouse while clicking or whatever.

I checked again and: no, your change in subr.el has neither an effect in
behavior nor do I get a different backtrace.

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 18:22:22 +0100
> 
> Ok, so we have now different scenarios and different proposed cures.
> What concretely would help further?

I still don't think I have the answer to my question: was the backtrace
exactly the same with the patch I sent, or was it different?  I'm asking
about the org-capture case, not about the "C-h k" case.  It is important for
me to know whether the patch I sent solves part of the problem or nothing at
all.

> Did you try to reproduce the problem btw?

I can reproduce the "C-h k" case, which is why I'm asking about the other
one.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 18:53:07 +0100
> 
> I checked again and: no, your change in subr.el has neither an effect in
> behavior nor do I get a different backtrace.

OK, thanks.  Back to the drawing board...

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 20:17:28 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: 59785@debbugs.gnu.org
> > Date: Sat, 03 Dec 2022 18:53:07 +0100
> > 
> > I checked again and: no, your change in subr.el has neither an effect in
> > behavior nor do I get a different backtrace.
> 
> OK, thanks.  Back to the drawing board...

Is it possible for you to see whether the org-capture case worked okay in
Emacs 28?

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I still don't think I have the answer to my question: was the backtrace
> exactly the same with the patch I sent, or was it different?  I'm asking
> about the org-capture case, not about the "C-h k" case.  It is important for
> me to know whether the patch I sent solves part of the problem or nothing at
> all.

You should have been clearer what case you are interested in.

But I answered it: no difference.  The backtraces look exactly the same,
apart from details (depending on where I clicked).

AFAIU, in the case of the error your change doesn't make a difference
because the argument is a frame, not a window (last call below, these
are all calls to the function done in one reproduction of the recipe):

| 1 -> (posn-col-row (#<window 26 on *Calendar*> 419 ... 31213232 nil 419 ... nil ... ...)) 19:48:18.661
|   (mouse-drag-drag (down-mouse-2 (#<window 26 on *Calendar*> 419 (478 . 158) 31213232 nil 419 (34 . 5) nil (2 . 18) (14 . 28))))
|   (command-execute mouse-drag-drag)
|   (my-read-string--default-in-prompt-around-ad #<subr read-string> "Date+time [2022-12-03]: " nil org-read-date-history nil)
|   (org-read-date nil t nil nil)
|   (org-capture-fill-template)
|   (my-org-capture--around-ad #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0x1e2ea2230cf83a5>) nil)
|   (org-capture nil)
|   (command-execute org-capture)
| 1 <- posn-col-row: (34 . 5)
| 1 -> (posn-col-row (#<window 26 on *Calendar*> 419 ... 31213232 nil 419 ... nil ... ...)) 19:48:19.087
|   (mouse-drag-drag (down-mouse-2 (#<window 26 on *Calendar*> 419 (478 . 158) 31213232 nil 419 (34 . 5) nil (2 . 18) (14 . 28))))
|   (command-execute mouse-drag-drag)
|   (my-read-string--default-in-prompt-around-ad #<subr read-string> "Date+time [2022-12-03]: " nil org-read-date-history nil)
|   (org-read-date nil t nil nil)
|   (org-capture-fill-template)
|   (my-org-capture--around-ad #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0x1e2ea2230cf83a5>) nil)
|   (org-capture nil)
|   (command-execute org-capture)
| 1 <- posn-col-row: (34 . 5)
| 1 -> (posn-col-row #<frame  *Minibuf-1*      micha@drachen 0x56052a407bd8>) 19:48:19.161
|   (mouse-drag-drag (down-mouse-2 (#<window 26 on *Calendar*> 419 (478 . 158) 31213232 nil 419 (34 . 5) nil (2 . 18) (14 . 28))))
|   (command-execute mouse-drag-drag)
|   (my-read-string--default-in-prompt-around-ad #<subr read-string> "Date+time [2022-12-03]: " nil org-read-date-history nil)
|   (org-read-date nil t nil nil)
|   (org-capture-fill-template)
|   (my-org-capture--around-ad #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode -0x1e2ea2230cf83a5>) nil)
|   (org-capture nil)
|   (command-execute org-capture)
| 1 <- posn-col-row: !non-local\ exit!


Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 19:54:04 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I still don't think I have the answer to my question: was the backtrace
> > exactly the same with the patch I sent, or was it different?  I'm asking
> > about the org-capture case, not about the "C-h k" case.  It is important for
> > me to know whether the patch I sent solves part of the problem or nothing at
> > all.
> 
> You should have been clearer what case you are interested in.

Sorry I wasn't more clear.

Can you tell how to reproduce the org-capture case?  Is it feasible to
reproduce it from "emacs -Q"?

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is it possible for you to see whether the org-capture case worked okay
> in Emacs 28?

I have 27.  Would that suffice?

But I see now that this org-capture case depends on something in my
config that's not clear to me: I can't reproduce it in a master emacs
-Q.  I don't even have a recipe for emacs -Q for this case.  I didn't
check until now because originally I thought it would be the same as the
C-h k case.

I tried this:

#+begin_src emacs-lisp
(require 'org)

(require 'calendar)

(setq org-read-date-popup-calendar t)

(define-key calendar-mode-map [down-mouse-2] nil)

(setq calendar-setup 'calendar-only)

(org-read-date)
#+end_src

[ Org is missing to unbind down-mouse-2 in the calendar buffer to make
the mouse-2 button work, but this seems unrelated to the issue ]

I tried to load anything that seemed related but the issue is not
reproducible so far :-(


Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I tried to load anything that seemed related but the issue is not
> reproducible so far :-(

OTOH, binding mouse-2 to #'ignore in calendar-mode-map fixes the issue
in my configured Emacs.  That still doesn't explain why I don't need to
do this in emacs -Q, but... do you think it is still worth to
investigate further?


Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 20:46:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is it possible for you to see whether the org-capture case worked okay
> > in Emacs 28?
> 
> I have 27.  Would that suffice?

It's better than nothing.  I want to know if this problem happens because of
recent changes in various posn-* functions.  It will help me identify the
culprit if there is one (as opposed to if this is an old problem that no one
bothered to report).

> I tried to load anything that seemed related but the issue is not
> reproducible so far :-(

Too bad.  I'd like to have a way of reproducing this here, because I have
difficulty understanding the data and backtraces you posted.  Specifically,
I don't understand which code signals an error, what data triggers that, and
how the data which triggers the error is related to the switch-frame event
in the first place.

The "C-h k" case should be already fixed (by "other means"), so it cannot
help me anymore.  In any case, these two cases only share one thing in
common: that the switch-frame event was delivered to functions that didn't
expect it.  Everything else is different.

So if you cannot reproduce the org-capture case in "emacs -Q", perhaps some
other recipe which causes the same backtrace can be reproduced?

Thanks.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 21:19:42 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > I tried to load anything that seemed related but the issue is not
> > reproducible so far :-(
> 
> OTOH, binding mouse-2 to #'ignore in calendar-mode-map fixes the issue
> in my configured Emacs.  That still doesn't explain why I don't need to
> do this in emacs -Q, but... do you think it is still worth to
> investigate further?

See my other message about this, I think it answers the above question as
well.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So if you cannot reproduce the org-capture case in "emacs -Q", perhaps
> some other recipe which causes the same backtrace can be reproduced?

I tried all day and we are lucky, I finally found a recipe for emacs -Q,
and it seems indeed to be a regression from at least 27.1:

#+begin_src emacs-lisp
  (require 'org)
  (require 'calendar)

  (setq org-read-date-popup-calendar t)
  (setq calendar-setup 'calendar-only)

  ;; my probably a bit non-standard setup:
  (global-set-key [down-mouse-2] #'mouse-drag-drag)
  (define-key calendar-mode-map [down-mouse-2] nil)

  (setq debug-on-error t)
  ;; this is only to allow to switch to the
  ;; Debugger despite of the active minibuffer
  (setq enable-recursive-minibuffers t)

  ;; Now select a date with mouse-2 in the calendar after
  ;; evaluating this:
  (org-read-date)
  ;; then switch to the debugger buffer (e.g. with C-x C-b)
#+end_src

This gives me:

| Debugger entered--Lisp error: (wrong-type-argument listp #<frame  *Minibuf-1* 0x56442ad52540>)
|   posn-col-row(#<frame  *Minibuf-1* 0x56442ad52540>)
|   #f(compiled-function () #<bytecode -0x1fa7ba0046068077>)()
|   internal--track-mouse(#f(compiled-function () #<bytecode -0x1fa7ba0046068077>))
|   mouse-drag-drag((down-mouse-2 (#<window 8 on *Calendar*> 499 (334 . 123) 89797497 nil 499 (37 . 6) nil (1 . 15) (9 . 18))))
|   funcall-interactively(mouse-drag-drag (down-mouse-2 (#<window 8 on *Calendar*> 499 (334 . 123) 89797497 nil 499 (37 . 6) nil (1 . 15) (9 . 18))))
|   call-interactively(mouse-drag-drag nil nil)
|   command-execute(mouse-drag-drag)
|   read-string("Date+time [2022-12-04]: " nil org-read-date-history nil)
|   org-read-date()
|   eval-buffer()  ; Reading at buffer position 677
|   funcall-interactively(eval-buffer)
|   call-interactively(eval-buffer record nil)
|   command-execute(eval-buffer record)
|   execute-extended-command(nil "eval-buffer" "eval-buffer")
|   funcall-interactively(execute-extended-command nil "eval-buffer" "eval-buffer")
|   call-interactively(execute-extended-command nil nil)
|   command-execute(execute-extended-command)


Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Sun, 04 Dec 2022 23:03:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So if you cannot reproduce the org-capture case in "emacs -Q", perhaps
> > some other recipe which causes the same backtrace can be reproduced?
> 
> I tried all day and we are lucky, I finally found a recipe for emacs -Q,
> and it seems indeed to be a regression from at least 27.1:
> 
> #+begin_src emacs-lisp
>   (require 'org)
>   (require 'calendar)
> 
>   (setq org-read-date-popup-calendar t)
>   (setq calendar-setup 'calendar-only)
> 
>   ;; my probably a bit non-standard setup:
>   (global-set-key [down-mouse-2] #'mouse-drag-drag)
>   (define-key calendar-mode-map [down-mouse-2] nil)
> 
>   (setq debug-on-error t)
>   ;; this is only to allow to switch to the
>   ;; Debugger despite of the active minibuffer
>   (setq enable-recursive-minibuffers t)
> 
>   ;; Now select a date with mouse-2 in the calendar after
>   ;; evaluating this:
>   (org-read-date)
>   ;; then switch to the debugger buffer (e.g. with C-x C-b)
> #+end_src

Thanks, this helped a lot.  Please try the patch below; it seems to work
here, and doesn't break the mouse-drag-drag feature (which was my TIL
moment, although it exists since Emacs 20...):

diff --git a/lisp/mouse-drag.el b/lisp/mouse-drag.el
index f515cc8..1665bd1 100644
--- a/lisp/mouse-drag.el
+++ b/lisp/mouse-drag.el
@@ -275,6 +275,7 @@ mouse-drag-drag
 	 have-scrolled
 	 window-last-row
 	 col window-last-col
+         switch-frame-p
 	 (scroll-col-delta 0)
 	 ;; be conservative about allowing horizontal scrolling
 	 (col-scrolling-p (mouse-drag-should-do-col-scrolling)))
@@ -286,15 +287,16 @@ mouse-drag-drag
       (setq track-mouse 'drag-dragging)
       (while (progn
 	       (setq event (read--potential-mouse-event)
-		     end (event-end event)
-		     row (cdr (posn-col-row end))
-		     col (car (posn-col-row end)))
-	       (or (mouse-movement-p event)
-		   (eq (car-safe event) 'switch-frame)))
+                     switch-frame-p (eq (car-safe event) 'switch-frame))
+               (or switch-frame-p
+                   (setq end (event-end event)
+		         row (cdr (posn-col-row end))
+		         col (car (posn-col-row end))))
+	       (or (mouse-movement-p event) switch-frame-p))
 	;; Scroll if see if we're on the edge.
 	;; FIXME: should handle mouse-in-other window.
 	(cond
-	 ((not (eq start-window (posn-window end)))
+	 ((or switch-frame-p (not (eq start-window (posn-window end))))
 	  t) ; wait for return to original window
 	 ((<= row 0) (mouse-drag-repeatedly-safe-scroll -1 0))
 	 ((>= row window-last-row) (mouse-drag-repeatedly-safe-scroll 1 0))

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please try the patch below; it seems to work here, and doesn't break
> the mouse-drag-drag feature (which was my TIL moment, although it
> exists since Emacs 20...)

Yes, works for me too, and it also fixes my original org-capture issue
with my config stuff loaded.

Very nice.  It is very satisfying that this ends with a tangible result.


Thanks,

Michael.

bug#59785: 30.0.50; mouse-2 > (wrong-type-argument listp #<frame *Calendar* 0x...>)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 59785@debbugs.gnu.org
> Date: Mon, 05 Dec 2022 20:15:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please try the patch below; it seems to work here, and doesn't break
> > the mouse-drag-drag feature (which was my TIL moment, although it
> > exists since Emacs 20...)
> 
> Yes, works for me too, and it also fixes my original org-capture issue
> with my config stuff loaded.
> 
> Very nice.  It is very satisfying that this ends with a tangible result.

Yes.

Thanks for testing, I've now installed the fix, and closing the bug.