GNU bug report logs - #25943
21.5 Frame Display Difficulties

Previous Next

Full log

Message #17 received at 25943 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: david <at> ngdr.net
Cc: 25943 <at> debbugs.gnu.org
Subject: Re: bug#25943: 21.5  Frame Display Difficulties
Date: Tue, 07 Mar 2017 10:45:28 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.