bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48901: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.mo


From: Eli Zaretskii
Subject: bug#48901: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: bug#48901: [kisara.moe] 28.0.50; Support text-based fringe contents alongside bitmaps
Date: Mon, 05 Jul 2021 14:43:40 +0300

[Please always use Reply All to keep the bug address on the CC list.]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Date: Mon, 05 Jul 2021 04:20:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Mohsin Kaleem <mohkale@kisara.moe>
> >> Cc: 48901@debbugs.gnu.org
> >> Date: Tue, 15 Jun 2021 23:10:33 +0100
> >> 
> >> What are your thoughts on having a dedicated face for the margin?
> >
> > Lisp programs display in the margins by putting string-valued
> > properties on buffer text.  While doing that, how hard is it to
> > specify the face for those strings? it's just one call to 'propertize'
> > away.
> >
> > By default, the text displayed in the margins inherits the face of the
> > text on which you put the corresponding properties, right?  Why isn't
> > that a good default?
> 
> I understand that but I still think there should be a built-in face that
> these other margin faces can inherit from.
> At the moment for example `diff-hl-mode` uses `diff-hl-margin-change`,
> and several other faces for the margin indicators. I've set these up to
> inherit from my `fringe` face so where diff-hl-mode attaches a margin
> indicator it looks like its on the fringe. However where it doesn't no
> default margin face exists so diff-hl-mode just applies the `default`
> face which looks out of place alongside margin faces.
> Now of course I could send a PR over to diff-hl-mode to ask them to let
> me specify a face for sections that don't have anything diff-hl needs to
> highlight, but then I'd have to do the same for every other package that
> does something like this for the margin; admittedly I only know of 2
> such packages atm so it's manageable, however a built in default face to
> inherit from seems to me like the best way to do this.

What you ask for might not be easy to implement.  AFAIR, Emacs
determines the face of the characters before it knows where they will
be displayed.  Since the text on the margins is displayed using text
or overlay properties similar to other uses of these properties, by
the time Emacs knowns some text needs to be displayed on the margin
it's too late: the face has been already merged.





reply via email to

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