From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Extend gdb to filter registers Date: Sat, 25 Jan 2020 10:24:15 +0200 Message-ID: <83zhecoseo.fsf@gnu.org> References: <878spmuerf.fsf@mail.linkov.net> <83wod3bx8i.fsf@gnu.org> <9f5ddaa5-0234-a17b-bdd7-81d70a0a50d6@gmx.at> <83FFF194-64CD-409E-8B7A-5A9DF91E79DE@gmail.com> <83v9pb314t.fsf@gnu.org> <838sm510d6.fsf@gnu.org> <83muakzoy5.fsf@gnu.org> <71042c9f-478b-47c8-f27e-1348e9f4536d@gmx.at> <83iml8zkbm.fsf@gnu.org> <6ad85759-7408-f177-38f6-45a72c2f5a9e@gmx.at> <83eevwzi79.fsf@gnu.org> <68ef651e-9319-b392-af1c-4564d5db9112@gmx.at> <831rrvzc81.fsf@gnu.org> <997C9AD2-D8DD-45DC-9195-28FEC907B2C4@gmail.com> <83muajxs04.fsf@gnu.org> <416593FF-C4BE-478F-B5AC-3379235146ED@gmail.com> <83lfq3xp66.fsf@gnu.org> <679953AF-F50A-4ABE-B836-150BA0F95DAE@gmail.com> <83h80rxlae.fsf@gnu.org> <8A5A507A-6036-4894-A8B1-749109EBE605@gmail.com> <83wo9mvwco.fsf@gnu.org> <2BEA3843-859E-481B-8561-35384438EF7F@gmail.com> <83lfpxs4sl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="28732"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org, juri@linkov.net To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 25 09:25:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ivGkW-0007Q7-H0 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 09:25:00 +0100 Original-Received: from localhost ([::1]:51808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivGkV-0003nF-KU for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 03:24:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39029) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivGk3-0003OU-Iw for emacs-devel@gnu.org; Sat, 25 Jan 2020 03:24:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ivGk2-0002OV-8F; Sat, 25 Jan 2020 03:24:30 -0500 Original-Received: from [176.228.60.248] (port=3839 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ivGk1-0006bg-MZ; Sat, 25 Jan 2020 03:24:30 -0500 In-reply-to: (message from Yuan Fu on Fri, 24 Jan 2020 15:12:37 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244599 Archived-At: > From: Yuan Fu > Date: Fri, 24 Jan 2020 15:12:37 -0500 > Cc: martin rudalics , > Juri Linkov , > emacs-devel , > Stefan Monnier , > John Yates > > I'm also slightly worried by the fact that previously this stuff > obeyed the display-buffer customizations, whereas after these changes > it won't. Martin, any thoughts or comments? > > I still haven’t had a clear idea on “how to open the new window” part. In the previous patch I simply used > display-window-pop-window so the code works, but we should definitely come up with something else. > Currently my naive idea is to use (display-buffer buffer gdb-display-source-buffer-action), where > gdb-display-source-buffer-action can be customized by user. WDYT? Sounds OK, but I'd still like to hear martin's views on this. > I don't understand this part: wasn't the original motivation to cause > gdb-mi to _always_ reuse the source window? > > You have the choice. If I want gdb to always reuse the window, I can set the number to 1. Yes, I think we should probably start at 1 and let users customize that if they want to. > My personal preference, and something I was always telling users who > expressed frustration with gdb-mi window handling, is to devote a > separate frame to gdb-mi windows. This avoids messing up the user's > windows on other frames. If enough people here agree with that, > perhaps we should move gdb-mi towards preferring such a modus > operandi? > > Are you referring to the complain that gdb messes up windows after it quits? No, the usual complaint is that gdb-mi messes up windows during the debugging session itself. E.g., if you had several source files displayed in carefully configured windows on a frame, starting "M-x gdb" will typically mess up your window configuration on that frame. Using a separate frame works around that. > That’s not hard to fix since we > have window-configurations now. I have a patch that makes gdb preserves window configuration that the user > had prior to starting gdb. That could be another way, but running a debugging session usually benefits from maximizing the frame. Will your patch undo that as well?