[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 05:32:55 +0200 |
> From: Yuri Khan <address@hidden>
> Date: Mon, 7 Dec 2015 02:24:26 +0600
> Cc: John Wiegley <address@hidden>, Stefan Monnier <address@hidden>,
> Emacs developers <address@hidden>
>
> On Sun, Dec 6, 2015 at 10:10 PM, Eli Zaretskii <address@hidden> wrote:
>
> 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
Can you name Emacs packages that implement those? (The first item
excluded, of course.)
> > 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.
If there are no packages that use the margins except the 2 classes
mentioned here, then this user preference is for now theoretical.
- Re: Better handling of window margins, (continued)
- Re: Better handling of window margins, Stefan Monnier, 2015/12/04
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/04
- Re: Better handling of window margins, Stefan Monnier, 2015/12/04
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/05
- Re: Better handling of window margins, Stefan Monnier, 2015/12/05
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/05
- Re: Better handling of window margins, Stefan Monnier, 2015/12/05
- Re: Better handling of window margins, John Wiegley, 2015/12/06
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/06
- Re: Better handling of window margins, Yuri Khan, 2015/12/06
- Re: Better handling of window margins,
Eli Zaretskii <=
- Re: Better handling of window margins, Yuri Khan, 2015/12/07
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/06
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/07
- Re: Better handling of window margins, Achim Gratz, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/07
- Re: Better handling of window margins, Achim Gratz, 2015/12/07
- Re: Better handling of window margins, Stefan Monnier, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/07