bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[aaron peterson]

To: kifer@cs.stonybrook.edu, bug-gnu-emacs@gnu.org
Subject: Ediff 2.81.5 of July 4, 2013; control panel frame location
and focus broken
From: Aaron Peterson <metaxis@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
 )

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[Eli Zaretskii]

> From: aaron peterson <metaxis@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.

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[Michael Kifer]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]


On 11/29/2016 01:03 PM, Eli Zaretskii wrote:
>> From: aaron peterson <metaxis@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



[-- Attachment #2: Type: text/html, Size: 1011 bytes --]

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[aaron peterson]

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

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[Charles A. Roelli]

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)

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[Charles A. Roelli]

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.

bug#25057: Ediff 2.81.5 of July 4, 2013; control panel frame location and focus broken

[Charles A. Roelli]

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