From xemacs-m  Fri Mar  7 11:59:19 1997
Received: from palrel3.hp.com (palrel3.hp.com [15.253.88.10])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id LAA21072
	for <xemacs-beta@xemacs.org>; Fri, 7 Mar 1997 11:59:18 -0600 (CST)
Received: from rlab24.rsn.hp.com (rlab24.rsn.hp.com [15.99.219.24]) by palrel3.hp.com with ESMTP (8.7.5/8.7.3) id JAA22722 for <xemacs-beta@xemacs.org>; Fri, 7 Mar 1997 09:59:09 -0800 (PST)
Message-Id: <199703071759.JAA22722@palrel3.hp.com>
Received: by rlab24.rsn.hp.com
	(1.38.193.4/16.2) id AA126427633; Fri, 7 Mar 1997 12:00:33 -0600
Date: Fri, 7 Mar 1997 12:00:33 -0600
From: Shane Holder <holder@rsn.hp.com>
To: xemacs-beta@xemacs.org
Subject: Problems with gdb.el

In XEmacs 20.1 [Lucid] (hppa1.1-hp-hpux10.01) of Thu Mar  6 1997 on rlab24

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The function (gdb) uses (file-truename) to resolve a symbolic link
down to the real name of a file.  (gdb) shouldn't be put me where it
*thinks* I should go.  Using (expand-file-name) should be enough.

(defun gdb (path &optional corefile)
  "Run gdb on program FILE in buffer *gdb-FILE*.
The directory containing FILE becomes the initial working directory
and source-file directory for GDB.  If you wish to change this, use
the GDB commands `cd DIR' and `directory'."
  (interactive "FRun gdb on file: ")
  (setq path (file-truename (expand-file-name path)))
  (let ((file (file-name-nondirectory path)))



Recent input:
~ / l i b / e l i s TAB C-a C-k C-g C-g M-x l o a d 
- f i l e RET ~ / l i b / e l i s TAB g d b . e l c 
RET M-x g d b RET m a c h _ k e r n e l RET C-x b C-g 
M-x x BS DEL r e p TAB TAB o TAB r TAB RET P r o b 
l e m s SPC w i t h SPC g d b . e l RET

Recent messages:


Continue...
Loading gdb...
Loading gdb...done
Library is file /opt/xemacs/lib/xemacs-20.1-b5/lisp/comint/gdb.elc
Loading /home/holder/lib/elisp/gdb.elc...
Loading /home/holder/lib/elisp/gdb.elc...done
Loading emacsbug...
Loading emacsbug...done

