[Top][All Lists]

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

Re: ELPA: add lin.el

From: Protesilaos Stavrou
Subject: Re: ELPA: add lin.el
Date: Sat, 06 Nov 2021 06:55:49 +0200
User-agent: Notmuch/0.33.2 (https://notmuchmail.org) Emacs/29.0.50 (x86_64-pc-linux-gnu)

On 2021-11-05, 13:28 -0700, Stefan Kangas <stefankangas@gmail.com> wrote:

> Protesilaos Stavrou <info@protesilaos.com> writes:
>> The user can enable 'lin-mode' in select major modes to have a more
>> intense (or just different) style for the highlighted line of
>> 'hl-line-mode', without compromising the utility of the 'hl-line' face
>> in all other buffers.
> This looks useful, thanks.  My question is: why make it into a
> third-party package instead of a patch against hl-line.el?

The package has the upside that it can be used right away.  Whereas
changes in Emacs 29 will have to be followed by changes to all relevant
downstream packages that need to style hl-line accordingly (I know of
Elfeed, Mu4e, Notmuch).

I suggest we do both: let the package exist and also patch hl-line.el.

> I imagine that we could introduce a new permanently local defvar that
> users (or even mode developers?) could set in individual modes.  If
> that variable is non-nil, these faces are used instead of the default
> ones.  We could also have a defcustom that disables this completely (I
> think it should be on by default, but we can bikeshed that later).
> We could also just include the mode of course, if we think that's the
> better interface.  I sort of like the variables, as that allows modes to
> "register" themselves as interesting for this purpose, and the user to
> completely disable the functionality if they don't like it by setting a
> defcustom.  (Instead of all users having tons of mode-hooks in their
> configuration for each and every little mode where this could make
> sense.)
> What do you think?

I think having major modes register themselves in that way is the best
outcome.  The presence of a separate minor-mode/package is just a way to
work around the current constraints.

Protesilaos Stavrou

reply via email to

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