bug#25943: 21.5 Frame Display Difficulties

[david]

Hello Martin,

I am a bit surprised by the content of your reply.  I wonder if I have
offended you; if I have I apologize; I assure you I do not know how, nor
was it intentional.

In view of what you have written I do think that I need to do a reset and
try to make clear how I see things.  I have core code, extended over
years, that has run successfully on emacs 18.n, 19.n, 20.n, 21.n, 22.n,
and 23.n.  The code, and emacs, have run successfully on numerous
platforms and operating systems, the ones I remember being DEC/Unix,
IBM/aix, PC/Windows NT, and PC/Linux(various).  I cannot remember much
about the window managers I have used, I just take what is there.  Over
the years I have become increasingly grateful for emacs because emacs has
kept me insulated from the vagaries of the hardware and software on which
I have been running.  When moving to a new version of emacs, sometimes I
have needed to make minor changes, and, since I have a small amount of C
code that is necessary for me, I have always needed to modify a few C
files, make update patches, etc.; but that is all, the lisp has gone on
forever.  Upgrading has been simple and, crucially, _possible_!  It is not
always possible with software to rehost.

I want to emphasize the "insulated" part of what I have written.  I have
successfully transferred my code from emacs version to version, host
machine to machine, run across the internet running on one OS and
displaying on another, etc.; and all the time emacs has, very simply, got
on with it.  I am constantly staggered by the flexibility of emacs, at any
time, and over time, and its ability, I repeat, to insulate me from the
hardware and software changes that are occurring underneath the code that
I write.

Now I have to upgrade my OS and emacs version again.  This time a couple
of
nasty things have happened.  It is very simple: emacs 25.1 has failed.  I
have no reason to think that my code is faulty; it has not been changed
and the same lisp code (not even a copy) is running right now on emacs
23.2 as it has run for a long, long, time on other versions.  My code runs
on 25.1 except for a couple of, for me, serious, display bugs.  I
submitted a bug report to the best of my ability; and I still hope that
the bugs will be repaired; I still want to use emacs.


The above is my starting point, not what you have written.  In addition,
there are other things that are disturbing.  One is that you write

    "As a rule, users should not specify frame positions manually.  Window
     managers dislike it.  Not because they think they are better at it
     but because it disturbs their usual flow of control."

So, for the first time in a quarter of a century, I, an emacs user, have
to concern myself with the window manager that I am using?  Also: "While
this might work some of the time with some window managers I wouldn't rely
on it."  So, successfully transferring emacs and my code in the way that I
have in the past has been thrown out of the window, emacs is no longer
going to handle such things as it has done so magnificently in the past?

The second disturbing point is "If you really need to position and size a
new frame, please stick to the following rules:".  Sorry, but no.  I am
not a cowboy programmer; also I am quite compulsive about sticking to
conventions and rules; generally, I find that to be good practice.  But
the rules that you have announced are there for the wrong reason: emacs
25.1 cannot do what its predecessors have done.  It should not be the
responsibility of a user to cover the failings of a new version of emacs.

Thirdly, do you really think that my code is so simple, or so buggy, that
I can zip in and change a couple of things to get it working again?  I
hope not.  Also, if a function such as set-frame-position exists and is
documented, then it should be usable and it should work.  Otherwise,
there is a bug.


This thread has gone off track, regrettably.  Here is my summary of the
present status of the three problems I have had with 25.1:

Problem one [initial display of a new invisible frame is not correctly
placed] has been identified clearly.  This problem can be demonstrated
with simple lisp code.  The problem only occurs when a toolkit is used.
There are a couple of get-arounds.  The problem source has not been found.

Problem two [initial display of a new visible frame can involve
non-clearing of the terminal input buffer] has been identified mainly by
its solution, which is appropriate use of (discard-input).  This problem
can be demonstrated with simple lisp code when it occurs, which may be
machine dependent.  The problem source has not been found.

Problem three [buffer display in a new frame can be truncated] has not
been demonstrated with simple code.  However, this is a serious display
problem that has arisen with 25.1.  The problem source has not been found.


I hope both that the above is a reasonable description of the problems,
and that progress can be made on these problems; I am willing to help to
the extent that I can.

David



On Thu, 09 Mar 2017 09:56:42 +0100, martin rudalics <rudalics@gmx.at>
wrote:
>> 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,
> 
> The latter seems to indicate that popping up an additional frame on the
> same workspace is the exception, not the rule.
> 
>  > and flip between them according to need.
> 
> I generally use one workspace, maximized frames and all sorts of key
> combinations to switch between frames and windows.
> 
>  > It sounds as though you use
>  > mouse activated menus, scroll bars, and a mouse.
> 
> In general only when testing or trying to reproduce scenarios described
> in bug reports.
> 
>  > Yes.  It seems to me that problems one and two both are
initialization
>  > faults in some code or other.
> 
> So let's concentrate on these "initialization faults" first.  The basic
> motivation for your code is that "Starting with a visible frame is tacky
> because of the flashing that results".  Hence you want to start with an
> invisible frame and show it only after you're done with positioning and
> sizing it.  In a nutshell, you do
> 
>    (let ((invoking-frame  (selected-frame))
>       (simple-frame (make-frame '((visibility . nil)))))
>      (set-frame-size simple-frame 60 6)
>      (set-frame-position
>       simple-frame  -41 (frame-parameter invoking-frame 'top))
>      (select-frame-set-input-focus simple-frame))
> 
> This will first create a frame with some default size and position, then
> resize the frame and finally reposition it.  While this might work some
> of the time with some window managers I wouldn't rely on it.
> 
> As a rule, users should not specify frame positions manually.  Window
> managers dislike it.  Not because they think they are better at it but
> because it disturbs their usual flow of control.  If you really need to
> position and size a new frame, please stick to the following rules:
> 
> (1) Use frame parameters for specifying the position.  First they give
>      you more freedom.  For example, you can't use ‘set-frame-position’
>      to put a frame at the right edge of your display.  More
importantly,
>      they allow Emacs to do its work _before_ the frame becomes visible.
> 
> (2) Use frame parameters for specifying the size.  Again this allows
>      Emacs to do the associated calculations before the frame becomes
>      visible.
> 
>      When specifying the frame position via a negative offset (your
"-41"
>      above), rule (2) becomes even more important because Emacs has to
>      calculate the prospective size of your frame before it can
calculate
>      its prospective position.
> 
> (3) Add a ‘user-position’ entry to your frame parameters.  It might not
>      help with all but it might help with some window managers to
clarify
>      your intentions.
> 
> A sub-rule of (2): Use negative offsets with care.  The original sin of
> the API of all window managing programs is that an application has to
> specify the size of the inner (aka "client") rectangle and the position
> of the outer (aka "display") rectangle.  Extracting the size differences
> between these rectangles is difficult and sometimes virtually impossible
> (just think of wrapping tool or menu bars resulting from changing the
> major mode of a buffer shown in the selected window).  Everything Emacs
> can provide here is just some approximative behavior.
> 
> Consequently, I would suggest to rewrite the above form as follows:
> 
>    (let ((simple-frame
>        (make-frame
>         `((visibility . nil)
>           (left . -41)
>           (top . ,(frame-parameter nil 'top))
>           (width . 60)
>           (height . 6)))))
>      (select-frame-set-input-focus simple-frame))
> 
> Please try it and tell me whether it gives better results.
> 
> Thanks, martin