Re: Better handling of window margins

[martin rudalics <rudalics@gmx.at>]

 > For the first issue, IMO it isn't enough to specify just one value,
 > the required margin width.  You need also to specify the width of the
 > stuff, if any, that is displayed in the margin.  (This will have to be
 > specified in pixels, because you can display images and pixel-granular
 > stretches of white space in the margins.)  For example, linum-mode
 > will specify a margin width of N columns, and display width of the
 > same N columns in pixels.

How would this work with scaled text?

 > By contrast, modes such as writeroom-mode
 > will specify a margin width of M columns and display width of zero.
 >
 > So we need to maintain, for each of the 2 margins, a list of elements
 > of the form:
 >
 >     (SYMBOL MARGIN-WIDTH DISPLAY-WIDTH)
 >
 > where SYMBOL is a unique symbol used to identify the request that came
 > from a specific feature/mode.  We should provide a function to return
 > this list, or maybe make it the value of a local public variable.  We
 > should also have a way for a feature to update its request.

This probably has to be a window parameter because at least the
margin-width may differ according to the window the buffer is displayed in.

 > Now regarding the split-window issue.  I believe we shouldn't try to
 > second-guess how to split windows in these cases.  Instead, we should
 > place the burden of doing TRT on the modes.  Specifically:
 >
 >   . for splitting the window with "C-x 2" and "C-x 3", the mode could
 >     simply invoke the correct splitting function itself

When two modes simultaneously use the margins, which splitting function
would be chosen?

 >   . for splitting the window as result of some command calling
 >     display-buffer, we could expect the modes to customize the
 >     display-buffer-* variables to control how the window is split (if
 >     there are currently no features/variables to that effect, we should
 >     add them)

When two modes simultaneously use the margins, which buffer display
function would be chosen?

And how would we handle functions like ‘set-window-fringes’ or
‘set-frame-width’?

martin