From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GDB startup Date: Tue, 15 Feb 2005 20:16:02 -0500 Message-ID: References: <16914.27405.844755.48839@farnswood.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 1108516457 11574 80.91.229.2 (16 Feb 2005 01:14:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Feb 2005 01:14:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 16 02:14:16 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D1Dlb-0001ip-8Z for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2005 02:14:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1E1R-00027T-LQ for ged-emacs-devel@m.gmane.org; Tue, 15 Feb 2005 20:30:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D1E1D-00027F-VL for emacs-devel@gnu.org; Tue, 15 Feb 2005 20:30:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D1E1C-00026i-BH for emacs-devel@gnu.org; Tue, 15 Feb 2005 20:30:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1E1C-00026f-98 for emacs-devel@gnu.org; Tue, 15 Feb 2005 20:30:18 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D1DnS-0003e4-SS for emacs-devel@gnu.org; Tue, 15 Feb 2005 20:16:07 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id A125A8282A7; Tue, 15 Feb 2005 20:16:06 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 59BBA2CC002; Tue, 15 Feb 2005 20:16:02 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 472C64BCF2; Tue, 15 Feb 2005 20:16:02 -0500 (EST) Original-To: Nick Roberts In-Reply-To: <16914.27405.844755.48839@farnswood.snap.net.nz> (Nick Roberts's message of "Wed, 16 Feb 2005 10:35:09 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.801, requis 5, autolearn=not spam, AWL 0.10, BAYES_00 -4.90) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33515 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33515 >> Would it be possible to "do it in the background", maybe? > I'm not sure what you mean. GDB runs asynchronously from Emacs, so all > commands sent to it *do* run in the background. Maybe, because there is > so much input and output, you can't get the prompt so it feels like its > running in foreground. I understand that it's not clear what I mean by "in the background" (that's why I put it between quotes): I understand that those commands are sent asynchronously and so Emacs is not stuck waiting, but gdb is kept sufficiently busy that the prompt doesn't appear. > Presumably a lot of your buffers aren't visible Indeed the large majority of my buffers are in iconified frames. > which makes me wonder whether its possible to have > a when-buffer-becomes-visible-hook? I guess post-command-hook is the closest thing. Maybe another approach is to limit the buffers that are considered to some set of major modes, or to some subtree of the filesystem. But neither seems quite practical. Another alternative could be to handle the files/buffers "slowly", with a 0.5s delay between each file/buffer, starting with the buffers that are currently visible. > A more practical solution might be to limit the number of buffers/files > (its probably the latter which takes most time) that Emacs considers. > Clearly, what is a sensible number would depend on the speed of the > computer (I think that perhaps you have a clunky machine). 2GB, 1.4GHz Opteron. It's not the bestest and greatest, but it hardly qualifies as clunky. > Generally, how many buffers do you have open with files in them? Anywhere between 20 and 100. Let's say in the 50s. Stefan