From debbugs-submit-bounces@debbugs.gnu.org Fri May 07 09:24:21 2010 Received: (at submit) by debbugs.gnu.org; 7 May 2010 13:24:21 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OANXQ-0006p2-AI for submit@debbugs.gnu.org; Fri, 07 May 2010 09:24:21 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OANRx-0006ld-KM for submit@debbugs.gnu.org; Fri, 07 May 2010 09:18:42 -0400 Received: from lists.gnu.org ([199.232.76.165]:58201) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OANRv-0004No-7G for submit@debbugs.gnu.org; Fri, 07 May 2010 09:18:39 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OANRt-0005TY-Fe for bug-gnu-emacs@gnu.org; Fri, 07 May 2010 09:18:37 -0400 Received: from [140.186.70.92] (port=58329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OANRp-0003vL-Em for bug-gnu-emacs@gnu.org; Fri, 07 May 2010 09:18:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OAMUV-0004Ww-2k for bug-gnu-emacs@gnu.org; Fri, 07 May 2010 08:17:17 -0400 Received: from mail.lysator.liu.se ([130.236.254.3]:58688) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OAMUU-0004WJ-PB for bug-gnu-emacs@gnu.org; Fri, 07 May 2010 08:17:15 -0400 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D3E104000B for ; Fri, 7 May 2010 14:17:11 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id C39A440080; Fri, 7 May 2010 14:17:11 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.lysator.liu.se (Postfix) with ESMTP id 6617C4000B for ; Fri, 7 May 2010 14:17:11 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 07 May 2010 14:17:11 +0200 From: busk To: bug-gnu-emacs@gnu.org Subject: 23.1; artist-mode spray-can malfunction Message-ID: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> X-Sender: busk@lysator.liu.se User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 07 May 2010 09:24:19 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) I get a malfunction with the artist-mode spray-can when my drawing goes "over" the borders of the frame, which manifests itself thusly: It doesn't stop drawing on that particular are, but rather keeps filling #'s in an area where I drawed until emacs is killed. "Activating" another frame belonging to the same emacs process moves the behaviour to that frame. Activating the mini-buffer makes it draw in the minibuffer. Confirmed this on three different machines with different releases of the ubuntu gnu/linux distribution and three different releases of emacs (22.2.1, 23.1.1 and 23.1.50), and this misbehaviour does not exist in 22.2.1, at least. I have not been able to test this on a bzr snapshot, however, so in theory this might already have been discovered and fixed, I guess. In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.3) of 2010-03-26 on crested, modified by Debian Windowing system distributor `The X.Org Foundation', version 11.0.1060400= 0 configured using `configure '--build=3Dx86_64-linux-gnu' '--host=3Dx86_64-linux-gnu' '--prefix=3D/usr' '--sharedstatedir=3D/var/li= b' '--libexecdir=3D/usr/lib' '--localstatedir=3D/var/lib' '--infodir=3D/usr/share/info' '--mandir=3D/usr/share/man' '--with-pop=3Dy= es' '--enable-locallisppath=3D/etc/emacs23:/etc/emacs:/usr/local/share/emacs/= 23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/sit= e-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' '--with-toolkit-scroll-bars' 'build_alias=3Dx86_64-linux-gnu' 'host_alias=3Dx86_64-linux-gnu' 'CFLAGS=3D-DDEBIAN -g -O2' 'LDFLAGS=3D-g' 'CPPFLAGS=3D'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t global-hl-line-mode: t show-paren-mode: t sml-modeline-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r Recent messages: Loading /etc/emacs/site-start.d/55ecb.el (source)...done Loading /etc/emacs/site-start.d/65wl-beta.el (source)...done /usr/bin/mail is not an executable. Setting mail-interactive to t. Loading /home/busk/elisp/color-theme-6.6.0/themes/color-theme-example.el (source)...done Loading /home/busk/elisp/color-theme-6.6.0/themes/color-theme-insp1.el (source)...done Loading /home/busk/elisp/color-theme-6.6.0/themes/color-theme-library.el (source)...done Loading /home/busk/.emacs.d/custom.el (source)...done Starting Emacs daemon. When done with this frame, type C-x 5 0 Making completion list... From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 17 03:31:07 2015 Received: (at 6130) by debbugs.gnu.org; 17 Jan 2015 08:31:08 +0000 Received: from localhost ([127.0.0.1]:59682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCOmg-0007El-Lw for submit@debbugs.gnu.org; Sat, 17 Jan 2015 03:31:07 -0500 Received: from sender1.zohomail.com ([74.201.84.155]:30172) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCLsn-0002Q8-P3 for 6130@debbugs.gnu.org; Sat, 17 Jan 2015 00:25:16 -0500 Received: from cornelius (99-181-53-37.lightspeed.rcsntx.sbcglobal.net [99.181.53.37]) by mx.zohomail.com with SMTPS id 14214723034471005.1228127793079; Fri, 16 Jan 2015 21:25:03 -0800 (PST) From: Daniel Koning To: busk Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> Date: Fri, 16 Jan 2015 23:25:01 -0600 In-Reply-To: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> (busk@lysator.liu.se's message of "Fri, 07 May 2010 14:17:11 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 6130 X-Mailman-Approved-At: Sat, 17 Jan 2015 03:31:04 -0500 Cc: 6130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) busk writes: > I get a malfunction with the artist-mode spray-can when my drawing > goes "over" the borders of the frame, which manifests itself thusly: > It doesn't stop drawing on that particular are, but rather keeps > filling #'s in an area where I drawed until emacs is > killed. "Activating" another frame belonging to the same emacs process > moves the behaviour to that frame. Activating the mini-buffer makes it > draw in the minibuffer. I ran into this one while playing around with artist-mode and trying the various drawing tools. I really don't think it should have been classified as minor -- it's a nasty little loop that you can only get out of by killing the emacs process. If you're prudent, you might maintain the presence of mind to do so without trying to kill the artist-mode buffer first, which just makes the spray can spew garbage characters into whatever buffer was behind it. What's happening is this. The spray can tool is based on a generic helper function called `artist-mouse-draw-continuously'. (Actually, it's misspelled as "continously," but I'm ignoring that.) This function has a loop that checks each mouse event that comes in and exits when the button is released. At the end of the body, it restarts a timer that repeatedly calls `draw-fn', causing (say) the spray can to keep spraying as long as the mouse is held down. The problem is that the loop body tries to determine the latest event's buffer coordinates with `posn-col-row', which, since Emacs 23, has retrieved the buffer-local line spacing by taking the event's position object and calling `window-buffer' on its window element. This is an error on the part of `posn-col-row'. The position object only contains a window element when the position is inside the boundaries of the selected frame. Otherwise it just contains the frame. (Of course, this behavior is completely counterintuitive: you only get an out-of-frame position with drag events, or with motion events inside a `track-mouse' macro; the function for retrieving the frame/window element is just called `posn-window'; and the possibility that the object contains a frame is totally undocumented.) Because `window-buffer' doesn't accept a frame as an argument, it throws an uncaught error when it tries to handle the motion event that takes the pointer outside the frame. `artist-mouse-draw-continuously' then unwinds in the middle of the while loop. This happens before the previous `draw-fn' timer gets cancelled, so you end up with a zombie timer spewing garbage characters. There are a few different things that could stand to be fixed here: 1. The draw-continuously mouse tracking loop really needs to be inside an `unwind-protect' with a cleanup form that gets rid of the timer. 2. `posn-col-row' should correctly handle the case in which `posn-window' returns a frame. Preferably, it should give an estimate of where the position *would* be if the window were larger; this is the pre-23 behavior. 3. The elisp docs ought to reflect that the so-called `window' slot in a position object could actually be a frame. 4. Someone should search-and-replace "continously" to "continuously" throughout artist.el. Those functions are only referenced internally, I think, so doing so isn't likely to break anything. Here's a patch that handles 1 through 3. The extra explanatory material in the docs might be an inelegant half measure, though, considering the function and variable names still refer to the object as a window regardless of its actual type. I also went ahead and searched the lisp/ tree for other places that looked risky -- that is, where a position object was assumed to hold a window in a context where there was no such guarantee. Nothing jumped out at me, but there could be any number of issues with third-party code. diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 36c7445..aab58f1 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -1489,8 +1489,10 @@ prefix @samp{drag-}. For example, dragging the mouse with button 2 held down generates a @code{drag-mouse-2} event. The second and third elements of the event give the starting and ending position of the drag, as mouse position lists (@pxref{Click Events}). You can access -the second element of any mouse event in the same way, with no need to -distinguish drag events from others. +the second element of any mouse event in the same way. However, the +drag event may end outside the boundaries of the selected frame. In +that case, the third element's position list contains the selected +frame in place of a window. The @samp{drag-} prefix follows the modifier key prefixes such as @samp{C-} and @samp{M-}. @@ -1635,7 +1637,10 @@ represented by lists that look like this: @noindent @var{position} is a mouse position list (@pxref{Click Events}), -specifying the current position of the mouse cursor. +specifying the current position of the mouse cursor. As with the +end-position of a drag event, this position list may represent a +location outside the boundaries of the selected frame, in which case +the list contains the selected frame in place of a window. The special form @code{track-mouse} enables generation of motion events within its body. Outside of @code{track-mouse} forms, Emacs @@ -1850,6 +1855,14 @@ into another window. That produces a pair of events like these: -453816)) @end smallexample +The frame with input focus might not take up the entire screen, and +the user might move the mouse outside the scope of the frame. Inside +the @code{track-mouse} special form, that produces an event like this: + +@smallexample +(mouse-movement (# nil (563 . 205) 532301936)) +@end smallexample + To handle a SIGUSR1 signal, define an interactive function, and bind it to the @code{signal usr1} event sequence: @@ -2014,7 +2027,9 @@ Events}); and @code{nil} otherwise. various parts of it: @defun posn-window position -Return the window that @var{position} is in. +Return the window that @var{position} is in. If the frame with input +focus does not have any window at @var{position}, return the frame +instead. @end defun @defun posn-area position diff --git a/lisp/subr.el b/lisp/subr.el index 0534585..94f6d01 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1142,24 +1142,29 @@ For a scroll-bar event, the result column is 0, and the row corresponds to the vertical position of the click in the scroll bar. POSITION should be a list of the form returned by the `event-start' and `event-end' functions." - (let* ((pair (posn-x-y position)) - (window (posn-window position)) - (area (posn-area position))) + (let* ((pair (posn-x-y position)) + (frame-or-window (posn-window position)) + (frame (if (framep frame-or-window) + frame-or-window + (window-frame frame-or-window))) + (window (if (windowp frame-or-window) + frame-or-window + nil)) + (area (posn-area position))) (cond - ((null window) + ((null frame-or-window) '(0 . 0)) ((eq area 'vertical-scroll-bar) (cons 0 (scroll-bar-scale pair (1- (window-height window))))) ((eq area 'horizontal-scroll-bar) (cons (scroll-bar-scale pair (window-width window)) 0)) (t - (let* ((frame (if (framep window) window (window-frame window))) - ;; FIXME: This should take line-spacing properties on - ;; newlines into account. - (spacing (when (display-graphic-p frame) - (or (with-current-buffer (window-buffer window) - line-spacing) - (frame-parameter frame 'line-spacing))))) + ;; FIXME: This should take line-spacing properties on + ;; newlines into account. + (let* ((spacing (when (display-graphic-p frame) + (or (with-current-buffer (window-buffer window) + line-spacing) + (frame-parameter frame 'line-spacing))))) (cond ((floatp spacing) (setq spacing (truncate (* spacing (frame-char-height frame))))) diff --git a/lisp/textmodes/artist.el b/lisp/textmodes/artist.el index 8a2383c..85d9410 100644 --- a/lisp/textmodes/artist.el +++ b/lisp/textmodes/artist.el @@ -4963,52 +4963,55 @@ The event, EV, is the mouse event." (artist-funcall init-fn x1 y1) (if (not artist-rubber-banding) (artist-no-rb-set-point1 x1 y1)) - (track-mouse - (while (or (mouse-movement-p ev) - (member 'down (event-modifiers ev))) - (setq ev-start-pos (artist-coord-win-to-buf - (posn-col-row (event-start ev)))) - (setq x1 (car ev-start-pos)) - (setq y1 (cdr ev-start-pos)) - - ;; Cancel previous timer - (if timer - (cancel-timer timer)) - - (if (not (eq initial-win (posn-window (event-start ev)))) - ;; If we moved outside the window, do nothing - nil - - ;; Still in same window: - ;; - ;; Check if user presses or releases shift key - (if (artist-shift-has-changed shift-state ev) - - ;; First check that the draw-how is the same as we - ;; already have. Otherwise, ignore the changed shift-state. - (if (not (eq draw-how - (artist-go-get-draw-how-from-symbol - (if (not shift-state) shifted unshifted)))) - (message "Cannot switch to shifted operation") - - ;; progn is "implicit" since this is the else-part - (setq shift-state (not shift-state)) - (setq op (if shift-state shifted unshifted)) - (setq draw-how (artist-go-get-draw-how-from-symbol op)) - (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) - - ;; Draw the new shape - (setq shape (artist-funcall draw-fn x1 y1)) - (artist-move-to-xy x1 y1) - - ;; Start the timer to call `draw-fn' repeatedly every - ;; `interval' second - (if (and interval draw-fn) - (setq timer (run-at-time interval interval draw-fn x1 y1)))) - - ;; Read next event - (setq ev (read-event)))) - + (unwind-protect + (track-mouse + (while (or (mouse-movement-p ev) + (member 'down (event-modifiers ev))) + (setq ev-start-pos (artist-coord-win-to-buf + (posn-col-row (event-start ev)))) + (setq x1 (car ev-start-pos)) + (setq y1 (cdr ev-start-pos)) + + ;; Cancel previous timer + (if timer + (cancel-timer timer)) + + (if (not (eq initial-win (posn-window (event-start ev)))) + ;; If we moved outside the window, do nothing + nil + + ;; Still in same window: + ;; + ;; Check if user presses or releases shift key + (if (artist-shift-has-changed shift-state ev) + + ;; First check that the draw-how is the same as we + ;; already have. Otherwise, ignore the changed shift-state. + (if (not (eq draw-how + (artist-go-get-draw-how-from-symbol + (if (not shift-state) shifted unshifted)))) + (message "Cannot switch to shifted operation") + + ;; progn is "implicit" since this is the else-part + (setq shift-state (not shift-state)) + (setq op (if shift-state shifted unshifted)) + (setq draw-how (artist-go-get-draw-how-from-symbol op)) + (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) + + ;; Draw the new shape + (setq shape (artist-funcall draw-fn x1 y1)) + (artist-move-to-xy x1 y1) + + ;; Start the timer to call `draw-fn' repeatedly every + ;; `interval' second + (if (and interval draw-fn) + (setq timer (run-at-time interval interval draw-fn x1 y1)))) + + ;; Read next event + (setq ev (read-event)))) + ;; Cleanup: get rid of any active timer. + (if timer + (cancel-timer timer))) ;; Cancel any timers (if timer (cancel-timer timer)) From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 17 08:56:59 2015 Received: (at 6130) by debbugs.gnu.org; 17 Jan 2015 13:56:59 +0000 Received: from localhost ([127.0.0.1]:59759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCTs2-0002VM-2I for submit@debbugs.gnu.org; Sat, 17 Jan 2015 08:56:58 -0500 Received: from mout.gmx.net ([212.227.15.15]:59334) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCTrv-0002V1-Ge for 6130@debbugs.gnu.org; Sat, 17 Jan 2015 08:56:52 -0500 Received: from [178.191.141.62] ([178.191.141.62]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lux3h-1XmOTX2aYb-0101Ec; Sat, 17 Jan 2015 14:56:38 +0100 Message-ID: <54BA6A0A.4080408@gmx.at> Date: Sat, 17 Jan 2015 14:56:26 +0100 From: martin rudalics MIME-Version: 1.0 To: Daniel Koning , busk Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ywOZ88QF6H/MULECZjsh8N40wN8rvV70XdQtstoGY6lS09AVjil L/6YZe+gR9/rWhS8I279lvp/AMrgZpGWEU1N80siQhvBtMV3VFWwYGDu2EjcTHM0DBkso41 JnzKiAPlJWSAcvy7u+aa19h5v+f56U7OSI57xJjKDEvU48wIKxaTJQi7Njz1ktxGn2AVRnh Tsfhst1iw9maP7pisfzyg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Thank you very much, especially for the detailed explanation. > Here's a patch that handles 1 through 3. I think your patch should go into Emacs 24.5. Have you signed a FSF copyright form? If not, please do that as soon as possible. > The extra explanatory material > in the docs might be an inelegant half measure, though, considering the > function and variable names still refer to the object as a window > regardless of its actual type. We could rename it to `posn-window-or-frame' and provide an alias. > I also went ahead and searched the lisp/ tree for other places that > looked risky -- that is, where a position object was assumed to hold a > window in a context where there was no such guarantee. Nothing jumped > out at me, but there could be any number of issues with third-party > code. `posnp' also looks strange in this regard. > +the second element of any mouse event in the same way. However, the ^ Please always use two spaces after the end of a sentence. > +drag event may end outside the boundaries of the selected frame. In > +that case, the third element's position list contains the selected > +frame in place of a window. I'd expect it to be the selected frame but are we 100% sure? Could this frame not still be the frame selected at the time mouse dragging started while the selected frame has changed under our feet? Think of weird things like `focus-follows-mouse' and `mouse-autoselect-window'. (This remark might be silly but I was too lazy to test its validity right now.) > +location outside the boundaries of the selected frame, in which case > +the list contains the selected frame in place of a window. Same as before. > +Return the window that @var{position} is in. If the frame with input > +focus does not have any window at @var{position}, return the frame > +instead. Hmmm... here you use "frame with input focus". This looks better but I'm still not entirely convinced. > + (window (if (windowp frame-or-window) > + frame-or-window > + nil)) Please use either (and (windowp frame-or-window) frame-or-window) or (when (windowp frame-or-window) frame-or-window) here. > + (let* ((spacing (when (display-graphic-p frame) > + (or (with-current-buffer (window-buffer window) Here `window' is the selected window. IMHO (frame-selected-window frame) sounds more accurate, given what I said about the selected frame above. > diff --git a/lisp/textmodes/artist.el b/lisp/textmodes/artist.el I didn't look into these but just trust your experience here. Thanks again, martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 18 00:47:51 2015 Received: (at 6130) by debbugs.gnu.org; 18 Jan 2015 05:47:51 +0000 Received: from localhost ([127.0.0.1]:60444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCiiD-0002zB-Sm for submit@debbugs.gnu.org; Sun, 18 Jan 2015 00:47:50 -0500 Received: from sender1.zohomail.com ([74.201.84.155]:30630) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCiiA-0002yz-B8 for 6130@debbugs.gnu.org; Sun, 18 Jan 2015 00:47:48 -0500 Received: from cornelius (99-181-53-37.lightspeed.rcsntx.sbcglobal.net [99.181.53.37]) by mx.zohomail.com with SMTPS id 1421560052737630.5577038187165; Sat, 17 Jan 2015 21:47:32 -0800 (PST) From: Daniel Koning To: martin rudalics Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> Date: Sat, 17 Jan 2015 23:47:29 -0600 In-Reply-To: <54BA6A0A.4080408@gmx.at> (martin rudalics's message of "Sat, 17 Jan 2015 14:56:26 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) martin rudalics writes: >> Here's a patch that handles 1 through 3. > > I think your patch should go into Emacs 24.5. Have you signed a FSF > copyright form? If not, please do that as soon as possible. I've put in a request. I'll write back when I've received and returned the form. >> I also went ahead and searched the lisp/ tree for other places that >> looked risky -- that is, where a position object was assumed to hold a >> window in a context where there was no such guarantee. Nothing jumped >> out at me, but there could be any number of issues with third-party >> code. > > `posnp' also looks strange in this regard. > It does indeed, and I added a line to check for frames. > Please always use two spaces after the end of a sentence. > Please use either > (and (windowp frame-or-window) frame-or-window) > or > (when (windowp frame-or-window) frame-or-window) Done and done. > I'd expect it to be the selected frame but are we 100% sure? Could this > frame not still be the frame selected at the time mouse dragging started > while the selected frame has changed under our feet? Think of weird > things like `focus-follows-mouse' and `mouse-autoselect-window'. (This > remark might be silly but I was too lazy to test its validity right now.) Good eye. Upon testing it out, it does seem to be the case that the event's end position will always reflect the originally selected frame. I'll reword my commentary to reflect that. 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. >> +Return the window that @var{position} is in. If the frame with input >> +focus does not have any window at @var{position}, return the frame >> +instead. > > Hmmm... here you use "frame with input focus". This looks better but > I'm still not entirely convinced. 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, [...]" >> + (let* ((spacing (when (display-graphic-p frame) >> + (or (with-current-buffer (window-buffer window) > > Here `window' is the selected window. IMHO > > (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.) >> 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'. Here's the revised patch. diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 36c7445..6fdc8e2 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -1489,8 +1489,10 @@ prefix @samp{drag-}. For example, dragging the mouse with button 2 held down generates a @code{drag-mouse-2} event. The second and third elements of the event give the starting and ending position of the drag, as mouse position lists (@pxref{Click Events}). You can access -the second element of any mouse event in the same way, with no need to -distinguish drag events from others. +the second element of any mouse event in the same way. However, the +drag event may end outside the boundaries of the frame that was +initially selected. In that case, the third element's position list +contains that frame in place of a window. The @samp{drag-} prefix follows the modifier key prefixes such as @samp{C-} and @samp{M-}. @@ -1635,7 +1637,10 @@ represented by lists that look like this: @noindent @var{position} is a mouse position list (@pxref{Click Events}), -specifying the current position of the mouse cursor. +specifying the current position of the mouse cursor. As with the +end-position of a drag event, this position list may represent a +location outside the boundaries of the initially selected frame, in +which case the list contains that frame in place of a window. The special form @code{track-mouse} enables generation of motion events within its body. Outside of @code{track-mouse} forms, Emacs @@ -1850,6 +1855,14 @@ into another window. That produces a pair of events like these: -453816)) @end smallexample +The frame with input focus might not take up the entire screen, and +the user might move the mouse outside the scope of the frame. Inside +the @code{track-mouse} special form, that produces an event like this: + +@smallexample +(mouse-movement (# nil (563 . 205) 532301936)) +@end smallexample + To handle a SIGUSR1 signal, define an interactive function, and bind it to the @code{signal usr1} event sequence: @@ -2014,7 +2027,9 @@ Events}); and @code{nil} otherwise. various parts of it: @defun posn-window position -Return the window that @var{position} is in. +Return the window that @var{position} is in. If @var{position} +represents a location outside the frame where the event was initiated, +return that frame instead. @end defun @defun posn-area position diff --git a/lisp/subr.el b/lisp/subr.el index 0534585..2eb293a 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1083,7 +1083,7 @@ The return value is a positive integer." (defun posnp (obj) "Return non-nil if OBJ appears to be a valid `posn' object." - (and (windowp (car-safe obj)) + (and (or (windowp (car-safe obj)) (framep (car-safe obj))) (atom (car-safe (setq obj (cdr obj)))) ;AREA-OR-POS. (integerp (car-safe (car-safe (setq obj (cdr obj))))) ;XOFFSET. (integerp (car-safe (cdr obj))))) ;TIMESTAMP. @@ -1142,24 +1142,28 @@ For a scroll-bar event, the result column is 0, and the row corresponds to the vertical position of the click in the scroll bar. POSITION should be a list of the form returned by the `event-start' and `event-end' functions." - (let* ((pair (posn-x-y position)) - (window (posn-window position)) - (area (posn-area position))) + (let* ((pair (posn-x-y position)) + (frame-or-window (posn-window position)) + (frame (if (framep frame-or-window) + frame-or-window + (window-frame frame-or-window))) + (window (when (windowp frame-or-window) frame-or-window)) + (area (posn-area position))) (cond - ((null window) + ((null frame-or-window) '(0 . 0)) ((eq area 'vertical-scroll-bar) (cons 0 (scroll-bar-scale pair (1- (window-height window))))) ((eq area 'horizontal-scroll-bar) (cons (scroll-bar-scale pair (window-width window)) 0)) (t - (let* ((frame (if (framep window) window (window-frame window))) - ;; FIXME: This should take line-spacing properties on - ;; newlines into account. - (spacing (when (display-graphic-p frame) - (or (with-current-buffer (window-buffer window) - line-spacing) - (frame-parameter frame 'line-spacing))))) + ;; FIXME: This should take line-spacing properties on + ;; newlines into account. + (let* ((spacing (when (display-graphic-p frame) + (or (with-current-buffer + (window-buffer (frame-selected-window frame)) + line-spacing) + (frame-parameter frame 'line-spacing))))) (cond ((floatp spacing) (setq spacing (truncate (* spacing (frame-char-height frame))))) diff --git a/lisp/textmodes/artist.el b/lisp/textmodes/artist.el index 8a2383c..85d9410 100644 --- a/lisp/textmodes/artist.el +++ b/lisp/textmodes/artist.el @@ -4963,52 +4963,55 @@ The event, EV, is the mouse event." (artist-funcall init-fn x1 y1) (if (not artist-rubber-banding) (artist-no-rb-set-point1 x1 y1)) - (track-mouse - (while (or (mouse-movement-p ev) - (member 'down (event-modifiers ev))) - (setq ev-start-pos (artist-coord-win-to-buf - (posn-col-row (event-start ev)))) - (setq x1 (car ev-start-pos)) - (setq y1 (cdr ev-start-pos)) - - ;; Cancel previous timer - (if timer - (cancel-timer timer)) - - (if (not (eq initial-win (posn-window (event-start ev)))) - ;; If we moved outside the window, do nothing - nil - - ;; Still in same window: - ;; - ;; Check if user presses or releases shift key - (if (artist-shift-has-changed shift-state ev) - - ;; First check that the draw-how is the same as we - ;; already have. Otherwise, ignore the changed shift-state. - (if (not (eq draw-how - (artist-go-get-draw-how-from-symbol - (if (not shift-state) shifted unshifted)))) - (message "Cannot switch to shifted operation") - - ;; progn is "implicit" since this is the else-part - (setq shift-state (not shift-state)) - (setq op (if shift-state shifted unshifted)) - (setq draw-how (artist-go-get-draw-how-from-symbol op)) - (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) - - ;; Draw the new shape - (setq shape (artist-funcall draw-fn x1 y1)) - (artist-move-to-xy x1 y1) - - ;; Start the timer to call `draw-fn' repeatedly every - ;; `interval' second - (if (and interval draw-fn) - (setq timer (run-at-time interval interval draw-fn x1 y1)))) - - ;; Read next event - (setq ev (read-event)))) - + (unwind-protect + (track-mouse + (while (or (mouse-movement-p ev) + (member 'down (event-modifiers ev))) + (setq ev-start-pos (artist-coord-win-to-buf + (posn-col-row (event-start ev)))) + (setq x1 (car ev-start-pos)) + (setq y1 (cdr ev-start-pos)) + + ;; Cancel previous timer + (if timer + (cancel-timer timer)) + + (if (not (eq initial-win (posn-window (event-start ev)))) + ;; If we moved outside the window, do nothing + nil + + ;; Still in same window: + ;; + ;; Check if user presses or releases shift key + (if (artist-shift-has-changed shift-state ev) + + ;; First check that the draw-how is the same as we + ;; already have. Otherwise, ignore the changed shift-state. + (if (not (eq draw-how + (artist-go-get-draw-how-from-symbol + (if (not shift-state) shifted unshifted)))) + (message "Cannot switch to shifted operation") + + ;; progn is "implicit" since this is the else-part + (setq shift-state (not shift-state)) + (setq op (if shift-state shifted unshifted)) + (setq draw-how (artist-go-get-draw-how-from-symbol op)) + (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) + + ;; Draw the new shape + (setq shape (artist-funcall draw-fn x1 y1)) + (artist-move-to-xy x1 y1) + + ;; Start the timer to call `draw-fn' repeatedly every + ;; `interval' second + (if (and interval draw-fn) + (setq timer (run-at-time interval interval draw-fn x1 y1)))) + + ;; Read next event + (setq ev (read-event)))) + ;; Cleanup: get rid of any active timer. + (if timer + (cancel-timer timer))) ;; Cancel any timers (if timer (cancel-timer timer)) From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 18 04:57:32 2015 Received: (at 6130) by debbugs.gnu.org; 18 Jan 2015 09:57:32 +0000 Received: from localhost ([127.0.0.1]:60518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCmbr-00012L-UY for submit@debbugs.gnu.org; Sun, 18 Jan 2015 04:57:32 -0500 Received: from mout.gmx.net ([212.227.17.21]:52252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YCmbp-000122-Re for 6130@debbugs.gnu.org; Sun, 18 Jan 2015 04:57:30 -0500 Received: from [88.117.58.166] ([88.117.58.166]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LwXCt-1Xg3Ju2i9n-018GcD; Sun, 18 Jan 2015 10:57:21 +0100 Message-ID: <54BB8375.9000506@gmx.at> Date: Sun, 18 Jan 2015 10:57:09 +0100 From: martin rudalics MIME-Version: 1.0 To: Daniel Koning Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:f5q0wsS0Oz9vBUM/b44kPwnRROhX9kIeM/9rPHVeZexYq2e6jwj nO8O/Ov0e4bNhFQEgKNvLMuyNVdQxrUadBrgS/mKf1rbziZbaqr7hx/8GfmM5JamTfKSRhZ Gzio+QgBiyk31Qn0OKUmi8yBoXMHszKbx+yoK5MrnHDNG8MgdCw20N2cmoqew8+3byVQvxc lZNDZm6nm8nAV3BokOleA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 19:26:46 2015 Received: (at 6130) by debbugs.gnu.org; 21 Jan 2015 00:26:46 +0000 Received: from localhost ([127.0.0.1]:51186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDj89-000572-HV for submit@debbugs.gnu.org; Tue, 20 Jan 2015 19:26:46 -0500 Received: from sender1.zohomail.com ([74.201.84.155]:29200) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDj85-00056s-Rh for 6130@debbugs.gnu.org; Tue, 20 Jan 2015 19:26:43 -0500 Received: from cornelius (99-181-53-37.lightspeed.rcsntx.sbcglobal.net [99.181.53.37]) by mx.zohomail.com with SMTPS id 1421799989004554.9554962858034; Tue, 20 Jan 2015 16:26:29 -0800 (PST) From: Daniel Koning To: martin rudalics Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> Date: Tue, 20 Jan 2015 18:26:27 -0600 In-Reply-To: <54BB8375.9000506@gmx.at> (martin rudalics's message of "Sun, 18 Jan 2015 10:57:09 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain martin rudalics writes: >> 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. Okay, but I think this should be a reasonably high priority for the maintainers of this part of the lisp tree. Aren't there likely to be quite a few undiscovered bugs, some perhaps quite destructive, that result from following the behavior as it was documented, just as there are (presumably) places where new bugs would manifest if `posnp' were brought in line with its advertised behavior? In any case, I've appended a FIXME comment in addition to revising the docstring. I added the log entry to the highest-level ChangeLog file, since I edited files in lisp/ and doc/ (even though the doc/ changes were only in reference to functionality implemented under lisp/). Is that right? Daniel --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=artist.patch Content-Description: Fix for #6130 diff --git a/ChangeLog b/ChangeLog index 309b04f..53d7bb4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2015-01-20 Daniel Koning + + Prevent artist-mode from creating runaway timers. + * lisp/textmodes/artist.el: Cancel timers if an error occurs + during continuous drawing. + * lisp/subr.el: Make `posn-col-row' work with all mouse position + objects. Correct docstring of `posnp'. + * doc/lispref/commands.texi: Describe actual range of values that + mouse position objects can have. + Fixes: bug#6130 + 2015-01-16 Paul Eggert Give up on -Wsuggest-attribute=const diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 36c7445..6fdc8e2 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -1489,8 +1489,10 @@ prefix @samp{drag-}. For example, dragging the mouse with button 2 held down generates a @code{drag-mouse-2} event. The second and third elements of the event give the starting and ending position of the drag, as mouse position lists (@pxref{Click Events}). You can access -the second element of any mouse event in the same way, with no need to -distinguish drag events from others. +the second element of any mouse event in the same way. However, the +drag event may end outside the boundaries of the frame that was +initially selected. In that case, the third element's position list +contains that frame in place of a window. The @samp{drag-} prefix follows the modifier key prefixes such as @samp{C-} and @samp{M-}. @@ -1635,7 +1637,10 @@ represented by lists that look like this: @noindent @var{position} is a mouse position list (@pxref{Click Events}), -specifying the current position of the mouse cursor. +specifying the current position of the mouse cursor. As with the +end-position of a drag event, this position list may represent a +location outside the boundaries of the initially selected frame, in +which case the list contains that frame in place of a window. The special form @code{track-mouse} enables generation of motion events within its body. Outside of @code{track-mouse} forms, Emacs @@ -1850,6 +1855,14 @@ into another window. That produces a pair of events like these: -453816)) @end smallexample +The frame with input focus might not take up the entire screen, and +the user might move the mouse outside the scope of the frame. Inside +the @code{track-mouse} special form, that produces an event like this: + +@smallexample +(mouse-movement (# nil (563 . 205) 532301936)) +@end smallexample + To handle a SIGUSR1 signal, define an interactive function, and bind it to the @code{signal usr1} event sequence: @@ -2014,7 +2027,9 @@ Events}); and @code{nil} otherwise. various parts of it: @defun posn-window position -Return the window that @var{position} is in. +Return the window that @var{position} is in. If @var{position} +represents a location outside the frame where the event was initiated, +return that frame instead. @end defun @defun posn-area position diff --git a/lisp/subr.el b/lisp/subr.el index 0534585..b37d17f 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1082,7 +1082,10 @@ The return value is a positive integer." ;;;; Extracting fields of the positions in an event. (defun posnp (obj) - "Return non-nil if OBJ appears to be a valid `posn' object." + "Return non-nil if OBJ appears to be a valid `posn' object that specifies a window. If OBJ is a valid `posn' object, but specifies a frame rather than a window, return nil." + ;; FIXME: Correct the behavior of this function so that all valid + ;; `posn' objects are recognized, after updating other code that + ;; depends on its present behavior. (and (windowp (car-safe obj)) (atom (car-safe (setq obj (cdr obj)))) ;AREA-OR-POS. (integerp (car-safe (car-safe (setq obj (cdr obj))))) ;XOFFSET. @@ -1142,24 +1145,28 @@ For a scroll-bar event, the result column is 0, and the row corresponds to the vertical position of the click in the scroll bar. POSITION should be a list of the form returned by the `event-start' and `event-end' functions." - (let* ((pair (posn-x-y position)) - (window (posn-window position)) - (area (posn-area position))) + (let* ((pair (posn-x-y position)) + (frame-or-window (posn-window position)) + (frame (if (framep frame-or-window) + frame-or-window + (window-frame frame-or-window))) + (window (when (windowp frame-or-window) frame-or-window)) + (area (posn-area position))) (cond - ((null window) + ((null frame-or-window) '(0 . 0)) ((eq area 'vertical-scroll-bar) (cons 0 (scroll-bar-scale pair (1- (window-height window))))) ((eq area 'horizontal-scroll-bar) (cons (scroll-bar-scale pair (window-width window)) 0)) (t - (let* ((frame (if (framep window) window (window-frame window))) - ;; FIXME: This should take line-spacing properties on - ;; newlines into account. - (spacing (when (display-graphic-p frame) - (or (with-current-buffer (window-buffer window) - line-spacing) - (frame-parameter frame 'line-spacing))))) + ;; FIXME: This should take line-spacing properties on + ;; newlines into account. + (let* ((spacing (when (display-graphic-p frame) + (or (with-current-buffer + (window-buffer (frame-selected-window frame)) + line-spacing) + (frame-parameter frame 'line-spacing))))) (cond ((floatp spacing) (setq spacing (truncate (* spacing (frame-char-height frame))))) diff --git a/lisp/textmodes/artist.el b/lisp/textmodes/artist.el index 8a2383c..85d9410 100644 --- a/lisp/textmodes/artist.el +++ b/lisp/textmodes/artist.el @@ -4963,52 +4963,55 @@ The event, EV, is the mouse event." (artist-funcall init-fn x1 y1) (if (not artist-rubber-banding) (artist-no-rb-set-point1 x1 y1)) - (track-mouse - (while (or (mouse-movement-p ev) - (member 'down (event-modifiers ev))) - (setq ev-start-pos (artist-coord-win-to-buf - (posn-col-row (event-start ev)))) - (setq x1 (car ev-start-pos)) - (setq y1 (cdr ev-start-pos)) - - ;; Cancel previous timer - (if timer - (cancel-timer timer)) - - (if (not (eq initial-win (posn-window (event-start ev)))) - ;; If we moved outside the window, do nothing - nil - - ;; Still in same window: - ;; - ;; Check if user presses or releases shift key - (if (artist-shift-has-changed shift-state ev) - - ;; First check that the draw-how is the same as we - ;; already have. Otherwise, ignore the changed shift-state. - (if (not (eq draw-how - (artist-go-get-draw-how-from-symbol - (if (not shift-state) shifted unshifted)))) - (message "Cannot switch to shifted operation") - - ;; progn is "implicit" since this is the else-part - (setq shift-state (not shift-state)) - (setq op (if shift-state shifted unshifted)) - (setq draw-how (artist-go-get-draw-how-from-symbol op)) - (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) - - ;; Draw the new shape - (setq shape (artist-funcall draw-fn x1 y1)) - (artist-move-to-xy x1 y1) - - ;; Start the timer to call `draw-fn' repeatedly every - ;; `interval' second - (if (and interval draw-fn) - (setq timer (run-at-time interval interval draw-fn x1 y1)))) - - ;; Read next event - (setq ev (read-event)))) - + (unwind-protect + (track-mouse + (while (or (mouse-movement-p ev) + (member 'down (event-modifiers ev))) + (setq ev-start-pos (artist-coord-win-to-buf + (posn-col-row (event-start ev)))) + (setq x1 (car ev-start-pos)) + (setq y1 (cdr ev-start-pos)) + + ;; Cancel previous timer + (if timer + (cancel-timer timer)) + + (if (not (eq initial-win (posn-window (event-start ev)))) + ;; If we moved outside the window, do nothing + nil + + ;; Still in same window: + ;; + ;; Check if user presses or releases shift key + (if (artist-shift-has-changed shift-state ev) + + ;; First check that the draw-how is the same as we + ;; already have. Otherwise, ignore the changed shift-state. + (if (not (eq draw-how + (artist-go-get-draw-how-from-symbol + (if (not shift-state) shifted unshifted)))) + (message "Cannot switch to shifted operation") + + ;; progn is "implicit" since this is the else-part + (setq shift-state (not shift-state)) + (setq op (if shift-state shifted unshifted)) + (setq draw-how (artist-go-get-draw-how-from-symbol op)) + (setq draw-fn (artist-go-get-draw-fn-from-symbol op)))) + + ;; Draw the new shape + (setq shape (artist-funcall draw-fn x1 y1)) + (artist-move-to-xy x1 y1) + + ;; Start the timer to call `draw-fn' repeatedly every + ;; `interval' second + (if (and interval draw-fn) + (setq timer (run-at-time interval interval draw-fn x1 y1)))) + + ;; Read next event + (setq ev (read-event)))) + ;; Cleanup: get rid of any active timer. + (if timer + (cancel-timer timer))) ;; Cancel any timers (if timer (cancel-timer timer)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 03:22:41 2015 Received: (at 6130) by debbugs.gnu.org; 21 Jan 2015 08:22:41 +0000 Received: from localhost ([127.0.0.1]:51272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDqYj-0008NJ-32 for submit@debbugs.gnu.org; Wed, 21 Jan 2015 03:22:41 -0500 Received: from mout.gmx.net ([212.227.17.21]:54585) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDqYg-0008My-66 for 6130@debbugs.gnu.org; Wed, 21 Jan 2015 03:22:38 -0500 Received: from [178.190.18.57] ([178.190.18.57]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MgXCF-1YP4gV0DwN-00O2tn; Wed, 21 Jan 2015 09:22:28 +0100 Message-ID: <54BF61BE.5000307@gmx.at> Date: Wed, 21 Jan 2015 09:22:22 +0100 From: martin rudalics MIME-Version: 1.0 To: Daniel Koning Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TyIbyXYC+sj+TaPUHwjJD6j8FoXQXYGkfJpoaHfQ9adtSvdM8eh RFLuNYPaz5xXoX7+hgabYIz13H+IuamM3hh/kF5qdBqPaKjHoLQs7AJ8jRg1vsKGAYKj6o2 yBGSCetFFu8VXohtCRh/2vpS3LHUnRObb06rNN+Zejh9W6Rjo/yYZxm7KzhaqsMKcyCWa2s CpUwfwdFjVegwuJcw+h6Q== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Okay, but I think this should be a reasonably high priority for the > maintainers of this part of the lisp tree. Aren't there likely to be > quite a few undiscovered bugs, some perhaps quite destructive, that > result from following the behavior as it was documented, just as there > are (presumably) places where new bugs would manifest if `posnp' were > brought in line with its advertised behavior? In any case, I've appended > a FIXME comment in addition to revising the docstring. Thanks. I slightly tweaked the doc-string of `posnp' to make its first line fit. We can change the behavior of `posnp' for Emacs 25 as soon as you received your confirmation from the FSF. > I added the log entry to the highest-level ChangeLog file, since I > edited files in lisp/ and doc/ (even though the doc/ changes were only > in reference to functionality implemented under lisp/). Is that right? Not really. But the way of writing ChangeLog entries will change in the near future anyway so there's not much use to tell you the precise details. I used your entry to create more appropriate ones. I pushed your changes to the Emacs-24 branch as commit 4c09e3a..3ea1b31 emacs-24 -> emacs-24 They should appear on trunk/master with the next merge. Please have a look, my experience with git is still rather poor. If you think I've done everything right, please close the bug. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 10:22:52 2015 Received: (at 6130) by debbugs.gnu.org; 21 Jan 2015 15:22:52 +0000 Received: from localhost ([127.0.0.1]:52009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDx7M-0003Ld-Ba for submit@debbugs.gnu.org; Wed, 21 Jan 2015 10:22:52 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46058) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDx7K-0003LQ-Bk for 6130@debbugs.gnu.org; Wed, 21 Jan 2015 10:22:50 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQRWIxALDiYSFBgNJIhT1lkBAQEHAgEfkG8HhEgFiwGmJoQZIYJ3AQEB X-IPAS-Result: AjsPAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQRWIxALDiYSFBgNJIhT1lkBAQEHAgEfkG8HhEgFiwGmJoQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="108371429" Received: from 167-88-21-140.cpe.teksavvy.com (HELO pastel.home) ([167.88.21.140]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jan 2015 10:22:44 -0500 Received: by pastel.home (Postfix, from userid 20848) id 9D6CF12C9; Wed, 21 Jan 2015 10:22:44 -0500 (EST) From: Stefan Monnier To: Daniel Koning Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction Message-ID: References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> Date: Wed, 21 Jan 2015 10:22:44 -0500 In-Reply-To: (Daniel Koning's message of "Tue, 20 Jan 2015 18:26:27 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, martin rudalics , busk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) The Right Thing to do, AFAICT, is for posnp to return non-nil also when the `car' is a frame. 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. 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, and/or deprecate it (in favor of a new posn-window-or-frame). Can someone look at its various users to see what would be best? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 11:55:11 2015 Received: (at 6130) by debbugs.gnu.org; 21 Jan 2015 16:55:11 +0000 Received: from localhost ([127.0.0.1]:52051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDyYh-0005iJ-DJ for submit@debbugs.gnu.org; Wed, 21 Jan 2015 11:55:11 -0500 Received: from mout.gmx.net ([212.227.15.18]:61478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDyYf-0005i3-3F for 6130@debbugs.gnu.org; Wed, 21 Jan 2015 11:55:09 -0500 Received: from [188.22.33.74] ([188.22.33.74]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MKprU-1YDyYS2vXk-0003tz; Wed, 21 Jan 2015 17:54:56 +0100 Message-ID: <54BFD9D9.70708@gmx.at> Date: Wed, 21 Jan 2015 17:54:49 +0100 From: martin rudalics MIME-Version: 1.0 To: Stefan Monnier , Daniel Koning Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:XdD41Rf8/JzbYB9otDIfzHpdKfHTE5CErKV9kXASr8QJM1cLU6x 7hPA3uPQbqvo0mO2tXtkdNJ6P68eByhO/ZFq5o2zQ41WcmayEzSnJ98rI+gmZMrZCQFaog7 zs5w4nVJ5UoycfvhNWQZZkBoCSJNFn459wUYyMQ3q9np3SzVNBgaJxAp9dmvl7LGTzPAWxr oC/CWN74sbHD+rmDNZxIw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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. If we have `posnp' return t for a frame as well, it will fail. And as Daniel has shown, such a failure can be quite annoying in its consequences. It probably could have been avoided if artist had used `posnp'. So at least for Emacs 24.5 I would rather not change the current behavior. I would change it for Emacs 25. > 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". > 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. > and/or deprecate > it (in favor of a new posn-window-or-frame). That's what I had in mind. > Can someone look at its various users to see what would be best? martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 12:02:18 2015 Received: (at 6130) by debbugs.gnu.org; 22 Jan 2015 17:02:18 +0000 Received: from localhost ([127.0.0.1]:53067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEL97-0002fw-Sa for submit@debbugs.gnu.org; Thu, 22 Jan 2015 12:02:18 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:60620) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEL96-0002fh-3V for 6130@debbugs.gnu.org; Thu, 22 Jan 2015 12:02:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAYNhokWEGSGCdwEBAQ X-IPAS-Result: AjsPAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAYNhokWEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="108480305" Received: from 167-88-21-140.cpe.teksavvy.com (HELO pastel.home) ([167.88.21.140]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2015 12:02:09 -0500 Received: by pastel.home (Postfix, from userid 20848) id DEBE32A58; Thu, 22 Jan 2015 12:02:09 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction Message-ID: References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> Date: Thu, 22 Jan 2015 12:02:09 -0500 In-Reply-To: <54BFD9D9.70708@gmx.at> (martin rudalics's message of "Wed, 21 Jan 2015 17:54:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk , Daniel Koning X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 13:24:07 2015 Received: (at 6130) by debbugs.gnu.org; 22 Jan 2015 18:24:07 +0000 Received: from localhost ([127.0.0.1]:53230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMQJ-0007W0-2Q for submit@debbugs.gnu.org; Thu, 22 Jan 2015 13:24:07 -0500 Received: from mout.gmx.net ([212.227.17.20]:64032) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMQH-0007VG-2d for 6130@debbugs.gnu.org; Thu, 22 Jan 2015 13:24:05 -0500 Received: from [178.191.140.119] ([178.191.140.119]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MBJF3-1YO1aK3qcv-00AELW; Thu, 22 Jan 2015 19:23:50 +0100 Message-ID: <54C1402D.1000100@gmx.at> Date: Thu, 22 Jan 2015 19:23:41 +0100 From: martin rudalics MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HYZtn8+h2qjt9KNGbnxJbm0s6AvwiNXoTTXc79cHVr45fZixPFt DmYaInNjNCkJCznyuwrFEpzSjRLXb9iIvyFTYz6nONA7rYfPFBSASlFkRG42m8beMKacy1q /wZe+yOYJgJfDbHPZBzTX+vJBLupp6Kg0Wh1q8Hv2YPmHvxX2NPNFLI0XW5WoK+QcANl4SP Lpzr2CzPmsEN5kQ6R/6Nw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk , Daniel Koning X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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)? Daniel in his first post wrote that I also went ahead and searched the lisp/ tree for other places that looked risky -- that is, where a position object was assumed to hold a window in a context where there was no such guarantee. Nothing jumped out at me, but there could be any number of issues with third-party code. so I think this has been taken care of already. >>> 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. Then we have still another choice: Provide a function `posn-frame' and have `posn-window' return nil when the first element is a frame. This would backfire for people who would like `posn-window' to always return the first element of a position. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 18:08:51 2015 Received: (at 6130) by debbugs.gnu.org; 22 Jan 2015 23:08:51 +0000 Received: from localhost ([127.0.0.1]:53303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEQrr-000699-5X for submit@debbugs.gnu.org; Thu, 22 Jan 2015 18:08:51 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29085) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEQrj-00068q-3Q for 6130@debbugs.gnu.org; Thu, 22 Jan 2015 18:08:49 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0IAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxSMCgSUWAQEBAQEBfIQDAQEDAXkFCwsNJxIUGDGISgnWWQEBAQEGAgEfkG8HhEgFiwGYcY01hBkhgncBAQE X-IPAS-Result: Au0IAOwQflSnWBWM/2dsb2JhbABbgweDYIVaxSMCgSUWAQEBAQEBfIQDAQEDAXkFCwsNJxIUGDGISgnWWQEBAQEGAgEfkG8HhEgFiwGYcY01hBkhgncBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="108510056" Received: from unknown (HELO pastel.home) ([167.88.21.140]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2015 18:08:37 -0500 Received: by pastel.home (Postfix, from userid 20848) id 2C02A2A58; Thu, 22 Jan 2015 18:08:37 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction Message-ID: References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> Date: Thu, 22 Jan 2015 18:08:36 -0500 In-Reply-To: <54C1402D.1000100@gmx.at> (martin rudalics's message of "Thu, 22 Jan 2015 19:23:41 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk , Daniel Koning X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Daniel in his first post wrote that > I also went ahead and searched the lisp/ tree for other places that > looked risky -- that is, where a position object was assumed to hold a > window in a context where there was no such guarantee. Nothing jumped > out at me, but there could be any number of issues with third-party > code. > so I think this has been taken care of already. To be honest, I don't know what that means. IIUC it means that most of the code doesn't care if posn-window sometimes returns a frame. It's wrong for posn-window to return a frame. 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? > This would backfire for people who would like `posn-window' to always > return the first element of a position. 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. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 03:27:19 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 08:27:19 +0000 Received: from localhost ([127.0.0.1]:53471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEZaJ-0004T4-4b for submit@debbugs.gnu.org; Fri, 23 Jan 2015 03:27:19 -0500 Received: from mout.gmx.net ([212.227.17.22]:51875) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEZaG-0004Sj-QO for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 03:27:17 -0500 Received: from [88.117.81.28] ([88.117.81.28]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1nOg-1XPdsx3Kpu-00tiRs; Fri, 23 Jan 2015 09:27:05 +0100 Message-ID: <54C205D0.3000607@gmx.at> Date: Fri, 23 Jan 2015 09:26:56 +0100 From: martin rudalics MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oRxRgkA6VmFoI/+hHRG9IIjxq+pEFyE+x0ya4hz+Ah0O8ly9LgN 3FhqfrKmSdLjvs3ARY1hNnnxI+kGUN92/VAAqHwdioRcwJvXXAcvIMXZncAM1LfM271TWas SIKhyQWH+lqqF8xrd7q+AnVLsclVfDsAgCWRqnAttotEhZACZjZn7OqBJQTTLQqy8OYiFNj tFZV8XPwXaptIi0Nhjarg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk , Daniel Koning X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > It's wrong for posn-window to return a frame. Is it right for it to return nil? There seems to be no particular restriction on what a "mouse position list" as returned by `event-start' and `event-end' has to contain. Many callers simply use the selected window or the window buffer of the selected window when the return value of `posn-window' is nil. > 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). I don't understand `handle-delete-frame' but it hardly will cause problems when it gets nil or an error. I didn't check for occurrences of things like "(nth 0 position". >> This would backfire for people who would like `posn-window' to always >> return the first element of a position. > > 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. If we really cared, we'd probably have to write something like (defsubst posn-window (position) "Return the window in POSITION. POSITION should be a list of the form returned by the `event-start' and `event-end' functions." (if (window-live-p (nth 0 position)) (nth 0 position) 'none)) martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 04:43:20 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 09:43:20 +0000 Received: from localhost ([127.0.0.1]:53482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEalr-0007PN-NQ for submit@debbugs.gnu.org; Fri, 23 Jan 2015 04:43:20 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:50143) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEall-0007Or-Qq for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 04:43:15 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NIM00E00IZOZP00@a-mtaout22.012.net.il> for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 11:43:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIM00EE6IZUX330@a-mtaout22.012.net.il>; Fri, 23 Jan 2015 11:43:07 +0200 (IST) Date: Fri, 23 Jan 2015 11:43:08 +0200 From: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction In-reply-to: <54C205D0.3000607@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83mw59u91v.fsf@gnu.org> References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se, monnier@iro.umontreal.ca, dk@danielkoning.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 23 Jan 2015 09:26:56 +0100 > From: martin rudalics > Cc: 6130@debbugs.gnu.org, busk , > Daniel Koning > > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 11:55:18 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 16:55:18 +0000 Received: from localhost ([127.0.0.1]:54513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEhVs-0005n0-W8 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 11:55:17 -0500 Received: from mout.gmx.net ([212.227.15.18]:57273) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEhVq-0005mk-TL for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 11:55:15 -0500 Received: from [178.190.18.67] ([178.190.18.67]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFtf4-1YSOcs07ba-00ErO6; Fri, 23 Jan 2015 17:54:52 +0100 Message-ID: <54C27CD2.1040402@gmx.at> Date: Fri, 23 Jan 2015 17:54:42 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> In-Reply-To: <83mw59u91v.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LIDd5M1rCUl1+zSs+T1xUGKYb9w438iGHMw9ZOleLlodcsitegw pVuwWOg7/ys6BRrPM5a/9sosdY178G5U/8q/9nV9lcjhzvtMjqXtBPhzoL657E1fJMcQhgb w0RW0lJ8V5BrtDw+xpqVEyI7K+2mrOcIDhFzWutC0f7FT2PmXpRo25RPTeBj/C+GsEKrnYX 3dJb5QMHjiPBgvCljKC6Q== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se, monnier@iro.umontreal.ca, dk@danielkoning.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> `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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:06:14 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 21:06:14 +0000 Received: from localhost ([127.0.0.1]:54616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElQk-0004l6-68 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:06:14 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34998) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElQh-0004ky-S5 for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 16:06:12 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id C545685D5E; Fri, 23 Jan 2015 16:06:09 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 451681E5B94; Fri, 23 Jan 2015 16:05:34 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 24A2CB4102; Fri, 23 Jan 2015 16:05:34 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction Message-ID: References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> Date: Fri, 23 Jan 2015 16:05:33 -0500 In-Reply-To: <54C27CD2.1040402@gmx.at> (martin rudalics's message of "Fri, 23 Jan 2015 17:54:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, Eli Zaretskii , busk@lysator.liu.se, dk@danielkoning.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >>> > It's wrong for posn-window to return a frame. >> Can you explain why it's wrong? If you take a step back and read my sentence you'll see it's pretty obvious: since it says "window" it shouldn't return a "frame". Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:26:18 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 21:26:18 +0000 Received: from localhost ([127.0.0.1]:54638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElk9-0005FN-NY for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:26:18 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:48998) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElk7-0005F9-5S for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 16:26:16 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NIN00B00FB8JG00@a-mtaout23.012.net.il> for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 23:26:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN00BF8FJKJI00@a-mtaout23.012.net.il>; Fri, 23 Jan 2015 23:26:08 +0200 (IST) Date: Fri, 23 Jan 2015 23:26:11 +0200 From: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83ppa5rxxo.fsf@gnu.org> References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, rudalics@gmx.at, busk@lysator.liu.se, dk@danielkoning.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 6130@debbugs.gnu.org, busk@lysator.liu.se, dk@danielkoning.com > Date: Fri, 23 Jan 2015 16:05:33 -0500 > > >>> > It's wrong for posn-window to return a frame. > >> Can you explain why it's wrong? > > If you take a step back and read my sentence you'll see it's pretty > obvious: since it says "window" it shouldn't return a "frame". We do that all the time. For example: (display-graphic-p &optional DISPLAY) Return non-nil if DISPLAY is a graphic display. [...] DISPLAY can be a display name, a frame, or nil (meaning the selected frame's display). In polymorphic interfaces, the alternative is to say DISPLAY-OR-FRAME-OR-... which is too tedious. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:53:15 2015 Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 21:53:15 +0000 Received: from localhost ([127.0.0.1]:54647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmAE-0007Gc-SV for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:53:15 -0500 Received: from sender1.zohomail.com ([74.201.84.155]:30252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmAB-0007GR-Mp for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 16:53:12 -0500 Received: from cornelius (99-181-53-37.lightspeed.rcsntx.sbcglobal.net [99.181.53.37]) by mx.zohomail.com with SMTPS id 1422049976580434.68227131099684; Fri, 23 Jan 2015 13:52:56 -0800 (PST) From: Daniel Koning To: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> <83ppa5rxxo.fsf@gnu.org> Date: Fri, 23 Jan 2015 15:52:54 -0600 In-Reply-To: <83ppa5rxxo.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 23 Jan 2015 23:26:11 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, rudalics@gmx.at, busk@lysator.liu.se, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli Zaretskii writes: > We do that all the time. For example: > > (display-graphic-p &optional DISPLAY) > > Return non-nil if DISPLAY is a graphic display. > [...] > DISPLAY can be a display name, a frame, or nil (meaning the selected > frame's display). >From a user perspective, there is a crucial distinction between these two examples of ambiguous naming. When an argument is called DISPLAY even though it can be other things besides a display, the function still works in every case that its name and its arguments' names suggest that it should work. But when the return value is called WINDOW when it might not be one, then it becomes a source of potential error merely to rely on the function to behave as its name suggests. Sure, you can write documentation to warn users about the pitfall, but misleading naming conventions are one of the factors that cause people to write mistaken documentation. (Cf. the documentation of `posn-window' until a few days ago!) > In polymorphic interfaces, the alternative is to say > DISPLAY-OR-FRAME-OR-... which is too tedious. If that's the main problem with assigning accurate names in polymorphic contexts -- that the names end up too long when you include every possible type -- how about defining a supertype which includes (in this case) both windows and frames? That may seem cumbersome, but realize that this is effectively what is already happening, insofar as "window" is being coerced into serving as metonymy for the entire class of mouse-position containers. Daniel From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 24 03:12:58 2015 Received: (at 6130) by debbugs.gnu.org; 24 Jan 2015 08:12:58 +0000 Received: from localhost ([127.0.0.1]:54772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEvpx-00075D-Ea for submit@debbugs.gnu.org; Sat, 24 Jan 2015 03:12:57 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:61906) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEvpu-00074y-1t for 6130@debbugs.gnu.org; Sat, 24 Jan 2015 03:12:55 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NIO00D009CE1W00@a-mtaout23.012.net.il> for 6130@debbugs.gnu.org; Sat, 24 Jan 2015 10:12:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIO00D3O9HA0B30@a-mtaout23.012.net.il>; Sat, 24 Jan 2015 10:12:47 +0200 (IST) Date: Sat, 24 Jan 2015 10:12:51 +0200 From: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction In-reply-to: X-012-Sender: halo1@inter.net.il To: Daniel Koning Message-id: <83mw58sikc.fsf@gnu.org> References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> <83ppa5rxxo.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, rudalics@gmx.at, busk@lysator.liu.se, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Daniel Koning > Cc: Stefan Monnier , rudalics@gmx.at, 6130@debbugs.gnu.org, busk@lysator.liu.se > Date: Fri, 23 Jan 2015 15:52:54 -0600 > > When an argument is called DISPLAY even though it can be other things > besides a display, the function still works in every case that its name > and its arguments' names suggest that it should work. > > But when the return value is called WINDOW when it might not be one, > then it becomes a source of potential error merely to rely on the > function to behave as its name suggests. Sure, you can write > documentation to warn users about the pitfall, but misleading naming > conventions are one of the factors that cause people to write mistaken > documentation. (Cf. the documentation of `posn-window' until a few days > ago!) I agree that the documentation was (or maybe still is) in the need of improvement (documentation of events is quite obscure, to tell the truth, and was like that for a very long time). But I fail to see the crucial difference between these two examples. In any case, the example I brought up was just the first thing that popped up in my mind, you can find plenty of examples of the other kind as well. IOW, in Emacs one must read the documentation before they believe the literal meaning of an argument's name. > If that's the main problem with assigning accurate names in polymorphic > contexts -- that the names end up too long when you include every > possible type -- how about defining a supertype which includes (in this > case) both windows and frames? Try proposing one, maybe we will adopt it. However, we have bad experience with terminology that only Emacs uses, or, worse, where the Emacs meaning is different from that of the rest of the world. So I'm not sure this path is better. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 24 04:09:13 2015 Received: (at 6130) by debbugs.gnu.org; 24 Jan 2015 09:09:13 +0000 Received: from localhost ([127.0.0.1]:54793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEwiO-0008QP-Rn for submit@debbugs.gnu.org; Sat, 24 Jan 2015 04:09:13 -0500 Received: from mout.gmx.net ([212.227.15.15]:64173) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEwiN-0008QC-HH for 6130@debbugs.gnu.org; Sat, 24 Jan 2015 04:09:11 -0500 Received: from [178.189.207.245] ([178.189.207.245]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MNIi1-1YLINC2Gj3-006uYR; Sat, 24 Jan 2015 10:08:55 +0100 Message-ID: <54C3611D.10900@gmx.at> Date: Sat, 24 Jan 2015 10:08:45 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Daniel Koning Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> <83ppa5rxxo.fsf@gnu.org> <83mw58sikc.fsf@gnu.org> In-Reply-To: <83mw58sikc.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zv8UBpuPwf1nnwCe/PqBjrDTuwI0iYjRrfacIPdB0gEERsQfW0A F11zQiqlKb27TDud0aClCUf33hNloZDm+0ayEL5Ui7VTF036MbRTG2q7IHxsey/IVHN8hCJ tioJaFJ4sjIEJHAwwUguHOAIoKL378AsTnmgZ6hqxpou5fP+FPRDMO6/kUUBNl46oVFREtn 2Qi6uFHiKE8se8t1EimLQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > IOW, in Emacs one must read the documentation before they believe the > literal meaning of an argument's name. Unfortunately, in the case at hand the documentation was wrong and misleading as most uses of `posn-window' still reflect. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 24 04:49:44 2015 Received: (at 6130) by debbugs.gnu.org; 24 Jan 2015 09:49:44 +0000 Received: from localhost ([127.0.0.1]:54814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExLb-00011A-95 for submit@debbugs.gnu.org; Sat, 24 Jan 2015 04:49:43 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:50255) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExLZ-00010x-4B for 6130@debbugs.gnu.org; Sat, 24 Jan 2015 04:49:41 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NIO00100DFFHI00@a-mtaout22.012.net.il> for 6130@debbugs.gnu.org; Sat, 24 Jan 2015 11:49:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIO000UFDYMVYC0@a-mtaout22.012.net.il>; Sat, 24 Jan 2015 11:49:35 +0200 (IST) Date: Sat, 24 Jan 2015 11:49:39 +0200 From: Eli Zaretskii Subject: Re: bug#6130: 23.1; artist-mode spray-can malfunction In-reply-to: <54C3611D.10900@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83egqkse30.fsf@gnu.org> References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> <83ppa5rxxo.fsf@gnu.org> <83mw58sikc.fsf@gnu.org> <54C3611D.10900@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 6130 Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se, monnier@iro.umontreal.ca, dk@danielkoning.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 24 Jan 2015 10:08:45 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 6130@debbugs.gnu.org, busk@lysator.liu.se > > > IOW, in Emacs one must read the documentation before they believe the > > literal meaning of an argument's name. > > Unfortunately, in the case at hand the documentation was wrong and > misleading I agree. > as most uses of `posn-window' still reflect. I'm not sure. It could be the case that most of those uses will never get a frame from posn-window, in which case there's nothing wrong with their current code. The only way to tell is by analyzing the events that are input to those code fragments. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 06 11:05:13 2016 Received: (at 6130-done) by debbugs.gnu.org; 6 Apr 2016 15:05:13 +0000 Received: from localhost ([127.0.0.1]:51875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1anp16-0002E8-8q for submit@debbugs.gnu.org; Wed, 06 Apr 2016 11:05:12 -0400 Received: from mail.lysator.liu.se ([130.236.254.3]:42858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1anjaI-0000Na-O1 for 6130-done@debbugs.gnu.org; Wed, 06 Apr 2016 05:17:11 -0400 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 431DF40022 for <6130-done@debbugs.gnu.org>; Wed, 6 Apr 2016 11:17:09 +0200 (CEST) Received: from localhost (yes.unit.liu.se [130.236.16.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 1880E4001D for <6130-done@debbugs.gnu.org>; Wed, 6 Apr 2016 11:17:09 +0200 (CEST) Date: Wed, 6 Apr 2016 11:17:08 +0200 From: Johan Busk Eriksson To: 6130-done@debbugs.gnu.org Subject: bug#6130: 23.1; artist-mode spray-can malfunction Message-ID: <20160406111708.00000e71@lysator.liu.se> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 6130-done X-Mailman-Approved-At: Wed, 06 Apr 2016 11:05:10 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I can't seem to replicate the bug anymore in 24.5, so I'll assume it's been fixed without being closed. To be honest I kind of forgot about filing the bug between 2010 and when the replies started coming in 2015, and didn't really bother seeing if it persisted in the last few releases. /Johan From unknown Mon Jun 23 18:32:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 05 May 2016 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator