bug#25943: 21.5 Frame Display Difficulties

[martin rudalics <rudalics@gmx.at>]

 > It appears that you and I use our operating systems and emacs very
 > differently!  You use one workspace and never change.  I use nine
 > workspaces, run each application in its own workspace, often fullscreen,

The latter seems to indicate that popping up an additional frame on the
same workspace is the exception, not the rule.

 > and flip between them according to need.

I generally use one workspace, maximized frames and all sorts of key
combinations to switch between frames and windows.

 > It sounds as though you use
 > mouse activated menus, scroll bars, and a mouse.

In general only when testing or trying to reproduce scenarios described
in bug reports.

 > Yes.  It seems to me that problems one and two both are initialization
 > faults in some code or other.

So let's concentrate on these "initialization faults" first.  The basic
motivation for your code is that "Starting with a visible frame is tacky
because of the flashing that results".  Hence you want to start with an
invisible frame and show it only after you're done with positioning and
sizing it.  In a nutshell, you do

   (let ((invoking-frame  (selected-frame))
	(simple-frame (make-frame '((visibility . nil)))))
     (set-frame-size simple-frame 60 6)
     (set-frame-position
      simple-frame  -41 (frame-parameter invoking-frame 'top))
     (select-frame-set-input-focus simple-frame))

This will first create a frame with some default size and position, then
resize the frame and finally reposition it.  While this might work some
of the time with some window managers I wouldn't rely on it.

As a rule, users should not specify frame positions manually.  Window
managers dislike it.  Not because they think they are better at it but
because it disturbs their usual flow of control.  If you really need to
position and size a new frame, please stick to the following rules:

(1) Use frame parameters for specifying the position.  First they give
     you more freedom.  For example, you can't use ‘set-frame-position’
     to put a frame at the right edge of your display.  More importantly,
     they allow Emacs to do its work _before_ the frame becomes visible.

(2) Use frame parameters for specifying the size.  Again this allows
     Emacs to do the associated calculations before the frame becomes
     visible.

     When specifying the frame position via a negative offset (your "-41"
     above), rule (2) becomes even more important because Emacs has to
     calculate the prospective size of your frame before it can calculate
     its prospective position.

(3) Add a ‘user-position’ entry to your frame parameters.  It might not
     help with all but it might help with some window managers to clarify
     your intentions.

A sub-rule of (2): Use negative offsets with care.  The original sin of
the API of all window managing programs is that an application has to
specify the size of the inner (aka "client") rectangle and the position
of the outer (aka "display") rectangle.  Extracting the size differences
between these rectangles is difficult and sometimes virtually impossible
(just think of wrapping tool or menu bars resulting from changing the
major mode of a buffer shown in the selected window).  Everything Emacs
can provide here is just some approximative behavior.

Consequently, I would suggest to rewrite the above form as follows:

   (let ((simple-frame
	 (make-frame
	  `((visibility . nil)
	    (left . -41)
	    (top . ,(frame-parameter nil 'top))
	    (width . 60)
	    (height . 6)))))
     (select-frame-set-input-focus simple-frame))

Please try it and tell me whether it gives better results.

Thanks, martin