bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

Problem:
========

When I use `emacsclient -c -nw' for `customize-faces', `default' and
unset foreground and background color, the GUI faces shrink to miniscule
sizes that I cannot even read any more.

How to reproduce:

1. emacs -Q

2. M-x server-start

3. open xterm

4. $ emacsclient -c -nw

5. within emacsclient in xterm: M-x customize-faces, then `default'

6. Move to foreground, background and unset it

7. save settings for the session

8. At this point the GUI shrinks its faces to something unreadable



In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
 of 2021-01-01 built on protected.rcdrun.com
Repository revision: 30a1d5da7a43d51a97cbe8d91add9a26dd99df90
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=/package/text/emacs --with-modules
 --with-x-toolkit=lucid
 PKG_CONFIG_PATH=/home/data1/protected/GNUstep/Library/Libraries/pkgconfig:/usr/lib/pkgconfig'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny dired
dired-loaddefs rfc822 mml easymenu mml-sec epa derived epg epg-config
gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map text-property-search
time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 55676 7783)
 (symbols 48 7329 0)
 (strings 32 20390 2395)
 (string-bytes 1 650558)
 (vectors 16 13010)
 (vector-slots 8 225748 23461)
 (floats 8 26 39)
 (intervals 56 256 0)
 (buffers 984 12))

-- 
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> From: Jean Louis <bugs@gnu.support>
> Date: Mon, 11 Jan 2021 22:44:08 +0300
> 
> When I use `emacsclient -c -nw' for `customize-faces', `default' and
> unset foreground and background color, the GUI faces shrink to miniscule
> sizes that I cannot even read any more.

Don't do that: Customize changes the faces globally, not only for the
frame where you do it.  It's the wrong tool if you want to customize
faces on some frames, but not others.  Use set-face-foreground and its
ilk.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-01-11 23:31]:
> > From: Jean Louis <bugs@gnu.support>
> > Date: Mon, 11 Jan 2021 22:44:08 +0300
> > 
> > When I use `emacsclient -c -nw' for `customize-faces', `default' and
> > unset foreground and background color, the GUI faces shrink to miniscule
> > sizes that I cannot even read any more.
> 
> Don't do that: Customize changes the faces globally, not only for the
> frame where you do it.  It's the wrong tool if you want to customize
> faces on some frames, but not others.  Use set-face-foreground and its
> ilk.

For your and my better understanding:

- I had to unset foreground and background colors, as I wanted to use
  emacsclient -nw in xterm but the current theme was not quite
  readable in console

- to change the theme with customize-themes, I had to unset foreground
  and background color, as otherwise changing theme simply does not
  work. This may be another bug, and I do so for many months as a
  workaround to change the them. Usually I unset the
  foreground/background color, even if under emacs -Q and only then I
  am able to see the changes of the changing themes function
  customize-themes

- but this time I had both GUI and console, unsetting
  foreground/background color in console, made GUI have miniscule
  faces or fonts

Thus my intention is and was not to change the background and
foreground color, rather to unset it so that I can change the theme.

When the GUI practically disappears due to shrinkage of faces, that
still seem a bug, and shrinking faces are to me as user not related to
unsetting of foreground and background colors.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 05:51:13 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> - I had to unset foreground and background colors, as I wanted to use
>   emacsclient -nw in xterm but the current theme was not quite
>   readable in console
> 
> - to change the theme with customize-themes, I had to unset foreground
>   and background color, as otherwise changing theme simply does not
>   work. This may be another bug, and I do so for many months as a
>   workaround to change the them. Usually I unset the
>   foreground/background color, even if under emacs -Q and only then I
>   am able to see the changes of the changing themes function
>   customize-themes
> 
> - but this time I had both GUI and console, unsetting
>   foreground/background color in console, made GUI have miniscule
>   faces or fonts

This is a whole different problem, one that I cannot reproduce.  For
me, customize-themes works as documented: I can enable and disable any
theme I want, and it works as I'd expect, including changes in colors.

However, you didn't tell how you used customize-themes, and what
didn't work there, so I don't think we are talking about the same
thing.

So I don't think I understand your problem, and if the only reason for
customizing faces on a TTY frame was that customize-themes didn't work
for you, we should talk about the latter, and you should begin with
describing how customize-themes doesn't work for you.

> When the GUI practically disappears due to shrinkage of faces, that
> still seem a bug

It's not a bug, it's a cockpit error: you yourself did something that
has this effect, and you did it globally.  Customize is limited to
changing faces globally, on all frames, existing and future ones; if
that's not what you want, don't use Customize.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-01-12 18:14]:
> > Date: Tue, 12 Jan 2021 05:51:13 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 45799@debbugs.gnu.org
> > 
> > - I had to unset foreground and background colors, as I wanted to use
> >   emacsclient -nw in xterm but the current theme was not quite
> >   readable in console
> > 
> > - to change the theme with customize-themes, I had to unset foreground
> >   and background color, as otherwise changing theme simply does not
> >   work. This may be another bug, and I do so for many months as a
> >   workaround to change the them. Usually I unset the
> >   foreground/background color, even if under emacs -Q and only then I
> >   am able to see the changes of the changing themes function
> >   customize-themes
> > 
> > - but this time I had both GUI and console, unsetting
> >   foreground/background color in console, made GUI have miniscule
> >   faces or fonts
> 
> This is a whole different problem, one that I cannot reproduce.  For
> me, customize-themes works as documented: I can enable and disable any
> theme I want, and it works as I'd expect, including changes in colors.
> 
> However, you didn't tell how you used customize-themes, and what
> didn't work there, so I don't think we are talking about the same
> thing.

I have given the recipe how to reproduce. You say you cannot reproduce
it? My build is pretty recent from development and I have reproduced
it by using emacs -Q, basically you would have 2 windows, one is
Emacs, other is xterm and in xterm I was unsetting the colors.

In that recipe, I have not used customize-themes but that was
intention.

So if I would use customize-themes without unsetting of foreground and
background color, I would not see much of changes in console, as
colors would not change.

> So I don't think I understand your problem, and if the only reason for
> customizing faces on a TTY frame was that customize-themes didn't work
> for you, we should talk about the latter, and you should begin with
> describing how customize-themes doesn't work for you.

See above. But the recipe and bug is not really related to
customize-themes, as I did not use it in the recipe.

> > When the GUI practically disappears due to shrinkage of faces, that
> > still seem a bug
> 
> It's not a bug, it's a cockpit error: you yourself did something that
> has this effect, and you did it globally.  Customize is limited to
> changing faces globally, on all frames, existing and future ones; if
> that's not what you want, don't use Customize.

So you say if I unset foreground color by using emacsclient in
console, it is just fine that all the fonts in GUI are shrinked?

I did not shrink the faces and I did not unset settings of fonts. Why
is then font changing? It is not logical to say that should be default
behavior.

Let me make a video of it.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

I have researched more. I am entering into this problem as I was used
to enter M-x customize-faces default from GUI and I was used that GUI
face height was by some default and it stays so.

When I however, entered from xterm, from console mode with
emacsclient -nw than after M-x customize-faces default I can see that
height is 1 point. And it is set to 1

   [X] Height: Value Menu Height in 1/10 pt: 1                                  

that is what I see if I enter customize-faces from console by using
server.

   [X] Height: Value Menu Height in 1/10 pt: 113

Is that normal behavior according to you?

It does not sound logical that Height on console should be displayed
as 1 as that does not relate to console height, I just guess so. I
think console height cannot be changed by Emacs. So if Emacs is
displaying height as 1 in customize-faces default in console, that is
not proper in my opinion.

The other issue about changing themes from console, let me verify that
one better and report back.

Jean

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

I hope you understood it all about the shrinkage and that it comes
from 1 pt face that is displayed if I enter settings through
emacsclient in console mode with -nw

Now regarding the customize-themes, if I change themes by using
emacsclient -nw in xterm, then themes change normally in GUI, I can
observe it, but not that it reflects back in xterm. Maybe that is all
alright and good as you say.

I think since more than 1 year, I often in GUI to first unset
foreground and background as otherwise I could not change the
theme. This is same problem and it is observable without -Q, with my
configuration. But I think my configuration should not influence
it.

Should it? I think it should not. Because whatever my configuration
was then the new theme should overwrite foreground and background
colors, but it does not.

Do you think it is bug?

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 19:36:57 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> > This is a whole different problem, one that I cannot reproduce.  For
> > me, customize-themes works as documented: I can enable and disable any
> > theme I want, and it works as I'd expect, including changes in colors.
> > 
> > However, you didn't tell how you used customize-themes, and what
> > didn't work there, so I don't think we are talking about the same
> > thing.
> 
> I have given the recipe how to reproduce. You say you cannot reproduce
> it?

You didn't give the recipe for using customize-themes which you say
doesn't work unless you unset the colors.  That was the reason you
needed to unset the colors to begin with, right?  Or did I
misunderstand you?

Once again: unsetting colors as you did will affect the default face
on all frames, which is not what you want.  So if you really need ti
change the default colors, I suggest using set-face-foreground and
set-face-background, which can be told to change the colors only for a
certain frame.  And if you don't need to change the colors, but need
customize-themes to work, then let's talk about your problem with
customize-themes, and forget about changing the default face, which
you say was just a workaround.

> So if I would use customize-themes without unsetting of foreground and
> background color, I would not see much of changes in console, as
> colors would not change.

Please show a recipe for such a failure in customize-themes, starting
with "emacs -Q".

> > So I don't think I understand your problem, and if the only reason for
> > customizing faces on a TTY frame was that customize-themes didn't work
> > for you, we should talk about the latter, and you should begin with
> > describing how customize-themes doesn't work for you.
> 
> See above. But the recipe and bug is not really related to
> customize-themes, as I did not use it in the recipe.

AFAIU, it _is_ related, because you explained that you didn't really
need to change the colors, except as a workaround for a problem you
have with customize-themes.

> > It's not a bug, it's a cockpit error: you yourself did something that
> > has this effect, and you did it globally.  Customize is limited to
> > changing faces globally, on all frames, existing and future ones; if
> > that's not what you want, don't use Customize.
> 
> So you say if I unset foreground color by using emacsclient in
> console, it is just fine that all the fonts in GUI are shrinked?

You didn't unset the colors, you've customized the default face.

> I did not shrink the faces and I did not unset settings of fonts. Why
> is then font changing? It is not logical to say that should be default
> behavior.

You are using Customize for a job for which it wasn't intended.  Font
size problems aside, using Customize like that will never do what you
want.  Why do you insist on using a command for a job that is not what
you want?

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 19:51:55 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> When I however, entered from xterm, from console mode with
> emacsclient -nw than after M-x customize-faces default I can see that
> height is 1 point. And it is set to 1
> 
>    [X] Height: Value Menu Height in 1/10 pt: 1                                  
> 
> that is what I see if I enter customize-faces from console by using
> server.
> 
>    [X] Height: Value Menu Height in 1/10 pt: 113
> 
> Is that normal behavior according to you?

Yes.  Everything is 1 pixel on a TTY frame.  That's why it's a bad
idea to customize faces on a TTY frame using "M-x customize-face".

> It does not sound logical that Height on console should be displayed
> as 1 as that does not relate to console height

Emacs has no way of knowing the size of font on text-mode frames, so
it counts it as 1.  That's the lowest granularity of text size on TTY
frames, as far as Emacs is concerned, as it cannot reference partial
character width or height in text mode.  The height of each text line
is 1 and the width of every character is 1 (with the exception of
double-width characters, whose width is 2).

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-01-12 20:21]:
> > Date: Tue, 12 Jan 2021 19:51:55 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 45799@debbugs.gnu.org
> > 
> > When I however, entered from xterm, from console mode with
> > emacsclient -nw than after M-x customize-faces default I can see that
> > height is 1 point. And it is set to 1
> > 
> >    [X] Height: Value Menu Height in 1/10 pt: 1                                  
> > 
> > that is what I see if I enter customize-faces from console by using
> > server.
> > 
> >    [X] Height: Value Menu Height in 1/10 pt: 113
> > 
> > Is that normal behavior according to you?
> 
> Yes.  Everything is 1 pixel on a TTY frame.  That's why it's a bad
> idea to customize faces on a TTY frame using "M-x customize-face".

Yes, and no. I use GUI mostly but there are ways why I need emacs on
console, and often themes make the console less readable or contrast
is not good enough. It may be bad idea, but I do not know what better
or else to do to customize console temporarily.

> > It does not sound logical that Height on console should be displayed
> > as 1 as that does not relate to console height
> 
> Emacs has no way of knowing the size of font on text-mode frames, so
> it counts it as 1.  That's the lowest granularity of text size on TTY
> frames, as far as Emacs is concerned, as it cannot reference partial
> character width or height in text mode.  The height of each text line
> is 1 and the width of every character is 1 (with the exception of
> double-width characters, whose width is 2).

OK I understand. Just it is not visible to user. I was not thinking of
height, I just wanted to have some better contrast and missed to see
that height on console is 1.

Still there is problem. You basically say "it is bad idea" advising me
and users to rather avoid the issue on hand.

The issue is that users are allowed to customize faces on console and
that such customization does affect GUI in the same time.

As if Emacs pulls some default for console such as 1, then it should
not affect GUI, but console only.

Or other solution would be to split settings and tell user that
specific customization of face height is for GUI, and other line is
for TUI, something like that.

So if the font on console is 1 then customization of the default face
in console should not affect the GUI. Can we agree on that?

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-01-12 20:11]:
> > Date: Tue, 12 Jan 2021 19:36:57 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 45799@debbugs.gnu.org
> > 
> > > This is a whole different problem, one that I cannot reproduce.  For
> > > me, customize-themes works as documented: I can enable and disable any
> > > theme I want, and it works as I'd expect, including changes in colors.
> > > 
> > > However, you didn't tell how you used customize-themes, and what
> > > didn't work there, so I don't think we are talking about the same
> > > thing.
> > 
> > I have given the recipe how to reproduce. You say you cannot reproduce
> > it?
> 
> You didn't give the recipe for using customize-themes which you say
> doesn't work unless you unset the colors.  That was the reason you
> needed to unset the colors to begin with, right?  Or did I
> misunderstand you?

That was the reason. But not a problem described.

> Once again: unsetting colors as you did will affect the default face
> on all frames, which is not what you want.

Ideally I would like if I unset colors in console or GUI, that it
affects all frames. Not one frame.

I could see you have idea of setting up one frame, but that was never
my idea, and I never yet desired to do so. Just to inform you of
user's pattern of thinking.

> So if you really need ti change the default colors, I suggest using
> set-face-foreground and set-face-background, which can be told to
> change the colors only for a certain frame.

That is alright as workaround and it solves temporarily some
problems. But doing that is difficult as on console some letters will
disappear, one has to do blind job.

set-foreground-color white will whiten many things and then I have to
do blind set-background-color black. With "blind" I mean that many
letters I will not be able to read as some have been already set white.

> And if you don't need to change the colors, but need
> customize-themes to work, then let's talk about your problem with
> customize-themes, and forget about changing the default face, which
> you say was just a workaround.

I prefer quickly changing a theme rather then foreground/background
one by one. But I reported bug for other users more than for me
personally. 

> > > It's not a bug, it's a cockpit error: you yourself did something that
> > > has this effect, and you did it globally.  Customize is limited to
> > > changing faces globally, on all frames, existing and future ones; if
> > > that's not what you want, don't use Customize.
> > 
> > So you say if I unset foreground color by using emacsclient in
> > console, it is just fine that all the fonts in GUI are shrinked?
> 
> You didn't unset the colors, you've customized the default face.

Yes, I see.

But if default face on GUI 113 and on TUI 1, then user shall not get 1
on TUI to customize also GUI to be 1. Can we agree on that?

In my opinion if Emacs strategy on console is to display console's
font's size then better affect only console even if there is no real
effect, rather that then affecting the GUI and shrinking fonts to 1.

> > I did not shrink the faces and I did not unset settings of fonts. Why
> > is then font changing? It is not logical to say that should be default
> > behavior.
> 
> You are using Customize for a job for which it wasn't intended.  Font
> size problems aside, using Customize like that will never do what you
> want.  Why do you insist on using a command for a job that is not what
> you want?

I do not insist, I use what I think I have as an option to use. If I
wish to change the theme I cannot change it because foreground and
background colors first need to be unset, you say customize, but for
me it is unsetting as I remove the [X] into empty [ ] and apply it for
current session, only then I can customize the theme.

By attempting to do so, faces shrunk and I did not know it is because
of font being 1 pt.

With emacs -Q I cannot reproduce the theme settings. Problem is
appearing when user has already set the foreground and background
colors as then themes will not change those colors.

Is that maybe default behavior?

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 20:01:52 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> Now regarding the customize-themes, if I change themes by using
> emacsclient -nw in xterm, then themes change normally in GUI, I can
> observe it, but not that it reflects back in xterm. Maybe that is all
> alright and good as you say.

Please be more specific: which themes you tried to enable in -nw, what
happened, etc.  You are not giving enough details to investigate the
issue.  In general, only a small number of themes are suitable for
TTYs, but I'm not yet sure whether the problems you encountered are
due to this or to something else.  Please help me understand the issue
completely.

> I think since more than 1 year, I often in GUI to first unset
> foreground and background as otherwise I could not change the
> theme.

Please describe the steps to reproduce, and please also tell what
exactly does "could not change the theme" mean.

> Do you think it is bug?

I don't know yet, although it sounds like it is.  More detail is
needed.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 20:46:00 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> So if the font on console is 1 then customization of the default face
> in console should not affect the GUI. Can we agree on that?

Someone will have to implement an infrastructure to allow users
customize faces separately for each type of frame.  The current
Customize machinery for faces was not supposed to allow that.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> Date: Tue, 12 Jan 2021 20:55:02 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 45799@debbugs.gnu.org
> 
> > You didn't unset the colors, you've customized the default face.
> 
> Yes, I see.
> 
> But if default face on GUI 113 and on TUI 1, then user shall not get 1
> on TUI to customize also GUI to be 1. Can we agree on that?

This is not specific to TTY frames vs GUI frames.  You will have the
same problem if some frames use larger fonts for some reason: using
"M-x customize-face" will change the default face on _all_ of the
frames, and thus shrink the font size on the frames that used the
larger fonts.

Where does this end?

You are perceiving customize-face as a means for customizing the face
only on some frames, but that is not how that feature works, it
changes the faces globally, and for a good reason: Custom was invented
for users who want to avoid customizing Emacs in Lisp, so Custom
supports only simple use cases, and tries not to confuse the users by
providing too much flexibility and too much power.

If you want selective customizations, you must do that not via
customize-face.

> In my opinion if Emacs strategy on console is to display console's
> font's size then better affect only console even if there is no real
> effect, rather that then affecting the GUI and shrinking fonts to 1.

That's your opinion, and it's biased because you bumped into this
situation (quite unnecessarily, AFAIU).  the "usual" situations where
users invoke customize-face are very different.  What you intended to
do is not currently supported by customize-face, and I doubt that it
will ever be supported.

> With emacs -Q I cannot reproduce the theme settings. Problem is
> appearing when user has already set the foreground and background
> colors as then themes will not change those colors.

Then please try to come up with a simplest series of steps to
reproduce the problem with customize-themes.  There's some other
factor at work here, and we need to uncover it.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Someone will have to implement an infrastructure to allow users
  > customize faces separately for each type of frame.  The current
  > Customize machinery for faces was not supposed to allow that.

How many types of frames are there?  Just two (GUI and text)?  For
just two, it could be that a user could customize each one fairly
easily.  Make two files, .emacs.gui and .emacs.text, then have .emacs
choose to load one or the other of those two.  Then put the
customization for GUI terminals into .emacs.gui and that for text
terminals into .emacs.text.

It's not super-clean but it may be good enough.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2021-01-13 08:39]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Someone will have to implement an infrastructure to allow users
>   > customize faces separately for each type of frame.  The current
>   > Customize machinery for faces was not supposed to allow that.
> 
> How many types of frames are there?  Just two (GUI and text)?  For
> just two, it could be that a user could customize each one fairly
> easily.  Make two files, .emacs.gui and .emacs.text, then have .emacs
> choose to load one or the other of those two.  Then put the
> customization for GUI terminals into .emacs.gui and that for text
> terminals into .emacs.text.
> 
> It's not super-clean but it may be good enough.

I am using TUI by using emacsclient that speaks to GUI running
server. Do you think that may work with 2 customization files?

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-01-12 21:04]:
> > Date: Tue, 12 Jan 2021 20:01:52 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 45799@debbugs.gnu.org
> > 
> > Now regarding the customize-themes, if I change themes by using
> > emacsclient -nw in xterm, then themes change normally in GUI, I can
> > observe it, but not that it reflects back in xterm. Maybe that is all
> > alright and good as you say.
> 
> Please be more specific: which themes you tried to enable in -nw, what
> happened, etc.  You are not giving enough details to investigate the
> issue.  In general, only a small number of themes are suitable for
> TTYs, but I'm not yet sure whether the problems you encountered are
> due to this or to something else.  Please help me understand the issue
> completely.

Here is full description of all information that I think that applies
there.

In my init.el I have this customization related to faces.

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((t (:inherit nil :extend nil :stipple nil :background "white" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 140 :width normal :foundry "GOOG" :family "Noto Sans Mono"))))
 '(term ((t (:background "black" :foreground "white smoke" :height 1.2 :family "xos4 Terminus")))))

Side notes:

- I have found this happening since long time, it could be that I
  already filed bug on this

- normally I use GUI, not TUI, but when answering many emails one
  after the other, Emacs in XTerm (TUI) gives me more consistent
  interface as I do not need to switch my focus from XTerm to GUI.

- I do not install any outside themes, I just use the built-in Emacs
  themes, and I do not have any favorite. Often randomly I change the
  theme. 

Intention while working in XTerm is that by quickly changing the
theme to get a better contrast.

With the above settings then if I would do just:

M-x customize-themes

and choose any theme, the foreground and background color would not
change.

It does not matter if I try changing themese from TUI or GUI.

Example is adwaita and deeper-blue, if I click there, foreground and
background do not change. So to make them change, I do: M-x
customize-faces and choose `default' and then I unset foreground and
background colors and click 0 to have it remembered for a session.

