[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: Sun, 26 Jan 2020 09:41:49 +0100

> I do not want to disable splitting altogether, only of certain
> windows.

You always can do that by setting the 'split-window' parameter of those
windows to 'ignore'.

> Thus an unsplittable frame solution is not practical

Maybe you should put those windows in an atomic window then.

>> (2) making windows fixed-size
> Making a windows fixed-size seems - at best - a kludge.
> It provides no way to state my intent.  Instead I achieve
> that intent - namely preventing certain windows from
> getting split - indirectly by specifying an unrelated property.
> The dissonance here is that I actually do _not_ want my
> windows (in this case gdb-mi's dedicated windows) to
> be fixed-size.  I regularly resize those windows by dragging
> their  borders.  Would that continue to be possible once I
> make the windows fixed size?


>> (1) setting 'split-height-threshold' and 'split-width-threshold'
>> accordingly
> Using ridiculously large splitting thresholds does allow
> me to have stable windows that never get split while
> continuing to be resizeable via dragging.  The unfortunate
> side-effect is that it prevents display-buffer from managing
> the large amount of screen space I have provided for
> displaying source buffers.


> An unsplittable window property sure seems appealing :-)
> The semantics are straight forward.  And I find it hard to
> imagine that the implementation would be very difficult.
> I expect that the biggest efforts would be documentation,
> NEWS, etc.

If all you want is to make a window really "unsplittable", the
'split-window' parameter mentioned above should accomplish that.  I
suppose though, that you want to make such windows unsplittable for
'display-buffer' only.  And this will cause real problems because how
should 'display-buffer-below-selected' or 'display-buffer-at-bottom'
handle such a case?


reply via email to

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