From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Extend gdb to filter registers Date: Fri, 24 Jan 2020 15:12:37 -0500 Message-ID: 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 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_29527085-449F-45A7-8347-4E8F47C75BCD" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="66506"; mail-complaints-to="usenet@ciao.gmane.io" Cc: martin rudalics , emacs-devel , Stefan Monnier , John Yates , Juri Linkov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 24 21:13:26 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 1iv5KY-000HGV-1L for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jan 2020 21:13:26 +0100 Original-Received: from localhost ([::1]:47308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv5KX-0006g6-5L for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jan 2020 15:13:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39372) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv5Jw-000674-3I for emacs-devel@gnu.org; Fri, 24 Jan 2020 15:12:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iv5Ju-0001qm-5M for emacs-devel@gnu.org; Fri, 24 Jan 2020 15:12:48 -0500 Original-Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]:40363) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iv5Jr-0001o9-GG; Fri, 24 Jan 2020 15:12:43 -0500 Original-Received: by mail-qt1-x833.google.com with SMTP id v25so2520525qto.7; Fri, 24 Jan 2020 12:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=a+cb/mCjWB3MsFNbxNuq4Q1I5yzG4G1bBCBvVPdYLg4=; b=aw4e1G+fRWmsou4DmlPHb2p7uwjxRo/gQSllLW1eMGCf8yb/Nt5+Fm7fiidpwc5QbA jwkg2haxOaPq+kKEBMEYG90HLX+yiGeuHbysbTarshAukfCOUAVZ0HBumHaMbgtq1Qsh IlaK2GYQpAhZK5B88Ts4P4xvSshXYwULVEM1EBpJVv7PAOaK9SCvTKLm6Ck9GbFCDFal 2q1V/pJs0s1lqVMjO3kNsX5PsmpSMEAZa5oBWu0wXjYhqHLP/wJmugO0iubMeOpH6vnE UYUA4Q6btefoLRrfP1rZLNT56veH6eFZ35s0mchsqaQQkghzN+RGUt8HXwYRRSFQMmeG qDHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=a+cb/mCjWB3MsFNbxNuq4Q1I5yzG4G1bBCBvVPdYLg4=; b=s3dJYa0LW+p6S7XrLhbZMDXOjKQHDKPKGcZeiGU674YiD/B2mJesCaEaamG4mG/YKY dvMGmOjxvOdrNGh7WeagI4wN6AkrKVvvng5MlF5+3hbguAPJ9lg+4/g2cu+M3+nlXsr8 o7NuW6QohMU2GQXT9DJ+5n/e9HdKAwirGGx/ABACU7BXnQtodw9C/EGSmXcTfH9pOnh4 aGIrXbbVBVrc5mhN9nDCZu28Q1ggwgjjBEq7Lq2XxJrDE+a2QrC/IRuSPgd64yen4qJS 0TG3TjjLnFnSvyFxrefY5g+WhRkLL2ymj7R99n9+vrL8fHCoTsPmLug030lfR6kThbAc ZrcA== X-Gm-Message-State: APjAAAUfZ3VmcSld42IV+40fHF7urjIPhVyKgBRp38IjUhisvkS4VnYD BDkdf3ZzX7snITQR2CLn8PNfmMZsehd5Ee/f X-Google-Smtp-Source: APXvYqyByerMn6XY/OS6Un4QK88GVmeWB5G9Avp2Wr39mAKLEJz25e+k00QX80sZrUecihQDoR/NcA== X-Received: by 2002:aed:2050:: with SMTP id 74mr4120890qta.217.1579896762063; Fri, 24 Jan 2020 12:12:42 -0800 (PST) Original-Received: from [192.168.1.5] (c-174-60-229-153.hsd1.pa.comcast.net. [174.60.229.153]) by smtp.gmail.com with ESMTPSA id f7sm4064302qtp.86.2020.01.24.12.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 12:12:41 -0800 (PST) In-Reply-To: <83lfpxs4sl.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::833 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:244584 Archived-At: --Apple-Mail=_29527085-449F-45A7-8347-4E8F47C75BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 24, 2020, at 2:16 AM, Eli Zaretskii wrote: >=20 >> 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 >>=20 >> 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).=20 >=20 > Thanks. >=20 > I have two comments/questions to this design: >=20 > . 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? No, but this can be easily fixed. I=E2=80=99ll fix that in the next = patch. > . 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? In gdb-mi.el, there is only one function that used = gbd-display-source-buffer =E2=80=94 gdb-goto-breakpoint. In gud.el, = there is also only one function, gud-display-frame calls = gud-display-line calls gdb-display-source-buffer (after patch, before = patch it calls display-buffer). And gud-display-frame is used to display = a file:line. Overall I think it=E2=80=99s save. Of course you can never = be so sure by just looking at the code and reason. But there is no test, = and I don=E2=80=99t know how to write tests for interactive programs = like this. Maybe you can give me some pointers on tests, if you think = that=E2=80=99s vitally important. > 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=E2=80=99t had a clear idea on =E2=80=9Chow to open the new = window=E2=80=9D 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? >=20 >> 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?) >=20 > 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.=20 > 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. I guess you mean this is somewhat ad-hoc. I agree. We can change it to = options like =E2=80=9Calways reuse one=E2=80=9D, =E2=80=9Cswitch between = 2=E2=80=9D, =E2=80=9Ccycle between 3=E2=80=9D and =E2=80=9Cas many as = possible=E2=80=9D, how about that? I.e.,=20 (defcustom gdb-source-window-number 'always-reuse-one :type 'symbol :options '(always-reuse-one switch-between-two cycle-between-three as-many-as-possible) :group 'gdb "Number of source windows gdb uses.=E2=80=9D) >=20 >> If you think this patch is fine, I=E2=80=99ll 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? >=20 > 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? That=E2=80=99s 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. As for = opening a new frame, that solves the problem in someway, but what if = someone don=E2=80=99t want to open a new frame and don=E2=80=99t want = gdb messes his windows either? If you are talking about the problem = where gdb opens new source windows when I don=E2=80=99t want it to, I = don=E2=80=99t see now opening gdb in a new frame help that. Yuan --Apple-Mail=_29527085-449F-45A7-8347-4E8F47C75BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 24, 2020, at 2:16 AM, Eli Zaretskii <eliz@gnu.org> = wrote:

