Calling `TEDIT` with title-less window as second arg blocks prompt area

[pamoroso]

Pass a window with no title as the second argument of a call to TEDIT, like this:

(SETQ W (TEDIT NIL (CREATEW)))

and swipe out a small window like this:

Most of the prompt area is blocked by the title bar of the TEdit window. Next, print something into the prompt area:

(TEDIT.PROMPTPRINT W "Hi there" T)

Now the prompt area blocks most of the TEdit title bar:

If you make the TEdit window large enough both the prompt area and the title bar will show up at full size:

This interaction between the prompt area and the title bar may lead to more issues when attaching a menu window to TEdit called with a title-less window. An example is documented here, where the fix was to set the window title before calling TEDIT.

This happens on both Linux Mint and Medley Online.

[rmkaplan]

I think the problem here is that there are 2 different (incompatible) notions of how to interpret the provided window. The code that puts on the title considers that the given window should include only the text area, and so the title comes on top of that. Since the title is usually taken out of the given region of a window, to compensate it grows the window to be enough bigger than the window provided so that the title sits on top of the provided text area.

But the code that attaches the promptwindow considers the given window to already have included space for a title, and attaches to the top of that. So the title and the promptwindow overlap.

If instead of giving the CREATEW window, you give the value of that window's region, then everything looks right...but the height of the text region is reduced by the space that was reserved for the title.

If from the user's point of view, a Tedit window is a single "object" that always has a title region and a promptwindow region, then a consistent behavior would be for space for the title and promptwindow be subtracted out from a given or swept out region, or the region of a given window. The text region would always be reduced accordingly, but the space occupied on the screen would be what the user specfied.

Alternatively, we could assert that the given region (however presented) is supposed to be the text region, and the title and promptwindow then take up additional space beyond what was given. So there may be overlap with other windows that are just above the specified region.

I tend to like the subtractive arrangement.

[pamoroso]

I'm leaning towards the subtractive arrangement too. When I swipe out a window or define its region I expect that area to include everything the window involves, not to grow further in possibly unpredicatle ways.

Any potential compatibility issues with existing code?

[rmkaplan]

The file browser windows are created in subtractive mode, so the header windows and the menu are all within the given region. File browser has fairly complicated code to do that.

There is a version of ATTACHWINDOW in lispusers/REGIONMANAGER that systematizes the subtractive construction of window constellations (See the "Constellation regions" section of REGIONMANAGER.TEDIT). If the new argument TAKEFROMCENTRAL is true, the central window shrinks so that the new attachment fits within the central window's original region.

This extension is available in the full loadup, because TEDIT imports REGIONMANAGER. But it could also be moved into ATTACHEDWINDOW so it is always available.