Re: Better handling of window margins

[Yuri Khan]

On Sun, Dec 6, 2015 at 10:10 PM, Eli Zaretskii <address@hidden> wrote:

> What I suggested should allow several packages displaying in the
> margin without interfering with each other.  That is already a
> solution that looks for a problem, since the most complex use case I'm
> aware of involves one package that displays in the margin and another
> that just needs the margins to be of certain width, but doesn't
> display anything there.

I can name several uses for the margin off the top of my head:

* Line numbers
* Bookmark markers (name(s) of register(s) which contain locations in this line)
* Modification bars (which might display one marker on lines modified
since the last save, another marker on lines which differ from the
staged state, and yet another for differences from last commit)
* Outlining widgets (collapse/expand whichever syntax constructs the
current mode defines)
* Breakpoints and current statement (which currently display in the
fringe but the fringe is limited)
* Lines that contain errors found during the last compilation
* Lines that contain matches found during the last grep
* “git blame” annotations
* Test coverage (or lack thereof) markers

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

IMO packages shouldn’t want to — not without knowing a great deal
about each other. The user, on the other hand, should be able to. A
simple priority map or a list of modes ordered by priority might be
sufficient.