Re: Extend gdb to filter registers

[Eli Zaretskii]

> From: Yuan Fu <address@hidden>
> Date: Fri, 24 Jan 2020 15:12:37 -0500
> Cc: martin rudalics <address@hidden>,
>  Juri Linkov <address@hidden>,
>  emacs-devel <address@hidden>,
>  Stefan Monnier <address@hidden>,
>  John Yates <address@hidden>
> 
>  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’t had a clear idea on “how to open the new window” 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.

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

Yes, I think we should probably start at 1 and let users customize
that if they want to.

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

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’s 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.

That could be another way, but running a debugging session usually
benefits from maximizing the frame.  Will your patch undo that as well?