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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 6130 <at> debbugs.gnu.org, busk <busk <at> lysator.liu.se>, Daniel Koning <dk <at> danielkoning.com>
Subject: bug#6130: 23.1; artist-mode spray-can malfunction
Date: Thu, 22 Jan 2015 12:02:09 -0500

>> The Right Thing to do, AFAICT, is for posnp to return non-nil also when
>> the `car' is a frame.
> If the caller of `posnp' is not prepared to deal with a frame but used
> `posnp' to check that the position is "valid", it currently will not
> fail.

Yes, I understand.  We can't always Do The Right Thing.  But that's
still The Right Thing.

> `posnp'.  So at least for Emacs 24.5 I would rather not change the
> current behavior.

That's for sure, yes.

> I would change it for Emacs 25.

We violently agree.

>> For posn-window, the question is more tricky.  I don't think it should
>> ever return a frame, since its name makes it clear it returns a window.
> Agreed.  But `posn-window' is just a mnemonic for "get me the first
> element of a position".

Could you take a look at the existing callers to see how they would
react to receiving nil (instead of a frame), or a frame (as now), or an
error (instead of a frame)?

>> So we should either make it return nil when the car is a frame, or
>> signal an error, or return the frame's selected-window,
> The latter would be certainly wrong.  We are NOT in that window.

Indeed.

>> and/or deprecate it (in favor of a new posn-window-or-frame).
> That's what I had in mind.

But that only makes sense if most callers of posn-window can (or would
like to) also handle a frame.


        Stefan

Previous Next

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