From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Multiple debugging sessions Date: Thu, 10 Nov 2005 23:34:41 -0500 Message-ID: <878xvvreoh.fsf-monnier+emacs@gnu.org> References: <87u0feb5b7.fsf@wigwam.deepwood.net> <871x2hck3a.fsf@cut.bc.hsia.telus.net> <17239.8445.256875.931159@kahikatea.snap.net.nz> <17266.60914.593789.221645@kahikatea.snap.net.nz> <871x1os7i4.fsf-monnier+emacs@gnu.org> <17267.60704.229605.641146@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1131683716 2635 80.91.229.2 (11 Nov 2005 04:35:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2005 04:35:16 +0000 (UTC) Cc: snogglethorpe@gmail.com, emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 11 05:35:14 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EaQd7-0000j5-F1 for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 05:35:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaQd6-0004Px-To for ged-emacs-devel@m.gmane.org; Thu, 10 Nov 2005 23:35:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EaQce-0004M2-PJ for emacs-devel@gnu.org; Thu, 10 Nov 2005 23:34:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EaQce-0004Lg-38 for emacs-devel@gnu.org; Thu, 10 Nov 2005 23:34:44 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaQcd-0004Lb-TG for emacs-devel@gnu.org; Thu, 10 Nov 2005 23:34:43 -0500 Original-Received: from [209.226.175.4] (helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EaQcd-0002aX-4t; Thu, 10 Nov 2005 23:34:43 -0500 Original-Received: from alfajor ([65.92.243.185]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20051111043441.UDJD21026.tomts16-srv.bellnexxia.net@alfajor>; Thu, 10 Nov 2005 23:34:41 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 4A36FD7662; Thu, 10 Nov 2005 23:34:41 -0500 (EST) Original-To: Nick Roberts In-Reply-To: <17267.60704.229605.641146@kahikatea.snap.net.nz> (Nick Roberts's message of "Fri, 11 Nov 2005 14:00:16 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:45717 Archived-At: >> > Retrofitting such a feature is probably a lot harder than simply being >> > a bit careful to keep things well-parameterized from the beginning >> > (well i guess it's too late now, but ...). >> >> The main problem (based on my experience making it possible to have multiple >> PCL-CVS buffers) is that you need both to understand the code you're >> changing and to understand how to use buffer-local variables to their best >> advantage. > I've only just started using pcl-cvs, but doesn't it just use one buffer? A > debugging session with gdb can comprise many buffers: stack, locals, > breakpoints etc. I'm not claiming PCL-CVS is as complex as gdba. But yes, PCL-CVS uses more than one buffer: one *cvs* buffer for the display, a *cvs-tmp* for the output of the process (not shown to the user), then some others like *cvs-info* to show cvs log or cvs status output (the cvs status output is also parsed, just like the *cvs-tmp* output), ... > There is only one GUD buffer per session, so maybe variables > could be local to that and some sort of indirection used, but it would be > more complicated. That's whay I do it in PCL-CVS: each one of those buffers has a buffer-local variable `cvs-buffer' which points to the *cvs* buffer where all the relevant info is kept. So a process can find the corresponding info by checking its buffer's `cvs-buffer' variable, and then looking up the info in that buffer. It requires a bit of discipline, but really nothing too terrible. It actually all becomes fairly intuitive when you start thinking in terms of the most general/scary case rather than in terms of the "normal" case. Stefan