Re: Better handling of window margins

[Eli Zaretskii <eliz@gnu.org>]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 06 Dec 2015 16:29:01 -0800
> 
> > Now we are talking about going even farther into the fantasy land, and
> > imagine packages that also want to control the order with which their stuff
> > is displayed in the margins. Sounds like over-engineering to me, but if
> > someone can show such packages, perhaps it's not fantasy after all.
> 
> If the driving force behind this discussion is the inability of linum.el and
> darkroom.el to play together, then I'm simply OK with them being incompatible
> at this stage in Emacs' development.

It is driven by inability of _any_ 2 packages to request margin space
without stomping on the other package's needs.

> I would much rather we solve the general case of dealing with window display
> overall -- solving the multi-margin problem en passant -- than to invent new
> APIs for a specific use case.
> 
> It's OK if some things don't work -- even if it feels like they should. It's
> better to wait for the right solution, then to scramble for an immediate
> half-solution.

I don't think we know what _is_ the right solution for the more
general problem.  We don't have any experience and AFAIK no packages
that need such a solution.

Anyway, I'm okay with trying to solve a more general case, if
someone's got that itch, but I'd object to significant changes in the
display engine on behalf of that, unless we have clear use cases that
we want to support.  The display engine already supports a gazillion
minor features, many of which were almost unknown, until some
inquiring minds discovered them, thought they were very cool, and are
using each one of them in a couple of obscure packages, mostly
unbundled, that are very precious to their users.  So now we are in a
situation where no significant cleanups are possible that won't cause
bug reports about broken features, and adding new features is a royal
pain.

So I think we should be very cautious with adding non-trivial display
features, and be sure they have important use cases backing them up
that we want to support for the observable future.