From: <david@ngdr.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 25943@debbugs.gnu.org
Subject: bug#25943: 21.5 Frame Display Difficulties
Date: Wed, 08 Mar 2017 15:58:58 -0700 [thread overview]
Message-ID: <142b4d1d519a6bf87a5fe320d9eeb419@127.0.0.1> (raw)
In-Reply-To: <58BE8138.1040607@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]
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
[-- Attachment #2: doit-2-as-sent.el --]
[-- Type: text/plain, Size: 2375 bytes --]
\f
(global-set-key [f12] 'simple-doit-2)
(defun simple-doit-2 ()
"Tests fit-frame-to-buffer."
(interactive)
(let ((simple-frame (make-frame `((name . "Simple Frame")
(visibility . ,simple-visibility))) )
(simple-buffer (get-buffer-create "Simple Buffer")))
(set-window-buffer (frame-selected-window simple-frame) simple-buffer)
(with-current-buffer simple-buffer (erase-buffer)
(insert (format "version %s" .emacs-current-emacs-version)))
;;; (raise-frame simple-frame)
(let* ((invoking-frame (selected-frame))
(newish (<= 25.1 (string-to-number .emacs-current-emacs-version)))
(invoke-origin (if newish
(frame-position invoking-frame)
'(0 . 25)))
(invoke-left (car invoke-origin))
(invoke-top (cdr invoke-origin))
(left -41)
(top invoke-top)
(width 60)
(height 6))
(unwind-protect
(while (progn
;;; (set-frame-size simple-frame width height)
(set-frame-position simple-frame left top)
(or (frame-visible-p simple-frame)
(raise-frame simple-frame))
(select-frame-set-input-focus simple-frame)
(set-buffer simple-buffer)
(goto-char (point-max))
(insert (format "\n%s l:%3d t:%3d w:%3d h:%3d"
(selected-frame) left top width height))
(fit-frame-to-buffer simple-frame)
(setq left (+ left 10)
top (+ top 10)
height (+ height 1))
(if newish (discard-input))
;; loop test
(not (equal
(read-event "press any key to continue, escape to terminate")
'escape))) )
;; end no body while
;; Protected.
(select-frame invoking-frame)
(delete-frame simple-frame))) ))
next prev parent reply other threads:[~2017-03-08 22:58 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
2017-03-08 22:58 ` david [this message]
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=142b4d1d519a6bf87a5fe320d9eeb419@127.0.0.1 \
--to=david@ngdr.net \
--cc=25943@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/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.