[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: Sat, 05 Dec 2015 09:56:33 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 04 Dec 2015 16:33:00 -0500
> >> It means that package A and B place their things on different lines, so
> >> the needed margin size is the max of X and Y rather than the sum.
> > How can the packages themselves know that?
> Good question.  Presumably they'd need to detect when they add
> a display-margin element somewhere where there is already another
> such element.

It is much simpler to assume that each one of the packages displays
something in the margin on each screen line, at least potentially.  It
wastes some screen real estate, but it will never fail to show what
the packages want to display.

> >> You can't.  But if you need to share those two properties, it means
> >> they're displayed at the same place, which also means that maybe they
> >> don't need to be in different buffer location.
> >> At least, that's my assumption.
> > I don't see how that assumption could be a valid one.  Imagine a
> > buffer with linum-mode turned on, and an (imaginary) package that
> > displays in the margin short notes to specific places in the buffer.
> > The buffer position that correspond to the notes must be obeyed, or
> > else editing the buffer will not move the notes as expected.
> I'm not sure whether we can handle well all possible cases, indeed.
> But if we design an API where the elements are always associated with
> lines rather than with precise buffer positions, it should
> be manageable.  Maybe this API will be inconvenient for some use cases,
> of course.

Once again, my proposal handles this for all cases.  So I think it's a
good starting point.

reply via email to

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