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: Fri, 31 Jan 2020 15:58:45 +0200 Message-ID: <83blqjlobu.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> <83zhecoseo.fsf@gnu.org> <6AC6E78C-69C2-400C-902E-CCB32E296887@gmail.com> 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="50604"; 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 Fri Jan 31 14:59:46 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 1ixWpm-000D84-5W for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Jan 2020 14:59:46 +0100 Original-Received: from localhost ([::1]:53328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixWpl-0000Y5-7e for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Jan 2020 08:59:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39420) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixWpA-0008FW-PU for emacs-devel@gnu.org; Fri, 31 Jan 2020 08:59:10 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ixWp9-0001sc-IN; Fri, 31 Jan 2020 08:59:07 -0500 Original-Received: from [176.228.60.248] (port=4383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ixWp8-00088f-Is; Fri, 31 Jan 2020 08:59:07 -0500 In-reply-to: <6AC6E78C-69C2-400C-902E-CCB32E296887@gmail.com> (message from Yuan Fu on Sat, 25 Jan 2020 17:34:13 -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:244788 Archived-At: > From: Yuan Fu > Date: Sat, 25 Jan 2020 17:34:13 -0500 > Cc: rudalics@gmx.at, > juri@linkov.net, > emacs-devel@gnu.org, > monnier@iro.umontreal.ca, > john@yates-sheets.org > > > 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? > > No, I simply save the window configuration at gdb start up by `window-state-get` and restores it when gdb quits. If gdb doesn’t maximize the frame, it shouldn’t un-maximize the frame after it quits either. If you want to make gdb maximize the frame by default, then gdb should un-maximize the frame after it quits. What I want to say is, who makes the change, who is responsible for it. But we already have gdb-restore-windows, so it sounds like users already can restore their window configuration. Why do we need anything else?