Introducing face in comments for various modes

Introducing face in comments for various modes

[Heime]

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))

Re: Introducing face in comments for various modes

[Stefan Monnier via Users list for the GNU Emacs text editor]

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


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))

Re: Introducing face in comments for various modes

[Heime]

------- 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
 
Yes.  I use headings as you describe to identify sections of code that focus on a particular task.  But I also wanted to have some lower level categorisation (within a function, say) to group some descriptions together.
 
> 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))
> 
>

Re: Introducing face in comments for various modes

[Heime]

Sent with Proton Mail secure email.

------- 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.   





> Yes. I use headings as you describe to identify sections of code that focus on a particular task. But I also wanted to have some lower level categorisation (within a function, say) to group some descriptions together.
> 
> > 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))

Re: Introducing face in comments for various modes

[Thibaut Verron]

Le lun. 12 déc. 2022 à 04:01, Heime <heimeborgia@protonmail.com> a écrit :

>
>
>
>
>
> Sent with Proton Mail secure email.
>
> ------- 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.

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.

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.

Best wishes,
Thibaut



>
>
>
>
>
> > Yes. I use headings as you describe to identify sections of code that
> focus on a particular task. But I also wanted to have some lower level
> categorisation (within a function, say) to group some descriptions together.
> >
> > > 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))
>
>

Re: Introducing face in comments for various modes

[Heime via Users list for the GNU Emacs text editor]

------- 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. But, a dark background also makes the pupil expand, which amplifies the impairment of those with astigmatism.

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

>> 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.

> 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.

> Best wishes,
> Thibaut
>
>>> Yes. I use headings as you describe to identify sections of code that focus on a particular task. But I also wanted to have some lower level categorisation (within a function, say) to group some descriptions together.
>>>
>>> > 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))

Re: Introducing face in comments for various modes

[Thibaut Verron]

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))
>>
>

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> 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.

Standard metrics exist.  The Gnu Project like many others, does not
want to use them.
 
> 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.

If you use "modus-vivendi" for org-mode, the colours are all almost white,
a big problem particularly when you fold the org headings.
 
> > 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.
 
What metrics are being used.  The blind belief that the proper way is the 
current way, is the origin of the problem. 
 
> > > > 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.

One can at least use good metrics for light (white) and dark (dark) background.
We have not even arrived at that yet.  I am not arguing against comments looking
the same, but that there should specific settings for the canonical white and
black background as minimum.
 
> 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...

Am only discussing for white background and black background, which are the
canonical settings for printing.  With colour contrast you are limited by
the metric values which limits to about eight colours.  

It is not Christmas Tree as you say.  Focusing on any possible colour combination
(blue, or green backgrounds) is beyond the scope of my discussion.

Quite reasonable and achievable if there is the will.
 
> 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.

Good design in much more important that consistency.
 
> > > >
> > > > > 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))

Re: Introducing face in comments for various modes

[Thibaut Verron]

On 12/12/2022 11:20, Heime wrote:
> ------- Original Message -------
> On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verron<thibaut.verron@gmail.com>  wrote:
>
>
>> 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, Heimeheimeborgia@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 editorhelp-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.
> Standard metrics exist.  The Gnu Project like many others, does not
> want to use them.
You're moving the goalpost: the sentence I quoted claimed that "focusing 
on a light background is the wrong approach".

It's also factually not true that the GNU project does not care about 
readability metrics, especially now that the Modus themes are shipped 
with Emacs.

>> 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.
> If you use "modus-vivendi" for org-mode, the colours are all almost white,
> a big problem particularly when you fold the org headings.

I don't like dark backgrounds, but it seems perfectly readable to me.

Anyway, from personal experience the developer of the Modus themes is 
extremely responsive. If you have a problem with his themes you should 
take it up with him.

>>> 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.
>   
> What metrics are being used.  The blind belief that the proper way is the
> current way, is the origin of the problem.

For one, the Modus themes were developed with quantified metrics 
(minimal contrast ratio afaik), and they are two completely different 
themes for black and light backgrounds.

If you think you can do better, you are welcome to try. But if you come 
and claim that the current way is the wrong way, the burden of proof is 
on you. :)


>   
>>>>> 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.
> One can at least use good metrics for light (white) and dark (dark) background.
> We have not even arrived at that yet.  I am not arguing against comments looking
> the same, but that there should specific settings for the canonical white and
> black background as minimum.

And I am telling you that there are.

For light background: the default theme, leuven, tango, modus-operandi

For dark background: the default theme with inverse-video, tango-dark, 
modus-vivendi



>> 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...
> Am only discussing for white background and black background, which are the
> canonical settings for printing.  With colour contrast you are limited by
> the metric values which limits to about eight colours.
> It is not Christmas Tree as you say.  Focusing on any possible colour combination
> (blue, or green backgrounds) is beyond the scope of my discussion.

No it's not. My point is that if you leave the responsibility of 
choosing colors to packages as opposed to themes, it will be a Christmas 
tree and there will be unpredictable combinations. It's a direct 
consequence of your idea, you can't just wave it off.

It's already bad enough now with some packages defining their own faces 
without at least inheriting from the standard ones.

There are currently 5330 packages on Melpa. Do you plan to contact the 
authors of all of them individually to get them to implement your 
preferred colors?

With the current approach, on the other hand, it's very easy: report a 
bug for the theme you're using, or make your own theme if you really 
want to.

>> 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.
> Good design in much more important that consistency.

It's also much easier to achieve in a consistent system.


>>>>>> 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))

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Monday, December 12th, 2022 at 10:50 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 12/12/2022 11:20, Heime wrote:
> 
> > ------- Original Message -------
> > On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verronthibaut.verron@gmail.com wrote:
> > 
> > > 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, Heimeheimeborgia@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 editorhelp-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.
> > > Standard metrics exist. The Gnu Project like many others, does not
> > > want to use them.
> 
> You're moving the goalpost: the sentence I quoted claimed that "focusing
> on a light background is the wrong approach".

Having worked with modus-themes, it was concluded that there exist greater
variations in possibilities with a dark background that with a light one.
 
> It's also factually not true that the GNU project does not care about
> readability metrics, especially now that the Modus themes are shipped
> with Emacs.
> 
> > > 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.

Yes, contrast is my primary concern on some packages.

> > > M-x customize-themes and make your choice.
> > > If you use "modus-vivendi" for org-mode, the colours are all almost white,
> > > a big problem particularly when you fold the org headings.
> 
> 
> I don't like dark backgrounds, but it seems perfectly readable to me.

I personally always cater for both light and dark theme.
 
