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

[martin rudalics <rudalics@gmx.at>]

 > I've put in a request. I'll write back when I've received and returned
 > the form.

Thanks.  It usually takes some time and it might be a good idea to
complain after a few weeks in order to speed things up.

 >> `posnp' also looks strange in this regard.
 >>
 >
 > It does indeed, and I added a line to check for frames.

No - this might be dangerous for now.  Suppose we have callers that
relied on `posnp' to return nil in that case.  They would all of sudden
have to deal with the fact that they get a frame now, so more or less we
could reintroduce the problem you try to fix presently.  Please take
this out for the moment but state in the doc-string that `posnp' returns
nil if the first element of OBJ is a frame.  Later on we can change this
as you did and see what happens.

 > That said, I don't *think* it's ever possible in practice to change the
 > selected frame in the middle of a drag event through user interaction
 > alone -- either implicitly or by a keypress bound to `other-frame'. I'm
 > basing this on having just tried it in several window systems on both OS
 > X and BSD, including with focus-follows-mouse behavior enabled (and with
 > the corresponding Emacs variable turned on). I was only able to test it
 > by means of an event-reading loop which programmatically called
 > `other-frame' after every down-mouse event.

Fine.  I suppose it would defeat the purpose of mouse dragging if the
selected frame could ever change in between but wanted to make sure.
Here I was not able to produce a frame select event either.

 > Come to think of it, this is wrong either way, because the implication
 > of "the frame with input focus" is the frame with input focus at the
 > time of evaluation, whereas the position list reflects the state at the
 > time it was generated.
 >
 > How about: "If @var{position} represents a location outside the frame
 > where the event was initiated, [...]"

Good.

 >> (frame-selected-window frame)
 >>
 >> sounds more accurate, given what I said about the selected frame above.
 >
 > I haven't changed these lines except for taking them out of a
 > now-superfluous let*, but I agree that they look wrong. (Technically
 > `window' is either the window from the position list or nil. If it is
 > nil, though, `window-buffer' does return the buffer of the selected
 > window. The calculation should be made w/r/t the selected window of the
 > position list's frame, so I'll make that change.)

OK.  Given your observations above it should not matter.

 >>> diff --git a/lisp/textmodes/artist.el b/lisp/textmodes/artist.el
 >>
 >> I didn't look into these but just trust your experience here.
 >
 > This one looks like a major change because of all the diffed lines, but
 > that's just due to adding an extra layer of indentation. The only
 > semantic change is wrapping the `track-mouse' form in an `unwind-protect'.

Ahh.  I didn't notice.  In that case we could commit your patch as a
tiny change.

 > Here's the revised patch.

Looks good.  Please fix the `posnp' thingy I mentioned above, add some
ChangeLog entries and resend the patch as an attachment. If there are no
objections I'll commit it then to the emacs-24 branch.

Thanks, martin