all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Forcing emacs to not use 256 colors
       [not found] <20230628115134.6f5874ca@fecfc4134a3d>
@ 2023-06-28 15:51 ` Tom Noonan II
  2023-06-30 12:00   ` Eli Zaretskii
  2023-07-02  8:47   ` Gregory Heytings
  0 siblings, 2 replies; 11+ messages in thread
From: Tom Noonan II @ 2023-06-28 15:51 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

Good day:

I'm a long time emacs user and I'm used to the default 16 color syntax
highlighting.  I recently upgraded my system which brought in 256 color
support, and I find the new syntax highlighting colors distasteful.  I
also dislike how the colors may be completely different depending on if
I'm using a 16 color terminal or a 256 color terminal.  I'd like to
force emacs to only use 16 color or less palettes.

I took a look at M-x customize-themes but that doesn't look like what I
want.  That appears to be changing the overall theme, including
foreground and background colors.  I want to force the default, non
-256color behavior everywhere, not change the overall coloring.

I tried searching but the results are getting flooded out with posts on
how to enable 256 colors.  Is there a way to disable these 256color
specific syntax highlighting pallettes?  Or otherwise limit the color
mapping to the various $TERM values?

--Tom Noonan II



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-06-28 15:51 ` Forcing emacs to not use 256 colors Tom Noonan II
@ 2023-06-30 12:00   ` Eli Zaretskii
  2023-06-30 15:14     ` John Yates
  2023-07-02  8:47   ` Gregory Heytings
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2023-06-30 12:00 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Tom Noonan II <tom@tjnii.com>
> Date: Wed, 28 Jun 2023 15:51:39 +0000
> 
> Good day:
> 
> I'm a long time emacs user and I'm used to the default 16 color syntax
> highlighting.  I recently upgraded my system which brought in 256 color
> support, and I find the new syntax highlighting colors distasteful.  I
> also dislike how the colors may be completely different depending on if
> I'm using a 16 color terminal or a 256 color terminal.  I'd like to
> force emacs to only use 16 color or less palettes.
> 
> I took a look at M-x customize-themes but that doesn't look like what I
> want.  That appears to be changing the overall theme, including
> foreground and background colors.  I want to force the default, non
> -256color behavior everywhere, not change the overall coloring.
> 
> I tried searching but the results are getting flooded out with posts on
> how to enable 256 colors.  Is there a way to disable these 256color
> specific syntax highlighting pallettes?  Or otherwise limit the color
> mapping to the various $TERM values?

Either (a) install and use a terminal emulator that supports only 16
colors, or (b) edit the terminfo database for your terminal emulator
to tell Emacs that only 16 colors are supported.

That said, I'm curious: why do you dislike more than 16 colors?  If
you don't like the default colors themselves, isn't it better to
customize the faces to use the colors you like?  That way, you will
not need to lie to Emacs about the number of supported colors, and the
customizations will work on any terminal.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-06-30 12:00   ` Eli Zaretskii
@ 2023-06-30 15:14     ` John Yates
  2023-06-30 18:58       ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: John Yates @ 2023-06-30 15:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: help-gnu-emacs

> If you don't like the default colors themselves, isn't it better to
> customize the faces to use the colors you like?

Properly done, that is an enormous undertaking.  Just take a look
at the work Protesilaos has put into creating themes covering large
numbers of emacs packages.

The alternative is to have a jarring experience each time one renders
an uncustomized face.

/john



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-06-30 15:14     ` John Yates
@ 2023-06-30 18:58       ` Eli Zaretskii
  2023-07-01  6:50         ` tomas
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2023-06-30 18:58 UTC (permalink / raw)
  To: help-gnu-emacs

> From: John Yates <john@yates-sheets.org>
> Date: Fri, 30 Jun 2023 11:14:28 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> > If you don't like the default colors themselves, isn't it better to
> > customize the faces to use the colors you like?
> 
> Properly done, that is an enormous undertaking.

Not if you only ever customize the faces you care about.  Let's not
gratuitously exaggerate the problem, okay?

> Just take a look at the work Protesilaos has put into creating
> themes covering large numbers of emacs packages.

Themes customize most if not all faces, something individual users
will never need to do.

Of course, the best is to just use the defaults: they are, after all,
well thought-out...



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-06-30 18:58       ` Eli Zaretskii
@ 2023-07-01  6:50         ` tomas
  2023-07-01  8:07           ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: tomas @ 2023-07-01  6:50 UTC (permalink / raw)
  To: help-gnu-emacs

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

