From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: jonetsu Newsgroups: gmane.emacs.help Subject: Re: Using gdb (windows popping up) Date: Mon, 10 Jun 2019 14:52:12 -0400 Message-ID: <20190610145212.56e60e7e@mistral> References: <20190609115246.41281b50@mistral> <83ftoibofg.fsf@gnu.org> <20190609145921.0fc60f3c@mistral> <83ef42bmij.fsf@gnu.org> <20190609152705.705c806b@mistral> <20190609154856.7d20feea@mistral> <20190609171036.18a89cb0@mistral> <87tvcymlba.fsf@telefonica.net> <20190610093324.2c71fc44@mistral> <87a7eptv1a.fsf@telefonica.net> <20190610100045.61c22fe0@mistral> <835zpdbg28.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218032"; mail-complaints-to="usenet@blaine.gmane.org" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jun 10 20:54:56 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1haPRW-000uRx-Tb for geh-help-gnu-emacs@m.gmane.org; Mon, 10 Jun 2019 20:54:55 +0200 Original-Received: from localhost ([::1]:49066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1haPRV-0007AR-UT for geh-help-gnu-emacs@m.gmane.org; Mon, 10 Jun 2019 14:54:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46631) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1haPP0-0004vO-0q for help-gnu-emacs@gnu.org; Mon, 10 Jun 2019 14:52:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1haPOy-00006R-7u for help-gnu-emacs@gnu.org; Mon, 10 Jun 2019 14:52:17 -0400 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:29705) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1haPOx-0008UP-5k for help-gnu-emacs@gnu.org; Mon, 10 Jun 2019 14:52:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EZLQAtpv5c/0Tb1BhmHAEBAR8EAQEFA?= =?us-ascii?q?QGBTgGBJwIBAQEBAWBvTA4lKI0QjAU1AY4gjAUJAQEBOgECAQGEOgICAQECgnQ?= =?us-ascii?q?kOBMBAwEBAQQBAQEBBAICaShCARABhHgBBAE6HCgLCAMJGCUPSBmFHg+pcohpg?= =?us-ascii?q?UYigRACAQEBAQEBAYttgT9AgRGDEj6FEYUVBItGiEKVHwmCEYFpkU0nDIxgii+?= =?us-ascii?q?lWyKBWHAVgyeBF486HSYwgQIBBgEBARUIEwUFAQGHCIURKoIoAQE?= X-IPAS-Result: =?us-ascii?q?A2EZLQAtpv5c/0Tb1BhmHAEBAR8EAQEFAQGBTgGBJwIBAQE?= =?us-ascii?q?BAWBvTA4lKI0QjAU1AY4gjAUJAQEBOgECAQGEOgICAQECgnQkOBMBAwEBAQQBA?= =?us-ascii?q?QEBBAICaShCARABhHgBBAE6HCgLCAMJGCUPSBmFHg+pcohpgUYigRACAQEBAQE?= =?us-ascii?q?BAYttgT9AgRGDEj6FEYUVBItGiEKVHwmCEYFpkU0nDIxgii+lWyKBWHAVgyeBF?= =?us-ascii?q?486HSYwgQIBBgEBARUIEwUFAQGHCIURKoIoAQE?= X-IronPort-AV: E=Sophos;i="5.60,576,1549947600"; d="scan'208";a="96739415" Original-Received: from 24-212-219-68.cable.teksavvy.com (HELO mistral) ([24.212.219.68]) by smtp.teksavvy.com with ESMTP; 10 Jun 2019 14:52:12 -0400 In-Reply-To: <835zpdbg28.fsf@gnu.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120896 Archived-At: On Mon, 10 Jun 2019 18:44:47 +0300 Eli Zaretskii wrote: > One again, the GDB UI was _designed_ to work in dedicated windows, > something that few Emacs features do. I suggest not to fight that, > but instead find a way of coexisting peacefully with that design. And indeed, the approach I described in the last replies results in a comfortable setup, which just a little bit of jitter at the beginning. > One way of coexisting peacefully is to invoke "M-x gdb" in a new > frame. That is, first type "C-x 5 2" to create a new frame, then > invoke "M-x gdb" in that new frame. This way, your window arrangement > in the original frame will be left intact. Switching to that original > frame is easy both with a mouse and via keyboard, so this is what the > Emacs manual recommends. Yes, I'll keep that in mind if needed, although the current approach with gdb-display-io-nopopup set to non-nil is not bad at all as far as getting close to a normal emacs use. > You can save the customization of gdb-many-windows with a non-nil > value for your future sessions, in which case Emacs will start with > all the UI windows right after you invoke "M-x gdb", thus avoiding > this temporary "disruption" altogether. This is what I tried right before starting this thread (described in the previous thread by me) and abandoned the approach altogether since it becomes way too difficult to show dedicated non-gdb buffers which I need during debugging as I take notes, refer to notes, refer to other sources, etc. I could switch to another frame (equivalent of another app for all practical user interface purposes since it requires switching over - switching over to another full screen frame on the same desktop or another desktop) although I still like to do everything in one emacs session/frame/instance, as I'm used to work with emacs. The bottom line to this is that some people have decided that gdb (many windows option) should be presented in a very specific way when there's no need to do so at all, none whatsoever. The user is absolutely capable of freely choosing which gdb buffers to be shown and where, while have full co-existence with any other buffers. There are no logical reasons to impose a specific placement of gdb buffers. It will not make debugging work better. The chosen imposed presentation (many windows option) is not adding any performance improvement to debugging. gdb has a lot of functions and IMHO any development in gud would be towards integrating more of those functions - while not imposing anything on the users.