Re: Emacs geometry

[Nick Roberts <nickrob@snap.net.nz>]

 > > `pr' is tricky; I'm guessing that the Windows pipe emulation on the
 > > Emacs side and the console output on the GDB side don't work together
 > > well enough for `pr' to work from within Emacs.  (`pr' does work for
 > > me if I invoke GDB from the Command Prompt window outside Emacs.)  Use
 > > `xtype' to see the type and xint, xsymbol, xcar, etc., according to
 > > what xtype prints, to see the value.
 > 
 > Phew, finally! (c:
 > 
 > (gdb) p Fassq (Qtop, f->param_alist)
 > $1 = 23713793
 > (gdb) xtype
 > Lisp_Symbol
 > (gdb) xsymbol
 > $2 = (struct Lisp_Symbol *) 0x169d800
 > "nil"
 > (gdb)
 > 
 > That was done withing a MinGW shell.  `pr' isn't working in that shell
 > either.

I think Eli is right as to why, `pr' actually prints by executing Emacs.  The
commentary in gdb-ui.el has something about how to make the output stream
unbuffered (Note: I don't use Windows, it's just advice someone else gave me).

>From your earlier e-mail:

>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   string-match("//+" nil)
>>   gud-find-file(nil)
>>   gdb-set-hollow()
>>   gdb-prompt("")
>>   gud-gdba-marker-filter([...])
>>   apply([...])
>>   gud-marker-filter([...])
>>   gud-filter(#<process gud-emacs.exe> [...])

I'm a bit baffled because gdb-prompt doesn't call gdb-set-hollow, only
gdb-info-stack-custom does.  I've recently changed the code (yesterday)
so this part doesn't get called by default so you may have to set
gdb-find-source-frame to t to reproduce it.

If you do move the executable (as with "make install") you need to be sure
that GDB can still find the source (some debug formats store the information,
others don't).  Starting GDB in the source tree means GDB will find the
source because it looks in the current directory.

If you do:

* starting GDB from the command line and using `emacs.exe' as the
                        ************
  executable to debug
* loading .gdbinit from GDB with `source /path/to/.gdbinit'
* setting a breakpoint with `b w32_createwindow'
* running Emacs with `run -g 80x30+10+20'

Does it say something like?:

2071      w32fns.c: No such file or directory.
          in w32fns.c

Even so Emacs should say the same thing and not generate a backtrace.  Can
you find out how gdb-set-hollow gets called e.g do debug-on-entry there,
or Edebug on gdb-prompt?

-- 
Nick                                           http://www.inet.net.nz/~nickrob