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

Sure. So we are still using numbers (instead of symbols like `only-one-window` and `switch-between-two`, etc)?

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

No, I simply save the window configuration at gdb start up by `window-state-get` and restores it when gdb quits. If gdb doesn’t maximize the frame, it shouldn’t un-maximize the frame after it quits either. If you want to make gdb maximize the frame by default, then gdb should un-maximize the frame after it quits. What I want to say is, who makes the change, who is responsible for it.

> >> 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 think gdb could provide customizations via one or more customizable
> actions but always let users override them via their own buffer display
> customizations.

Do you mean user should be able to overwrite gdb-display-source-buffer-action as in (display-buffer gdb-display-source-buffer-action)? He is free to do so like any other (custom) variables. If you mean rules in `display-buffer-alist` should take precedence over gdb-display-source-buffer-action, I disagree. Because a source buffer in gdb setting is different from a normal buffer — it shouldn’t be surprising that source buffers display differently in gdb. Or, think of gdb as a special case, and special case normally take precedence over normal case.


As for John’s idea, un-splittable window property, I think it makes sense and would certainly be useful. But I suspect that the implementation is not as easy as that.


Below is the updates since last patch. Please apply this on top of the last patch. I figure this way you see the updates better. Now gud has the old behavior, `gdb-display-source-buffer` uses (display-buffer gdb-display-source-buffer-action), and I added two custom variable `gdb-max-source-window-count`(default to 1) and `gdb-display-source-buffer-action`.

Yuan