Re: Extend gdb to filter registers

[Yuan Fu <casouri@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5142 bytes --]



> On Jan 24, 2020, at 2:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 21 Jan 2020 20:50:46 -0500
>> Cc: martin rudalics <rudalics@gmx.at>,
>> Juri Linkov <juri@linkov.net>,
>> emacs-devel@gnu.org,
>> monnier@iro.umontreal.ca,
>> john@yates-sheets.org
>> 
>> 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?

No, but this can be easily fixed. I’ll fix that in the next patch.

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

In gdb-mi.el, there is only one function that used gbd-display-source-buffer — gdb-goto-breakpoint. In gud.el, there is also only one function, gud-display-frame calls gud-display-line calls gdb-display-source-buffer (after patch, before patch it calls display-buffer). And gud-display-frame is used to display a file:line. Overall I think it’s save. Of course you can never be so sure by just looking at the code and reason. But there is no test, and I don’t know how to write tests for interactive programs like this. Maybe you can give me some pointers on tests, if you think that’s vitally important.

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

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

You have the choice. If I want gdb to always reuse the window, I can set the number to 1. 

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

I guess you mean this is somewhat ad-hoc. I agree. We can change it to options like “always reuse one”, “switch between 2”, “cycle between 3” and “as many as possible”, how about that? I.e., 

(defcustom gdb-source-window-number 'always-reuse-one
  :type 'symbol
  :options '(always-reuse-one switch-between-two
                              cycle-between-three
                              as-many-as-possible)
  :group 'gdb
  "Number of source windows gdb uses.”)

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

Are you referring to the complain that gdb messes up windows after it quits? 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. As for opening a new frame, that solves the problem in someway, but what if someone don’t want to open a new frame and don’t want gdb messes his windows either? If you are talking about the problem where gdb opens new source windows when I don’t want it to, I don’t see now opening gdb in a new frame help that.

Yuan


[-- Attachment #2: Type: text/html, Size: 8057 bytes --]