GNU bug report logs - #6130
23.1; artist-mode spray-can malfunction

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 6130 <at> debbugs.gnu.org, busk <at> lysator.liu.se, monnier <at> iro.umontreal.ca, dk <at> danielkoning.com
Subject: bug#6130: 23.1; artist-mode spray-can malfunction
Date: Fri, 23 Jan 2015 11:43:08 +0200

> Date: Fri, 23 Jan 2015 09:26:56 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 6130 <at> debbugs.gnu.org, busk <busk <at> lysator.liu.se>,
> 	Daniel Koning <dk <at> danielkoning.com>
> 
>  > So are there callers that
>  > actually rely on this wrong behavior?  Are there callers where returning
>  > nil instead of a frame would be a problem?  Are there callers where
>  > signaling an error instead of returning a frame would be a problem?
> 
> `handle-delete-frame' seems to be the only function that expects
> `posn-window' to return a frame (unconditionally, BTW).

It's not the only one, AFAICS.  Any function that calls x-popup-menu
with a position constructed from what posn-window returns also depends
on that, albeit indirectly.  See, for example, mouse-select-buffer in
msb.el and popup-menu-normalize-position in menu-bar.el.

Other functions provide useful features based on this "misfeature".
One is handle-delete-frame already mentioned above; in that case, the
mouse click that deletes the frame is always on the frame, not on any
window.  Another user of this is mouse-buffer-menu in mouse.el.

> I don't understand `handle-delete-frame' but it hardly will cause
> problems when it gets nil or an error.

??? How can this support deleting a frame by clicking on some of the
frame's decorations?

>  > That's OK, in the sense that we don't care if people's feelings
>  > are hurt.  But if it breaks existing packages it's more problematic.

It sounds like it's the latter.

According to my grepping, most users of posn-window pass the result to
select-window or with-selected-window or window-buffer, and will
certainly bomb if the object is not a window.  Some of them presumably
already hit this problem, because they defend themselves against such
a calamity (example: dframe.el).

Btw, I'm not sure I understand why you said:

>  > It's wrong for posn-window to return a frame.

Can you explain why it's wrong?  If this is just about insufficient
documentation and people's surprise when they see a frame coming out
of that, then we could improve the docs.

Previous Next

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