On Fri, Jun 30, 2023 at 09:58:20PM +0300, Eli Zaretskii wrote:
> > From: John Yates <john@yates-sheets.org>
> > Date: Fri, 30 Jun 2023 11:14:28 -0400
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > If you don't like the default colors themselves, isn't it better to
> > > customize the faces to use the colors you like?
> > 
> > Properly done, that is an enormous undertaking.
> 
> Not if you only ever customize the faces you care about.  Let's not
> gratuitously exaggerate the problem, okay?

I think you're being a bit unfair here: the original problem
description is perfectly valid and John's observation seems
quite adequate.

For someone who has been happy with a set of defaults up to
now (for whatever set of reasons: habituation may be in there),
it can be jarring if those defaults change. That user perhaps
doesn't know how Emacs manages faces. Finding their way to
"customize the faces they care about" is the first challenge.
Finding the set of those may develop to a happy game of whack-
a-mole.

> > Just take a look at the work Protesilaos has put into creating
> > themes covering large numbers of emacs packages.
> 
> Themes customize most if not all faces, something individual users
> will never need to do.
> 
> Of course, the best is to just use the defaults: they are, after all,
> well thought-out...

I seriously hope this is tongue-in-cheek.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-07-01  6:50         ` tomas
@ 2023-07-01  8:07           ` Eli Zaretskii
  2023-07-02  8:04             ` tomas
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2023-07-01  8:07 UTC (permalink / raw)
  To: help-gnu-emacs

> Date: Sat, 1 Jul 2023 08:50:54 +0200
> From: <tomas@tuxteam.de>
> 
> > > > If you don't like the default colors themselves, isn't it better to
> > > > customize the faces to use the colors you like?
> > > 
> > > Properly done, that is an enormous undertaking.
> > 
> > Not if you only ever customize the faces you care about.  Let's not
> > gratuitously exaggerate the problem, okay?
> 
> I think you're being a bit unfair here: the original problem
> description is perfectly valid and John's observation seems
> quite adequate.

I didn't say the problem is invalid.  I just said that assuming the
user needs to customize _all_ of the faces is an exaggeration of the
problem facing the user.  I don't think I deserve this kind of cold
shower just because I have a different perspective on this.  I do my
share of face customizations, so I know something about what's
involved.

And I only wrote that as an aside, after trying to answer the specific
question the user asked.

Again, it's okay to disagree, but please do so in a way that respects
differing opinions, which means, among the rest, not to hint they are
invalid, "unfair", or any other such derogation.

> For someone who has been happy with a set of defaults up to
> now (for whatever set of reasons: habituation may be in there),
> it can be jarring if those defaults change. That user perhaps
> doesn't know how Emacs manages faces. Finding their way to
> "customize the faces they care about" is the first challenge.
> Finding the set of those may develop to a happy game of whack-
> a-mole.

If the OP doesn't know how to customize faces, or how to find which
face is used at a given location, they can always ask; this is what
this list is for.  Lecturing users about things they already know is
also sometimes taken as a patronizing offense, so I prefer to wait for
specific questions.  I don't see why this approach should be a
problem, but if you or someone else prefers to post the detailed
information without waiting for questions, please do.

> > > Just take a look at the work Protesilaos has put into creating
> > > themes covering large numbers of emacs packages.
> > 
> > Themes customize most if not all faces, something individual users
> > will never need to do.
> > 
> > Of course, the best is to just use the defaults: they are, after all,
> > well thought-out...
> 
> I seriously hope this is tongue-in-cheek.

It wasn't; it was a good-faith suggestion to consider whether the
defaults are really disliked or merely unusual (in which case maybe
they just take some getting used to).

And I wonder why you saw it appropriate to express that "hope" in a
public post in the first place.  This is supposed to be a forum where
each one tries to help those who asks questions as best as they can,
and I don't think my attempts to do so in this case were not useful,
let alone intentionally so, to deserve such rebuttals.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-07-01  8:07           ` Eli Zaretskii
@ 2023-07-02  8:04             ` tomas
  2023-07-02  8:23               ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: tomas @ 2023-07-02  8:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: help-gnu-emacs

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

On Sat, Jul 01, 2023 at 11:07:01AM +0300, Eli Zaretskii wrote:

[...]

> Again, it's okay to disagree, but please do so in a way that respects
> differing opinions, which means, among the rest, not to hint they are
> invalid, "unfair", or any other such derogation.

[...]

> And I wonder why you saw it appropriate to express that "hope" in a
> public post in the first place.  This is supposed to be a forum where
> each one tries to help those who asks questions as best as they can,
> and I don't think my attempts to do so in this case were not useful,
> let alone intentionally so, to deserve such rebuttals.

I have the impression that my post came across as a personal
attack. This is far from my intention and I must assume that
I'm failing to communicate. So perhaps it's best I stop now.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-07-02  8:04             ` tomas
@ 2023-07-02  8:23               ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2023-07-02  8:23 UTC (permalink / raw)
  To: help-gnu-emacs

