From: martin rudalics <rudalics@gmx.at>
To: david@ngdr.net
Cc: 25943@debbugs.gnu.org
Subject: bug#25943: 21.5 Frame Display Difficulties
Date: Tue, 07 Mar 2017 10:45:28 +0100 [thread overview]
Message-ID: <58BE8138.1040607@gmx.at> (raw)
In-Reply-To: <49adf8e1615512ac19189d75b5e04315@127.0.0.1>
>> 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
next prev parent reply other threads:[~2017-03-07 9:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 3:51 bug#25943: 21.5 Frame Display Difficulties david
2017-03-03 8:13 ` martin rudalics
[not found] ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>
2017-03-04 9:59 ` martin rudalics
2017-03-07 1:51 ` david
2017-03-07 9:45 ` martin rudalics [this message]
2017-03-08 22:58 ` david
2017-03-09 8:56 ` martin rudalics
2017-03-10 18:44 ` david
2017-03-11 10:21 ` martin rudalics
2017-03-23 7:59 ` martin rudalics
2017-03-28 22:43 ` david
2017-03-29 7:36 ` martin rudalics
2017-03-29 19:53 ` david
2017-03-30 7:29 ` martin rudalics
2017-04-01 4:35 ` david
2017-04-01 7:36 ` martin rudalics
[not found] ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1>
2017-04-02 7:55 ` martin rudalics
2017-04-04 0:35 ` david
2017-04-04 7:25 ` martin rudalics
2017-04-07 0:12 ` david
2017-04-07 5:56 ` martin rudalics
2017-04-07 21:16 ` david
2022-04-25 14:48 ` Lars Ingebrigtsen
2022-05-24 12:50 ` Lars Ingebrigtsen
2017-04-07 21:19 ` david
2017-04-08 9:00 ` martin rudalics
2017-04-11 6:49 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58BE8138.1040607@gmx.at \
--to=rudalics@gmx.at \
--cc=25943@debbugs.gnu.org \
--cc=david@ngdr.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.