Working with colors in --batch mode

Working with colors in --batch mode

[Kévin Le Gouguec]

Hello Emacs,

For some reason, today finds me playing with color contrast, and having
a devil of a time doing so in --batch mode.

Specifically, I'm stumped by…

$ emacs --batch \
    --eval '(message "color-name-to-rgb: %s"
                     (color-name-to-rgb "#abcdef"))'

… returning…

> color-name-to-rgb: (0.0 1.0 1.0)

… whereas in a non-batch session on an X display, I get something more
relevant to my usual Emacs experience (i.e. (window-system) ↦ x):

> color-name-to-rgb: (0.6705882352941176 0.803921568627451 0.9372549019607843)

The --batch behaviour thwarts my attempts to write a script that calls
modus-themes-contrast, since that function relies on color-name-to-rgb.

I think I've traced this to (color-values COLOR &optional FRAME) taking
a "wrong turn" because emacs --batch does not bother setting up
graphical frames; I tried coaxing Emacs into doing that prior to calling
any color function, with various combinations of…

* --display :0
* --eval "(make-frame '((display . \":0\") (window-system . x)))"
* --eval '(make-frame-on-display ":0")'

… to no avail; Emacs merely tells me "I/O possible" then terminates with
code 157 (-128=29, which tracks with signal(7) mapping this to SIGIO).

It might just be me not finding the right terms, but none of my research
(Emacs & Elisp info manuals; some googling) led me to examples of
handling graphical frames in batch mode.

I'm guessing it's just a matter of finding x such that…

$ emacs --batch \
    --eval "$x" \
    --eval '(message "color-name-to-rgb: %s"
                     (color-name-to-rgb "#abcdef"))'

… sets up enough "graphical terminal" support that display-graphic-p
holds, and (color-values "#abcdef") returns (43947 52685 61423) instead
of (0 65535 65535), but x eludes me thus far.

Alternatively, I could drop --batch and switch to princ +
external-debugging-output + kill-emacs, I guess.


There's still a bunch of things for me to consult before I feel
completely stuck ((elisp) Window Systems, (elisp) Frames, (emacs)
Display X, src/emacs.c, lisp/startup.el, ChatGPT); in the meantime,
bottling up this message and throwing it at the list in case someone
happens to be… sailing by?


Wishing y'all a merry time 🙏

Re: Working with colors in --batch mode

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Sun, 25 Dec 2022 18:50:57 +0100
> 
> For some reason, today finds me playing with color contrast, and having
> a devil of a time doing so in --batch mode.
> 
> Specifically, I'm stumped by…
> 
> $ emacs --batch \
>     --eval '(message "color-name-to-rgb: %s"
>                      (color-name-to-rgb "#abcdef"))'
> 
> … returning…
> 
> > color-name-to-rgb: (0.0 1.0 1.0)
> 
> … whereas in a non-batch session on an X display, I get something more
> relevant to my usual Emacs experience (i.e. (window-system) ↦ x):
> 
> > color-name-to-rgb: (0.6705882352941176 0.803921568627451 0.9372549019607843)

Emacs doesn't (and cannot, I think) load X colors unless it
initializes the X display, and that doesn't happen in batch sessions.
Basically, batch sessions behave like a colorless TTY session.

Re: Working with colors in --batch mode

[Eli Zaretskii]

> Date: Sun, 25 Dec 2022 20:05:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Emacs doesn't (and cannot, I think) load X colors unless it
> initializes the X display, and that doesn't happen in batch sessions.
> Basically, batch sessions behave like a colorless TTY session.

Btw, I don't really understand why you need the X machinery for this.
Doesn't tty-color-standard-values do the job?

 $ emacs -batch --eval "(message \"%s\" (tty-color-standard-values \"#abcdef\"))"
  => (43947 52685 61423)

Re: Working with colors in --batch mode

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 25 Dec 2022 20:05:59 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> Emacs doesn't (and cannot, I think) load X colors unless it
>> initializes the X display, and that doesn't happen in batch sessions.
>> Basically, batch sessions behave like a colorless TTY session.
>
> Btw, I don't really understand why you need the X machinery for this.
> Doesn't tty-color-standard-values do the job?
>
>  $ emacs -batch --eval "(message \"%s\" (tty-color-standard-values \"#abcdef\"))"
>   => (43947 52685 61423)

