bug#25380: 25.1; save-window-excursion problem in batch mode

[martin rudalics <rudalics@gmx.at>]

 >> IIUC the pixel comes from a menubar line which gets spuriously added.
 >
 > I believe you are right, see the backtrace below from the place which
 > changes the value from 0 to 1 (it's not pixel units, btw, it's
 > character units, AFAIU).

At the time the comparison fails in ‘compare-window-configurations’ it's
at !EQ (sw1->pixel_top, sw2->pixel_top) so it's off by one pixel.  It
probably would fail later at !EQ (sw1->top_line, sw2->top_line) as well.

 > More accurately, the initial current-window-configuration call happens
 > so early that the basic geometry of the "windows" is not yet set, and
 > in particular the menu bar is not yet computed and accounted for.
 > This is indeed where Emacs 25 behaves differently from previous
 > versions, and for a very good reason.

Does the basic geometry of the "windows" ever get set?  Would I have to
create a frame manually for that?

 >> If someone told me how to debug this, I might be able to tell more.
 >
 > I just ran Emacs under a debugger with a breakpoint in
 > Fcurrent_window_configuration, then put a watchpoint on every top_line
 > member of every window that got saved there, and waited for it to
 > break.

That's obvious.  But how do I find out where that menubar line gets set?

 >> I have no idea how the frame seen by ‘current-window-configuration’
 >> gets created in batch mode.
 >
 > It comes from temacs, AFAIR.

Hmm... the normal "F1" frame made by ‘make_initial_frame’.  Still: Who
adds the menubar line?  AFAIK neither NS nor GTK should.

 > I'm not actually certain we should try fixing this, unless Martin can
 > do that in some easy and safe way.  The code involved in this is quite
 > fragile, because Emacs creates its first frame without knowing
 > anything about its geometry and the window-system.  That code took a
 > long time to get right on all systems; I'd hate to break it to cater
 > to (IMO) much less important use cases.  I'd rather people wouldn't
 > count on anything related to "frames" and "windows" in the batch
 > session, except that they exist.  (They must exist because some
 > functions will simply not work without a frame or a window.)

So far I can't do anything here - this is code I cannot debug.  At the
time ‘compare-window-configurations’ gets called it's already much too
late :-(

 > IOW, I think unit tests that must compare windows cannot be naïvely
 > run in batch mode; you need to use tricks.  For example:
 >
 >    emacs -batch -eval "(progn (save-window-excursion (current-window-configuration)) (print (equal (save-window-excursion (current-window-configuration)) (current-window-configuration))))" => t

emacs -batch -eval "(progn (menu-bar-mode -1) (print (equal (save-window-excursion (current-window-configuration)) (current-window-configuration))))"

works here too.

martin