~eshel/dev

3 2

Simplify face definitions in sweeprolog

Details
Message ID
<jwvmt0szi2u.fsf-monnier+emacs@gnu.org>
DKIM signature
missing
Download raw message
Hi,

The patch below simplifies face definitions by consolidating common
elements from dark&light into the default.

The last hunk additionally avoids the use of font-lock's deprecated
"face variables", and refers to the face directly instead.


        Stefan
Details
Message ID
<m1o7l8571m.fsf@eshelyaron.com>
In-Reply-To
<jwvmt0szi2u.fsf-monnier+emacs@gnu.org> (view parent)
DKIM signature
missing
Download raw message
Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hi,
>
> The patch below simplifies face definitions by consolidating common
> elements from dark&light into the default.

Thank you, I really appreciate you taking an interest in Sweep.

The changes you suggest to the face definitions actually alter the
various faces that we end up with, though.  Basically, we have three
sets of faces: default, light and dark.  The default faces are what most
users should be using, while the light and dark styles are there to
provide a "soft landing" for users moving to Sweep (and GNU Emacs more
generally) from the SWI-Prolog built-in editor (called PceEmacs[0], an
Emacs that you program in Prolog!).  Sweep's light faces style is based
on how the SWI-Prolog built-in editor highlights Prolog code by
default[1], while the dark style is based on the built-in editor's dark
theme.

Crucially, the light and dark variants do not inherit from the default
variant.  The default variant id aimed to be the most natural for Emacs
users (hence it mostly relies on standard font-lock faces), while the
light and dark styles serve a different goal.  Admittedly, this adds a
layer of complication to the code, and I'm not sure the current approach
(namely the sweeprolog-defface macro) is the most elegant...

> The last hunk additionally avoids the use of font-lock's deprecated
> "face variables", and refers to the face directly instead.

I'll apply that part regardless, thanks.


Best,

Eshel


[0] https://www.swi-prolog.org/pldoc/man?section=pceemacs
[1] The reference for the light style is basically this https://github.com/SWI-Prolog/swipl-devel/blob/master/library/prolog_colour.pl#L2584
Details
Message ID
<jwvttuzvamj.fsf-monnier+emacs@gnu.org>
In-Reply-To
<m1o7l8571m.fsf@eshelyaron.com> (view parent)
DKIM signature
missing
Download raw message
> Crucially, the light and dark variants do not inherit from the default
> variant.  The default variant is aimed to be the most natural for Emacs
> users (hence it mostly relies on standard font-lock faces), while the
> light and dark styles serve a different goal.

Aha!  I had indeed misunderstood, thanks.

> Admittedly, this adds a layer of complication to the code, and I'm not
> sure the current approach (namely the sweeprolog-defface macro) is the
> most elegant...

Maybe a more elegant approach (or at least, one that fits better with
the rest of Emacs facilities) is to make the dark and the light options
custom-themes?  A "custom theme" is nothing more than a set of
variable&face settings, and users can enable any number of themes they
want, so it wouldn't prevent them from using some other theme at the
same time?


        Stefan
Details
Message ID
<m1352ja1t1.fsf@eshelyaron.com>
In-Reply-To
<jwvttuzvamj.fsf-monnier+emacs@gnu.org> (view parent)
DKIM signature
missing
Download raw message
>> Admittedly, this adds a layer of complication to the code, and I'm not
>> sure the current approach (namely the sweeprolog-defface macro) is the
>> most elegant...
>
> Maybe a more elegant approach (or at least, one that fits better with
> the rest of Emacs facilities) is to make the dark and the light options
> custom-themes?  A "custom theme" is nothing more than a set of
> variable&face settings, and users can enable any number of themes they
> want, so it wouldn't prevent them from using some other theme at the
> same time?

That makes a lot of sense, thanks!  I'll look into extracting the
non-default variants and refactoring them as custom themes.

-- 
Best,

Eshel
Reply to thread Export thread (mbox)