Because this message is the latest step in a longer journey that started
with me trying to call modus-themes-contrast in batch mode, as hinted in
the OP.

So I hope to find a solution that will let me keep calling this
high-level function, instead of re-implementing it and its callees
(e.g. color-name-to-rgb).

Thanks for weighing in; it's not obvious to me yet that there's no way
to ask emacs --batch to --eval its way into initializing the X display,
but I may well end up reaching that conclusion after more digging.

Re: Working with colors in --batch mode

[Kévin Le Gouguec]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I'm guessing it's just a matter of finding x such that…
>
> $ emacs --batch \
>     --eval "$x" \
>     --eval '(message "color-name-to-rgb: %s"
>                      (color-name-to-rgb "#abcdef"))'
>
> … sets up enough "graphical terminal" support that display-graphic-p
> holds, and (color-values "#abcdef") returns (43947 52685 61423) instead
> of (0 65535 65535), but x eludes me thus far.

Meh.  --batch sets noninteractive; from there,
src/dispnew.c:init_display completely avoids init_display_interactive,
so initial-window-system remains nil, which AFAICT tells lisp/startup.el
to skip a bunch of window-system initialization (such as, well,
lisp/term/x-win.el:window-system-initialization).

I crammed a sizable portion of startup.el into --eval, but never got
past the "I/O possible" signal I mentioned.  Ah well.

(Past-last-minute thought: hey, maybe I should see what function
installs the handler for that signal, and see if I can reach it from
--eval…  Oh well)

> Alternatively, I could drop --batch and switch to princ +
> external-debugging-output + kill-emacs, I guess.

Going with that 🤷

$ emacs \
    --eval "(princ (format \"color-name-to-rgb: %s\\n\"
                     (color-name-to-rgb \"#abcdef\"))
                   'external-debugging-output)" \
    -f kill-emacs
color-name-to-rgb: (0.6705882352941176 0.803921568627451 0.9372549019607843)

                                   ⁂
                                ℰ𝓅𝒾𝓁ℴℊ𝓊ℯ
                                   ⁂

Some closure for whoever took the time to read this.

Here's what I initially set out to do: review the contrast of diff faces
from the Modus themes v4 (in-progress), and flag those where the ratio
dips below 7:1.

With $PWD at the root of the Modus themes repo, on branch version-4, and
the attached modus-diff-contrast.el checked out:

<https://git.sr.ht/~protesilaos/modus-themes/tree/version-4>

$ emacs -Q -L . -l modus-themes                   \
        -l modus-diff-contrast.el                 \
        -f kill-emacs

Sample screenshots attached; personal takeaways:

* refinements really are somewhat hard to see (especially source code
  comments in Ediff); bummer, since they are supposed to help words pop
  out within a line,

* the dark deuteranopia theme has poorer contrast than the "vanilla"
  dark theme, on average.

Now to decide whether it's worth pestering Prot about this, or if I
should just use v4's new knobs to make vivendi-deuteranopia backgrounds
darker 🤔


Again, jolly good times to you all.



[-- Attachment #2: modus-diff-contrast.el --]
[-- Type: application/emacs-lisp, Size: 3287 bytes --]

[-- Attachment #3: modus-vivendi.png --]
[-- Type: image/png, Size: 59132 bytes --]

[-- Attachment #4: modus-vivendi-deuteranopia.png --]
[-- Type: image/png, Size: 60972 bytes --]

Re: Working with colors in --batch mode

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

> I crammed a sizable portion of startup.el into --eval, but never got
> past the "I/O possible" signal I mentioned.  Ah well.

Been there.

> (Past-last-minute thought: hey, maybe I should see what function
> installs the handler for that signal, and see if I can reach it from
> --eval…  Oh well)

I didn't try super hard, but at least my first few attempts didn't
get anywhere.

I ended up using `--daemon` instead of `--batch`, but it's not always
a good option.  You might want to `M-x report-emacs-bug` and request
a better way to do that.


        Stefan