bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

> ;;; -*-Mode: emacs-lisp; Coding: emacs-mule; fill-column: 100-*-
>
> ;;; This file is executable and shows some problems indicated below.
> Execution is addressed further

Thank you for your mail, David

Unfortunately, it seems that the text got mangled in between, so please
consider making the comments normal text or sending it as attachment.
Some short comments:

> ;;; The first problem is that 25.1 does not position a new frame correctly
> unless the frame is
> ;;; visible when created.  Starting with a visible frame is tacky because
> of the flashing that
> ;;; results.  Command simple-doit-1 demonstrates this,

What does this command demonstrate?  The flashing or some wrong
positioning?  Could you come up with a one-step example where the frame
gets positioned differently in the two versions you mention?  Here the
frame just moves around my screen getting larger with every step.

> see below for notes
> on execution.
>
> ;;; I spent a lot of time looking in the wrong places for a bug, but have
> concluded that the problem
> ;;; is more of a design issue.  I think that I have identified what is
> happening, but I leave that
> ;;; to you to judge.  The problem appears at xterm.c:10971, and is alluded
> to in window.c:2335-2340.
>
> ;;; This is from window.c
> ;;;                     /* Yuck!!  If we've just created the frame and the
> ;;;                        window-manager requested the user to place it
> ;;;                        manually, the window may still not be considered
> ;;;                        `visible'.  I'd argue it should be at least
> ;;;                        something like `iconified', but don't know how to 
do
> ;;;                        that yet.  --Stef  */

Can you tell me why you think that this is relevant for the problem at
hand?  Where does your code need candidate_p?

> ;;; This is part of x_make_frame_visible at line xterm.c:10963
> ;;;       Don't do this if the window has never been visible before,
> ;;;       because the window manager may choose the position
> ;;;       and we don't want to override it.  */
> ;;;
> ;;;    if (! FRAME_VISIBLE_P (f)
> ;;;        && ! FRAME_ICONIFIED_P (f)
> ;;;        && ! FRAME_X_EMBEDDED_P (f)
> ;;;        && f->win_gravity == NorthWestGravity
> ;;;        && previously_visible)

This part of the code was in xterm.c at least in 2003 as

    if (! FRAME_VISIBLE_P (f) && ! FRAME_ICONIFIED_P (f)
        && f->output_data.x->win_gravity == NorthWestGravity
        && previously_visible)

Why do you think it's impact on the behavior of your code changed?

> ;;; So, my case is that I create a frame and want to position it before I
> make it visible, this is
> ;;; nothing to do with the window manager.

I'm afraid it does.  The window manager might not want to position an
invisible frame.

> I can solve the problem by
> eliminating the
> ;;; "previously_visible" part of the test above, and I am doing that as a
> temporary get-around.
> ;;; But, of course, that elimination cuts across your window manager
> concern.

The previously_visible check should be present in your Emacs 23.2
version.  So something else must be involved here.

> ;;; The third problem was to have been demonstrated with another command,
> but I have been unable to
> ;;; reproduce the problem in a simple function.  The problem is a sometime
> occurring,
> ;;; display-wrecking, problem.  I wonder if it is not even an emacs
> problem, but due to underlying
> ;;; rendering library code.  The problem is repeatable.  Also, it is new
> in 25.1 compared with 23.2.
>
> ;;; What I have done is take a screen shot showing the problem, a .jpg
> image is attached, the screen
> ;;; shot is cropped.  What is shown is two frames, the green frame is a
> frame generated by executing
> ;;; code (similar to simple-doit-1, but considerably more complicated),
> the cream frame is the main
> ;;; emacs frame.  The black is the xterm background.  The frame windows
> are displaying the same
> ;;; buffer, at the same time, normally these displays are identical
> because the buffer is the same.
> ;;; The green frame in the image shows a distorted text display, this
> frame always is correctly
> ;;; sized for the correct text.  The break at the sixty-first column is
> repeatable, but other
> ;;; displays break at other places.

The frames look very special - no modelines, no echo area, no scroll
bars, no decorations but for the title bar of the green frame.  Could
you try to remove all these specialities so we can compare the frames
more easily?

Thanks, martin