Re: Extend gdb to filter registers

[Yuan Fu]

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

simplify-update1.patch
Description: Binary data