bug#25943: 21.5 Frame Display Difficulties

[david]

Hello Martin,

Summaries:

> So we can conclude that the effect depends on changing workspace when
> creating a new frame.  Interesting.  I never change workspace.

I think that your conclusion goes a little too far; for example, simply
re-starting emacs can do it as well.
 
> I suppose that most people on GNU/Linux want to build with GTK.  In my
> limited experience GTK builds are the worst ones (excluding the Gnustep
> builds).  They are not bad because GTK is bad.  I suppose they are bad
> because of a few historic constraints established by Emacs itself.  IMO
> toolkit builds could be as smooth as non-toolkit ones and still offer
> most advantages of the toolkit (better menus and scroll bars, in
> particular) if these constraints were removed.  But doing that is hard.

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,
and flip between them according to need.  It sounds as though you use
mouse activated menus, scroll bars, and a mouse.  I eliminate the menu bar
and scroll bars and control emacs with key bindings, no mouse.  I am in
favour of supporting these different ways of doing things, however, just
in case there is any question about that.

> If the code is evaluated as supplied, and assuming emacs is started with
> -Q, and assuming that performance is what I see on my machine, the first
> display of the popup is incorrectly positioned; ....
> 
> So "bouncing" happens only once, namely when setting up the initial
> size?

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


> Could you try the function ‘fit-frame-to-buffer’ for sizing the frame
> and tell me whether it also exhibits problem 3?  Just make a normal
> frame, put your buffer into that frame's selected window and call that
> function.

I have created simple-doit-2, attached, which shows what happens (this
uses code in the original executable file).  There are two ways shown to
raise the frame, which give two slightly different behaviours.  I am
pretty sure that problem 3 is buried deeper than this; and I have a sneaky
suspicion that this, too, is an initialization problem.

>  > Thus, truncate-lines does not really enter into the picture: I size
the
>  > frame to the text, rather than writing text into a fixed-size frame. 
I
>  > think that I see why you ask the question: the problem I have shows
>  > continuation arrows, which do not appear if the software is behaving
>  > itself.  Can you tell me where to look to see if I can find out
anything?
>  > It seems to me that the key is to consider that the same buffer is
being
>  > rendered differently in two frames.
> 
> If ‘fit-frame-to-buffer’ exhibits problem 3, we don't have to delve into
> the depths of your code and we can try to improve ‘fit-frame-to-buffer’.
> If it does not have problem 3, you could try to make your code behave a
> bit like ‘fit-frame-to-buffer’.

I do not think that problem 3 is caused by a mis-match between buffer
content and frame size.  Note that the original screenshot shows a gap
between the right of the text and the right side of the frame.

David

doit-2-as-sent.el
Description: Text document