all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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))) ))



  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.