[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extend gdb to filter registers

From: martin rudalics
Subject: Re: Extend gdb to filter registers
Date: Sat, 25 Jan 2020 09:58:49 +0100

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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]