>> So it seems the intension is to display source in new window, not using only one window as I originally
>> thought. I’d like to simplify it, put the decision logic into one place. And then we can add customizability to it.
> 
> Thanks, sounds like a good plan to me.

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

Gdb-mi.el used to have a variable gdb-source-window, I changed it to gdb-source-window-list. And now reusing a window is as simple as looking at this list of windows. (No need to check for last-last-frame, etc). 

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

Overall this patch doesn’t change the behavior except 1) new window/not is now determined by gdb-maximum-source-window-count instead of display-buffer 2) now gud also uses gdb’s display function, so there is no check for gdb-mi vs gud anymore

You’ll also notice that, when you quit, all the source windows are left undeleted. That’s the original behavior and I have another patch that restores the old window configuration the user have before starting gdb. So I didn’t do anything about that.

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?

Yuan