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

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

[Philipp Stephani]

Apparently, restoring a window configuration doesn't result in the same
window configuration in batch mode:

$ emacs -Q -batch -eval '(print (equal (save-window-excursion (current-window-configuration)) (current-window-configuration)))'

nil

This is unexpected, especially in unit tests that want to check window
comparisons.  In interactive mode, this works (i.e. (equal
(save-window-excursion (current-window-configuration))
(current-window-configuration)) is t).




In GNU Emacs 25.1.1 (x86_64-apple-darwin15.6.0, NS appkit-1404.47 Version 10.11.6 (Build 15G1004))
 of 2016-09-22 built on p
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs/25.1/share/info/emacs
 --prefix=/usr/local/Cellar/emacs/25.1 --without-x --with-xml2
 --without-dbus --without-gnutls --with-rsvg --with-ns
 --disable-ns-self-contained'

Configured features:
JPEG RSVG NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 196126 8185)
 (symbols 48 19634 0)
 (miscs 40 50 169)
 (strings 32 15015 5817)
 (string-bytes 1 435313)
 (vectors 16 32909)
 (vector-slots 8 654000 5657)
 (floats 8 158 18)
 (intervals 56 210 0)
 (buffers 976 18))

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

[Glenn Morris]

Philipp Stephani wrote:

> Apparently, restoring a window configuration doesn't result in the same
> window configuration in batch mode:
>
> $ emacs -Q -batch -eval '(print (equal (save-window-excursion (current-window-configuration)) (current-window-configuration)))'
>
> nil

It works in 24.5 and earlier. Something to do with window-edges?

emacs -Q -batch --eval '(progn (setq c (current-window-configuration))
(print (window-edges))
(set-window-configuration c)
(print (window-edges)))'

24.5:
(0 1 10 9)
(0 1 10 9)

25.1:
(0 0 10 9)
(0 1 10 10)

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

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 4506 bytes --]

Glenn Morris <rgm@gnu.org> schrieb am So., 8. Jan. 2017 um 19:37 Uhr:

> Philipp Stephani wrote:
>
> > Apparently, restoring a window configuration doesn't result in the same
> > window configuration in batch mode:
> >
> > $ emacs -Q -batch -eval '(print (equal (save-window-excursion
> (current-window-configuration)) (current-window-configuration)))'
> >
> > nil
>
> It works in 24.5 and earlier. Something to do with window-edges?
>
> emacs -Q -batch --eval '(progn (setq c (current-window-configuration))
> (print (window-edges))
> (set-window-configuration c)
> (print (window-edges)))'
>
> 24.5:
> (0 1 10 9)
> (0 1 10 9)
>
> 25.1:
> (0 0 10 9)
> (0 1 10 10)
>

According to 'git bisect' one of the following commits is the culprit:

768b24eb0e On GNU/Linux, use timerfd for asynchronous timers. * configure.ac
(toplevel): Check whether GNU/Linux-specific timerfd functions and macros
are available. * m4/clock_time.m4 (gl_CLOCK_TIME): Check for clock_getres
as well. * src/atimer.c (toplevel) [HAVE_TIMERFD]: Include sys/timerfd.h.
(toplevel): Rename alarm_timer_ok to special_timer_available.
[HAVE_TIMERFD]: Declare timerfd. [HAVE_CLOCK_GETRES]: Declare resolution.
(start_atimer) [HAVE_CLOCK_GETRES]: Round up timestamp to system timer
resolution. (set_alarm) [HAVE_TIMERFD]: Use timerfd_settime.
(timerfd_callback) [HAVE_TIMERFD]: New function. (atimer_result,
debug_timer_callback, Fdebug_timer_check) [ENABLE_CHECKING]: New function
for the sake of automated tests. (init_atimer) [HAVE_TIMERFD]: Setup
timerfd. [HAVE_CLOCK_GETRES]: Likewise for system timer resolution.
[ENABLE_CHECKING]: Defsubr test function. * src/atimer.h (timerfd_callback)
[HAVE_TIMERFD]: Add prototype. * src/lisp.h (add_timer_wait_descriptor)
[HAVE_TIMERFD]: Likewise. * src/process.c (add_timer_wait_descriptor)
[HAVE_TIMERFD]: New function. * test/automated/timer-tests.el
(timer-tests-debug-timer-check): New test.

