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: Mon, 27 Jan 2020 10:56:10 -0500 Message-ID: References: <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> <43cea5db-4cd0-446a-3da4-a18ce1f1a053@gmx.at> <745ebf9f-b87e-d8f9-a281-5996001869bc@gmx.at> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1081"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , John Yates , emacs-devel@gnu.org, monnier@iro.umontreal.ca, Juri Linkov To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 27 16:56:54 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 1iw6kv-0000Dd-PQ for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jan 2020 16:56:53 +0100 Original-Received: from localhost ([::1]:47198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iw6ku-00053H-TW for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jan 2020 10:56:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53555) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iw6kM-0004eU-35 for emacs-devel@gnu.org; Mon, 27 Jan 2020 10:56:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iw6kL-0007tM-0T for emacs-devel@gnu.org; Mon, 27 Jan 2020 10:56:18 -0500 Original-Received: from mail-qv1-xf2b.google.com ([2607:f8b0:4864:20::f2b]:36573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iw6kJ-0007qX-5a; Mon, 27 Jan 2020 10:56:15 -0500 Original-Received: by mail-qv1-xf2b.google.com with SMTP id db9so1090557qvb.3; Mon, 27 Jan 2020 07:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MynbP7umWGSaUQS+J8muisMThNrfbAnD1HpoCQcOvWE=; b=t23CRe+Sal1xD4uPXc4xPF1N9Cv4g6qk0vM2wWqaN9UvyParWMXPK80wG+qkrF3Zr9 kxeYeb/ar2rqF0dJqkPuosG8M/tMwZFsQaloEaz3lt9bKwWdfTkkq3LHzj8A8ZqGDMxA /VBVbhn33I1oAg9CYniU/4iLXS64N4Mu9a8kdh2nK5lvZFyJGedXb9nLth1xBQkiqjaC xTPnJnLnjdK1kfHxsvWAp27uwXJkmTXMTzct9zIirsF4kJu2ac04pkj5O+g0MlYoWyv4 ZHIdnvfKU4u9wetk1TWU/ghOYyMqmjYBbfHgPI9J9p1dYhzCrFTsmFBv3SF+t7v64hbp QFRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MynbP7umWGSaUQS+J8muisMThNrfbAnD1HpoCQcOvWE=; b=i5/m13giZSDuasX3JUcutCBTxnIz82/arYN5zLr7+ZOnYHT/e0bHQJ5xxXHfNuU7cG G+gZU6zshUiNIF3Tl2at1HLJG6Iay8KeuRsyNkqlQiYn/vmfJ6d74ii/B9n2SVyDgJ+G 12IA3DpRms2fM46YtesWGYFu3YHEyOwi5hy/NcDWKX+H3QYkVfob4BpHGT6a/DaIG5gs oNWVf2IN/Cqb2vCGRj6l3dGWNAQK3CDqKQJtvtXJXyi+NeaYxNz8HzdkMDmXGBxRv036 +Q7KGi/6Nqg4Sx1I4Fxg/Zta52IvPronK5rdbKX7xM1K1qsfmQ+9YdCmBS3YpOuHMG5L s4DQ== X-Gm-Message-State: APjAAAWVwGeHu1+ypGknALXJv55uzP47CoPpr5ZfO4HuML8bjyji+jp2 gneow/SJBrFFNLfT/Zib4qc= X-Google-Smtp-Source: APXvYqzBPP7Ddc2BFuCelSFBVjlc1wxrs7QkVBffpRSqglaB9DKMhOrpZKwhYHa+6mKLOdYp6859xg== X-Received: by 2002:a0c:cc8e:: with SMTP id f14mr10914313qvl.119.1580140572598; Mon, 27 Jan 2020 07:56:12 -0800 (PST) Original-Received: from [104.39.216.175] ([104.39.216.175]) by smtp.gmail.com with ESMTPSA id t23sm1370265qtp.82.2020.01.27.07.56.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jan 2020 07:56:11 -0800 (PST) In-Reply-To: <745ebf9f-b87e-d8f9-a281-5996001869bc@gmx.at> 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::f2b 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:244673 Archived-At: > On Jan 26, 2020, at 11:57 AM, martin rudalics wrote: >=20 > > I has a second look at the docstring of `display-buffer`, yes > > `display-buffer-alist` overrides supplied ACTION argument. Then the > > user is always able to override our display buffer customizations. >=20 > Right. An application can always re-override the user by using > 'display-buffer-overriding-action' but that should be a last remedy > only. >=20 > > Maybe we could provide a customization to make gdb function windows > > (breakpoint, io, thread, etc) un-splittable? >=20 > I think we should do two things. >=20 > (1) Provide a simple interface for users who don't need the function > windows. The aim here is to avoid that new windows pop up wildly > whenever hitting a new breakpoint or during stepping. Not sure if I understand you correctly, but AFAICT setting = gdb-many-windows to nil (default value) and our new variable = `gdb-max-source-window-count` to 1 (default value) should achieve that. = You need to set `gdb-show-main` to t (not default) to show source file = tho. > (2) Provide a more sophisticated window layout showing all sorts of > function windows using side windows. In particular, more "flat" = windows > like the breakpoint, locals, stack frames and maybe the io window = should > appear at the bottom and top of the frame. The gud window would = appear > on the left or right (the io window could then go to the opposite = side). >=20 > The center of the frame would be reserved for the source window or > whatever the user wants to show there. This way, 'display-buffer' > reaardless of whether it's called by gdb or anyone else would never > mangle those function windows - neither split nor delete or reuse them > arbitrarily - unless the user explicitly wants to do that. Currently gdb-many-windows gives a similar arrangement. And in my other = patch the user can customize his layout and save it to a file, and later = restore from it. So they have a lot of freedom in this aspect. Side = windows are a bit more limiting. And if we add non-split property to = function windows(breakpoint, io, etc), we can make sure all new source = windows are created around the old source windows (instead of splitting = function windows everywhere). That should work too. Btw, I have collected a few patches and they all resides in individual = branches, and it=E2=80=99s getting a bit confusing, especially when some = of the patches are several months old. Any tricks/advice on working with = a bunch of branches/patches? BBtw, Could someone have a look at the old patches that I sent to bug = tracker? Yuan=