bug#6130: 23.1; artist-mode spray-can malfunction

[martin rudalics <rudalics@gmx.at>]

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

Yes.  In these cases we'd probably pop up the menu at a position
calculated from the upper left corner of the selected window.

 > See, for example, mouse-select-buffer in
 > msb.el and popup-menu-normalize-position in menu-bar.el.

IIUC `popup-menu-normalize-position' relies on `posnp' so it would
already fail now with a frame.

 > 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 suppose that

       (select-window
        (if (framep window) (frame-selected-window window)
          window))

would select the `frame-selected-window' of the selected frame.

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

It wouldn't.  We'd have to use `posn-frame' here.  But I fail to
understand what happens when we call this with a window in EVENT.  Or
don't we ever?

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

We've hidden the semantics of this function from the users for very long
time.  It's not easy to get out of this situation without compromises.

martin