7daa4ff121 Parse completion input in a iPython friendly way.

a7947cd874 Fix the GDB xsubchartable command.

34c6b847fb Fix --without-x build and pacify --enable-gcc-warnings. Problems
reported in Bug#18122 and Bug#18124. * frame.c (get_frame_param): Define
even if !HAVE_WINDOW_SYSTEM. (frame_windows_min_size): Now static. *
frame.h (FRAME_HAS_HORIZONTAL_SCROLL_BARS) [!HAVE_WINDOW_SYSTEM]: Define as
no-op. (adjust_frame_size): Always declare prototype.

4256626a7a Prevent Python process shell buffer to pop twice. *
lisp/progmodes/python.el (python-shell-switch-to-shell): Do not call
pop-to-buffer.

414e1537ab Open doc text also if it's not saved to a file.

ca43b53625 * lisp/progmodes/python.el (python-shell-with-shell-buffer): New
macro. (python-shell-font-lock-get-or-create-buffer)
(python-shell-font-lock-kill-buffer)
(python-shell-font-lock-with-font-lock-buffer)
(python-shell-font-lock-cleanup-buffer) (python-shell-font-lock-toggle):
Use it. (python-shell-font-lock-turn-on) (python-shell-font-lock-turn-off):
Use it.  Make command.

da41ffdd08 Merge from emacs-24; up to 2014-06-26T06:55:15Z!rgm@gnu.org

f5bed1021b Grab all Python process output before inferior-python-mode hooks.

168f8e732d * frame.c (x_set_frame_parameters): Don't use uninitialized
locals.

2daa203c3e Fix Gnus-related issues reported by David Kastrup <dak@gnu.org>
in <http://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00370.html>. *
atimer.c (timerfd_callback): Always read expiration data. Add comment.
(turn_on_atimers) [HAVE_TIMERFD]: Disarm timerfd timer. * process.c
(add_timer_wait_descriptor): Add timer descriptor to input_wait_mask and
non_process_wait_mask as well.

5dc4b8ca3d Fix some issues with setting the frame height.

72c64ae95a More robust shell startup and code setup.

0f6bbc3da3 Support horizontal scrolling of bidirectional text.