As soon as I unset it, if I was in deeper-blue theme, then I get the
deeper-blue background.

Then I can also freely choose any of the themes below and foreground
and background will be changed by clicking on the theme.

I am unsure of it, but I think I remember times when I did not need to
unset foreground and background and theme switching would work
straight without unsetting.

My expectation is that I would not need to unset foreground/background
for default face and that theme should change it directly, but it does
not. 

[ ][ adwaita] -- Face colors similar to the default theme of Gnome 3 (Adwaita).
[ ][ deeper-blue] -- Face colors using a deep blue background.
[ ][ dichromacy] -- Face colors suitable for red/green color-blind users.
[ ][ leuven] -- (no documentation available)
[ ][ light-blue] -- Face colors utilizing a light blue background.
[ ][ manoj-dark] -- Very high contrast faces with a black background.
[ ][ misterioso] -- Predominantly blue/cyan faces on a dark cyan background.
[ ][ modus-operandi] -- Light theme that conforms with the highest accessibility
[ ][ modus-vivendi] -- Dark theme that conforms with the highest accessibility
[ ][ tango-dark] -- Face colors using the Tango palette (dark background).
[ ][ tango] -- Face colors using the Tango palette (light background).
[ ][ tsdh-dark] -- A dark theme used and created by Tassilo Horn.
[ ][ tsdh-light] -- A light Emacs theme.
[ ][ wheatgrass] -- High-contrast green/blue/brown faces on a black background.
[ ][ whiteboard] -- Face colors similar to markers on a whiteboard.
[X][ wombat] -- Medium-contrast faces with a dark gray background.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Mauro Aranda]

