Re: Extend gdb to filter registers

[Eli Zaretskii]

> From: Yuan Fu <address@hidden>
> Date: Tue, 21 Jan 2020 20:50:46 -0500
> Cc: martin rudalics <address@hidden>,
>  Juri Linkov <address@hidden>,
>  address@hidden,
>  address@hidden,
>  address@hidden
> 
> 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?
  . 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?

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

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.

> If you think this patch is fine, I’ll 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?