81abec91ee * net/tramp-sh.el (tramp-get-remote-python): Also search for
executables named "python2" or "python3".
(tramp-get-remote-uid-with-python): Use parentheses around arguments to
`print' to make it compatible with Python 3.
(tramp-get-remote-gid-with-python): Ditto.

8862cff49c Fix Changelog typo, introduced by last commit.

96fa02baec Reinstate removed code.

3477e27021 Complete pixelwise frame/window resizing, add horizontal
scrollbar support.

6628be853e * lisp/progmodes/python.el (inferior-python-mode): Make input
prompts read-only.

8e3b4f58f1 In adjust_frame_size use FRAME_WINDOW_P instead of
FRAME_X_WINDOW (Bug#18138).


Unfortunately compilation fails with these commits (on macOS), so I can't
narrow it down any further.

[-- Attachment #2: Type: text/html, Size: 6154 bytes --]

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

[martin rudalics]

 >> Apparently, restoring a window configuration doesn't result in the same
 >> window configuration in batch mode:
 >>
 >> $ emacs -Q -batch -eval '(print (equal (save-window-excursion (current-window-configuration)) (current-window-configuration)))'
 >>
 >> nil
 >
 > It works in 24.5 and earlier. Something to do with window-edges?
 >
 > emacs -Q -batch --eval '(progn (setq c (current-window-configuration))
 > (print (window-edges))
 > (set-window-configuration c)
 > (print (window-edges)))'
 >
 > 24.5:
 > (0 1 10 9)
 > (0 1 10 9)
 >
 > 25.1:
 > (0 0 10 9)
 > (0 1 10 10)

IIUC the pixel comes from a menubar line which gets spuriously added.
If someone told me how to debug this, I might be able to tell more.  I
have no idea how the frame seen by ‘current-window-configuration’ gets
created in batch mode.  I never use batch mode.

martin

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

[Eli Zaretskii]

> Date: Mon, 09 Jan 2017 10:39:36 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 25380@debbugs.gnu.org
> 
> > It works in 24.5 and earlier. Something to do with window-edges?
> >
> > emacs -Q -batch --eval '(progn (setq c (current-window-configuration))
> > (print (window-edges))
> > (set-window-configuration c)
> > (print (window-edges)))'
> >
> > 24.5:
> > (0 1 10 9)
> > (0 1 10 9)
> >
> > 25.1:
> > (0 0 10 9)
> > (0 1 10 10)
> 
> 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).

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.

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

> I have no idea how the frame seen by ‘current-window-configuration’
> gets created in batch mode.

It comes from temacs, AFAIR.

Turning back to the original report:

> $ emacs -Q -batch -eval '(print (equal (save-window-excursion 
> (current-window-configuration)) (current-window-configuration)))'
> 
> nil
> 
> This is unexpected, especially in unit tests that want to check window
> comparisons.  In interactive mode, this works (i.e. (equal
> (save-window-excursion (current-window-configuration))
> (current-window-configuration)) is t).

(This works in an interactive session because by the time you evaluate
the form, the frame geometry has been completely computed and set up.)

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

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

Here's the backtrace which shows where we change the top pixel from
zero to 1:

Thread 1 hit Hardware watchpoint 4: -location w->pixel_top

Old value = 0
New value = 1
resize_frame_windows (f=0x17752c8 <dumped_data+95208>, size=10,
    horflag=false, pixelwise=true) at window.c:4125
4125            r->total_lines = new_size;
(gdb) bt
#0  resize_frame_windows (f=0x17752c8 <dumped_data+95208>, size=10,
    horflag=false, pixelwise=true) at window.c:4125
#1  0x01014819 in adjust_frame_size (f=0x17752c8 <dumped_data+95208>,
    new_width=-1, new_height=-1, inhibit=1, pretend=false, parameter=52528)
    at frame.c:550
#2  0x010cf523 in Fset_window_configuration (
    configuration=-6917529027611094376) at window.c:6404
#3  0x012278e1 in eval_sub (form=-4611686018401701024) at eval.c:2211
#4  0x01220476 in Fprogn (body=-4611686018401701056) at eval.c:450
#5  0x0122052a in unwind_body (body=-4611686018401701056) at eval.c:463
#6  0x0122c92a in do_one_unbind (this_binding=0x88dc10, unwinding=true)
    at eval.c:3379
#7  0x0122cd0c in unbind_to (count=18, value=-6917529027611093664)
    at eval.c:3499
#8  0x01223b37 in Funwind_protect (args=-4611686018401701584) at eval.c:1198
#9  0x01227368 in eval_sub (form=-4611686018401701600) at eval.c:2164
#10 0x01220476 in Fprogn (body=-4611686018401701648) at eval.c:450
#11 0x01223005 in Flet (args=-4611686018401701680) at eval.c:973
#12 0x01227368 in eval_sub (form=-4611686018401702176) at eval.c:2164
#13 0x012280ff in eval_sub (form=-4611686018401978320) at eval.c:2282
#14 0x012277fd in eval_sub (form=-4611686018401978192) at eval.c:2199
#15 0x012277fd in eval_sub (form=-4611686018401978160) at eval.c:2199
#16 0x01226b8e in Feval (form=-4611686018401978160, lexical=0) at eval.c:2033
#17 0x01229fc9 in funcall_subr (subr=0x167d720 <Seval>, numargs=1,
    args=0x88e738) at eval.c:2812
#18 0x01229a14 in Ffuncall (nargs=2, args=0x88e730) at eval.c:2735
#19 0x0128e4e0 in exec_byte_code (bytestr=-9223372036833358424,
    vector=-6917529027619664456, maxdepth=4611686018427387927,
    args_template=4611686018427388161, nargs=1, args=0x88ec38)
    at bytecode.c:726
#20 0x0122ac8c in funcall_lambda (fun=-6917529027619664520, nargs=1,
    arg_vector=0x88ec30) at eval.c:2935
#21 0x01229a58 in Ffuncall (nargs=2, args=0x88ec28) at eval.c:2737
#22 0x0128e4e0 in exec_byte_code (bytestr=-9223372036833377352,
    vector=-6917529027619683384, maxdepth=4611686018427387925,
    args_template=4611686018427387904, nargs=0, args=0x88f1a8)
    at bytecode.c:726
#23 0x0122ac8c in funcall_lambda (fun=-6917529027619683448, nargs=0,
    arg_vector=0x88f1a8) at eval.c:2935
#24 0x01229a58 in Ffuncall (nargs=1, args=0x88f1a0) at eval.c:2737
#25 0x0128e4e0 in exec_byte_code (bytestr=-9223372036833380592,
    vector=-6917529027619686624, maxdepth=4611686018427387916,
    args_template=4611686018427387904, nargs=0, args=0x88f650)
    at bytecode.c:726
#26 0x0122ac8c in funcall_lambda (fun=-6917529027619686688, nargs=0,
    arg_vector=0x88f650) at eval.c:2935
#27 0x0122a755 in apply_lambda (fun=-6917529027619686688, args=0, count=4)
    at eval.c:2872
#28 0x01227e87 in eval_sub (form=-4611686018401371376) at eval.c:2256
#29 0x01226b8e in Feval (form=-4611686018401371376, lexical=0) at eval.c:2033
#30 0x01156473 in top_level_2 () at keyboard.c:1124
#31 0x0122464a in internal_condition_case (bfun=0x115643d <top_level_2>,
    handlers=21728, hfun=0x1155bf4 <cmd_error>) at eval.c:1336
#32 0x011564d9 in top_level_1 (ignore=0) at keyboard.c:1132
#33 0x01223786 in internal_catch (tag=58016, func=0x1156479 <top_level_1>,
    arg=0) at eval.c:1101
#34 0x01156355 in command_loop () at keyboard.c:1093
#35 0x01155620 in recursive_edit_1 () at keyboard.c:700
#36 0x011558be in Frecursive_edit () at keyboard.c:771
#37 0x01153068 in main (argc=4, argv=0xc21478) at emacs.c:1686

Lisp Backtrace:
"set-window-configuration" (0x88da40)
"unwind-protect" (0x88dd70)
"let" (0x88e000)
"save-window-excursion" (0x88e170)
"equal" (0x88e2e0)
"print" (0x88e450)
"eval" (0x88e738)
"command-line-1" (0x88ec30)
"command-line" (0x88f1a8)
"normal-top-level" (0x88f650)
(gdb) p FRAME_MENU_BAR_HEIGHT(f)
$8 = 1
(gdb) p FRAME_TOOL_BAR_HEIGHT(f)
$9 = 0
(gdb) p FRAME_TOP_MARGIN_HEIGHT(f)
$10 = 1
(gdb)

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

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

[Eli Zaretskii]

> Date: Mon, 09 Jan 2017 17:19:29 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, p.stephani2@gmail.com, 25380@debbugs.gnu.org
> 
>  >> 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.

Yes, but in a batch session 1 pixel = 1 character (it's not a GUI
session), right?

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

Yes.  No.

>  >> 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 will see what I can do about that.

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

It's a batch session, so the text-mode part is probably the one.

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

Of course.  Like I said: trickery.

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

[martin rudalics]

 > Yes, but in a batch session 1 pixel = 1 character (it's not a GUI
 > session), right?

Right.

 >> That's obvious.  But how do I find out where that menubar line gets set?
 >
 > I will see what I can do about that.

Could this be related to the bug#18136, bug#18196 woes?

martin

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

[Eli Zaretskii]

> Date: Mon, 09 Jan 2017 18:44:23 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: p.stephani2@gmail.com, 25380@debbugs.gnu.org
> 
> >  > 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 will see what I can do about that.

Further debugging reveals that I was mistaken: the frame's
FRAME_MENU_BAR_LINES value is already 1 when Emacs starts.  The
problem is that the window's top is not in sync with that value; I
guess resize_frame_windows was never called for the windows of the
frame, not even in temacs.

So perhaps one possible solution would be to call resize_frame_windows
somehow during temacs run.

> Could this be related to the bug#18136, bug#18196 woes?

Only tangentially, I think.  IOW, the same code is involved here, but
the menu-bar lines value is correct in this case.

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

[martin rudalics]

 > So perhaps one possible solution would be to call resize_frame_windows
 > somehow during temacs run.

Which code does create that frame?  make_terminal_frame?

martin

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

[Eli Zaretskii]

> Date: Tue, 10 Jan 2017 19:06:44 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: p.stephani2@gmail.com, 25380@debbugs.gnu.org
> 
>  > So perhaps one possible solution would be to call resize_frame_windows
>  > somehow during temacs run.
> 
> Which code does create that frame?  make_terminal_frame?

No, make_frame which is called from make_initial_frame.