> Anyway, from personal experience the developer of the Modus themes is
> extremely responsive. If you have a problem with his themes you should
> take it up with him.

Will let him know.  Perhaps there are some problems there he can see.
 
> > > > 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.
> > 
> > What metrics are being used. The blind belief that the proper way is the
> > current way, is the origin of the problem.
> 
> 
> For one, the Modus themes were developed with quantified metrics
> (minimal contrast ratio afaik), and they are two completely different
> themes for black and light backgrounds.
> 
> If you think you can do better, you are welcome to try. But if you come
> and claim that the current way is the wrong way, the burden of proof is
> on you. :)

I worked on the enhancement of modus-themes.
 
> > > > > > 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.
> > > One can at least use good metrics for light (white) and dark (dark) background.
> > > We have not even arrived at that yet. I am not arguing against comments looking
> > > the same, but that there should specific settings for the canonical white and
> > > black background as minimum.
> 
> 
> And I am telling you that there are.
> 
> For light background: the default theme, leuven, tango, modus-operandi
> 
> For dark background: the default theme with inverse-video, tango-dark,
> modus-vivendi
> 
> 
> > > 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...
> > > Am only discussing for white background and black background, which are the
> > > canonical settings for printing. With colour contrast you are limited by
> > > the metric values which limits to about eight colours.
> > > It is not Christmas Tree as you say. Focusing on any possible colour combination
> > > (blue, or green backgrounds) is beyond the scope of my discussion.
> 
> 
> No it's not. My point is that if you leave the responsibility of
> choosing colors to packages as opposed to themes, it will be a Christmas
> tree and there will be unpredictable combinations. It's a direct
> consequence of your idea, you can't just wave it off.
> 
> It's already bad enough now with some packages defining their own faces
> without at least inheriting from the standard ones.

Right.  My focus has been to provide colours with good metrics so that 
people inherit from the standard ones.

 
> There are currently 5330 packages on Melpa. Do you plan to contact the
> authors of all of them individually to get them to implement your
> preferred colors?

To start using actual standards.  Absolutely, they should learn more and change
their packages.  
 
> With the current approach, on the other hand, it's very easy: report a
> bug for the theme you're using, or make your own theme if you really
> want to.
> 
> > > 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.
> > > Good design in much more important that consistency.
> 
> It's also much easier to achieve in a consistent system.

The argument is to design separately for light and also for dark background.
Emacs does have light and dark checks.
 
> > > > > > > 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))

Re: Introducing face in comments for various modes

[Thibaut Verron]

On 12/12/2022 12:55, Heime wrote:
> ------- Original Message -------
> On Monday, December 12th, 2022 at 10:50 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:
>
>
>> On 12/12/2022 11:20, Heime wrote:
>>
>>> ------- Original Message -------
>>> On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verronthibaut.verron@gmail.com wrote:
>>>
>>>> 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, Heimeheimeborgia@protonmail.com a
>>>>>> écrit :
>>>>>>
>>>>>> ------- Original Message -------
>>>>>> On Monday, December 12th, 2022 at 2:24 AM, Heime
>>>>>> heimeborgia@protonmail.com wrote:
>>>>>>
>>>>>>> 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.
>>>> Standard metrics exist. The Gnu Project like many others, does not
>>>> want to use them.
>> You're moving the goalpost: the sentence I quoted claimed that "focusing
>> on a light background is the wrong approach".
> Having worked with modus-themes, it was concluded that there exist greater
> variations in possibilities with a dark background that with a light one.

Great for themes with a black background.

That doesn't make it "wrong" for a theme to have a light background.

>> It's already bad enough now with some packages defining their own faces
>> without at least inheriting from the standard ones.
> Right.  My focus has been to provide colours with good metrics so that
> people inherit from the standard ones.

That's called designing a theme. Aka the current approach. Which you 
have been arguing is wrong.

>   
>> There are currently 5330 packages on Melpa. Do you plan to contact the
>> authors of all of them individually to get them to implement your
>> preferred colors?
> To start using actual standards.  Absolutely, they should learn more and change
> their packages.

Great. Good luck with that.

On the other hand, the current recommended approach is to inherit from 
existing faces and let theme designers (or users, if they choose to) 
populate those with suitable colors.

No need for package developers to implement standards, no need to learn 
about theme design, no need to change things to accommodate for 
user-preferred colors, and if you have a problem, only one bug report to 
file -- with the theme.

>>>> 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.
>>>> Good design in much more important that consistency.
>> It's also much easier to achieve in a consistent system.
> The argument is to design separately for light and also for dark background.
> Emacs does have light and dark checks.
>   

That's again, moving the point.

Yes, Emacs does have those checks, but it's just a different way of 
providing two themes for light and dark backgrounds. If done for full 
themes, it's only a formal change, between two separate theme 
definitions, or one with interleaved conditionals.

If done for only a subset of faces, leaving the others untouched, it's a 
poor-person's way to try to accommodate everything, but it's imperfect 
and it might be unreadable on themes which are far from the standard 
white or black (not to mention terminal users). For that use-case, it is 
usually preferred to find an existing face to inherit from, trusting the 
theme designers for this face to be rendered in a readable way.

Re: Introducing face in comments for various modes

[Heime]

Returning back to the code presented.  Do you know how I could use a generic variable for the different programming languages for the comment character ?  So I won't have to hardwire ";;" inside the regex. 

