[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6130: 23.1; artist-mode spray-can malfunction
From: |
Eli Zaretskii |
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@gmx.at>
> Cc: 6130@debbugs.gnu.org, busk <busk@lysator.liu.se>,
> Daniel Koning <dk@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.
- bug#6130: 23.1; artist-mode spray-can malfunction, (continued)
- bug#6130: 23.1; artist-mode spray-can malfunction, Daniel Koning, 2015/01/18
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/18
- bug#6130: 23.1; artist-mode spray-can malfunction, Daniel Koning, 2015/01/20
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/21
- bug#6130: 23.1; artist-mode spray-can malfunction, Stefan Monnier, 2015/01/21
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/21
- bug#6130: 23.1; artist-mode spray-can malfunction, Stefan Monnier, 2015/01/22
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/22
- bug#6130: 23.1; artist-mode spray-can malfunction, Stefan Monnier, 2015/01/22
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/23
- bug#6130: 23.1; artist-mode spray-can malfunction,
Eli Zaretskii <=
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/23
- bug#6130: 23.1; artist-mode spray-can malfunction, Stefan Monnier, 2015/01/23
- bug#6130: 23.1; artist-mode spray-can malfunction, Eli Zaretskii, 2015/01/23
- bug#6130: 23.1; artist-mode spray-can malfunction, Daniel Koning, 2015/01/23
- bug#6130: 23.1; artist-mode spray-can malfunction, Eli Zaretskii, 2015/01/24
- bug#6130: 23.1; artist-mode spray-can malfunction, martin rudalics, 2015/01/24
- bug#6130: 23.1; artist-mode spray-can malfunction, Eli Zaretskii, 2015/01/24