all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thibaut Verron <thibaut.verron@gmail.com>
To: Heime <heimeborgia@protonmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
Subject: Re: Introducing face in comments for various modes
Date: Mon, 12 Dec 2022 10:58:55 +0100	[thread overview]
Message-ID: <21708ec2-d908-4e91-6c0a-4b1cd253e707@gmail.com> (raw)
In-Reply-To: <DePJnaBgy8k5ZQwFKcwnBrfyahE31g5cISaAse1UjQBHBwzNujwp3WbqRZgu4mqF6WGQ5rXuwyi0wWGLtkyx7sEUqIGHLpSBSsgtaSA95n8=@protonmail.com>


On 12/12/2022 10:21, Heime wrote:
> ------- Original Message -------
> On Monday, December 12th, 2022 at 8:49 AM, Thibaut Verron 
> <thibaut.verron@gmail.com> wrote:
>
>> Le lun. 12 déc. 2022 à 04:01, Heime <heimeborgia@protonmail.com> a 
>> écrit :
>>
>>
>>
>>     ------- Original Message -------
>>     On Monday, December 12th, 2022 at 2:24 AM, Heime
>>     <heimeborgia@protonmail.com> wrote:
>>
>>
>>     > ------- Original Message -------
>>     > On Sunday, December 11th, 2022 at 5:40 PM, Stefan Monnier via
>>     Users list for the GNU Emacs text editor help-gnu-emacs@gnu.org
>>     wrote:
>>     >
>>     > > BTW, there is a related convention in ELisp code where
>>     comments that
>>     > > start in column 0 and which are introduced with 3 or more
>>     semi-colons
>>     > > are considered sectioning headers (where ";;;" means a top-level
>>     > > header, ";;;;" a subheader, ";;;;;" a subsubheader, ...).
>>     > >
>>     > > I'd be happy if Emacs were changed to highlighting those.
>>     > >
>>     > > Stefan
>>
>>     If you are colourising "Sectioning Headers", ensure that vibrant
>>     and good contrast:
>>
>>     1) betweenthe text and the background;
>>
>>     2) and between a header, subheader, subsubheader, ...
>>
>>     Use some colour metric (e.g. using the Web Content Accessibility
>>     Guidelines [WCAG]).
>>
>>     Because I consistently see that developers almost never care (or
>>     have the skills)
>>     to properly set up colours. Have suggested changing the colour
>>     scheme as described,
>>     for "Org Headings" because they are indistinguishable against a
>>     dark background and
>>     between a heading and its subheading. Applying such metrics have
>>     been turned down,
>>     with the excuse that if I want them right, I have to work on
>>     emacs customisations
>>     myself, as the crappy colours are there to stay.
>>
>>
>> > The colors of the standard themes are chosen with its (light) 
>> background in mind. If you change that background, it is not 
>> surprising that things fall apart.
>
> Choosing colours with a light background in mind is the wrong approach 
> because colours produce far greater visual
> impact.

There is no right or wrong approach, but individual preferences.

If you want a dark background, just use a dark background theme. For 
instance, emacs has a built-in implementation of the tango dark color 
palette. If contrast if your primary concern, you should look at the 
modus themes (modus-vivendi for the dark background), which is also part 
of emacs now.

M-x customize-themes and make your choice.


>
> Rather, there there should be carefully chosen colour settings for 
> both light and dark backgrounds.

That's how you end up with settings which are at best acceptable, but 
not perfect, for both light and dark backgrounds. The range of colors 
which are suitable for both light and dark backgrounds is just too narrow.

The proper way is the current way: carefully curated themes implementing 
all colors in a consistent ways.



 > > > It is not a new problem, but it doesn't mean that you have to 
customize all the individual faces yourself. Instead, you should look 
for a theme implementing
>> > the colors you like, and install it. The responsibility for having 
>> consistent colors across all emacs fonts is on the theme designer. 
>> You can still tweak some
>> > faces from there if you choose to of course.
>>
>> At any rate, Stefan's suggestion would not require making new design 
>> choices, as there are already faces designed for fontifying headers: 
>> outline-1, outline-2, etc.
>
> Making a new design choice is a necessity if you want to move forward.

No. The question is whether to fontify those headers, how to identify 
them, etc.

That's completely separate from the question of changing the face 
currently used for headers in other places.

>
>> Those faces are used by outline-mode, but not by outline-minor-mode 
>> (which emacs-lisp-mode uses to implement the ;;; comment headers) at 
>> the moment.
>
> Which proves my point that changes are necessary.  What needs to be 
> done is for colour contrast metrics
> to be taken seriously by all packages, rather than relying on some 
> theme to fix the crappy default choices.