------- Original Message -------
On Monday, December 12th, 2022 at 12:17 PM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 12/12/2022 12:55, Heime wrote:
> 
> > ------- Original Message -------
> > On Monday, December 12th, 2022 at 10:50 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > 
> > > On 12/12/2022 11:20, Heime wrote:
> > > 
> > > > ------- Original Message -------
> > > > On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verronthibaut.verron@gmail.com wrote:
> > > > 
> > > > > 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, Heimeheimeborgia@protonmail.com a
> > > > > > > écrit :
> > > > > > > 
> > > > > > > ------- Original Message -------
> > > > > > > On Monday, December 12th, 2022 at 2:24 AM, Heime
> > > > > > > heimeborgia@protonmail.com wrote:
> > > > > > > 
> > > > > > > > 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.
> > > > > > > > Standard metrics exist. The Gnu Project like many others, does not
> > > > > > > > want to use them.
> > > > > > > > You're moving the goalpost: the sentence I quoted claimed that "focusing
> > > > > > > > on a light background is the wrong approach".
> > > > > > > > Having worked with modus-themes, it was concluded that there exist greater
> > > > > > > > variations in possibilities with a dark background that with a light one.
> 
> 
> Great for themes with a black background.
> 
> That doesn't make it "wrong" for a theme to have a light background.
> 
> > > It's already bad enough now with some packages defining their own faces
> > > without at least inheriting from the standard ones.
> > > Right. My focus has been to provide colours with good metrics so that
> > > people inherit from the standard ones.
> 
> 
> That's called designing a theme. Aka the current approach. Which you
> have been arguing is wrong.
> 
> > > There are currently 5330 packages on Melpa. Do you plan to contact the
> > > authors of all of them individually to get them to implement your
> > > preferred colors?
> > > To start using actual standards. Absolutely, they should learn more and change
> > > their packages.
> 
> 
> Great. Good luck with that.
> 
> On the other hand, the current recommended approach is to inherit from
> existing faces and let theme designers (or users, if they choose to)
> populate those with suitable colors.
> 
> No need for package developers to implement standards, no need to learn
> about theme design, no need to change things to accommodate for
> user-preferred colors, and if you have a problem, only one bug report to
> file -- with the theme.
> 
> > > > > 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.
> > > > > Good design in much more important that consistency.
> > > > > It's also much easier to achieve in a consistent system.
> > > > > The argument is to design separately for light and also for dark background.
> > > > > Emacs does have light and dark checks.
> 
> 
> That's again, moving the point.
> 
> Yes, Emacs does have those checks, but it's just a different way of
> providing two themes for light and dark backgrounds. If done for full
> themes, it's only a formal change, between two separate theme
> definitions, or one with interleaved conditionals.
> 
> If done for only a subset of faces, leaving the others untouched, it's a
> poor-person's way to try to accommodate everything, but it's imperfect
> and it might be unreadable on themes which are far from the standard
> white or black (not to mention terminal users). For that use-case, it is
> usually preferred to find an existing face to inherit from, trusting the
> theme designers for this face to be rendered in a readable way.
>

Re: Introducing face in comments for various modes

[Stefan Monnier]

> 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.

Many of the basic faces come with definitions that explicitly account
for both light and dark backgrounds (e.g. changing color depending on
the case).

So if a face has poor legibility on a dark background, please report it
as a bug.  That bug won't necessarily be fixed, because there might be
other concerns (we're talking about the defaults, so this has to
satisfy many conflicting requirements :-( ), but it's still the right
thing to do.

> 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.

And personally, I probably wouldn't use colors for those faces.
Instead I'd probably go with a proportional font with a size that
varies depending on the level.


        Stefan

Re: Introducing face in comments for various modes

[Stefan Monnier]

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

That's exactly what we try to do.
Face definitions can specify different attributes depending on the
`frame-background-mode`.


        Stefan

Re: Introducing face in comments for various modes

[Yuri Khan]

On Mon, 12 Dec 2022 at 17:53, Thibaut Verron <thibaut.verron@gmail.com> wrote:

> > If you use "modus-vivendi" for org-mode, the colours are all almost white,
> > a big problem particularly when you fold the org headings.
>
> I don't like dark backgrounds, but it seems perfectly readable to me.

Heime has a point. The complaint is not about *readability* of
modus-vivendi’s colors against the background. It is about
*distinction* between levels of Org headings, i.e. ability to
distinguish a level 3 heading from a level 4 just by color.

This is a nontrivial thing to solve, by the way. It’s very easy to
fall in the trap “WCAG level AAA prescribes a contrast ratio of at
least 7:1; I’ll make my primary foreground and all my accent
foreground colors exactly 7:1 against the background so all will be
readable”. Yes, but this way they are all the same luminance, and by
that token all very similar in some sense. A color-blind person might
even not be able to distinguish hues and rely on luminance alone to
tell colors apart.

As far as I can tell, WCAG does not give any guidance as to
distinction between foreground colors, except for “thou shalt not make
the user rely solely on color”.

Re: Introducing face in comments for various modes

[Thibaut Verron]

On Mon, 12 Dec 2022, 16:23 Yuri Khan, <yuri.v.khan@gmail.com> wrote:

> On Mon, 12 Dec 2022 at 17:53, Thibaut Verron <thibaut.verron@gmail.com>
> wrote:
>
> > > If you use "modus-vivendi" for org-mode, the colours are all almost
> white,
> > > a big problem particularly when you fold the org headings.
> >
> > I don't like dark backgrounds, but it seems perfectly readable to me.
>
> Heime has a point. The complaint is not about *readability* of
> modus-vivendi’s colors against the background. It is about
> *distinction* between levels of Org headings, i.e. ability to
> distinguish a level 3 heading from a level 4 just by color.
>

Fair enough, but I still find them easy enough to separate on the
screenshot, or also when folded. But it might be more from the indentation
and leading dots (from other packages).

For what is worth, the modus themes allow flexible configuration for the
headings, which should then be propagated to outline, org, etc.

Re: Introducing face in comments for various modes

[Christopher Dimech]

> Sent: Tuesday, December 13, 2022 at 3:22 AM
> From: "Yuri Khan" <yuri.v.khan@gmail.com>
> To: "Thibaut Verron" <thibaut.verron@gmail.com>
> Cc: "Heime" <heimeborgia@protonmail.com>, "Stefan Monnier" <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
> Subject: Re: Introducing face in comments for various modes
>
> On Mon, 12 Dec 2022 at 17:53, Thibaut Verron <thibaut.verron@gmail.com> wrote:
> 
> > > If you use "modus-vivendi" for org-mode, the colours are all almost white,
> > > a big problem particularly when you fold the org headings.
> >
> > I don't like dark backgrounds, but it seems perfectly readable to me.
> 
> Heime has a point. The complaint is not about *readability* of
> modus-vivendi’s colors against the background. It is about
> *distinction* between levels of Org headings, i.e. ability to
> distinguish a level 3 heading from a level 4 just by color.
> 
> This is a nontrivial thing to solve, by the way. It’s very easy to
> fall in the trap “WCAG level AAA prescribes a contrast ratio of at
> least 7:1; I’ll make my primary foreground and all my accent
> foreground colors exactly 7:1 against the background so all will be
> readable”. Yes, but this way they are all the same luminance, and by
> that token all very similar in some sense. A color-blind person might
> even not be able to distinguish hues and rely on luminance alone to
> tell colors apart.
> 
> As far as I can tell, WCAG does not give any guidance as to
> distinction between foreground colors, except for “thou shalt not make
> the user rely solely on color”.
 
For modus-themes I suggested a foreground implementation based on a colour
wheel, using a tricolour scheme for fixing adjacent colours.  A technique that
work very well, improving on the original modus-themes colours.

With such metric, one can have about 8 colours, which you can recycle over again. 

Re: Introducing face in comments for various modes

[Christopher Dimech]

----- Christopher Dimech
Administrator General - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/     https://www.gnu.org


> Sent: Tuesday, December 13, 2022 at 3:22 AM
> From: "Yuri Khan" <yuri.v.khan@gmail.com>
> To: "Thibaut Verron" <thibaut.verron@gmail.com>
> Cc: "Heime" <heimeborgia@protonmail.com>, "Stefan Monnier" <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
> Subject: Re: Introducing face in comments for various modes
>
> On Mon, 12 Dec 2022 at 17:53, Thibaut Verron <thibaut.verron@gmail.com> wrote:
> 
> > > If you use "modus-vivendi" for org-mode, the colours are all almost white,
> > > a big problem particularly when you fold the org headings.
> >
> > I don't like dark backgrounds, but it seems perfectly readable to me.
> 
> Heime has a point. The complaint is not about *readability* of
> modus-vivendi’s colors against the background. It is about
> *distinction* between levels of Org headings, i.e. ability to
> distinguish a level 3 heading from a level 4 just by color.
> 
> This is a nontrivial thing to solve, by the way. It’s very easy to
> fall in the trap “WCAG level AAA prescribes a contrast ratio of at
> least 7:1; I’ll make my primary foreground and all my accent
> foreground colors exactly 7:1 against the background so all will be
> readable”. Yes, but this way they are all the same luminance, and by
> that token all very similar in some sense. A color-blind person might
> even not be able to distinguish hues and rely on luminance alone to
> tell colors apart.

Correct.  WCAG Level AAA works well for a foreground upon a background colour.
Thusly it is still quite a basic scheme.  When, in addition, one considers 
colour contrast requirements upon adjacent coloured letters, the WCAG Levels
are not enough to do this.  One has to optimise colour contrast on both foreground
with background, as well as contrast upon adjacent colours.  

Some work on this showed that you would not be able to completely satisfy WCAG Levels,
if you want to optimise colour contrast between adjacent letters too. 

Still, one can use a metric.  The whole point to understand is that the colours
are not set up at the discretion of the programmer.  You are limited only to certain
colour tones only.  Doing anything else would always result in a sub-optimal result.

The original modes-themes, even though they were a huge improvements compared to other
themes, were found to be sub-optimal.
 
> As far as I can tell, WCAG does not give any guidance as to
> distinction between foreground colors, except for “thou shalt not make
> the user rely solely on color”.
> 
>

Re: Introducing face in comments for various modes

[Stefan Monnier]

> Heime has a point. The complaint is not about *readability* of
> modus-vivendi’s colors against the background. It is about
> *distinction* between levels of Org headings, i.e. ability to
> distinguish a level 3 heading from a level 4 just by color.

AFAIK relying colors to express the heading level would be a mistake.

> As far as I can tell, WCAG does not give any guidance as to
> distinction between foreground colors, except for “thou shalt not make
> the user rely solely on color”.

I think that guidance is quite apt here :-)


        Stefan

