Re: Extend gdb to filter registers

[martin rudalics]

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

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

I agree that having always one source window should be the, somewhat
austere, default behavior.

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

But only if you have not customized 'reusable-frames' and
'pop-up-frames'.

> That could be another way, but running a debugging session usually
> benefits from maximizing the frame.

Funnily, I always unmaximize my frame when running a debugging session.
How could I otherwise see the debuggee's frame?

martin