[Top][All Lists]

[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: Mon, 07 Dec 2015 18:24:15 +0200

> From: John Wiegley <address@hidden>
> Cc: address@hidden,  address@hidden
> 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

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.

reply via email to

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