Re: Introducing face in comments for various modes

[Christopher Dimech]

> Sent: Tuesday, December 13, 2022 at 5:44 AM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: "Yuri Khan" <yuri.v.khan@gmail.com>
> Cc: "Thibaut Verron" <thibaut.verron@gmail.com>, "Heime" <heimeborgia@protonmail.com>, help-gnu-emacs@gnu.org
> Subject: Re: Introducing face in comments for various modes
>
> > Heime has a point. The complaint is not about *readability* of
> > modus-vivendi’s colors against the background. It is about
> > *distinction* between levels of Org headings, i.e. ability to
> > distinguish a level 3 heading from a level 4 just by color.
> 
> AFAIK relying colors to express the heading level would be a mistake.

How is that conclusion reached?

> > As far as I can tell, WCAG does not give any guidance as to
> > distinction between foreground colors, except for “thou shalt not make
> > the user rely solely on color”.

Colour would be an additional capability that one could use.  I do not see
how it will subtract, it will only add.  It is proper to assert that the use 
of colour only is not sufficient for distinction (other considerations include
font type, text size, text weight).  Having worked in remote sensing development,
an essential ingredient in most remote sensing images is color.  

While variations in black and white imagery can be very informative, the number
of different gray tones that the eye can separate is limited to about 20 to 30
steps on a contrast scale.  On the other hand, the eye can distinguish many more 
color tints, enabling small variations within the target materials or classes to
be discerned.  Colour is capable of provide expanded information.  It would be 
ridiculous to discount the use of colour.

 

> I think that guidance is quite apt here :-)
> 
> 
>         Stefan
> 
> 
>

Re: Introducing face in comments for various modes

[Jean Louis]

Heime, I like the idea of highlighting comments, though I do it this
way to specify (syntax comment-start) as that works for multiple
modes.

; one
;; two
;;;      three
;;;;      and more

;;; Highlighting comments

(setq rcd-regexp-comment (rx line-start 
      	     		     (one-or-more (syntax comment-start)) 
      	     		     (one-or-more space) 
			     (group (one-or-more not-newline)) 
			     line-end))

;; (highlight-regexp regexp nil 1)
;; (unhighlight-regexp regexp)

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis <bugs@gnu.support> wrote:


> Heime, I like the idea of highlighting comments, though I do it this
> way to specify (syntax comment-start) as that works for multiple
> modes.
> 
> ; one
> ;; two
> ;;; three
> ;;;; and more
> 
> ;;; Highlighting comments
> 
> (setq rcd-regexp-comment (rx line-start
> (one-or-more (syntax comment-start))
> (one-or-more space)
> (group (one-or-more not-newline))
> line-end))
> 
> ;; (highlight-regexp regexp nil 1)
> ;; (unhighlight-regexp regexp)
> 
> Jean

I shall try this and report back.  But, how do I get to use "rcd-regexp-comment" ?
Is that just "regexp" ?

Re: Introducing face in comments for various modes

[Christopher Dimech]

> Sent: Tuesday, December 13, 2022 at 7:52 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Heime" <heimeborgia@protonmail.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Introducing face in comments for various modes
>
> 
> Heime, I like the idea of highlighting comments, though I do it this
> way to specify (syntax comment-start) as that works for multiple
> modes.
> 
> ; one
> ;; two
> ;;;      three
> ;;;;      and more
> 
> ;;; Highlighting comments
> 
> (setq rcd-regexp-comment (rx line-start 
>       	     		     (one-or-more (syntax comment-start)) 
>       	     		     (one-or-more space) 
> 			     (group (one-or-more not-newline)) 
> 			     line-end))
> 
> ;; (highlight-regexp regexp nil 1)
> ;; (unhighlight-regexp regexp)
> 
> -- 
> Jean

