bug#25943: 21.5 Frame Display Difficulties

[martin rudalics <rudalics@gmx.at>]

 >> It seems related to bug#24526 but when I run your example with
 >> simple-visibility set to 'icon the frame is positioned at -41 here.  Can
 >> you try that - I mean, run your code with
 >>
 >> (defconst  simple-visibility  'icon)
 >
 > This does solve the problem.  However, interestingly, previously_visible
 > never becomes true, even after multiple appearances of the frame:
 >
 > Thread 1 "emacs-25.1.13" hit Breakpoint 1, x_make_frame_visible
 > (f=0x1a80740) at xterm.c:10948
 > 10948	    bool previously_visible = f->output_data.x->has_been_visible;
 > 1: previously_visible = false
 >
 > As you have written: So something else must be involved here.
 > ditto: ... a reminder that things might be more complicated.
 >
 > Also, this, as a solution, must be considered a get-around; this is
 > because it is not true that the new frame is/has been iconified.

Yes.  I just wanted to know how this would behave.  There is also

https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html

which seems to hint in the same direction.  There were some changes in
the GTK/X11 code last year I haven't been able to track down yet.

 > Building --with-x-toolkit=no eliminates problem one, also appears to
 > eliminate problem two (see below), I have not seen problem two, as
 > generated by the sample code, under this no-toolkit build with either of
 > calls emacs -Q or emacs with a full load from my .emacs.  Wonderful!

Not really.  Nowadays practically all people build with some form of
toolkit support.  So no-toolkit is no viable alternative.

 > FYI, I have a policy, with multiple applications, of not disturbing
 > recommended practices on the assumption that an item's creator has better
 > insight than I.  With emacs this means that I build with a simple
 > ./configure; make.  As a result of the policy I get what is delivered to
 > me.  The key point is that (probably) I have never tried to build without
 > using a toolkit.  And now I am wondering just what it is that a toolkit
 > offers me.

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.

 > I apologize, I did not explain well.  The effect that I see under 25.1 in
 > the sample code is that, after pressing f11 once, instead of:
 >
 >> version 25.1
 >> #<frame Simple Frame 0337dac8>  l:-41  t: 88  w: 60  h:  6
 >
 > I see:
 >
 >> version 25.1
 >> #<frame Simple Frame 0337dac8>  l:-41  t: 88  w: 60  h:  6
 >> #<frame Simple Frame 0337dac8>  l:-31  t: 98  w: 60  h:  7

So "bouncing" happens only once, namely when setting up the initial
size?

 > 1st run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 1st run 25.1.1 -Q and simple-visibility = t   => no "key bounce" effect !
 > The ! means I was expecting the effect.
 >
 > killed emacs
 >
 > 2nd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 2nd run 25.1.1 -Q and simple-visibility = t   => "key bounce" effect
 >
 > killed emacs
 >
 > 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 3rd run 25.1.1 -Q and simple-visibility = t   => "key bounce" effect
 > 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 3rd run 25.1.1 -Q and simple-visibility = t   => "key bounce" effect
 >
 > Here I evaluated the buffer four times, as indicated.  Then I **changed
 > workspace** to go back to the emacs where I am writing this text, wrote
 > part of this text, **returned to the workspace** where I am running the
 > test emacs above, and:
 >
 > 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 3rd run 25.1.1 -Q and simple-visibility = t   => no "key bounce" effect !
 >
 > killed emacs
 >
 > 4th run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect
 > 4th run 25.1.1 -Q and simple-visibility = t   => "key bounce" effect

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

 >> Does this depend on the width of the window?  What happens when you set
 >> ‘truncate-lines’ to t?  What happens when you disable margins and
 >> fringes in the window?
 >
 > The no-toolkit build does not solve problem three; however, it does seem
 > to change where it happens.
 >
 > I use popup frames to display arbitrary text, by which I mean texts with,
 > a priori, unknown numbers of rows and columns.  The text is "sized up" by
 > my code and the frame size specified accordingly.  I already disable
 > margins, fringes, etc.  These popups are very much like tooltip popups.
 > At one time I had C code, based on tooltip code, that produced the popups.
 > But, emacs changed, my code no longer worked, and the fact is that for a
 > few years now, I believe due to hardware advances, plentiful memory, etc.,
 > there has been no point in having special code.  The standard make-frame,
 > etc. work very well.  So, with regard to the problem, the frames always
 > are correct for the target text, width and height.

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.

 > 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’.

Thanks, martin