> Date: Sun, 2 Jul 2023 10:04:18 +0200
> Cc: help-gnu-emacs@gnu.org
> From:  <tomas@tuxteam.de>
> 
> I have the impression that my post came across as a personal
> attack. This is far from my intention and I must assume that
> I'm failing to communicate. So perhaps it's best I stop now.

Not a personal attack, but a post that negatively assesses someone
else's attempt to help the OP.  I think such negative posts are only
appropriate here if the offending attempt to help is entirely
misleading or even damaging to the OP.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-06-28 15:51 ` Forcing emacs to not use 256 colors Tom Noonan II
  2023-06-30 12:00   ` Eli Zaretskii
@ 2023-07-02  8:47   ` Gregory Heytings
       [not found]     ` <20230704160635.306eedbe@fecfc4134a3d>
  1 sibling, 1 reply; 11+ messages in thread
From: Gregory Heytings @ 2023-07-02  8:47 UTC (permalink / raw)
  To: Tom Noonan II; +Cc: help-gnu-emacs


>
> I tried searching but the results are getting flooded out with posts on 
> how to enable 256 colors.  Is there a way to disable these 256color 
> specific syntax highlighting pallettes?  Or otherwise limit the color 
> mapping to the various $TERM values?
>

Can't you just do "export TERM=xterm-16color"?




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
       [not found]     ` <20230704160635.306eedbe@fecfc4134a3d>
@ 2023-07-04 20:06       ` Tom Noonan II
  2023-07-05  4:03         ` Platon Pronko
  0 siblings, 1 reply; 11+ messages in thread
From: Tom Noonan II @ 2023-07-04 20:06 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: help-gnu-emacs@gnu.org

This my current workaround but I'd prefer to find a solution that's
limited to emacs, if possible.  This seems like something I should be
able to configure, but I'm not familiar enough with the colorization
internals (or lisp) to know where to start.

On Sun, 02 Jul 2023 08:47:51 +0000
Gregory Heytings <gregory@heytings.org> wrote:

> >
> > I tried searching but the results are getting flooded out with
> > posts on how to enable 256 colors.  Is there a way to disable these
> > 256color specific syntax highlighting pallettes?  Or otherwise
> > limit the color mapping to the various $TERM values?
> >  
> 
> Can't you just do "export TERM=xterm-16color"?
> 




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Forcing emacs to not use 256 colors
  2023-07-04 20:06       ` Tom Noonan II
@ 2023-07-05  4:03         ` Platon Pronko
  0 siblings, 0 replies; 11+ messages in thread
From: Platon Pronko @ 2023-07-05  4:03 UTC (permalink / raw)
  To: Tom Noonan II, Gregory Heytings; +Cc: help-gnu-emacs@gnu.org

On 2023-07-05 00:06, Tom Noonan II wrote:
> This my current workaround but I'd prefer to find a solution that's
> limited to emacs, if possible.  This seems like something I should be
> able to configure, but I'm not familiar enough with the colorization
> internals (or lisp) to know where to start.

Maybe `alias emacs="TERM=xterm16-color emacs"`?

It's looks like the simplest approach, the alternative being going very deep into Emacs internals (and probably recompiling it with your own patches, as terminal color selection is probably done in C code).

-- 
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E




^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-07-05  4:03 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20230628115134.6f5874ca@fecfc4134a3d>
2023-06-28 15:51 ` Forcing emacs to not use 256 colors Tom Noonan II
2023-06-30 12:00   ` Eli Zaretskii
2023-06-30 15:14     ` John Yates
2023-06-30 18:58       ` Eli Zaretskii
2023-07-01  6:50         ` tomas
2023-07-01  8:07           ` Eli Zaretskii
2023-07-02  8:04             ` tomas
2023-07-02  8:23               ` Eli Zaretskii
2023-07-02  8:47   ` Gregory Heytings
     [not found]     ` <20230704160635.306eedbe@fecfc4134a3d>
2023-07-04 20:06       ` Tom Noonan II
2023-07-05  4:03         ` Platon Pronko

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.