Would your procedure not conflict when people use outline-mode.  Such comments
will end up getting folded by tho outline commands, something the OP does not want.



   

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 8:04 AM, Heime <heimeborgia@protonmail.com> wrote:


> ------- Original Message -------
> On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> 
> 
> 
> > Heime, I like the idea of highlighting comments, though I do it this
> > way to specify (syntax comment-start) as that works for multiple
> > modes.
> > 
> > ; one
> > ;; two
> > ;;; three
> > ;;;; and more
> > 
> > ;;; Highlighting comments
> > 
> > (setq rcd-regexp-comment (rx line-start
> > (one-or-more (syntax comment-start))
> > (one-or-more space)
> > (group (one-or-more not-newline))
> > line-end))
> > 
> > ;; (highlight-regexp regexp nil 1)
> > ;; (unhighlight-regexp regexp)
> > 
> > Jean

I would like to introduce (syntax comment-start) in place
of ";;" in "^;;\s+\\[.+\\].*$".

Re: Introducing face in comments for various modes

[Thibaut Verron]

On 13/12/2022 09:30, Heime wrote:
> ------- Original Message -------
> On Tuesday, December 13th, 2022 at 8:04 AM, Heime <heimeborgia@protonmail.com> wrote:
>
>
>> ------- Original Message -------
>> On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
>>
>>
>>
>>> Heime, I like the idea of highlighting comments, though I do it this
>>> way to specify (syntax comment-start) as that works for multiple
>>> modes.
>>>
>>> ; one
>>> ;; two
>>> ;;; three
>>> ;;;; and more
>>>
>>> ;;; Highlighting comments
>>>
>>> (setq rcd-regexp-comment (rx line-start
>>> (one-or-more (syntax comment-start))
>>> (one-or-more space)
>>> (group (one-or-more not-newline))
>>> line-end))
>>>
>>> ;; (highlight-regexp regexp nil 1)
>>> ;; (unhighlight-regexp regexp)
>>>
>>> Jean
> I would like to introduce (syntax comment-start) in place
> of ";;" in "^;;\s+\\[.+\\].*$".

It's not something you can "introduce" in your regexp, it only makes 
sense within the context of a regexp built with rx: 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html

Rewriting your regexp as an rx regexp would not be too difficult if you 
want to go that route, Jean's example is a good template.

Otherwise, as an approximation of that feature, you could built your 
regex string using the value of the variable comment-start ( ";" in 
emacs-lisp-mode) instead of hardcoding ;; .

To be clear, the variable comment-start happens to have the same name as 
the symbol in (syntax comment-start), but they are not the same thing, 
the syntax classification can in theory be a lot smarter than simply 
regexp matching.

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 13/12/2022 09:30, Heime wrote:
> 
> > ------- Original Message -------
> > On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
> > 
> > > ------- Original Message -------
> > > On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> > > 
> > > > Heime, I like the idea of highlighting comments, though I do it this
> > > > way to specify (syntax comment-start) as that works for multiple
> > > > modes.
> > > > 
> > > > ; one
> > > > ;; two
> > > > ;;; three
> > > > ;;;; and more
> > > > 
> > > > ;;; Highlighting comments
> > > > 
> > > > (setq rcd-regexp-comment (rx line-start
> > > > (one-or-more (syntax comment-start))
> > > > (one-or-more space)
> > > > (group (one-or-more not-newline))
> > > > line-end))
> > > > 
> > > > ;; (highlight-regexp regexp nil 1)
> > > > ;; (unhighlight-regexp regexp)
> > > > 
> > > > Jean
> > > > I would like to introduce (syntax comment-start) in place
> > > > of ";;" in "^;;\s+\\[.+\\].*$".
> 
> 
> It's not something you can "introduce" in your regexp, it only makes
> sense within the context of a regexp built with rx:
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
> 
> Rewriting your regexp as an rx regexp would not be too difficult if you
> want to go that route, Jean's example is a good template.
> 
> Otherwise, as an approximation of that feature, you could built your
> regex string using the value of the variable comment-start ( ";" in
> emacs-lisp-mode) instead of hardcoding ;; .

How can one specify two comment characters next to each other?
 
> To be clear, the variable comment-start happens to have the same name as
> the symbol in (syntax comment-start), but they are not the same thing,
> the syntax classification can in theory be a lot smarter than simply
> regexp matching.

Re: Introducing face in comments for various modes

[Thibaut Verron]

On 13/12/2022 10:46, Heime wrote:
> ------- Original Message -------
> On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:
>
>
>> On 13/12/2022 09:30, Heime wrote:
>>
>>> ------- Original Message -------
>>> On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
>>>
>>>> ------- Original Message -------
>>>> On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
>>>>
>>>>> Heime, I like the idea of highlighting comments, though I do it this
>>>>> way to specify (syntax comment-start) as that works for multiple
>>>>> modes.
>>>>>
>>>>> ; one
>>>>> ;; two
>>>>> ;;; three
>>>>> ;;;; and more
>>>>>
>>>>> ;;; Highlighting comments
>>>>>
>>>>> (setq rcd-regexp-comment (rx line-start
>>>>> (one-or-more (syntax comment-start))
>>>>> (one-or-more space)
>>>>> (group (one-or-more not-newline))
>>>>> line-end))
>>>>>
>>>>> ;; (highlight-regexp regexp nil 1)
>>>>> ;; (unhighlight-regexp regexp)
>>>>>
>>>>> Jean
>>>>> I would like to introduce (syntax comment-start) in place
>>>>> of ";;" in "^;;\s+\\[.+\\].*$".
>>
>> It's not something you can "introduce" in your regexp, it only makes
>> sense within the context of a regexp built with rx:
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
>>
>> Rewriting your regexp as an rx regexp would not be too difficult if you
>> want to go that route, Jean's example is a good template.
>>
>> Otherwise, as an approximation of that feature, you could built your
>> regex string using the value of the variable comment-start ( ";" in
>> emacs-lisp-mode) instead of hardcoding ;; .
> How can one specify two comment characters next to each other?

Using the variable, the same way you would normally do for a regexp, by 
putting \{2\} after the matched regexp.

E.g.

ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
"\\(;\\)\\{2\\}"