Sorry to be blunt, but you couldn't be more wrong. For a start, 
outline-mode and outline-minor-mode are the same package. :)

But more to the point, with the current system, packages choose existing 
faces to implement coloring based on *what* they should color (e.g. is 
it a comment, is it a header, is it a keyword, is it something 
important). And the theme designers choose colors (and other features) 
for those faces.

As a result, colors are the same across all of Emacs (for example 
comments look the same in elisp and python), and -- if the theme maker 
is competent -- the colors will implement good contrast and be readable 
everywhere.

If instead we were to let each package decide on its colors, Emacs would 
look like a Christmas tree with different colors all over the place. And 
most of them would be really crappy because the package developer was 
never trained in graphic design, or because they didn't plan for all 
possible background colors (it's not as simple as light and dark, some 
people use blue, or green backgrounds), or because they didn't predict 
that their choice of color would conflict with the choice made by a 
minor mode in another package, or...

You shouldn't think of themes as "fixing the default choices" 
(especially considering that you are the one "breaking" them by 
insisting to use them with a background they weren't designed for). 
Their purpose is to implement different choices in a consistent way.


>>     >
>>     > > Heime [2022-12-11 15:35:41] wrote:
>>     > >
>>     > > > The following uses `hi-lock` to change the foreground of
>>     comments matching
>>     > > > a regexp. This is implemented for emacs-lisp files where
>>     comments start
>>     > > > with ";;".
>>     > > >
>>     > > > I would like to extend this for other programming languages
>>     besides emacs-lisp
>>     > > > files, using the relevant comment character automatically
>>     for that language.
>>     > > >
>>     > > > (defface elfa-face
>>     > > > '((t :foreground "magenta"))
>>     > > > "Face for comment headings.")
>>     > > >
>>     > > > (defun elfa-regexp (&optional actm)
>>     > > > "Identify comment category ';; [Category]'."
>>     > > > (highlight-regexp
>>     > > > "^;;\s+\\[.+\\].*$" 'elfa-face))
>>     > > >
>>     > > > (defun elfa-category ()
>>     > > > "TODO."
>>     > > > (interactive)
>>     > > > (add-to-list 'auto-mode-alist '("\\.el\\'" . hi-lock-mode))
>>     > > > (add-hook 'emacs-lisp-mode-hook 'hi-lock-mode t)
>>     > > > (add-hook 'hi-lock-mode-hook 'elfa-regexp))
>>
>


  reply	other threads:[~2022-12-12  9:58 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-11 15:35 Introducing face in comments for various modes Heime
2022-12-11 17:40 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-12  2:24   ` Heime
2022-12-12  3:00     ` Heime
2022-12-12  8:49       ` Thibaut Verron
2022-12-12  9:21         ` Heime via Users list for the GNU Emacs text editor
2022-12-12  9:58           ` Thibaut Verron [this message]
2022-12-12 10:20             ` Heime
2022-12-12 10:50               ` Thibaut Verron
2022-12-12 11:55                 ` Heime
2022-12-12 12:17                   ` Thibaut Verron
2022-12-12 14:46                     ` Heime
2022-12-12 15:22                 ` Yuri Khan
2022-12-12 15:38                   ` Thibaut Verron
2022-12-12 15:55                   ` Christopher Dimech
2022-12-12 16:07                   ` Christopher Dimech
2022-12-12 17:44                   ` Stefan Monnier
2022-12-13  5:20                     ` Christopher Dimech
2022-12-12 15:22           ` Stefan Monnier
2022-12-13  7:52           ` Jean Louis
2022-12-13  8:04             ` Heime
2022-12-13  8:30               ` Heime
2022-12-13  9:35                 ` Thibaut Verron
2022-12-13  9:46                   ` Heime
2022-12-13 10:05                     ` Thibaut Verron
2022-12-13 10:24                       ` Christopher Dimech
2022-12-13 10:40                       ` Heime
2022-12-13 10:45                         ` Thibaut Verron
2022-12-13 10:49                           ` Heime
2022-12-13 15:00                           ` Heime
2022-12-13 12:37                     ` Jean Louis
2022-12-13 14:00                       ` Heime
2022-12-13 12:36                 ` Jean Louis
2022-12-13 13:46                   ` Heime
2022-12-13 12:35               ` Jean Louis
2022-12-13  8:17             ` Christopher Dimech
2022-12-13 19:19               ` Jean Louis
2022-12-12 15:20         ` Stefan Monnier

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21708ec2-d908-4e91-6c0a-4b1cd253e707@gmail.com \
    --to=thibaut.verron@gmail.com \
    --cc=heimeborgia@protonmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.