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, 24 Jan 2020 09:16:10 +0200 Message-ID: <83lfpxs4sl.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> 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="55746"; 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 24 08:17:15 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 1iutDM-000EPL-OQ for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jan 2020 08:17:12 +0100 Original-Received: from localhost ([::1]:38242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iutDL-0007Ks-TY for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jan 2020 02:17:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42692) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iutCm-0006ss-SV for emacs-devel@gnu.org; Fri, 24 Jan 2020 02:16:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iutCl-0007ru-Bp; Fri, 24 Jan 2020 02:16:35 -0500 Original-Received: from [176.228.60.248] (port=3452 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iutCf-0003Dn-8z; Fri, 24 Jan 2020 02:16:33 -0500 In-reply-to: <2BEA3843-859E-481B-8561-35384438EF7F@gmail.com> (message from Yuan Fu on Tue, 21 Jan 2020 20:50:46 -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:244554 Archived-At: > From: Yuan Fu > Date: Tue, 21 Jan 2020 20:50:46 -0500 > Cc: martin rudalics , > Juri Linkov , > emacs-devel@gnu.org, > monnier@iro.umontreal.ca, > john@yates-sheets.org > > Here is my first attempt. I make every function that needs to display a source buffer (only 2: gdb-goto-breakpoint, gud-display-line) use gdb-display-source-buffer. Previously they either use (or gdb-display-source-buffer display-buffer) or use (display-buffer). Thanks. I have two comments/questions to this design: . I think "M-x gud-gdb" should be unaffected by these changes. That command exists so that users who are unhappy with the new UI presented in gdb-mi.el, or have use cases that are insufficiently well supported by gdb-mi.el, so its workings must remain as they were historically. Does your patch affect only gdb-mi.el? . Are we sure that all the places that now use gdb-display-source-buffer should indeed use the same logic? From the names of the functions it seems the answer is YES, but could there be use cases where this isn't so? 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 added a variable for maximum number of windows used for source buffer. Right now the simple logic is to open as much windows as possible until the max is reached, then we start to reuse windows. Creating new window uses display-buffer-pop-up-window (I use this function just for completeness, I would modify this part when adding customization, maybe let user customize action for display-buffer?) I don't understand this part: wasn't the original motivation to cause gdb-mi to _always_ reuse the source window? And in any case, I'm not sure a simple max number of windows is a reasonable criterion for this functionality. E.g., if I needed to set the value of this variable, I wouldn't know what value to choose. > If you think this patch is fine, I’ll do these next: 1) add a straightforward customization, preferably only one variable. 2) currently gdb opens windows everywhere, I want to make it open in only one continues area and maybe balance windows. Do you think this is worth doing? Or it is suffice to let user customize the display-buffer action? 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?