[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25943: 21.5 Frame Display Difficulties
From: |
martin rudalics |
Subject: |
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
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/02
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/03
- Message not available
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/04
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/06
- bug#25943: 21.5 Frame Display Difficulties,
martin rudalics <=
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/08
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/09
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/10
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/11
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/23
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/28
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/29
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/29
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/30