GNU bug report logs - #25057
Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25057 in the body.
You can then email your comments to 25057 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: aaron peterson <metaxis <at> gmail.com>
To: kifer <at> cs.stonybrook.edu, bug-gnu-emacs <at> gnu.org
Subject: Ediff 2.81.5 of July 4, 2013;
 control panel frame location and focus broken
Date: Mon, 28 Nov 2016 23:46:22 -0800

To: kifer <at> cs.stonybrook.edu, bug-gnu-emacs <at> gnu.org
Subject: Ediff 2.81.5 of July 4, 2013; control panel frame location
and focus broken
From: Aaron Peterson <metaxis <at> gmail.com>
X-Reporter-Void-Vars-Found: ediff-patch-program ediff-patch-options
--text follows this line--


Congratulations!  You may have unearthed a bug in Ediff!

Please make a concise and accurate summary of what happened
and mail it to the address above.
-----------------------------------------------------------


Invoking "ediff-buffers" starts ediff with no visible control panel, in
either multiframe or plain.  There is a frame, but it is not visible.
It can be minimized with (iconify-frame), and it is then visible in the
dock, even showing the ediff help menu in the icon.

No visible control frame makes it difficult to switch *back* to ediff.
Using (other-frame) the frame remains invisible but can get focus, as
you can use ediff commands.

You can also get back to ediff by selecting the frame directly from the
Buffers menu or picking the ediff session from the registry.  But only by
creating a new frame and switching to the ediff control panel buffer
manually do you get a visible control panel.

However you get back to ediff, there is still a focus problem.  The
first command - like "n" or "p" often moves focus back to one of the two
buffers being diffed.  It can be reproduced with keyboard or mouse
actions - it appears to be every other time the control frame is
selected, say via mouse click or one of the above mechanisms, the next
action will lose focus.  I found a "workaround": get focus on the
control frame and toggle help "?".  Then you can safely execute other
actions without losing focus.

Thank you for your work!
-Aaron


Emacs  : GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS
appkit-1265.21 Version 10.9.5 (Build 13F1911))
 of 2016-09-20
Package: Ediff 2.81.5 of July 4, 2013

current state:
==============
(setq
 ediff-diff-program "diff"
 ediff-diff-options ""
 ediff-diff3-program "diff3"
 ediff-diff3-options ""
 ediff-shell "sh"
 ediff-use-faces t
 ediff-auto-refine 'on
 ediff-highlighting-style 'face
 ediff-buffer-A #<buffer 1st-scuba-dive.json>
 ediff-buffer-B #<buffer 1st-scuba-broke.json>
 ediff-control-buffer #<buffer *Ediff Control Panel*>
 ediff-forward-word-function 'ediff-forward-word
 ediff-control-frame #<frame Ediff 0x102d7a708>
 ediff-control-frame-parameters '((name . "Ediff") (minibuffer)
                                  (user-position . t) (vertical-scroll-bars)
                                  (scrollbar-width . 0) (scrollbar-height . 0)
                                  (menu-bar-lines . 0) (tool-bar-lines . 0)
                                  (left-fringe . 0) (right-fringe . 0)
                                  (auto-lower) (auto-raise . t) (visibility)
                                  (width . 1) (height . 1) (top . 1601)
                                  (left . 6561))
 ediff-control-frame-position-function 'ediff-make-frame-position
 ediff-prefer-iconified-control-frame nil
 ediff-window-setup-function 'ediff-setup-windows-multiframe
 ediff-split-window-function 'split-window-horizontally
 ediff-job-name 'ediff-buffers
 ediff-word-mode nil
 buffer-name "*Ediff Control Panel*"
 ediff-device-type 'ns
 )

Message #8 received at 25057 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: aaron peterson <metaxis <at> gmail.com>
Cc: kifer <at> cs.stonybrook.edu, 25057 <at> debbugs.gnu.org
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013;
 control panel frame location and focus broken
Date: Tue, 29 Nov 2016 20:03:20 +0200

> From: aaron peterson <metaxis <at> gmail.com>
> Date: Mon, 28 Nov 2016 23:46:22 -0800
> 
> Invoking "ediff-buffers" starts ediff with no visible control panel, in
> either multiframe or plain.  There is a frame, but it is not visible.
> It can be minimized with (iconify-frame), and it is then visible in the
> dock, even showing the ediff help menu in the icon.

I can't reproduce this, so it might be a Darwin specific problem.

Thanks.

Message #11 received at 25057 <at> debbugs.gnu.org (full text, mbox):

