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

[martin rudalics]

>> 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