(don't trust me for the number of escape characters)

But I don't think it's really what you want: for example, in a mode 
where comment-start is "# " (e.g. org or python), this will match "# # " 
but not "##".

Using the syntax table is better here, as the character # alone has the 
syntax of a comment-start.

I had forgotten about the simplest option, that is the regexp equivalent 
of the rx syntax: \s< in a regexp will match exactly a character with 
the syntax of a comment-start.

So: "\s<\{2\}" should be exactly what you want (at least in languages 
where comments start with a single character).

Re: Introducing face in comments for various modes

[Christopher Dimech]

> Sent: Tuesday, December 13, 2022 at 10:05 PM
> From: "Thibaut Verron" <thibaut.verron@gmail.com>
> To: "Heime" <heimeborgia@protonmail.com>
> Cc: "Jean Louis" <bugs@gnu.support>, help-gnu-emacs@gnu.org
> Subject: Re: Introducing face in comments for various modes
>
> On 13/12/2022 10:46, Heime wrote:
> > ------- Original Message -------
> > On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:
> >
> >
> >> On 13/12/2022 09:30, Heime wrote:
> >>
> >>> ------- Original Message -------
> >>> On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
> >>>
> >>>> ------- Original Message -------
> >>>> On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> >>>>
> >>>>> Heime, I like the idea of highlighting comments, though I do it this
> >>>>> way to specify (syntax comment-start) as that works for multiple
> >>>>> modes.
> >>>>>
> >>>>> ; one
> >>>>> ;; two
> >>>>> ;;; three
> >>>>> ;;;; and more
> >>>>>
> >>>>> ;;; Highlighting comments
> >>>>>
> >>>>> (setq rcd-regexp-comment (rx line-start
> >>>>> (one-or-more (syntax comment-start))
> >>>>> (one-or-more space)
> >>>>> (group (one-or-more not-newline))
> >>>>> line-end))
> >>>>>
> >>>>> ;; (highlight-regexp regexp nil 1)
> >>>>> ;; (unhighlight-regexp regexp)
> >>>>>
> >>>>> Jean
> >>>>> I would like to introduce (syntax comment-start) in place
> >>>>> of ";;" in "^;;\s+\\[.+\\].*$".
> >>
> >> It's not something you can "introduce" in your regexp, it only makes
> >> sense within the context of a regexp built with rx:
> >> https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
> >>
> >> Rewriting your regexp as an rx regexp would not be too difficult if you
> >> want to go that route, Jean's example is a good template.
> >>
> >> Otherwise, as an approximation of that feature, you could built your
> >> regex string using the value of the variable comment-start ( ";" in
> >> emacs-lisp-mode) instead of hardcoding ;; .
> > How can one specify two comment characters next to each other?
> 
> Using the variable, the same way you would normally do for a regexp, by 
> putting \{2\} after the matched regexp.
> 
> E.g.
> 
> ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
> "\\(;\\)\\{2\\}"
> 
> (don't trust me for the number of escape characters)
> 
> But I don't think it's really what you want: for example, in a mode 
> where comment-start is "# " (e.g. org or python), this will match "# # " 
> but not "##".

It is unfortunate that org and python demand a space after #
 
> Using the syntax table is better here, as the character # alone has the 
> syntax of a comment-start.
> 
> I had forgotten about the simplest option, that is the regexp equivalent 
> of the rx syntax: \s< in a regexp will match exactly a character with 
> the syntax of a comment-start.
> 
> So: "\s<\{2\}" should be exactly what you want (at least in languages 
> where comments start with a single character).
 

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 10:05 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 13/12/2022 10:46, Heime wrote:
> 
> > ------- Original Message -------
> > On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > 
> > > On 13/12/2022 09:30, Heime wrote:
> > > 
> > > > ------- Original Message -------
> > > > On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
> > > > 
> > > > > ------- Original Message -------
> > > > > On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> > > > > 
> > > > > > Heime, I like the idea of highlighting comments, though I do it this
> > > > > > way to specify (syntax comment-start) as that works for multiple
> > > > > > modes.
> > > > > > 
> > > > > > ; one
> > > > > > ;; two
> > > > > > ;;; three
> > > > > > ;;;; and more
> > > > > > 
> > > > > > ;;; Highlighting comments
> > > > > > 
> > > > > > (setq rcd-regexp-comment (rx line-start
> > > > > > (one-or-more (syntax comment-start))
> > > > > > (one-or-more space)
> > > > > > (group (one-or-more not-newline))
> > > > > > line-end))
> > > > > > 
> > > > > > ;; (highlight-regexp regexp nil 1)
> > > > > > ;; (unhighlight-regexp regexp)
> > > > > > 
> > > > > > Jean
> > > > > > I would like to introduce (syntax comment-start) in place
> > > > > > of ";;" in "^;;\s+\\[.+\\].*$".
> > > 
> > > It's not something you can "introduce" in your regexp, it only makes
> > > sense within the context of a regexp built with rx:
> > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
> > > 
> > > Rewriting your regexp as an rx regexp would not be too difficult if you
> > > want to go that route, Jean's example is a good template.
> > > 
> > > Otherwise, as an approximation of that feature, you could built your
> > > regex string using the value of the variable comment-start ( ";" in
> > > emacs-lisp-mode) instead of hardcoding ;; .
> > > How can one specify two comment characters next to each other?
> 
> 
> Using the variable, the same way you would normally do for a regexp, by
> putting \{2\} after the matched regexp.
> 
> E.g.
> 
> ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
> 
> "\\(;\\)\\{2\\}"
> 
> (don't trust me for the number of escape characters)
> 
> But I don't think it's really what you want: for example, in a mode
> where comment-start is "# " (e.g. org or python), this will match "# # "
> but not "##".

Let's disregard org and python at this time.
 
> Using the syntax table is better here, as the character # alone has the
> syntax of a comment-start.
> 
> I had forgotten about the simplest option, that is the regexp equivalent
> of the rx syntax: \s< in a regexp will match exactly a character with
> the syntax of a comment-start.
> 
> So: "\s<\{2\}" should be exactly what you want (at least in languages
> where comments start with a single character).

Re: Introducing face in comments for various modes

[Thibaut Verron]

On 13/12/2022 11:40, Heime wrote:
> ------- Original Message -------
> On Tuesday, December 13th, 2022 at 10:05 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:
>
>
>> On 13/12/2022 10:46, Heime wrote:
>>
>>> ------- Original Message -------
>>> On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
>>>
>>>> On 13/12/2022 09:30, Heime wrote:
>>>>
>>>>> ------- Original Message -------
>>>>> On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
>>>>>
>>>>>> ------- Original Message -------
>>>>>> On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
>>>>>>
>>>>>>> Heime, I like the idea of highlighting comments, though I do it this
>>>>>>> way to specify (syntax comment-start) as that works for multiple
>>>>>>> modes.
>>>>>>>
>>>>>>> ; one
>>>>>>> ;; two
>>>>>>> ;;; three
>>>>>>> ;;;; and more
>>>>>>>
>>>>>>> ;;; Highlighting comments
>>>>>>>
>>>>>>> (setq rcd-regexp-comment (rx line-start
>>>>>>> (one-or-more (syntax comment-start))
>>>>>>> (one-or-more space)
>>>>>>> (group (one-or-more not-newline))
>>>>>>> line-end))
>>>>>>>
>>>>>>> ;; (highlight-regexp regexp nil 1)
>>>>>>> ;; (unhighlight-regexp regexp)
>>>>>>>
>>>>>>> Jean
>>>>>>> I would like to introduce (syntax comment-start) in place
>>>>>>> of ";;" in "^;;\s+\\[.+\\].*$".
>>>> It's not something you can "introduce" in your regexp, it only makes
>>>> sense within the context of a regexp built with rx:
>>>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
>>>>
>>>> Rewriting your regexp as an rx regexp would not be too difficult if you
>>>> want to go that route, Jean's example is a good template.
>>>>
>>>> Otherwise, as an approximation of that feature, you could built your
>>>> regex string using the value of the variable comment-start ( ";" in
>>>> emacs-lisp-mode) instead of hardcoding ;; .
>>>> How can one specify two comment characters next to each other?
>>
>> Using the variable, the same way you would normally do for a regexp, by
>> putting \{2\} after the matched regexp.
>>
>> E.g.
>>
>> ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
>>
>> "\\(;\\)\\{2\\}"
>>
>> (don't trust me for the number of escape characters)
>>
>> But I don't think it's really what you want: for example, in a mode
>> where comment-start is "# " (e.g. org or python), this will match "# # "
>> but not "##".
> Let's disregard org and python at this time.
>   

Even then, avoiding the need to carefully count string expansions for 
backslashes would be enough reason to use syntax tables for me.


>> Using the syntax table is better here, as the character # alone has the
>> syntax of a comment-start.
>>
>> I had forgotten about the simplest option, that is the regexp equivalent
>> of the rx syntax: \s< in a regexp will match exactly a character with
>> the syntax of a comment-start.
>>
>> So: "\s<\{2\}" should be exactly what you want (at least in languages
>> where comments start with a single character).

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 10:45 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 13/12/2022 11:40, Heime wrote:
> 
> > ------- Original Message -------
> > On Tuesday, December 13th, 2022 at 10:05 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > 
> > > On 13/12/2022 10:46, Heime wrote:
> > > 
> > > > ------- Original Message -------
> > > > On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > > > 
> > > > > On 13/12/2022 09:30, Heime wrote:
> > > > > 
> > > > > > ------- Original Message -------
> > > > > > On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
> > > > > > 
> > > > > > > ------- Original Message -------
> > > > > > > On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> > > > > > > 
> > > > > > > > Heime, I like the idea of highlighting comments, though I do it this
> > > > > > > > way to specify (syntax comment-start) as that works for multiple
> > > > > > > > modes.
> > > > > > > > 
> > > > > > > > ; one
> > > > > > > > ;; two
> > > > > > > > ;;; three
> > > > > > > > ;;;; and more
> > > > > > > > 
> > > > > > > > ;;; Highlighting comments
> > > > > > > > 
> > > > > > > > (setq rcd-regexp-comment (rx line-start
> > > > > > > > (one-or-more (syntax comment-start))
> > > > > > > > (one-or-more space)
> > > > > > > > (group (one-or-more not-newline))
> > > > > > > > line-end))
> > > > > > > > 
> > > > > > > > ;; (highlight-regexp regexp nil 1)
> > > > > > > > ;; (unhighlight-regexp regexp)
> > > > > > > > 
> > > > > > > > Jean
> > > > > > > > I would like to introduce (syntax comment-start) in place
> > > > > > > > of ";;" in "^;;\s+\\[.+\\].*$".
> > > > > > > > It's not something you can "introduce" in your regexp, it only makes
> > > > > > > > sense within the context of a regexp built with rx:
> > > > > > > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
> > > > > 
> > > > > Rewriting your regexp as an rx regexp would not be too difficult if you
> > > > > want to go that route, Jean's example is a good template.
> > > > > 
> > > > > Otherwise, as an approximation of that feature, you could built your
> > > > > regex string using the value of the variable comment-start ( ";" in
> > > > > emacs-lisp-mode) instead of hardcoding ;; .
> > > > > How can one specify two comment characters next to each other?
> > > 
> > > Using the variable, the same way you would normally do for a regexp, by
> > > putting \{2\} after the matched regexp.
> > > 
> > > E.g.
> > > 
> > > ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
> > > 
> > > "\\(;\\)\\{2\\}"
> > > 
> > > (don't trust me for the number of escape characters)
> > > 
> > > But I don't think it's really what you want: for example, in a mode
> > > where comment-start is "# " (e.g. org or python), this will match "# # "
> > > but not "##".
> > > Let's disregard org and python at this time.
> 
> 
> Even then, avoiding the need to carefully count string expansions for
> backslashes would be enough reason to use syntax tables for me.

Let not start nit-picking and simply have a solution that would word for simple terms.
 
> > > Using the syntax table is better here, as the character # alone has the
> > > syntax of a comment-start.
> > > 
> > > I had forgotten about the simplest option, that is the regexp equivalent
> > > of the rx syntax: \s< in a regexp will match exactly a character with
> > > the syntax of a comment-start.
> > > 
> > > So: "\s<\{2\}" should be exactly what you want (at least in languages
> > > where comments start with a single character).

Re: Introducing face in comments for various modes

[Jean Louis]

* Heime <heimeborgia@protonmail.com> [2022-12-13 11:05]:
> > ;;; Highlighting comments
> > 
> > (setq rcd-regexp-comment (rx line-start
> > (one-or-more (syntax comment-start))
> > (one-or-more space)
> > (group (one-or-more not-newline))
> > line-end))
> > 
> > ;; (highlight-regexp regexp nil 1)
> > ;; (unhighlight-regexp regexp)
> > 
> > Jean
> 
> I shall try this and report back.  But, how do I get to use "rcd-regexp-comment" ?
> Is that just "regexp" ?

Yes, name it as you wish.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Introducing face in comments for various modes

[Jean Louis]

* Heime <heimeborgia@protonmail.com> [2022-12-13 11:31]:
> I would like to introduce (syntax comment-start) in place
> of ";;" in "^;;\s+\\[.+\\].*$".

Yes, that is good idea, and in emacs-lisp-mode the comment-start is
";", so the same idea could work in various modes by using syntax
syntax. :-)


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Introducing face in comments for various modes

[Jean Louis]

* Heime <heimeborgia@protonmail.com> [2022-12-13 12:47]:
> > > > > (setq rcd-regexp-comment (rx line-start
> > > > > (one-or-more (syntax comment-start))
> > > > > (one-or-more space)
> > > > > (group (one-or-more not-newline))
> > > > > line-end))

> How can one specify two comment characters next to each other?

(rx (one-or-more (syntax comment-start)))) cares about it. Or you just want it after two comment chars?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 12:36 PM, Jean Louis <bugs@gnu.support> wrote:


> * Heime heimeborgia@protonmail.com [2022-12-13 11:31]:
> 
> > I would like to introduce (syntax comment-start) in place
> > of ";;" in "^;;\s+\\[.+\\].*$".
> 
> 
> Yes, that is good idea, and in emacs-lisp-mode the comment-start is
> ";", so the same idea could work in various modes by using syntax
> syntax. :-)
> 
> --
> Jean

It did work very well.  I appreciate.

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 12:37 PM, Jean Louis <bugs@gnu.support> wrote:


> * Heime heimeborgia@protonmail.com [2022-12-13 12:47]:
> 
> > > > > > (setq rcd-regexp-comment (rx line-start
> > > > > > (one-or-more (syntax comment-start))
> > > > > > (one-or-more space)
> > > > > > (group (one-or-more not-newline))
> > > > > > line-end))
> 
> > How can one specify two comment characters next to each other?
> 
> 
> (rx (one-or-more (syntax comment-start)))) cares about it. Or you just want it after two comment chars?
> 
> --
> Jean

Only after two comments characters actually.

Re: Introducing face in comments for various modes

[Heime]

------- Original Message -------
On Tuesday, December 13th, 2022 at 10:45 AM, Thibaut Verron <thibaut.verron@gmail.com> wrote:


> On 13/12/2022 11:40, Heime wrote:
> 
> > ------- Original Message -------
> > On Tuesday, December 13th, 2022 at 10:05 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > 
> > > On 13/12/2022 10:46, Heime wrote:
> > > 
> > > > ------- Original Message -------
> > > > On Tuesday, December 13th, 2022 at 9:35 AM, Thibaut Verron thibaut.verron@gmail.com wrote:
> > > > 
> > > > > On 13/12/2022 09:30, Heime wrote:
> > > > > 
> > > > > > ------- Original Message -------
> > > > > > On Tuesday, December 13th, 2022 at 8:04 AM, Heime heimeborgia@protonmail.com wrote:
> > > > > > 
> > > > > > > ------- Original Message -------
> > > > > > > On Tuesday, December 13th, 2022 at 7:52 AM, Jean Louis bugs@gnu.support wrote:
> > > > > > > 
> > > > > > > > Heime, I like the idea of highlighting comments, though I do it this
> > > > > > > > way to specify (syntax comment-start) as that works for multiple
> > > > > > > > modes.
> > > > > > > > 
> > > > > > > > ; one
> > > > > > > > ;; two
> > > > > > > > ;;; three
> > > > > > > > ;;;; and more
> > > > > > > > 
> > > > > > > > ;;; Highlighting comments
> > > > > > > > 
> > > > > > > > (setq rcd-regexp-comment (rx line-start
> > > > > > > > (one-or-more (syntax comment-start))
> > > > > > > > (one-or-more space)
> > > > > > > > (group (one-or-more not-newline))
> > > > > > > > line-end))
> > > > > > > > 
> > > > > > > > ;; (highlight-regexp regexp nil 1)
> > > > > > > > ;; (unhighlight-regexp regexp)
> > > > > > > > 
> > > > > > > > Jean
> > > > > > > > I would like to introduce (syntax comment-start) in place
> > > > > > > > of ";;" in "^;;\s+\\[.+\\].*$".
> > > > > > > > It's not something you can "introduce" in your regexp, it only makes
> > > > > > > > sense within the context of a regexp built with rx:
> > > > > > > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx-Notation.html
> > > > > 
> > > > > Rewriting your regexp as an rx regexp would not be too difficult if you
> > > > > want to go that route, Jean's example is a good template.
> > > > > 
> > > > > Otherwise, as an approximation of that feature, you could built your
> > > > > regex string using the value of the variable comment-start ( ";" in
> > > > > emacs-lisp-mode) instead of hardcoding ;; .
> > > > > How can one specify two comment characters next to each other?
> > > 
> > > Using the variable, the same way you would normally do for a regexp, by
> > > putting \{2\} after the matched regexp.
> > > 
> > > E.g.
> > > 
> > > ELISP> (format "\\(%s\\)\\{2\\}" comment-start)
> > > 
> > > "\\(;\\)\\{2\\}"
> > > 
> > > (don't trust me for the number of escape characters)
> > > 
> > > But I don't think it's really what you want: for example, in a mode
> > > where comment-start is "# " (e.g. org or python), this will match "# # "
> > > but not "##".
> > > Let's disregard org and python at this time.
 
I do not think "python" comment character should be "# ", it is "#".  At least from what I have read about python. 

 
> Even then, avoiding the need to carefully count string expansions for
> backslashes would be enough reason to use syntax tables for me.
> 
> > > Using the syntax table is better here, as the character # alone has the
> > > syntax of a comment-start.
> > > 
> > > I had forgotten about the simplest option, that is the regexp equivalent
> > > of the rx syntax: \s< in a regexp will match exactly a character with
> > > the syntax of a comment-start.
> > > 
> > > So: "\s<\{2\}" should be exactly what you want (at least in languages
> > > where comments start with a single character).

Re: Introducing face in comments for various modes

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-12-13 11:17]:
> > ; one
> > ;; two
> > ;;;      three
> > ;;;;      and more
> > 
> > ;;; Highlighting comments
> > 
> > (setq rcd-regexp-comment (rx line-start 
> >       	     		     (one-or-more (syntax comment-start)) 
> >       	     		     (one-or-more space) 
> > 			     (group (one-or-more not-newline)) 
> > 			     line-end))
> > 
> > ;; (highlight-regexp regexp nil 1)
> > ;; (unhighlight-regexp regexp)
> > 
> > -- 
> > Jean
> 
> Would your procedure not conflict when people use outline-mode.  Such comments
> will end up getting folded by tho outline commands, something the OP does not want.

It is for Heime, but if people wish to use it, why not. There is no
conflict that I see. It gives me more highlighted comments, easier to navigate.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/