From: Rainer M Krug <Rainer@krugs.de>
To: Dan Espen <despen@verizon.net>
Cc: help-gnu-emacs@gnu.org
Subject: Re: custom-themes BAD?
Date: Tue, 25 Feb 2014 20:33:43 +0100 [thread overview]
Message-ID: <m27g8j0yy0.fsf@krugs.de> (raw)
In-Reply-To: <icmwhfcbne.fsf@home.home> (Dan Espen's message of "Tue, 25 Feb 2014 13:03:49 -0500")
[-- Attachment #1: Type: text/plain, Size: 7798 bytes --]
Dan Espen <despen@verizon.net> writes:
> Drew Adams <drew.adams@oracle.com> writes:
>
>>> When we get to packages like gnus, gnus goes ahead and
>>> defines it's own faces:
>>>
>>> gnus-cite-attribution-face
>>> gnus-cite-face-1
>>> gnus-cite-face-2
>>> gnus-cite-face-3
>>> gnus-cite-face-4
>>> gnus-cite-face-5
>>> gnus-cite-face-6
>>> gnus-cite-face-7
>>> gnus-cite-face-8
>>> gnus-cite-face-9
>>> gnus-cite-face-10
>>> gnus-cite-face-11
>>> gnus-emphasis-bold
>>> gnus-emphasis-bold-italic
>>>
>>> That's the problem, there should be font-lock faces like:
>>>
>>> font-lock-bold,
>>> font-lock-level-1 thru 12,
>>> font-lock-large-1,,,
>>> font-lock-blue...
>>> font-lock-reverse
>>
>> Those are not existing font-lock faces, AFAIK. They are certainly
>> not defined by library `font-lock.el'.
>
> I know that, that was my point, they (or something like them)
> should be available.
>
>>> and so on.
>>>
>>> All the packages should be using font-lock-* faces as far as
>>> possible. Then the themes can all set the same set of faces
>>> much more easily.
>>
>> I cannot speak to whether it is appropriate for Gnus to define
>> faces for its use here or whether it should instead just use
>> common font-lock faces instead. I do not use Gnus.
>
> I'm only using GNUS as an example. Take a look at
> manoj-dark-theme. You'll see the problem.
>
>> That kind of question needs to be decided on a case-by-case
>> basis. I only want to add here that it is NOT the case that
>> libraries "should" reuse font-lock faces, in general. They
>> should use font-lock faces when that makes sense, and not
>> otherwise.
>>
>> The advantage of reusing a common face is the same as the
>> disadavantage: change it once here and it gets changed everywhere
>> it is used. That makes some things easier and others more
>> difficult.
>>
>> What is especially pernicious, IMO, is *hard-coding* the use
>> of a particular face, rather than providing a new face whose
>> default appearance *inherits* from that face.
>>
>> That makes it unnecessarily difficult for a user to customize
>> the use of that particular highlighting.
>>
>> E.g., a given library `foo.el' might well define a face
>> `foo-emphasis', which might inherit its default appearance from
>> the basic face `italic'. It is then easy for a user to
>> customize the appearance of that Foo highlighting without
>> affecting use of face `italic' throughout Emacs.
>>
>> If, instead, `foo.el' just uses face `italic', then the user
>> loses flexibility: s?he must change the appearance everywhere
>> or nowhere.
>>
>> If a library defines a new face, but inherits its default
>> appearance from another face, a user can customize either the
>> parent face or the child. In the former case, the result is
>> the same as in the hard-coded context: customize once to
>> change the appearance everywhere (everywhere that inherits).
>> So you really lose nothing by defining a library-specific face.
>>
>> Other people, including some Emacs maintainers, disagree.
>> The result is that we still have some hard-coded uses of general
>> faces, rather than letting users decide easily.
>>
>> With no knowledge of Gnus and its faces, I'll ask: just what
>> is the problem that you are trying to raise here, wrt custom
>> themes? Is it that lots of faces means theme size is too large?
>> IOW, it's not clear to me what your point is.
>
> If you use manoj-dark theme, then switch to another theme,
> manoj will leave behind a huge number of it's customizations,
> since other themes don't set as many fonts.
Now this is an important point and raises one question: there is a
load-theme function - but not an unload-theme which removes the
customizations done by the package? An author of a theme can not be
expected to undo all changes another theme might have done - but one
could expect a package author to provide a function which unloads the
theme and restores the theme used before, or simply reset to the default
values.
IMO, this is the problem with themes.
Cheers,
Rainer
>
> manoj-dark is 800 lines. Too many for the other theme creators
> to deal with.
>
> A theme should be able to change all the colors a user is
> likely to see. A set of generic fonts that packages can
> inherit from should solve the problem.
>
> The font-lock faces are fine, they just don't go far enough.
Tue, 25 Feb 2014 13:03:49 -0500 (1 hour, 25 minutes, 11 seconds ago)
Organization: A noiseless patient Spider
Drew Adams <drew.adams@oracle.com> writes:
>> When we get to packages like gnus, gnus goes ahead and
>> defines it's own faces:
>>
>> gnus-cite-attribution-face
>> gnus-cite-face-1
>> gnus-cite-face-2
>> gnus-cite-face-3
>> gnus-cite-face-4
>> gnus-cite-face-5
>> gnus-cite-face-6
>> gnus-cite-face-7
>> gnus-cite-face-8
>> gnus-cite-face-9
>> gnus-cite-face-10
>> gnus-cite-face-11
>> gnus-emphasis-bold
>> gnus-emphasis-bold-italic
>>
>> That's the problem, there should be font-lock faces like:
>>
>> font-lock-bold,
>> font-lock-level-1 thru 12,
>> font-lock-large-1,,,
>> font-lock-blue...
>> font-lock-reverse
>
> Those are not existing font-lock faces, AFAIK. They are certainly
> not defined by library `font-lock.el'.
I know that, that was my point, they (or something like them)
should be available.
>> and so on.
>>
>> All the packages should be using font-lock-* faces as far as
>> possible. Then the themes can all set the same set of faces
>> much more easily.
>
> I cannot speak to whether it is appropriate for Gnus to define
> faces for its use here or whether it should instead just use
> common font-lock faces instead. I do not use Gnus.
I'm only using GNUS as an example. Take a look at
manoj-dark-theme. You'll see the problem.
> That kind of question needs to be decided on a case-by-case
> basis. I only want to add here that it is NOT the case that
> libraries "should" reuse font-lock faces, in general. They
> should use font-lock faces when that makes sense, and not
> otherwise.
>
> The advantage of reusing a common face is the same as the
> disadavantage: change it once here and it gets changed everywhere
> it is used. That makes some things easier and others more
> difficult.
>
> What is especially pernicious, IMO, is *hard-coding* the use
> of a particular face, rather than providing a new face whose
> default appearance *inherits* from that face.
>
> That makes it unnecessarily difficult for a user to customize
> the use of that particular highlighting.
>
> E.g., a given library `foo.el' might well define a face
> `foo-emphasis', which might inherit its default appearance from
> the basic face `italic'. It is then easy for a user to
> customize the appearance of that Foo highlighting without
> affecting use of face `italic' throughout Emacs.
>
> If, instead, `foo.el' just uses face `italic', then the user
> loses flexibility: s?he must change the appearance everywhere
> or nowhere.
>
> If a library defines a new face, but inherits its default
> appearance from another face, a user can customize either the
> parent face or the child. In the former case, the result is
> the same as in the hard-coded context: customize once to
> change the appearance everywhere (everywhere that inherits).
> So you really lose nothing by defining a library-specific face.
>
> Other people, including some Emacs maintainers, disagree.
> The result is that we still have some hard-coded uses of general
> faces, rather than letting users decide easily.
>
> With no knowledge of Gnus and its faces, I'll ask: just what
--
Rainer M. Krug
email: RMKrug<at>gmail<dot>com
[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]
next prev parent reply other threads:[~2014-02-25 19:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 17:08 custom-themes BAD? Dan Espen
2014-02-25 17:22 ` Joost Kremers
2014-02-25 17:38 ` E Sabof
2014-02-25 17:54 ` Dan Espen
[not found] ` <mailman.16024.1393350344.10748.help-gnu-emacs@gnu.org>
2014-02-25 18:06 ` Dan Espen
2014-02-25 17:35 ` Drew Adams
[not found] ` <mailman.16021.1393349758.10748.help-gnu-emacs@gnu.org>
2014-02-25 18:03 ` Dan Espen
2014-02-25 19:33 ` Rainer M Krug [this message]
[not found] ` <mailman.16038.1393356841.10748.help-gnu-emacs@gnu.org>
2014-02-25 19:48 ` Dan Espen
2014-02-25 20:04 ` Rainer M Krug
2014-02-25 21:05 ` W. Greenhouse
2014-02-25 22:19 ` Drew Adams
[not found] <<ic1tyrdsrh.fsf@home.home>
[not found] ` <<slrnlgpkad.3j2.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>
2014-02-25 17:45 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m27g8j0yy0.fsf@krugs.de \
--to=rainer@krugs.de \
--cc=despen@verizon.net \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).