Re: Better handling of window margins

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 03 Dec 2015 19:16:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  >> You say that linum-mode will specify a "display width of the same N
>  >> columns in pixels".  How would it react to an increase of the width of
>  >> the default face?
>  >
>  > How is it covered today?
> 
> Via ‘post-command-hook’ I suppose.
> 
>  >> IIUC this is not covered by any special hook so it has to be done
>  >> via ‘post-command-hook’.  No great deal but it shows that
>  >> ‘post-command-hook’ is indispensable for such modes.
>  >
>  > Even if this conclusion is correct, is it really relevant to the
>  > concrete issue being discussed?
> 
> Hopefully.  If we want to get rid of ‘post-command-hook’ dependencies.

My suggestion wasn't supposed to do anything about post-command-hook.
It aimed only at allowing separate features display in the margins
without interfering with one another.

>  > IOW, what I suggested wasn't supposed to solve any problem except one:
>  > how can several features display simultaneously on the same display
>  > margin.  It wasn't supposed magically solve other related or unrelated
>  > problems.
> 
> How does the ability to specify a margin size in pixels help to display
> several features simultaneously?

Size in pixels is not the main part of what I proposed.  I only
mentioned pixels because the margins can display images, and there's
no easy way of knowing how many columns an image will take.

The main part of my proposal is that each request for a window margin
will specify both the margin size and the size of the stuff that will
be displayed there.  Two values, not one.

>  >> So you mean there's no need for any new infrastructure here - the
>  >> ‘split-window’ window parameter can take care of this.
>  >
>  > I simply don't believe there could be a generic solution that doesn't
>  > involve active participation of the modes that are affected by this.
> 
> If modes can specify their needs for each window they act on, the
> overhead will be encapsulated in calculating a window's minimum width.

How can you encapsulate what an unknown mode will want to do?

> If we can't manage that, then modes will also have to intervene every
> time we set a window's fringes or scroll-bar width or adjust its right
> trailing edge.  I'm afraid that mode authors won't want to do that.

Sorry, you lost me.  What do fringes and scroll bars have in common
with the issue at point?  Do you envision a window with 20-column wide
fringes or something?

>  >>   >> 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?
>  >>
>  >> Is there one?
>  >
>  > Of course: imagine that the effects of 2 or more elements of the list
>  > contradict each other.  Which one to choose?
> 
> I thought Joost's idea was to capture this issue by having
> ‘window-splittable-p’ count static margins only.  So I don't see any
> contradiction.

It makes little sense to me to solve a small portion of a problem.