From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: Emacs geometry Date: Tue, 1 Aug 2006 11:51:52 +1200 Message-ID: <17614.38808.894701.994641@kahikatea.snap.net.nz> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1154391629 26565 80.91.229.2 (1 Aug 2006 00:20:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2006 00:20:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 01 02:20:25 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G7hzh-0003ya-U0 for ged-emacs-devel@m.gmane.org; Tue, 01 Aug 2006 02:20:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7hzh-0003Uy-Af for ged-emacs-devel@m.gmane.org; Mon, 31 Jul 2006 20:20:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7hzW-0003Ur-5F for emacs-devel@gnu.org; Mon, 31 Jul 2006 20:20:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7hzS-0003Uf-Pe for emacs-devel@gnu.org; Mon, 31 Jul 2006 20:20:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7hzS-0003Ub-JQ for emacs-devel@gnu.org; Mon, 31 Jul 2006 20:20:06 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G7i2D-0002cB-UX for emacs-devel@gnu.org; Mon, 31 Jul 2006 20:22:58 -0400 Original-Received: from kahikatea.snap.net.nz (p354-tnt1.snap.net.nz [202.124.111.100]) by viper.snap.net.nz (Postfix) with ESMTP id E2D4877D454; Tue, 1 Aug 2006 12:20:02 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 2BD63BE3B5; Tue, 1 Aug 2006 11:51:59 +1200 (NZST) Original-To: Ralf Angeli In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57893 Archived-At: > > `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(# [...]) 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