Jean Louis <bugs@gnu.support> writes:

> Here is full description of all information that I think that applies
> there.
>
> In my init.el I have this customization related to faces.
>
> (custom-set-faces
>  ;; custom-set-faces was added by Custom.
>  ;; If you edit it by hand, you could mess it up, so be careful.
>  ;; Your init file should contain only one such instance.
>  ;; If there is more than one, they won't work right.
>  '(default ((t (:inherit nil :extend nil :stipple nil :background "white" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 140 :width normal :foundry "GOOG" :family "Noto Sans Mono"))))
>  '(term ((t (:background "black" :foreground "white smoke" :height 1.2 :family "xos4 Terminus")))))
>

[...]

> With the above settings then if I would do just:
>
> M-x customize-themes
>
> and choose any theme, the foreground and background color would not
> change.
>
> It does not matter if I try changing themese from TUI or GUI.
>
> Example is adwaita and deeper-blue, if I click there, foreground and
> background do not change. So to make them change, I do: M-x
> customize-faces and choose `default' and then I unset foreground and
> background colors and click 0 to have it remembered for a session.
>
> As soon as I unset it, if I was in deeper-blue theme, then I get the
> deeper-blue background.

I don't see a bug here.  You have customized the default face in your
init file, so that setting gets saved in a theme, the user theme, which
takes precedence before all other themes you activate.  This is
described in several places, like in the *Custom Themes* buffer itself:

 Note: Your custom settings take precedence over theme settings.
       To migrate your settings into a theme, click here.

When you activate other themes, they do get activated, but your setting
for the default face takes precedence, so it will not change, and that's
why you have to unset your own customization of the default face, for
the theme settings to kick in.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bugs@gnu.support, 45799@debbugs.gnu.org
> Date: Wed, 13 Jan 2021 00:38:46 -0500
> 
>   > Someone will have to implement an infrastructure to allow users
>   > customize faces separately for each type of frame.  The current
>   > Customize machinery for faces was not supposed to allow that.
> 
> How many types of frames are there?  Just two (GUI and text)?  For
> just two, it could be that a user could customize each one fairly
> easily.  Make two files, .emacs.gui and .emacs.text, then have .emacs
> choose to load one or the other of those two.  Then put the
> customization for GUI terminals into .emacs.gui and that for text
> terminals into .emacs.text.

That doesn't do the job when you have a session which mixes GUI and
TTY frames, as in Jean's case.  Specifically, Emacs is started with
GUI frames, but then emacsclient requests a TTY frame in that session.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Eli Zaretskii]

> From: Mauro Aranda <maurooaranda@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  45799@debbugs.gnu.org
> Date: Wed, 13 Jan 2021 10:05:53 -0300
> 
> I don't see a bug here.  You have customized the default face in your
> init file, so that setting gets saved in a theme, the user theme, which
> takes precedence before all other themes you activate.  This is
> described in several places, like in the *Custom Themes* buffer itself:
> 
>  Note: Your custom settings take precedence over theme settings.
>        To migrate your settings into a theme, click here.
> 
> When you activate other themes, they do get activated, but your setting
> for the default face takes precedence, so it will not change, and that's
> why you have to unset your own customization of the default face, for
> the theme settings to kick in.

Agreed.

I also think Jean should try clicking on that "here" button, to
migrate his settings to a theme, then he could disable that theme and
enable another one, which should solve the problem.

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That doesn't do the job when you have a session which mixes GUI and
  > TTY frames, as in Jean's case.  Specifically, Emacs is started with
  > GUI frames, but then emacsclient requests a TTY frame in that session.

Oh well, I tried.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#45799: 28.0.50; Faces shrink unreadable on GUI when foreground/background color set in TUI

[Lars Ingebrigtsen]

Mauro Aranda <maurooaranda@gmail.com> writes:

> I don't see a bug here.  You have customized the default face in your
> init file, so that setting gets saved in a theme, the user theme, which
> takes precedence before all other themes you activate.  This is
> described in several places, like in the *Custom Themes* buffer itself:
>
>  Note: Your custom settings take precedence over theme settings.
>        To migrate your settings into a theme, click here.
>
> When you activate other themes, they do get activated, but your setting
> for the default face takes precedence, so it will not change, and that's
> why you have to unset your own customization of the default face, for
> the theme settings to kick in.

Skimming this bug report, this seems to be the conclusion, and I'm
therefore closing this bug report.  If there's something that should be
done here, please respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no