From: Yuan Fu <casouri@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, John Yates <john@yates-sheets.org>,
emacs-devel@gnu.org, monnier@iro.umontreal.ca,
Juri Linkov <juri@linkov.net>
Subject: Re: Extend gdb to filter registers
Date: Mon, 27 Jan 2020 10:56:10 -0500 [thread overview]
Message-ID: <BBF05241-BE20-4121-A5E0-260A83412F2C@gmail.com> (raw)
In-Reply-To: <745ebf9f-b87e-d8f9-a281-5996001869bc@gmx.at>
> On Jan 26, 2020, at 11:57 AM, martin rudalics <rudalics@gmx.at> wrote:
>
> > 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.
>
> Right. An application can always re-override the user by using
> 'display-buffer-overriding-action' but that should be a last remedy
> only.
>
> > Maybe we could provide a customization to make gdb function windows
> > (breakpoint, io, thread, etc) un-splittable?
>
> I think we should do two things.
>
> (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).
>
> 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’s 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
next prev parent reply other threads:[~2020-01-27 15:56 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 16:40 Extend gdb to filter registers Yuan Fu
2019-10-04 16:13 ` Fu Yuan
2019-10-04 19:32 ` Eli Zaretskii
2019-10-04 19:49 ` Stefan Monnier
2019-10-04 21:55 ` Yuan Fu
2019-10-05 3:15 ` Yuan Fu
2019-10-05 7:08 ` Eli Zaretskii
2019-10-05 13:15 ` Yuan Fu
2019-10-05 13:53 ` Eli Zaretskii
2019-10-05 17:51 ` Yuan Fu
2019-10-05 19:01 ` Eli Zaretskii
2019-10-06 4:24 ` Yuan Fu
2019-10-06 17:36 ` Eli Zaretskii
2019-10-08 2:23 ` Yuan Fu
2019-10-06 4:43 ` Michael Welsh Duggan
2019-10-07 15:50 ` Yuan Fu
2019-10-07 16:19 ` Michael Welsh Duggan
2019-10-08 0:19 ` Yuan Fu
2019-10-08 17:26 ` Stefan Monnier
2019-10-09 3:44 ` Yuan Fu
2019-10-09 3:51 ` Yuan Fu
2019-10-15 3:05 ` Yuan Fu
2019-10-15 9:48 ` martin rudalics
2019-10-17 3:14 ` Yuan Fu
2019-10-17 3:27 ` Yuan Fu
2019-10-17 8:26 ` martin rudalics
2019-10-15 18:10 ` Juri Linkov
2019-10-15 20:51 ` Stefan Monnier
2019-10-17 3:08 ` Yuan Fu
2019-10-17 8:19 ` Eli Zaretskii
2019-10-26 21:56 ` Yuan Fu
2019-10-27 7:47 ` martin rudalics
2019-10-27 17:38 ` Yuan Fu
2020-01-16 4:25 ` Yuan Fu
2020-01-16 14:51 ` Eli Zaretskii
2020-01-16 15:04 ` Yuan Fu
[not found] ` <CAO0xp5w8PwAiy=JNVmCK652rCs_06cMAO5_+1ppHwppQ2js4VQ@mail.gmail.com>
2020-01-17 23:31 ` Yuan Fu
2020-01-18 11:15 ` Eli Zaretskii
2020-01-18 13:32 ` Yuan Fu
2020-01-18 15:21 ` Eli Zaretskii
2020-01-18 15:41 ` Yuan Fu
2020-01-18 16:50 ` Eli Zaretskii
2020-01-18 16:20 ` John Yates
2020-01-18 16:53 ` Eli Zaretskii
2020-01-18 17:53 ` Yuan Fu
2020-01-18 17:56 ` Eli Zaretskii
2020-01-18 18:21 ` martin rudalics
2020-01-18 18:33 ` Eli Zaretskii
2020-01-18 18:36 ` Yuan Fu
2020-01-18 18:48 ` Eli Zaretskii
2020-01-18 20:10 ` Yuan Fu
2020-01-18 18:41 ` martin rudalics
2020-01-18 19:18 ` Eli Zaretskii
2020-01-18 21:43 ` martin rudalics
2020-01-19 15:40 ` Eli Zaretskii
2020-01-19 17:33 ` Yuan Fu
2020-01-19 17:42 ` Eli Zaretskii
2020-01-19 17:57 ` Yuan Fu
2020-01-19 18:43 ` Eli Zaretskii
2020-01-19 19:35 ` Yuan Fu
2020-01-19 20:07 ` Eli Zaretskii
2020-01-20 1:22 ` Yuan Fu
2020-01-20 18:03 ` Eli Zaretskii
2020-01-22 1:50 ` Yuan Fu
2020-01-24 7:16 ` Eli Zaretskii
2020-01-24 20:12 ` Yuan Fu
2020-01-24 22:37 ` John Yates
2020-01-25 7:45 ` Eli Zaretskii
2020-01-25 14:33 ` John Yates
2020-01-25 17:10 ` Eli Zaretskii
2020-01-25 8:43 ` martin rudalics
2020-01-25 14:56 ` John Yates
2020-01-25 17:14 ` martin rudalics
2020-01-25 20:17 ` John Yates
2020-01-26 8:41 ` martin rudalics
2020-01-26 4:18 ` Richard Stallman
2020-01-26 5:09 ` Drew Adams
2020-01-26 5:31 ` Yuan Fu
2020-01-26 17:12 ` Eli Zaretskii
2020-01-25 8:24 ` Eli Zaretskii
2020-01-25 8:58 ` martin rudalics
2020-01-25 10:25 ` Eli Zaretskii
2020-01-25 10:30 ` Eli Zaretskii
2020-01-25 22:34 ` Yuan Fu
2020-01-26 8:42 ` martin rudalics
2020-01-26 16:12 ` Yuan Fu
2020-01-26 16:57 ` martin rudalics
2020-01-27 15:56 ` Yuan Fu [this message]
2020-01-27 19:18 ` martin rudalics
2020-01-27 19:53 ` Yuan Fu
2020-01-28 9:49 ` martin rudalics
2020-01-28 20:01 ` Yuan Fu
2020-01-28 20:33 ` John Yates
2020-01-31 13:58 ` Eli Zaretskii
2020-01-31 15:25 ` Yuan Fu
2020-01-31 15:35 ` Eli Zaretskii
2020-01-25 8:43 ` martin rudalics
2020-01-25 10:21 ` Eli Zaretskii
2020-01-25 12:11 ` martin rudalics
2020-01-25 13:35 ` Eli Zaretskii
2020-01-25 8:42 ` martin rudalics
2020-01-19 18:30 ` martin rudalics
2020-01-19 18:47 ` Eli Zaretskii
2020-01-19 18:05 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BBF05241-BE20-4121-A5E0-260A83412F2C@gmail.com \
--to=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=john@yates-sheets.org \
--cc=juri@linkov.net \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).