all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Using Emacs in fbterm.
Date: Mon, 29 Aug 2022 21:53:46 +0300	[thread overview]
Message-ID: <83a67mx4n9.fsf@gnu.org> (raw)
In-Reply-To: <Yw0JChTvzL/MoQsj@ACM> (message from Alan Mackenzie on Mon, 29 Aug 2022 18:44:26 +0000)

> Date: Mon, 29 Aug 2022 18:44:26 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > The face hi-green, for example, rather than having background
> > > "green" gets "light green".  This appears on the terminal as dark
> > > yellow, which is clearly wrong.
> 
> > Why do you think it's wrong?
> 
> hi-green MUST be green, otherwise, what's the point?

Why, because of the textual similarity? that's a wrong way of finding
the best match for a color.  Long time ago what is now tty-colors.el
used such "heuristics", and it was found to be less satisfactory than
the current system based on RGB values.

So we won't go back to the sub-optimal method.

> What is wrong is the "light" in light green.  It's simply "green" on
> the Linux console.  Looking at the Lisp expression in
> customize-face, light green can only happen when (min-colors 88) is
> satisfied.

You are misinterpreting what the code does.  It doesn't work the way
you think it does.

Once again, if the results of automatic translation of colors are
unsatisfactory, we should do one of these:

   . change the colors such that (a) on color-rich terminals the
     colors are similar, but (b) on 8-color terminals we get better
     results; or
   . change the face definition to have a separate setting of colors
     for terminals with 8 colors

Please try to see which one of these gives better results, and let's
go with that.  Although...

> I've made further progress in diagnosing this.  If the environment
> variable TERM is "linux", the problems with the colours don't happen.
> If it's "fbterm", they do.

Which problems do or don't happen depending on $TERM?

> So, I would guess that somewhere in the depths of the face construction,
> there's a test for TERM being "linux".

I doubt that.

> Or, maybe, an inappropriate terminfo entry is getting used when it's
> "fbterm".  Or something like that.  Maybe the fbterm terminfo entry
> is inconsistent with fbterm itself.

That's possible, but also unlikely.  If terminfo is the problem, then
looking at the color commands that we send to the terminal (in term.c)
could perhaps point out the reason.



  reply	other threads:[~2022-08-29 18:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29 16:41 Using Emacs in fbterm Alan Mackenzie
2022-08-29 17:33 ` Eli Zaretskii
2022-08-29 18:44   ` Alan Mackenzie
2022-08-29 18:53     ` Eli Zaretskii [this message]
2022-08-29 18:54     ` Gregory Heytings
2022-08-29 18:59       ` Eli Zaretskii
2022-08-29 19:29         ` Gregory Heytings
2022-08-29 19:42           ` Eli Zaretskii
2022-08-29 19:45             ` Gregory Heytings
2022-08-29 19:55               ` Gregory Heytings
2022-08-29 19:34       ` Andreas Schwab
2022-08-29 19:43         ` Gregory Heytings
2022-08-29 19:52           ` Andreas Schwab
2022-08-29 20:27             ` Gregory Heytings
2022-08-29 20:35               ` Alan Mackenzie
2022-08-29 20:52                 ` Gregory Heytings
2022-08-29 22:28                   ` Gregory Heytings
2022-08-30 11:32                     ` Eli Zaretskii
2022-08-30 12:04                       ` Gregory Heytings
2022-08-30 12:10                         ` Eli Zaretskii
2022-08-30 21:10                           ` Gregory Heytings
2022-08-30 13:16                         ` Stefan Monnier
2022-08-30 15:37                           ` Gregory Heytings
2022-08-30 18:26                             ` Stefan Monnier
2022-08-30 21:20                               ` Gregory Heytings
2022-08-30 21:56                                 ` Stefan Monnier
2022-08-30 22:07                                   ` Gregory Heytings
2022-09-04  2:59                                     ` Stefan Monnier
2022-08-29 18:50 ` Gregory Heytings

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=83a67mx4n9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

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