From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se, dk@danielkoning.com
Subject: bug#6130: 23.1; artist-mode spray-can malfunction
Date: Fri, 23 Jan 2015 11:43:08 +0200 [thread overview]
Message-ID: <83mw59u91v.fsf@gnu.org> (raw)
In-Reply-To: <54C205D0.3000607@gmx.at>
> 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.
next prev parent reply other threads:[~2015-01-23 9:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 12:17 bug#6130: 23.1; artist-mode spray-can malfunction busk
2015-01-17 5:25 ` Daniel Koning
2015-01-17 13:56 ` martin rudalics
2015-01-18 5:47 ` Daniel Koning
2015-01-18 9:57 ` martin rudalics
2015-01-21 0:26 ` Daniel Koning
2015-01-21 8:22 ` martin rudalics
2015-01-21 15:22 ` Stefan Monnier
2015-01-21 16:54 ` martin rudalics
2015-01-22 17:02 ` Stefan Monnier
2015-01-22 18:23 ` martin rudalics
2015-01-22 23:08 ` Stefan Monnier
2015-01-23 8:26 ` martin rudalics
2015-01-23 9:43 ` Eli Zaretskii [this message]
2015-01-23 16:54 ` martin rudalics
2015-01-23 21:05 ` Stefan Monnier
2015-01-23 21:26 ` Eli Zaretskii
2015-01-23 21:52 ` Daniel Koning
2015-01-24 8:12 ` Eli Zaretskii
2015-01-24 9:08 ` martin rudalics
2015-01-24 9:49 ` Eli Zaretskii
2016-04-06 9:17 ` Johan Busk Eriksson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83mw59u91v.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=6130@debbugs.gnu.org \
--cc=busk@lysator.liu.se \
--cc=dk@danielkoning.com \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).