emacs-devel
[Top][All Lists]
Advanced

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

Re: Better handling of window margins


From: Eli Zaretskii
Subject: Re: Better handling of window margins
Date: Wed, 02 Dec 2015 19:53:59 +0200

> Date: Wed, 02 Dec 2015 18:43:47 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > 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?

Not sure what problem bothers you.  set-window-margins interpret its
argument as the number of character cells.  Converting from pixels, if
needed, is simple.  If worse comes to worst, the requesting mode can
use the likes of string-width to compute that.

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

It's up to the mode that wants to support splitting in any non-trivial
manner.  The mode knows exactly what are its needs, so it is free of
the guesswork.

In any case, the same problem exists if this is somehow guessed.  The
infrastructure cannot know enough about the modes to make a decision.

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

The same problem exists with the proposed solution, doesn't it?

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

Hey, one problem at a time, please!




reply via email to

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