From: Yuan Fu <casouri@gmail.com>
Date: Tue, 21 Jan 2020 20:50:46 -0500
Cc: = martin rudalics <rudalics@gmx.at>,
Juri Linkov <juri@linkov.net>,
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?

No, but this can be easily fixed. I=E2=80=99ll fix = that in the next patch.

 . 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?

In = gdb-mi.el, there is only one function that used = gbd-display-source-buffer =E2=80=94 gdb-goto-breakpoint. In gud.el, = there is also only one function, gud-display-frame calls = gud-display-line calls gdb-display-source-buffer (after patch, before = patch it calls display-buffer). And gud-display-frame is used to display = a file:line. Overall I think it=E2=80=99s save. Of course you can never = be so sure by just looking at the code and reason. But there is no test, = and I don=E2=80=99t know how to write tests for interactive programs = like this. Maybe you can give me some pointers on tests, if you think = that=E2=80=99s vitally important.

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=E2=80=99t had a clear idea on =E2=80=9C= how to open the new window=E2=80=9D 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?


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?

You have the choice. If I want gdb to always reuse the = window, I can set the number to 1. 

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.

I = guess you mean this is somewhat ad-hoc. I agree. We can change it to = options like =E2=80=9Calways reuse one=E2=80=9D, =E2=80=9Cswitch between = 2=E2=80=9D, =E2=80=9Ccycle between 3=E2=80=9D and =E2=80=9Cas many as = possible=E2=80=9D, how about that? I.e., 

(defcustom gdb-source-window-number = 'always-reuse-one
  :type = 'symbol
  :options '(always-reuse-one = switch-between-two
            =                   = cycle-between-three
            =                   = as-many-as-possible)
  :group = 'gdb
  "Number of source windows gdb = uses.=E2=80=9D)


If you think this patch is fine, I=E2=80=99ll 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?

Are you referring to the complain that gdb messes = up windows after it quits? That=E2=80=99s 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. As for = opening a new frame, that solves the problem in someway, but what if = someone don=E2=80=99t want to open a new frame and don=E2=80=99t want = gdb messes his windows either? If you are talking about the problem = where gdb opens new source windows when I don=E2=80=99t want it to, I = don=E2=80=99t see now opening gdb in a new frame help = that.

Yuan

= --Apple-Mail=_29527085-449F-45A7-8347-4E8F47C75BCD--