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: Sat, 25 Jan 2020 17:34:13 -0500 Message-ID: <6AC6E78C-69C2-400C-902E-CCB32E296887@gmail.com> 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> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Content-Type: multipart/mixed; boundary="Apple-Mail=_8FB766A5-937F-4E86-9017-FD78E794D1FF" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="29909"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 25 23:35:13 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 1ivU1I-0007k5-NE for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 23:35:12 +0100 Original-Received: from localhost ([::1]:57976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivU1H-0005IQ-RX for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 17:35:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43252) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivU0W-0004e7-7L for emacs-devel@gnu.org; Sat, 25 Jan 2020 17:34:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivU0U-0004Xo-RQ for emacs-devel@gnu.org; Sat, 25 Jan 2020 17:34:23 -0500 Original-Received: from mail-qk1-x733.google.com ([2607:f8b0:4864:20::733]:45999) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivU0T-0004Ul-00; Sat, 25 Jan 2020 17:34:21 -0500 Original-Received: by mail-qk1-x733.google.com with SMTP id x1so5918960qkl.12; Sat, 25 Jan 2020 14:34:20 -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=QXyzcN/DN2WDn42BXiU2A0RJOfoAQKyVdDebQD2PSO4=; b=t3dnBxBiI1F8Y5U3TSJr0awaytl5fiTqNMx04jLWh3IQ9hYjTw6hPcre7aQ5nNCR3Q 9PwQgeuSVsJ8fmSNzqECSeRDXQZQKPSLtjfqnb0cmETKysnG9MAUTfPEO6O5GDF+M4Sc TWPAeUeOjcYCre7IxwYqLMLTqPFawdJ9m8rOalX+KysD2C22VEksLkXYHXPSQWRwVxmt mZwjHYmempAnhbHhzrfUVL58eqJ0w5l+X6z+cK4+RJYfb7OSK9eTLBUCb3vFrlJJSUWZ pIjXwy/Ubs2owAbAEEl89rgp/J1dIp5RXEuvpQpN3jHkHZCF/EbPlf4/p6jQKbzVAoha uIiA== 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=QXyzcN/DN2WDn42BXiU2A0RJOfoAQKyVdDebQD2PSO4=; b=SYCmc4AaA7jxa/NghsBaZZeFbcum40rw0s7Dzdzp3yA3hLPElrm+CqG+RhnR1DQQjK 0Du93jses3guyJy0XXLYaUl7Ek92+yRc7bq2IxT59vgDMPAACfDt7jk5j/OFYvjo8y+X pgQeMNILQotjEIIc0jRHtSnE2HcU9Gc1ohM95iNvXo53mRdgvLbyST0+eMmWBKUdECEz GJc8zDztw5D7tpN+9WXYn6r0lJ4eR1JSO7mQ18UlDqSxiykaVhtvb94jfo08vYbLg+1K iKj8hT1/qwYb+OB4Za8syPic4hKMnXilHeX/yboYGLzYQBO6EVa1fr0Hy/T5uZtzdzUH u/GQ== X-Gm-Message-State: APjAAAXC9s+Vd7IWeV4AQLklMfmhPl8nzfxCbP+H7tE8x73j+hvwsKJt ITHCHBL4i1E7Z2dHV3zbNndIPOMEyumsKudN X-Google-Smtp-Source: APXvYqyqo7rCyEmsPC2Fq7k4MwsypYFOFVnpYAL8fAPUpXFGG8oM6NuK/5vVFtbr/6bOTcHUiLRV9g== X-Received: by 2002:a37:8ec7:: with SMTP id q190mr9938048qkd.412.1579991659677; Sat, 25 Jan 2020 14:34:19 -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 y26sm6510471qtc.94.2020.01.25.14.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jan 2020 14:34:19 -0800 (PST) In-Reply-To: <83zhecoseo.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::733 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:244640 Archived-At: --Apple-Mail=_8FB766A5-937F-4E86-9017-FD78E794D1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >> I don't understand this part: wasn't the original motivation to cause >> gdb-mi to _always_ reuse the source window? >>=20 >> You have the choice. If I want gdb to always reuse the window, I can = set the number to 1.=20 >=20 > Yes, I think we should probably start at 1 and let users customize > that if they want to. Sure. So we are still using numbers (instead of symbols like = `only-one-window` and `switch-between-two`, etc)? >=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? >>=20 >> Are you referring to the complain that gdb messes up windows after it = quits? >=20 > 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=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. >=20 > 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=E2=80=99t = maximize the frame, it shouldn=E2=80=99t 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. > >> 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? > > > > Sounds OK, but I'd still like to hear martin's views on this. >=20 > I think gdb could provide customizations via one or more customizable > actions but always let users override them via their own buffer = display > customizations. Do you mean user should be able to overwrite = gdb-display-source-buffer-action as in (display-buffer = gdb-display-source-buffer-action)? He is free to do so like any other = (custom) variables. If you mean rules in `display-buffer-alist` should = take precedence over gdb-display-source-buffer-action, I disagree. = Because a source buffer in gdb setting is different from a normal buffer = =E2=80=94 it shouldn=E2=80=99t be surprising that source buffers display = differently in gdb. Or, think of gdb as a special case, and special case = normally take precedence over normal case. As for John=E2=80=99s idea, un-splittable window property, I think it = makes sense and would certainly be useful. But I suspect that the = implementation is not as easy as that. Below is the updates since last patch. Please apply this on top of the = last patch. I figure this way you see the updates better. Now gud has = the old behavior, `gdb-display-source-buffer` uses (display-buffer = gdb-display-source-buffer-action), and I added two custom variable = `gdb-max-source-window-count`(default to 1) and = `gdb-display-source-buffer-action`. Yuan --Apple-Mail=_8FB766A5-937F-4E86-9017-FD78E794D1FF Content-Disposition: attachment; filename=simplify-update1.patch Content-Type: application/octet-stream; x-unix-mode=0700; name="simplify-update1.patch" Content-Transfer-Encoding: quoted-printable =46rom=200c54015a2264830ceb34f9458a4ebfbef92d7b70=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Sat,=20= 25=20Jan=202020=2017:27:32=20-0500=0ASubject:=20[PATCH]=20Simplify=20= update=201=0A=0A---=0A=20lisp/progmodes/gdb-mi.el=20|=2019=20= ++++++++++++++++---=0A=20lisp/progmodes/gud.el=20=20=20=20|=20=206=20= +++++-=0A=202=20files=20changed,=2021=20insertions(+),=204=20= deletions(-)=0A=0Adiff=20--git=20a/lisp/progmodes/gdb-mi.el=20= b/lisp/progmodes/gdb-mi.el=0Aindex=2027031e24f7..db1f544077=20100644=0A= ---=20a/lisp/progmodes/gdb-mi.el=0A+++=20b/lisp/progmodes/gdb-mi.el=0A@@=20= -214,8=20+214,6=20@@=20gdb-first-done-or-error=0A=20(defvar=20= gdb-source-window-list=20nil=0A=20=20=20"List=20of=20windows=20used=20= for=20displaying=20source=20files.=0A=20Sorted=20in=20most=20recently=20= visited=20first=20order.")=0A-(defvar=20gdb-max-source-window-count=202=0A= -=20=20"Maximum=20number=20of=20source=20windows=20to=20use.")=0A=20= (defvar=20gdb-inferior-status=20nil)=0A=20(defvar=20gdb-continuation=20= nil)=0A=20(defvar=20gdb-supports-non-stop=20nil)=0A@@=20-593,6=20+591,21=20= @@=20gdb-show-main=0A=20=20=20:group=20'gdb=0A=20=20=20:version=20= "22.1")=0A=20=0A+(defcustom=20gdb-display-source-buffer-action=20nil=0A+=20= =20"`display-buffer'=20action=20used=20when=20GDB=20displaying=20a=20= source=20buffer."=0A+=20=20:type=20'list=0A+=20=20:group=20'gdb=0A+=20=20= :version=20"28.1")=0A+=0A+(defcustom=20gdb-max-source-window-count=201=0A= +=20=20"Maximum=20number=20of=20source=20windows=20to=20use.=0A+Until=20= there=20are=20such=20number=20of=20source=20windows=20on=20screen,=20GDB=0A= +tries=20to=20open=20a=20new=20window=20when=20visiting=20a=20new=20= source=20file;=20if=0A+there=20are,=20GDB=20will=20start=20to=20reuse=20= existing=20source=20windows."=0A+=20=20:type=20'number=0A+=20=20:grou=20= 'gdb=0A+=20=20:version=20"28.1")=0A+=0A=20(defvar=20gdbmi-debug-mode=20= nil=0A=20=20=20"When=20non-nil,=20print=20the=20messages=20sent/received=20= from=20GDB/MI=20in=20*Messages*.")=0A=20=0A@@=20-2020,7=20+2033,7=20@@=20= gdb-display-source-buffer=0A=20=20=20=20=20=20=20=20=20(if=20(>=20= gdb-max-source-window-count=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20(length=20gdb-source-window-list))=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20;;=20create=20new=20window,=20push=20to=20list,=20return=20it=0A-=20= =20=20=20=20=20=20=20=20=20=20=20(car=20(push=20= (display-buffer-pop-up-window=20buffer=20nil)=0A+=20=20=20=20=20=20=20=20= =20=20=20=20(car=20(push=20(display-buffer=20buffer=20= gdb-display-source-buffer-action)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20gdb-source-window-list))=0A=20=20=20=20=20= =20=20=20=20=20=20;;=20reuse,=20we=20use=20the=20oldest=20window=20and=20= put=20that=20to=20front=0A=20=20=20=20=20=20=20=20=20=20=20(let=20= ((last-win=20(car=20(last=20gdb-source-window-list)))=0Adiff=20--git=20= a/lisp/progmodes/gud.el=20b/lisp/progmodes/gud.el=0Aindex=20= ccf9026417..8189394c60=20100644=0A---=20a/lisp/progmodes/gud.el=0A+++=20= b/lisp/progmodes/gud.el=0A@@=20-2826,7=20+2826,11=20@@=20= gud-display-line=0A=20=09=20(buffer=0A=20=09=20=20(with-current-buffer=20= gud-comint-buffer=0A=20=09=20=20=20=20(gud-find-file=20true-file)))=0A-=09= =20(window=20(when=20buffer=20(gdb-display-source-buffer=20buffer)))=0A+=09= =20(window=20(when=20buffer=20(if=20(eq=20gud-minor-mode=20'gdb-mi)=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20(gdb-display-source-buffer=20buffer)=0A+=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20;;=20we=20don't=20change=20the=20old=20behavior=20for=20gud=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20(or=20(get-buffer-window=20buffer)=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20(display-buffer=20buffer=20'(nil=20= (inhibit-same-window=20.=20t)))))))=0A=20=09=20(pos))=0A=20=20=20=20=20= (when=20buffer=0A=20=20=20=20=20=20=20(with-current-buffer=20buffer=0A--=20= =0A2.25.0=0A=0A= --Apple-Mail=_8FB766A5-937F-4E86-9017-FD78E794D1FF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_8FB766A5-937F-4E86-9017-FD78E794D1FF--