From: Michael Kifer <kifer <at> cs.stonybrook.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, aaron peterson <metaxis <at> gmail.com>
Cc: 25057 <at> debbugs.gnu.org
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame
 location and focus broken
Date: Tue, 29 Nov 2016 17:41:00 -0500

[Message part 1 (text/plain, inline)]

On 11/29/2016 01:03 PM, Eli Zaretskii wrote:
>> From: aaron peterson <metaxis <at> gmail.com>
>> Date: Mon, 28 Nov 2016 23:46:22 -0800
>>
>> Invoking "ediff-buffers" starts ediff with no visible control panel, in
>> either multiframe or plain.  There is a frame, but it is not visible.
>> It can be minimized with (iconify-frame), and it is then visible in the
>> dock, even showing the ediff help menu in the icon.
> I can't reproduce this, so it might be a Darwin specific problem.
>

me neither

[Message part 2 (text/html, inline)]

Message #14 received at 25057 <at> debbugs.gnu.org (full text, mbox):

From: aaron peterson <metaxis <at> gmail.com>
To: Michael Kifer <kifer <at> cs.stonybrook.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 25057 <at> debbugs.gnu.org
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame
 location and focus broken
Date: Tue, 29 Nov 2016 15:08:41 -0800

Sorry about the platform.  So this is more likely to be a problem with
window handling specific to the OS rather than ediff per se.  I don't
have any experience with emacs development, but I'd be happy to do

some more light-weight sleuthing such as:

* provide more detail or debug info
* try to repro against other versions of OS X (the bug was observed on
Darwin 16.1.0, "macOS 10.12")
* build and try fixes

Message #17 received at 25057 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: aaron peterson <metaxis <at> gmail.com>
Cc: 25057 <at> debbugs.gnu.org
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013;
 control panel frame location and focus broken
Date: Thu, 16 Feb 2017 20:03:28 +0100

On Tue, Nov 29 2016 at 03:08:41 pm, aaron peterson wrote:

> Sorry about the platform.  So this is more likely to be a problem with
> window handling specific to the OS rather than ediff per se.  I don't
> have any experience with emacs development, but I'd be happy to do
>
> some more light-weight sleuthing such as:
>
> * provide more detail or debug info
> * try to repro against other versions of OS X (the bug was observed on
> Darwin 16.1.0, "macOS 10.12")
> * build and try fixes

I can also reproduce this on 10.6/Snow Leopard.  I use the following as
a workaround:

(setq ediff-window-setup-function 'ediff-setup-windows-plain)

Message #20 received at 25057 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: aaron peterson <metaxis <at> gmail.com>
Cc: 25057 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013;
 control panel frame location and focus broken
Date: Sat, 18 Feb 2017 18:06:26 +0100

Ediff normally initializes its control frame to a location just outside
the viewable area of the monitor, then it brings the frame back into the
viewable area shortly afterwards.  With Emacs on OS X, though, it seems
that a frame that left the viewable area cannot return.

The following code slowly moves a frame across the width of the monitor
until it's a little past the viewable edge, then brings it back.

(let ((display-width (display-pixel-width))
      (dx            200)
      (frame-x       1))
  (setq frame-test (make-frame
		    `((top . 1) (left . ,frame-x))))
  (sleep-for 0.5)
  ;; 1. Move it until it's off-screen.
  (while (< frame-x display-width)
    (setq frame-x (+ frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  ;; 2. Bring it back.
  (while (> frame-x dx)
    (setq frame-x (- frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  (delete-frame frame-test))

On GNU/Linux, the frame comes back as expected.  But on OS X 10.6 the
frame does not return to the viewable area (step 2).  Maybe there is a
bug in the frame handling code for the NS port.

Message #25 received at 25057-done <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 25057-done <at> debbugs.gnu.org, metaxis <at> gmail.com, eliz <at> gnu.org
Subject: Re: bug#25057: Ediff 2.81.5 of July 4, 2013;
 control panel frame location and focus broken
Date: Tue, 22 Aug 2017 17:47:22 +0200

This is fixed in the next release (26.1), so I'm closing this bug.

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25818, and:

  commit 6e0cac4896f70b28b2a608fd63bc88b0253313bf
  Date:   Thu Apr 27 20:44:09 2017 +0200

  Constrain non-child frames to screen area in OS X

  * src/nsterm.m (constrainFrameRect:toScreen:): Constrain non-child
  frames in OS X, if they would otherwise go offscreen.

  Fixes: debbugs:25818

Previous Next

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