Turning off colorization

Turning off colorization

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

M-x font-lock-mode will turn off colorization, but it's not a name
that will come to a user's mind very easily.  How about making
colorize-mode an alias for font-lock-mode?

Also, how about putting it in the Options menu?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> M-x font-lock-mode will turn off colorization, but it's not a name
> that will come to a user's mind very easily.  How about making
> colorize-mode an alias for font-lock-mode?
>
> Also, how about putting it in the Options menu?

Why not "syntax-highlight-mode"?

It's the general name, although I realise that it doesn't always
indicate syntax.

Phil

Re: Turning off colorization

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

  > > M-x font-lock-mode will turn off colorization, but it's not a name
  > > that will come to a user's mind very easily.  How about making
  > > colorize-mode an alias for font-lock-mode?
  > >
  > > Also, how about putting it in the Options menu?

  > Why not "syntax-highlight-mode"?

There's nothing wrong with that name,
but it's not what a user will think of.
What the mode normally does is put the text in color.
A user will think of typing M-x color TAB
to look for a name.

So I think it should have the name colorize-mode.

If it also has the name syntax-highlight-mode, that is fine too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > M-x font-lock-mode will turn off colorization, but it's not a name
>   > > that will come to a user's mind very easily.  How about making
>   > > colorize-mode an alias for font-lock-mode?
>   > >
>   > > Also, how about putting it in the Options menu?
>
>   > Why not "syntax-highlight-mode"?
>
> There's nothing wrong with that name,
> but it's not what a user will think of.
> What the mode normally does is put the text in color.
> A user will think of typing M-x color TAB
> to look for a name.
>
> So I think it should have the name colorize-mode.
>
> If it also has the name syntax-highlight-mode, that is fine too.

Syntax highlighting is an established term for this.  Even the
description of font-lock-mode has the summary

    Toggle syntax highlighting in this buffer (Font Lock mode).

and every editor capable of doing it calls it "syntax highlighting".
Colorization, in contrast, is a much more generic term missing the
connotation of the _meaning_ with which colors are assigned.

I don't see the point in diverging from established terminology here: as
opposed to kill/yank (vs cut/paste) we do not have mnemonic keybindings
riding on our original terms.

If I do "man vim", I read

       There  are a lot of enhancements above Vi: multi level undo, multi win\u2010
       dows and buffers, syntax highlighting, command line  editing,  filename

If I do apt-cache search -f bluefish, I get

     fully featured image insert dialog; thumbnail creation and automatically
     linking of the thumbnail with the original image; and configurable HTML
     syntax highlighting.

    Package: winefish
    Description-md5: 0c545214eec1a9e30aec3c9e8f9c296d
    Description-en: LaTeX Editor based on Bluefish
     Winefish is a GTK+ based LaTeX editor, which was forked from Bluefish.
     The main features are autotext, auto-completion, function references,
     syntax highlighting, customizable external tools and UTF-8 support.

If I do apt-cache search -f emacs, I get far, far too many entries.  The
very first mentioning _anything_ along the kind of font-locking is

    Description-en: A Cascading Style Sheets (CSS) editing mode for Emacs
     This is a simple Emacs mode for editing CSS style sheets. It adds
     font-locking and some basic auto-indentation support to Emacs. It
     works with Emacs 19.34, but should also work with both older and
     newer versions as well as XEmacs.

The next is

    Package: erlang-mode
    Description-md5: 458834bc6eb6df394adfd308669076f9
    Description-en: Erlang major editing mode for Emacs
     This package includes the mode for editing Erlang programs in GNU Emacs.
     It is provided with the default Erlang/OTP distribution. It supports
     sophisticated indentation, syntax highlighting, electric commands,
     module name verification, comments, skeletons, tags etc.


Really, this battle is over.  And in this case, I see no point in
digging up its grave.

-- 
David Kastrup

Re: Turning off colorization

[Ted Zlatanov]

On Wed, 05 Nov 2014 10:11:34 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> Syntax highlighting is an established term for this.  Even the
DK> description of font-lock-mode has the summary

DK>     Toggle syntax highlighting in this buffer (Font Lock mode).

DK> and every editor capable of doing it calls it "syntax highlighting".
DK> Colorization, in contrast, is a much more generic term missing the
DK> connotation of the _meaning_ with which colors are assigned.

Some color-blind or visually impaired people may want syntax
highlighting but not colorization. I think that was the original reason
for this request: rendering HTML with no colors for better contrast in a
specific terminal configuration.

In HTML we can specify colors explicitly or indirectly through styles
(equivalent to syntax highlighting). Viewing a web page without color,
therefore, is different from viewing it without syntax highlighting.

So maybe Emacs could offer a way to turn off colors without turning off
syntax highlighting, at least in SHR. I think it would be generally
useful, but don't know if and how it could work generally.

(I also agree that `colorization-mode' and `syntax-highlight-mode' are
better names for `font-lock-mode'.)

Ted

Re: Turning off colorization

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Some color-blind or visually impaired people may want syntax
> highlighting but not colorization.

Very good point.

> So maybe Emacs could offer a way to turn off colors without turning
> off syntax highlighting, at least in SHR. I think it would be
> generally useful, but don't know if and how it could work generally.

Wouldn't it suffice to provide a `no-colors' theme that sets up the
standard font-lock faces so that they don't use colors but only bold
fonts, italics, underline, etc?

Probably, that wouldn't suffice because redefining each and every face
defined by some package isn't feasible.  But maybe that "theme" could
also advise `defface' and friends and strip color attributes from
face-specs.

Bye,
Tassilo

Re: Turning off colorization

[Andreas Schwab]

Tassilo Horn <tsdh@gnu.org> writes:

> Probably, that wouldn't suffice because redefining each and every face
> defined by some package isn't feasible.  But maybe that "theme" could
> also advise `defface' and friends and strip color attributes from
> face-specs.

Most face specs already have alternatives for monochrome displays.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Turning off colorization

[Tassilo Horn]

Andreas Schwab <schwab@suse.de> writes:

>> Probably, that wouldn't suffice because redefining each and every
>> face defined by some package isn't feasible.  But maybe that "theme"
>> could also advise `defface' and friends and strip color attributes
>> from face-specs.
>
> Most face specs already have alternatives for monochrome displays.

That might apply to built-in faces but less so for third-party packages.
One could argue that this is a deficiency on their side (and it is) but
a general solution should handle that, too.

And it's not only a matter of colors versus no colors.  Someone who is
color-blind usually can't disambiguate red from green too well but still
she might enjoy colors, just not combinations of red and green in the
same buffer.  (Well, of course replacing shades of green with an
alternative color that is properly distinguishable of other used colors
is a much harder job than just stripping colors, but at least it seems
doable.)

Bye,
Tassilo

Re: Turning off colorization

[Phillip Lord]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 05 Nov 2014 10:11:34 +0100 David Kastrup <dak@gnu.org> wrote: 
>
> DK> Syntax highlighting is an established term for this.  Even the
> DK> description of font-lock-mode has the summary
>
> DK>     Toggle syntax highlighting in this buffer (Font Lock mode).
>
> DK> and every editor capable of doing it calls it "syntax highlighting".
> DK> Colorization, in contrast, is a much more generic term missing the
> DK> connotation of the _meaning_ with which colors are assigned.
>
> Some color-blind or visually impaired people may want syntax
> highlighting but not colorization. I think that was the original reason
> for this request: rendering HTML with no colors for better contrast in a
> specific terminal configuration.
>
> In HTML we can specify colors explicitly or indirectly through styles
> (equivalent to syntax highlighting). Viewing a web page without color,
> therefore, is different from viewing it without syntax highlighting.
>
> So maybe Emacs could offer a way to turn off colors without turning off
> syntax highlighting, at least in SHR. I think it would be generally
> useful, but don't know if and how it could work generally.

This would be a matter of picking a different "colour" scheme surely?
One with no colours, but using the other elements that you talk about.
I have a high-vis colour scheme (white background rather than my usual
dark) which I use on my laptop on a sunny day, for instance.

Then a command line option to choose it, to avoid the bootstrap problem
of not being able to see emacs properly to choose the option.

Of course, you'd need to ask an accessibility expert as to whether this
would help or not.

Phil

Re: Turning off colorization

[Ted Zlatanov]

On Wed, 05 Nov 2014 11:52:04 +0000 phillip.lord@newcastle.ac.uk (Phillip Lord) wrote: 

PL> Ted Zlatanov <tzz@lifelogs.com> writes:

>> So maybe Emacs could offer a way to turn off colors without turning off
>> syntax highlighting, at least in SHR. I think it would be generally
>> useful, but don't know if and how it could work generally.

PL> This would be a matter of picking a different "colour" scheme surely?
PL> One with no colours, but using the other elements that you talk about.
PL> I have a high-vis colour scheme (white background rather than my usual
PL> dark) which I use on my laptop on a sunny day, for instance.

PL> Then a command line option to choose it, to avoid the bootstrap problem
PL> of not being able to see emacs properly to choose the option.

I think that's reasonable, and Tassilo agrees...

PL> Of course, you'd need to ask an accessibility expert as to whether this
PL> would help or not.

I think it's clear that it would help Emacs users, but opinions welcome...

On Wed, 05 Nov 2014 12:51:56 +0100 Tassilo Horn <tsdh@gnu.org> wrote: 

TH> Wouldn't it suffice to provide a `no-colors' theme that sets up the
TH> standard font-lock faces so that they don't use colors but only bold
TH> fonts, italics, underline, etc?

TH> Probably, that wouldn't suffice because redefining each and every face
TH> defined by some package isn't feasible.  But maybe that "theme" could
TH> also advise `defface' and friends and strip color attributes from
TH> face-specs.

I'd be OK with this, but don't know if it's enough or easy.

Ted

Re: Turning off colorization

[Phillip Lord]

Ted Zlatanov <tzz@lifelogs.com> writes:
> PL> Of course, you'd need to ask an accessibility expert as to whether this
> PL> would help or not.
>
> I think it's clear that it would help Emacs users, but opinions welcome...


Well, we'd need to ask someone who knows something about visual
disability (I am assuming that you don't, apologies if this is
incorrect). There are a number of ways of being visually disabled, and
they do not all have the same requirements. Someone with no vision at
all is unlikely to bothered by colours, one way or another, for
instance.

My point is that it's easy to think that you understand what a person
with disability needs, but better to ask.

Phil

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So maybe Emacs could offer a way to turn off colors without turning off
> syntax highlighting, at least in SHR. I think it would be generally
> useful, but don't know if and how it could work generally.

Yeah.  It seems like whenever somebody asks for stuff in this area, it's
always "make all those colours go away", not "make syntax highlighting
stop".  For instance, I would assume that people would still want links
in eww to be underlined even if nothing colourful happens.

So perhaps Emacs just needs another general setting here?  `color-mode'
(or something).  If that (buffer-local) variable is nil, redisplay would
simply ignore all foreground/background colour specs.

This isn't really about syntax highlighting, but about how some people
prefer monochrome buffers, I think.

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

Re: Turning off colorization

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> So perhaps Emacs just needs another general setting here?  `color-mode'
> (or something).  If that (buffer-local) variable is nil, redisplay would
> simply ignore all foreground/background colour specs.

It should be just a matter of making display-color-p return nil.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

> It should be just a matter of making display-color-p return nil.

I tried

(defun display-color-p (&optional display) nil)

and things got less colourful, but putting a `face "red"' on a region
still made the region red.

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

Re: Turning off colorization

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 05 Nov 2014 18:06:56 +0100
> Cc: emacs-devel@gnu.org
> 
> Andreas Schwab <schwab@suse.de> writes:
> 
> > It should be just a matter of making display-color-p return nil.
> 
> I tried
> 
> (defun display-color-p (&optional display) nil)
> 
> and things got less colourful, but putting a `face "red"' on a region
> still made the region red.

display-color-p is not a magic wand: it only causes defface's that
defined a setting for a non-color display to use that setting.  If you
yourself specify a color, there's no magic in Emacs to turn it to
something else.

IOW, if it hurts, don't do that.

Re: Turning off colorization

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> It should be just a matter of making display-color-p return nil.
>
> I tried
>
> (defun display-color-p (&optional display) nil)
>
> and things got less colourful, but putting a `face "red"' on a region
> still made the region red.

Of course, you get what you asked for.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

>> I tried
>>
>> (defun display-color-p (&optional display) nil)
>>
>> and things got less colourful, but putting a `face "red"' on a region
>> still made the region red.
>
> Of course, you get what you asked for.

What I asked for was:

> So perhaps Emacs just needs another general setting here?  `color-mode'
> (or something).  If that (buffer-local) variable is nil, redisplay would
> simply ignore all foreground/background colour specs.

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

Re: Turning off colorization

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 05 Nov 2014 20:56:23 +0100
> Cc: emacs-devel@gnu.org
> 
> What I asked for was:
> 
> > So perhaps Emacs just needs another general setting here?  `color-mode'
> > (or something).  If that (buffer-local) variable is nil, redisplay would
> > simply ignore all foreground/background colour specs.

Patches are welcome to implement that.

Re: Turning off colorization

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> So maybe Emacs could offer a way to turn off colors without turning
>> off syntax highlighting, at least in SHR. I think it would be
>> generally useful, but don't know if and how it could work generally.
>
> Yeah.  It seems like whenever somebody asks for stuff in this area,
> it's always "make all those colours go away", not "make syntax
> highlighting stop".  For instance, I would assume that people would
> still want links in eww to be underlined even if nothing colourful
> happens.
>
> So perhaps Emacs just needs another general setting here?
> `color-mode' (or something).  If that (buffer-local) variable is nil,
> redisplay would simply ignore all foreground/background colour specs.

The problem is that standard emacs faces seem to use only colors to
disambiguate stuff.  E.g., I've just visited an elisp file with emacs -Q
and keywords, functions, strings, and comments are displayed with the
very same font and attributes except for different foreground colors.
So simply stripping color specs would be equivalent to disabling
font-lock-mode altogether at least for elisp mode.

That's why I've suggested we might want to have a `no-colors' theme, a
`red-green-blind' theme that either use no colors but other face
attributes, or only a restricted set of colors, respectively.  Well, and
somehow those themes would need to adjust new faces as they appear,
e.g., when a third-party package is loaded, too.

Bye,
Tassilo

Re: Turning off colorization

[Yoni Rabkin]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> So maybe Emacs could offer a way to turn off colors without turning off
>> syntax highlighting, at least in SHR. I think it would be generally
>> useful, but don't know if and how it could work generally.
>
> Yeah.  It seems like whenever somebody asks for stuff in this area, it's
> always "make all those colours go away", not "make syntax highlighting
> stop".  For instance, I would assume that people would still want links
> in eww to be underlined even if nothing colourful happens.
>
> So perhaps Emacs just needs another general setting here?  `color-mode'
> (or something).  If that (buffer-local) variable is nil, redisplay would
> simply ignore all foreground/background colour specs.
>
> This isn't really about syntax highlighting, but about how some people
> prefer monochrome buffers, I think.

That is a very good description of my personal needs. I even understand
the physics of what's wrong (with me) but I can't speak to how many
other people may or may not have this issue. So I can't say if we are
solving a bigger problem or just making a big deal about my weird
problem.

I've set up Emacs to work for me and I'd like to be able to say to Eww:
"please leave my background and foreground choices alone for text that
wouldn't otherwise be decorated in any way"

The shr-inhibit-coloration patch does exactly that, but I understand
that there is some discussion as to how classify this type of change.

As Wolfgang pointed out, font-lock isn't it since I still want
font-locking.

-- 
   "Cut your own wood and it will warm you twice"

Re: Turning off colorization

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Yeah.  It seems like whenever somebody asks for stuff in this area, it's
LMI> always "make all those colours go away", not "make syntax highlighting
LMI> stop".  For instance, I would assume that people would still want links
LMI> in eww to be underlined even if nothing colourful happens.

It is not just no colours, but more like:  leave the background alone and
ensure whatever colours are used are readable on that background.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

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

There are many different forms of highlighting that some users might
prefer.  General customization facilities are the way to cater to all
those preferences.

However, anyone may need to turn off highlighting for a particular
file because (1) font lock is too slow for it or (2) too much text is
in a dark color and hard to see.

Thus, I suggest we give M-x font-lock-mode some obvious aliases,
and put a switch for it into the Options menu.

Stefan wrote:

  > syntax-highlight-mode sounds like a very good alias for
  > global-font-lock-mode.  I'd welcome a patch which takes care of that.

That's not what we need.

The global setting is a default.  Once you specify the defaults you
want, you will probably never change that setting again.  What we
need, for the default, is to make it easy to specify the settings
permanently (in .emacs).

However, you will need to turn off highlighting occasionally
in a particular buffer because of specific problems.

We should make obvious ways to toggle it in the current buffer.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[James Cloos]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> Thus, I suggest we give M-x font-lock-mode some obvious aliases,
RS> and put a switch for it into the Options menu.

That certainly is reasonable, not matter whether any additional changes
are made.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

[David Kastrup]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:
>
> RS> Thus, I suggest we give M-x font-lock-mode some obvious aliases,
> RS> and put a switch for it into the Options menu.
>
> That certainly is reasonable, not matter whether any additional changes
> are made.

You mean, like reverting

    Author: Dan Nicolaescu <dann@ics.uci.edu>
    Date:   Mon Nov 14 08:03:59 2005 +0000

        (menu-bar-options-menu): Delete "Syntax
        Highlighting" entry, it is on by default now.

I have to admit that one to be puzzling to me.  Why would one remove an
option from the menus because its default has changed?

-- 
David Kastrup

Re: Turning off colorization

[Stefan Monnier]

> I have to admit that one to be puzzling to me.  Why would one remove an
> option from the menus because its default has changed?

The reason why we added it to the menu is because "everyone" wanted to
enable it, so we wanted to make it as easy as possible.
OTOH I find it is rather rare for people to want to disable
font-lock-mode (or jit-lock-mode for that matter).

To the point that it has crossed my mind a few times that maybe
a redesign of the code is in order: get rid of the font-lock-mode minor
mode, set fontification-functions globally (i.e. enable jit-lock in all
buffers) and have it call font-lock-set-defaults.


        Stefan

Re: Turning off colorization

[Alan Mackenzie]

Hello, Stefan.

On Thu, Nov 06, 2014 at 10:26:33AM -0500, Stefan Monnier wrote:
> > I have to admit that one to be puzzling to me.  Why would one remove an
> > option from the menus because its default has changed?

> The reason why we added it to the menu is because "everyone" wanted to
> enable it, so we wanted to make it as easy as possible.
> OTOH I find it is rather rare for people to want to disable
> font-lock-mode (or jit-lock-mode for that matter).

It's not that rare for me.  I do it to make it less difficult to
diagnose bugs in font-locking.  Disabling font-lock-mode and setting
font-lock-support-mode to nil is a normal thing to do.

> To the point that it has crossed my mind a few times that maybe
> a redesign of the code is in order: get rid of the font-lock-mode minor
> mode, set fontification-functions globally (i.e. enable jit-lock in all
> buffers) and have it call font-lock-set-defaults.

You're trolling, right?  ;-)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Turning off colorization

[Stefan Monnier]

> It's not that rare for me.  I do it to make it less difficult to
> diagnose bugs in font-locking.  Disabling font-lock-mode and setting
> font-lock-support-mode to nil is a normal thing to do.

Of course, for development purposes it's handy.  But the same
functionality could be offered some other way.

>> To the point that it has crossed my mind a few times that maybe
>> a redesign of the code is in order: get rid of the font-lock-mode minor
>> mode, set fontification-functions globally (i.e. enable jit-lock in all
>> buffers) and have it call font-lock-set-defaults.
> You're trolling, right?  ;-)

No.  The only reason this hasn't happened yet is because it's
low priority.


        Stefan

Re: Turning off colorization

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

  > >> To the point that it has crossed my mind a few times that maybe
  > >> a redesign of the code is in order: get rid of the font-lock-mode minor
  > >> mode, set fontification-functions globally (i.e. enable jit-lock in all
  > >> buffers) and have it call font-lock-set-defaults.

Would that make it impossible to turn off font lock mode in a single
buffer?  I would have to turn it off in all buffers in order to get it
off in one?

That would be very bad.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Stefan Monnier]

> Would that make it impossible to turn off font lock mode in a single
> buffer?

No.  It would only affect efficiency (i.e. optimize for the case where
all displayed buffers are font-locked), and of course it would subtly
change some ordering of initialization code.


        Stefan

Re: Turning off colorization

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

  > > Would that make it impossible to turn off font lock mode in a single
  > > buffer?

  > No.  It would only affect efficiency

Would it still work to type M-x font-lock-mode to disable font lock
in the current buffer?  If not, what would one have to do?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Stefan Monnier]

>> No.  It would only affect efficiency
> Would it still work to type M-x font-lock-mode to disable font lock
> in the current buffer?  If not, what would one have to do?

I can't think of any obvious reason why we couldn't keep using M-x
font-lock-mode for that, but  I haven't thought nearly enough about it
to be able to tell you.  Can we stop this hypothetical discussion?



        Stefan

Re: Turning off colorization

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

  > I can't think of any obvious reason why we couldn't keep using M-x
  > font-lock-mode for that, but  I haven't thought nearly enough about it
  > to be able to tell you.

The reason I keep talking about it is that I keep seeing proposals
that sound like they would change this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

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

  > OTOH I find it is rather rare for people to want to disable
  > font-lock-mode (or jit-lock-mode for that matter).

I turn it off for a small fraction of buffers, but when it's
needed, it's absolutely necessary.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Stefan Monnier]

DK> Toggle syntax highlighting in this buffer (Font Lock mode).

syntax-highlight-mode sounds like a very good alias for
global-font-lock-mode.  I'd welcome a patch which takes care of that.

I don't think it's terribly important, tho, since most users don't
really need to know how it's called since it's enabled by default.

> Some color-blind or visually impaired people may want syntax
> highlighting but not colorization.

Indeed.  IIRC, in the past, there was some kind of option in font-lock
to choose between "use fonts -vs- use colors".

> So maybe Emacs could offer a way to turn off colors without turning off
> syntax highlighting, at least in SHR.  I think it would be generally
> useful, but don't know if and how it could work generally.

That would be great, indeed.  Someone posted a patch last year or so,
that made it possible to tweak in Elisp the computation of faces (IIRC
it was around the discussion of the fallback-background color, to try
and dynamically compute the background face to use for the region, so
that it's always visible).  Maybe it could work that way.


        Stefan

Re: Turning off colorization

[N. Jackson]

At 11:02 -0400 on Wednesday 2014-11-05, Stefan Monnier wrote:

> Someone posted a patch last year or so, that made it possible to tweak
> in Elisp the computation of faces (IIRC it was around the discussion
> of the fallback-background color, to try and dynamically compute the
> background face to use for the region, so that it's always visible).

Perhaps you are thinking of this message by Daniel Colascione?:

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01272.html

Unfortunately, this very promising approach (which it seems would
minimise the need for turning off "colourisation" in buffers just to be
able to see the text) seemed to get derailed by bickering over defaults.

Regards,
N. Jackson

Re: Turning off colorization

[Tim Cross]

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

I'm always amazed at how a group of smart people can too often over
complicate a question. This thread started with s relatively simple
usability question on whether font-lock was a good term wrt font colours.
We have then strayed off into related questions, but away from the original
question.

I agree font-lock is not a very intuitive name and could be improved. My
view is in line with David K's points. While syntax-highlighting may not be
100% accurate, it is a common term used to refer to different text being
displayed in different colours. I also prefer it over 'colorize' as it
avoids the issues associated with different spelling. Syntax is also a term
likely to be familiar with a majority of users - emacs is after all
primarily used by those involved in programming at some level.

The other points relating to vision impairments, colour blindness etc are
also interesting, but a side issue. As someone who has used emacs for
nearly 20 years and who has a sight impairment which requires tweaking of
colours, I can say things have improved immensely. Originally, I use to
spend hours defining an elisp file to customize all the faces and adding
new packages with their own face definitions was often a source of
frustration as you would need to then modify your setup. However, the
introduction of thems has made this a lot simpler. We do need to encourage
package writers to use default values derived from the standard set of
faces i.e. use inheritance rather than simply defining new faces with their
own colour settings as this will improve how themes work and often gives a
better result as too often, individual packages will not use the full
configuration i.e. don't define defaults for monochrome, tty etc.

There are already themes defined which will set colours that are typically
better for red-green colour blind and even monochrome themes for those who
prefer no colours. I think this is a good approach. The range of vision
impairments and individual requirements is far too broad for us to ever
hope to cater for everyone. Providing some basic themes which can then be
tweaked to suit individual tastes/needs is the way to go.

The critical requirement is to make it easy for people to find out how to
customize things. This means getting the names right, which is a really
hard thing to do. I would suggest adding both syntax-highlighting and
colorize-mode seem to be reasonable starting points to address this issue.
It would also be worthwhile ensuring the manual covers this and includes
links to the customize-theme stuff as experience has taught me you are much
better off starting with a theme close to your requirements and then
tweaking it than going through the tedious task of listing all the faces
and tweaking them individually.

Tim


On 7 November 2014 07:13, N. Jackson <nljlistbox2@gmail.com> wrote:

> At 11:02 -0400 on Wednesday 2014-11-05, Stefan Monnier wrote:
>
> > Someone posted a patch last year or so, that made it possible to tweak
> > in Elisp the computation of faces (IIRC it was around the discussion
> > of the fallback-background color, to try and dynamically compute the
> > background face to use for the region, so that it's always visible).
>
> Perhaps you are thinking of this message by Daniel Colascione?:
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01272.html
>
> Unfortunately, this very promising approach (which it seems would
> minimise the need for turning off "colourisation" in buffers just to be
> able to see the text) seemed to get derailed by bickering over defaults.
>
> Regards,
> N. Jackson
>
>
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 4468 bytes --]

Re: Turning off colorization

[Stefan Monnier]

>> Someone posted a patch last year or so, that made it possible to tweak
>> in Elisp the computation of faces (IIRC it was around the discussion
>> of the fallback-background color, to try and dynamically compute the
>> background face to use for the region, so that it's always visible).
> Perhaps you are thinking of this message by Daniel Colascione?:
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01272.html

Indeed.

> Unfortunately, this very promising approach (which it seems would
> minimise the need for turning off "colourisation" in buffers just to be
> able to see the text) seemed to get derailed by bickering over defaults.

The discussion was about what to do for the 24.4 release, and it wasn't
a good time to make such fundamental changes.

Now would be a good time to add such functionality.


        Stefan

Re: Turning off colorization

[Daniel Colascione]

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

On 11/06/2014 11:14 PM, Stefan Monnier wrote:
>>> Someone posted a patch last year or so, that made it possible to tweak
>>> in Elisp the computation of faces (IIRC it was around the discussion
>>> of the fallback-background color, to try and dynamically compute the
>>> background face to use for the region, so that it's always visible).
>> Perhaps you are thinking of this message by Daniel Colascione?:
>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01272.html
> 
> Indeed.
> 
>> Unfortunately, this very promising approach (which it seems would
>> minimise the need for turning off "colourisation" in buffers just to be
>> able to see the text) seemed to get derailed by bickering over defaults.
> 
> The discussion was about what to do for the 24.4 release, and it wasn't
> a good time to make such fundamental changes.
> 
> Now would be a good time to add such functionality.

Any serious objection to merging the patch in a form close to what's in
that message?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Turning off colorization

[Stefan Monnier]

> Any serious objection to merging the patch in a form close to what's in
> that message?

IIUC that patch made it possible to compute the colors only, right?
I'd like it to be able to compute any attribute dynamically.


        Stefan

Re: Turning off colorization

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

  > Syntax highlighting is an established term for this.

"Colorize" is the most obvious term for this, to a user
who doesn't know the established term.

So let's define both colorize-mode and syntax-highlight-mode.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:
>   > > M-x font-lock-mode will turn off colorization, but it's not a name
>   > > that will come to a user's mind very easily.  How about making
>   > > colorize-mode an alias for font-lock-mode?
>   > >
>   > > Also, how about putting it in the Options menu?
>
>   > Why not "syntax-highlight-mode"?
>
> There's nothing wrong with that name,
> but it's not what a user will think of.
> What the mode normally does is put the text in color.
> A user will think of typing M-x color TAB
> to look for a name.
>
> So I think it should have the name colorize-mode.
>
> If it also has the name syntax-highlight-mode, that is fine too.


Having both would be okay, although I think everyone will look for
syntax-highlight. It is what the Emacs FAQ calls it for instance.

http://www.gnu.org/software/emacs/manual/html_node/efaq/Turning-on-syntax-highlighting.html

But any name other than font-lock which is cryptic in the extreme.

Phil

Re: Turning off colorization

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> M-x font-lock-mode will turn off colorization, but it's not a name
> that will come to a user's mind very easily.  How about making
> colorize-mode an alias for font-lock-mode?
>
> Also, how about putting it in the Options menu?

I wish it was called colorization-mode instead of font-lock. I think
font-lock is a more and more confusing name.


Nic

Re: Turning off colorization

[Kelvin White]

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

> I wish it was called colorization-mode instead of font-lock. I think
> font-lock is a more and more confusing name.

I agree, I've often wondered what was the idea behind that name, just makes
no sense to me... Unless I'm missing something here

[-- Attachment #2: Type: text/html, Size: 298 bytes --]

Re: Turning off colorization

[Stephen J. Turnbull]

Kelvin White writes:
 > > I wish it was called colorization-mode instead of font-lock. I think
 > > font-lock is a more and more confusing name.
 > 
 > I agree, I've often wondered what was the idea behind that name,
 > just makes no sense to me... Unless I'm missing something here

Are you too young to have read a computer science textbook on paper?

Originally the idea was black and white presentation (colored pixels
were too fat for high density text) using fonts and faces to express
what today we use color to express.

Re: Turning off colorization

[Harald Hanche-Olsen]

["Stephen J. Turnbull" <stephen@xemacs.org> (2014-11-05 02:10:57 UTC)]

> Kelvin White writes:
>  > > I wish it was called colorization-mode instead of font-lock. I think
>  > > font-lock is a more and more confusing name.
>  > 
>  > I agree, I've often wondered what was the idea behind that name,
>  > just makes no sense to me... Unless I'm missing something here
> 
> Are you too young to have read a computer science textbook on paper?

Perhaps it was the “lock” part of the name he found confusing. It is
to me, anyhow. I suppose it stems from some implementation detail, but
what it is doing in the name of the mode, beats me.

– Harald

Re: Turning off colorization

[N. Jackson]

At 12:43 -0400 on Tuesday 2014-11-04, Richard Stallman wrote:

> M-x font-lock-mode will turn off colorization, but it's not a name
> that will come to a user's mind very easily. How about making
> colorize-mode an alias for font-lock-mode?
>
> Also, how about putting it in the Options menu?

I would be all for an easy/quick way to toggle "colourisation" on those
occasions when my buffer text is unreadable, but I find that toggling
off font-lock-mode does not help (on Emacs 24.4).

It's very rare to get buffer text that's unreadable[1], except when
reading HTML mail in Gnus[2] where I very frequently get presented with
a medium grey text on a medium grey background or a very dark text on my
normal black background. To see the text, I have come up with three
strategies, all of them annoying:

1. Turn my display brightness all the way up. (This will allow me make
out a few words if the ambient light is dim.)

2. Select the text so that it is "highlighted".

3. Use <menu-bar> <commands> <Washing> <Quoted-Printable>
(gnus-article-de-quoted-unreadable) to display normal white text on a
normal black background.

After reading this thread, today I tried toggling off font-lock-mode
(and global-font-lock-mode) in an unreadable HTML mail buffer to see if
that provides a better solution. However it seems to have no effect
whatsoever on how the buffer is displayed. So providing a more
intuitive alias for it, or putting it on the menus, would not be helpful
(at least in my case).

It would be very nice to have the option of turning on an auto-contrast
function that would automatically adjust foreground or background colour
whenever they are too similar, along with a way for the user to specify
how similar is too similar. This would minimise (or eliminate) the need
to turn off colourisation due to unreadable text.

Regards,
N. Jackson


[1] I use the "wheatgrass" colour theme (not for any particular merits on
its part, but simply because, when I iterated through the built-in
colour themes after installing Emacs 24, it was the first one that
seemed to have things about right).

[2] Gnus v5.13

Re: Turning off colorization

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Thu, 06 Nov 2014 12:47:14 -0400
> 
> After reading this thread, today I tried toggling off font-lock-mode
> (and global-font-lock-mode) in an unreadable HTML mail buffer to see if
> that provides a better solution. However it seems to have no effect
> whatsoever on how the buffer is displayed.

I'm quite sure HTML colors are not handled by font-lock.  They are
probably handled by putting explicit color faces on chunks of text,
under control of the HTML tags/CSS.

Go to one of the colored places and type

  M-x describe-text-properties RET

If you don't see "fontified    t" among the properties, you are not up
against font-lock.

> So providing a more intuitive alias for it, or putting it on the
> menus, would not be helpful (at least in my case).

I don't think it will help, see above.

Re: Turning off colorization

[N. Jackson]

At 13:36 -0400 on Thursday 2014-11-06, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Thu, 06 Nov 2014 12:47:14 -0400
>> 
>> After reading this thread, today I tried toggling off font-lock-mode
>> (and global-font-lock-mode) in an unreadable HTML mail buffer to see if
>> that provides a better solution. However it seems to have no effect
>> whatsoever on how the buffer is displayed.
>
> I'm quite sure HTML colors are not handled by font-lock.  They are
> probably handled by putting explicit color faces on chunks of text,
> under control of the HTML tags/CSS.
>
> Go to one of the colored places and type
>
>   M-x describe-text-properties RET
>
> If you don't see "fontified    t" among the properties, you are not up
> against font-lock.

Indeed.

>> So providing a more intuitive alias for it, or putting it on the
>> menus, would not be helpful (at least in my case).
>
> I don't think it will help, see above.

Yes. That's what I was trying to say.

What I was also trying to say, and failed to say explicitly, is that
adding, for the benefit of the naive user (me in this case), a function
to toggle "colourisation" (IIRC color-mode was proposed) will not work
if it is just an alias for font-lock-mode.

Regards,
N. Jackson

Re: Turning off colorization

[Wolfgang Jenkner]

On Thu, Nov 06 2014, N. Jackson wrote:

> It's very rare to get buffer text that's unreadable[1], except when
> reading HTML mail in Gnus[2] where I very frequently get presented
> with a medium grey text on a medium grey background or a very dark
> text on my normal black background.

If you are satisfied with an ad hoc solution for this problem the
following snippet (eval'ed with M-: in the article buffer) should work
with a graphical version of emacs (at least with the built-in html
renderer, viz. shr.el).  You can then go back to the colourized version
by simply redisplaying the article (`g' in the summary or article
buffer).

(let ((fg (face-foreground 'default))
      (bg (face-background 'default)))
  (with-silent-modifications
    (font-lock-prepend-text-property (point-min) (point-max)
				     'face `(:foreground ,fg :background ,bg))))

Re: Turning off colorization

[N. Jackson]

At 14:00 -0400 on Thursday 2014-11-06, Wolfgang Jenkner wrote:

> On Thu, Nov 06 2014, N. Jackson wrote:
>
>> It's very rare to get buffer text that's unreadable[1], except when
>> reading HTML mail in Gnus[2] where I very frequently get presented
>> with a medium grey text on a medium grey background or a very dark
>> text on my normal black background.
>
> If you are satisfied with an ad hoc solution for this problem the
> following snippet (eval'ed with M-: in the article buffer) should work
> with a graphical version of emacs (at least with the built-in html
> renderer, viz. shr.el).  You can then go back to the colourized version
> by simply redisplaying the article (`g' in the summary or article
> buffer).
>
> (let ((fg (face-foreground 'default))
>       (bg (face-background 'default)))
>   (with-silent-modifications
>     (font-lock-prepend-text-property (point-min) (point-max)
> 				     'face `(:foreground ,fg :background ,bg))))

Thanks Wolfgang,

That works well. It's much better than my existing workarounds. I'll
need to get it working on the right buffer and get it bound to a key
combination, and then it will serve until a real solution emerges.

Regards,
N. Jackson

Re: Turning off colorization

[Tassilo Horn]

nljlistbox2@gmail.com (N. Jackson) writes:

> It's very rare to get buffer text that's unreadable[1], except when
> reading HTML mail in Gnus[2] where I very frequently get presented
> with a medium grey text on a medium grey background or a very dark
> text on my normal black background.

If you use shr as `mm-text-html-renderer' which is the default, then
HTML colors should be auto-adjusted so that they stay readable.  If you
still get "light-X" foreground on "a-little-less-X" background, you can
try increasing the minimum color distances used.  For example, I use

  (setq shr-color-visible-distance-min 10
        shr-color-visible-luminance-min 60)

to have a bit more contrast.

Bye,
Tassilo

Re: Turning off colorization

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 06 Nov 2014 20:44:24 +0100
> Cc: emacs-devel@gnu.org
> 
> If you use shr as `mm-text-html-renderer' which is the default, then
> HTML colors should be auto-adjusted so that they stay readable.  If you
> still get "light-X" foreground on "a-little-less-X" background, you can
> try increasing the minimum color distances used.  For example, I use
> 
>   (setq shr-color-visible-distance-min 10
>         shr-color-visible-luminance-min 60)
> 
> to have a bit more contrast.

It's a pity this isn't documented in any of our manuals.

Re: Turning off colorization

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you use shr as `mm-text-html-renderer' which is the default, then
>> HTML colors should be auto-adjusted so that they stay readable.  If you
>> still get "light-X" foreground on "a-little-less-X" background, you can
>> try increasing the minimum color distances used.  For example, I use
>> 
>>   (setq shr-color-visible-distance-min 10
>>         shr-color-visible-luminance-min 60)
>> 
>> to have a bit more contrast.
>
> It's a pity this isn't documented in any of our manuals.

Yes, I think this question has indeed popped up a few times already.
I've just looked into the Gnus manual, and I guess it would fit well in
section (info "(gnus)HTML").

I'll go give it a try to update that section...

Bye,
Tassilo

Re: Turning off colorization

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: nljlistbox2@gmail.com,  emacs-devel@gnu.org, ding@gnus.org
> Date: Fri, 07 Nov 2014 07:36:02 +0100
> 
> >>   (setq shr-color-visible-distance-min 10
> >>         shr-color-visible-luminance-min 60)
> >> 
> >> to have a bit more contrast.
> >
> > It's a pity this isn't documented in any of our manuals.
> 
> Yes, I think this question has indeed popped up a few times already.
> I've just looked into the Gnus manual, and I guess it would fit well in
> section (info "(gnus)HTML").
> 
> I'll go give it a try to update that section...

Thank you.

It seems like most (all?) of shr documentation is in eww.texi, so
perhaps you should do it there instead.  In any case, please have a
cross-reference from the other manual to where this is described.

Re: Turning off colorization

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes, I think this question has indeed popped up a few times already.
>> I've just looked into the Gnus manual, and I guess it would fit well in
>> section (info "(gnus)HTML").
>> 
>> I'll go give it a try to update that section...
>
> Thank you.
>
> It seems like most (all?) of shr documentation is in eww.texi, so
> perhaps you should do it there instead.

I think the HTML article section is the place users will have a look
first, and that was outdated anyway.  So now it mentions shr, and
there's a footnote that points to a new Gnus FAQ entry 4.16:

--8<---------------cut here---------------start------------->8---
Question 4.16
.............

How can I ensure more contrast when viewing HTML mail?

Answer
......

Gnus’ built-in simple HTML renderer (you use it if the value of
‘mm-text-html-renderer’ is ‘shr’) uses the colors which are declared in
the HTML mail.  However, it adjusts them in order to prevent situations
like dark gray text on black background.  In case the results still have
a too low contrast for you, increase the values of the variables
‘shr-color-visible-distance-min’ and ‘shr-color-visible-luminance-min’.
--8<---------------cut here---------------end--------------->8---

But yes, I think the two variables should be documented in eww.texi,
too.  I've just done that.

> In any case, please have a cross-reference from the other manual to
> where this is described.

Ok, that's now also in place (Gnus -> EWW).

Bye,
Tassilo

Re: Turning off colorization

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: nljlistbox2@gmail.com,  emacs-devel@gnu.org,  ding@gnus.org
> Date: Fri, 07 Nov 2014 08:59:05 +0100
> 
> But yes, I think the two variables should be documented in eww.texi,
> too.  I've just done that.
> 
> > In any case, please have a cross-reference from the other manual to
> > where this is described.
> 
> Ok, that's now also in place (Gnus -> EWW).

Thanks.  I back-ported that to the emacs-24 branch, and also fixed a
typo.

(In general, any improvements in the documentation of features that
exist on the branch should be committed to the branch.)

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> It's very rare to get buffer text that's unreadable[1], except when
> reading HTML mail in Gnus[2] where I very frequently get presented with
> a medium grey text on a medium grey background or a very dark text on my
> normal black background. 

Do you have an example HTML file that does this?

`shr-color' is supposed to ensure that the distance between all colours
are sufficient to allow people to read the text, and this sounds like
the luminance or the distance is (by default) too low.

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

Re: Turning off colorization

[James Cloos]

>>>>> "NJ" == N Jackson <nljlistbox2@gmail.com> writes:

NJ> It's very rare to get buffer text that's unreadable[1],

There are some easy ways to get to that.

Emacs in screen backed by a dark-on-light rxvt-unicode terminal,
where TERM is screen-256color, is always unreadable.

I'm sure there are other combinations.

Gnus biggest colour problem is horible html backgrounds (backgrounds
which, incidently, do not show up in dedicated browsers).  That is even
worse than the light text on white one gets inside screen.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

[Gregor Zattler]

Hi James, emacs developers,
* James Cloos <cloos@jhcloos.com> [06. Nov. 2014]:
>>>>>> "NJ" == N Jackson <nljlistbox2@gmail.com> writes:
> 
> NJ> It's very rare to get buffer text that's unreadable[1],
> 
> There are some easy ways to get to that.
> 
> Emacs in screen backed by a dark-on-light rxvt-unicode terminal,
> where TERM is screen-256color, is always unreadable.

This is also my setup (I played with
shr-color-visible-distance-min and shr-color-visible-luminance
but this changed nothing).

For the record this is also true without screen.  Try eww on
http://lwn.net/Articles in emacs on black rxvt-unicode: White
background, bright blue (or something) letters.  Quite
unreadable.

Ciao; Gregor

Re: Turning off colorization

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 14:57:21 +0100
> From: Gregor Zattler <telegraph@gmx.net>
> 
> Try eww on http://lwn.net/Articles in emacs on black rxvt-unicode:
> White background, bright blue (or something) letters.  Quite
> unreadable.

FWIW, I just tried that, and I cannot support the "quite unreadable"
claim.  I have no problem reading it, and it doesn't even annoy.

Of course, all this is highly personal.

Re: Turning off colorization

[Gregor Zattler]

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

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [07. Nov. 2014]:
>> Date: Fri, 7 Nov 2014 14:57:21 +0100
>> From: Gregor Zattler <telegraph@gmx.net>
>> 
>> Try eww on http://lwn.net/Articles in emacs on black rxvt-unicode:
>> White background, bright blue (or something) letters.  Quite
>> unreadable.
> 
> FWIW, I just tried that, and I cannot support the "quite unreadable"
> claim.  I have no problem reading it, and it doesn't even annoy.

This astonishes me because in the described setup the background
is bright white, links are barely readable bright blue or bright
turquoise while normal text is invisible (=bright white).

What I did:
- rename ~/.Xdefaults
- restart X
- urxvt -bg black -fg white -e emacs-snapshot -Q -nw
- eww lwn.net/Articles
  (looks as described)
- configure the two shr-color-visible-  variables
- kill eww
- eww lwn.net/Articles
  (looks the same as before).

I did the same with xterm and there the site is displayed "quite
unreadable" (background is some kind of grey, the text is white
the links in some kind of bright blue...), but customization also
does not matter.

> Of course, all this is highly personal.

In the case of what I see in the case of the urxvt I would
dispute "personal".  A attach two screen shots, they weigh 64
KiBi in sum, don't know if the mailing list supports this


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

[-- Attachment #2: almost-unreadable-eww-buffer-lwn-shr-configured-black-xterm.png --]
[-- Type: image/png, Size: 40561 bytes --]

[-- Attachment #3: unreadable-eww-buffer-lwn-shr-configured-black-urxvt.png --]
[-- Type: image/png, Size: 21051 bytes --]

Re: Turning off colorization

[Eli Zaretskii]

> Date: Fri, 7 Nov 2014 15:47:07 +0100
> From: Gregor Zattler <telegraph@gmx.net>
> 
> > FWIW, I just tried that, and I cannot support the "quite unreadable"
> > claim.  I have no problem reading it, and it doesn't even annoy.
> 
> This astonishes me because in the described setup the background
> is bright white, links are barely readable bright blue or bright
> turquoise while normal text is invisible (=bright white).

The way an X-based terminal emulator converts color specifications to
X colors is not 100% deterministic, and depends both on your X setup
and system-wide customizations.

> In the case of what I see in the case of the urxvt I would
> dispute "personal".  A attach two screen shots, they weigh 64
> KiBi in sum, don't know if the mailing list supports this

Your #909090 color (the background color) is too bright, AFAICS.  What
I see is significantly darker, which is why the text is readable in my
case.

I don't know enough about X colors to tell why the difference.

Re: Turning off colorization

[Gregor Zattler]

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [07. Nov. 2014]:
> The way an X-based terminal emulator converts color specifications to
> X colors is not 100% deterministic, and depends both on your X setup
> and system-wide customizations.
> 
[...]
> Your #909090 color (the background color) is too bright, AFAICS.  What
> I see is significantly darker, which is why the text is readable in my
> case.
> 
> I don't know enough about X colors to tell why the difference.

Thanks for looking into this.  

I found xgamma directives in my .xsession, but I removed them and
restarted X and it looks the same.

This is an up to date debian/testing system with no files in
/etc/X11/xorg.conf.d .  There is only configuration in
/etc/X11/xorg.conf regarding font paths and input devices.

Ciao, Gre--who-wonders-and-is-clueless--gor

Re: Turning off colorization

[James Cloos]

>>>>> "GZ" == Gregor Zattler <telegraph@gmx.net> writes:

GZ> For the record this is also true without screen.  Try eww on
GZ> http://lwn.net/Articles in emacs on black rxvt-unicode: White
GZ> background, bright blue (or something) letters.  Quite
GZ> unreadable.

In screen, using emacs24-nox from deb sid, and with TERM=screen-256color
I get the background changed to gray and cyan links.  In screen with
TERM=rxvt I get that same gray background but blue links.  OTOH, with
screen and TERM=rxvt-unicode I get my proper white background and blue
links.  Using TERM=rxvt-unicode-256color (the terminal's default TERM)
in screen gives the white background but light cyan links.  (In that
last case the *scratch* buffer's comments are light green on white, vs
red on white for TERM=rxvt-unicode.)  That is all on a box w/ a very
minimal ~/.emacs.

W/ or w/o screen, w/ TERM=rxvt-unicode-256color or screen-256color, on
my (Gentoo) workstation with emacs master, eww is OK.

When the background is gray, the <title> line is black on white; when
the background is white the <title> line is black on green or black on
mint green.

But even when eww on a web site, w/in gnus I still get crappy backgrounds
for most html email.  And it often takes forever for shr to render.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

RE: Turning off colorization

[Mirek Kaim]

> In screen, using emacs24-nox from deb sid, and with TERM=screen-256color
> I get the background changed to gray and cyan links. In screen with
> TERM=rxvt I get that same gray background but blue links. OTOH, with
> screen and TERM=rxvt-unicode I get my proper white background and blue
> links. Using TERM=rxvt-unicode-256color (the terminal's default TERM)
> in screen gives the white background but light cyan links. (In that
> last case the *scratch* buffer's comments are light green on white, vs
> red on white for TERM=rxvt-unicode.) That is all on a box w/ a very
> minimal ~/.emacs.

yeah. emacs24-nox under screen here (cygwin), screen-256color as well. mintty theme set to solarized, and that website under eww is basically unreadable.

imho, when the terminal reports 256 colors (or emacs runs in GUI mode), website rendering should use full available palette, not the base theme colors, because this clearly leads to a disaster, especially in case of other-than-default theme. that, or avoid trying to be 'fancy, full featured rainbow web browser' and just stick to default background per theme and use only those base theme colors for text that are guaranteed to be readable. this should be the default, imho, because when someone cares about all that fancy css stuff, he surely won't be using eww for a web browsing anyway.


unic0rn

 		 	   		  

Re: Turning off colorization

[Andreas Schwab]

Gregor Zattler <telegraph@gmx.net> writes:

> For the record this is also true without screen.  Try eww on
> http://lwn.net/Articles in emacs on black rxvt-unicode: White
> background, bright blue (or something) letters.  Quite
> unreadable.

FWIW, this is the standard link face.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Turning off colorization

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

  > I would be all for an easy/quick way to toggle "colourisation" on those
  > occasions when my buffer text is unreadable, but I find that toggling
  > off font-lock-mode does not help (on Emacs 24.4).

Why doesn't it help?  What's the problem?

  > It's very rare to get buffer text that's unreadable[1], except when
  > reading HTML mail in Gnus[2] where I very frequently get presented with
  > a medium grey text on a medium grey background or a very dark text on my
  > normal black background.

I find any fairly dark color for the text makes it unreadable when 
the ambient light level is high.  Very often I can read ordinary white text
and can't read blue or red text.

However, the worst problem I get with font-lock is when it takes a minute
to read my next command.

  > After reading this thread, today I tried toggling off font-lock-mode
  > (and global-font-lock-mode) in an unreadable HTML mail buffer to see if
  > that provides a better solution. However it seems to have no effect
  > whatsoever on how the buffer is displayed.

That seems like a bug.  Perhaps something is setting face properties
directly when it ought to be setting font-lock-face properties.

Can you find a test case and send a bug report?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Eli Zaretskii]

> Date: Fri, 07 Nov 2014 02:13:15 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>   > I would be all for an easy/quick way to toggle "colourisation" on those
>   > occasions when my buffer text is unreadable, but I find that toggling
>   > off font-lock-mode does not help (on Emacs 24.4).
> 
> Why doesn't it help?  What's the problem?

Not every face that defines a color is controlled by font-lock.

> That seems like a bug.  Perhaps something is setting face properties
> directly when it ought to be setting font-lock-face properties.

There's nothing wrong with that, we even have infrastructure for doing
so (facemenu.el).

Re: Turning off colorization

[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 seems like a bug.  Perhaps something is setting face properties
  > > directly when it ought to be setting font-lock-face properties.

  > There's nothing wrong with that, we even have infrastructure for doing
  > so (facemenu.el).

Manual specification, such as with facemenu, should go on the face property.
However, automatic font specification -- anything equivalent in spirit
to Font-Lock mode -- should set font-lock-face instead.

The purpose of this is so that M-x font-lock-mode will toggle whether
those faces actually appear in the display.

Thus, if html-mode sets the faces through `face', it should be fixed
to set `font-lock-face' instead.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Eli Zaretskii]

> Date: Sat, 08 Nov 2014 01:44:31 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: nljlistbox2@gmail.com, emacs-devel@gnu.org
> 
> Manual specification, such as with facemenu, should go on the face property.
> However, automatic font specification -- anything equivalent in spirit
> to Font-Lock mode -- should set font-lock-face instead.
> 
> The purpose of this is so that M-x font-lock-mode will toggle whether
> those faces actually appear in the display.
> 
> Thus, if html-mode sets the faces through `face', it should be fixed
> to set `font-lock-face' instead.

This is a misunderstanding: the discussion here is not about colors
set by html-mode based on some syntactic properties of HTML markup,
it's about colors set by an HTML renderer as specified by the HTML
page that Emacs is about to display.

Re: Turning off colorization

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

  > This is a misunderstanding: the discussion here is not about colors
  > set by html-mode based on some syntactic properties of HTML markup,
  > it's about colors set by an HTML renderer as specified by the HTML
  > page that Emacs is about to display.

Sorry for my misunderstanding, but I think it is the same sort of
issue; I think it would be handy, for users, if font-lock-mode
controls whether to display those colors or not.  It would give users
a simple way to turn off the colors if they want to, which won't
require any additional human memory.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[James Cloos]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> This is a misunderstanding: the discussion here is not about colors
EZ> set by html-mode based on some syntactic properties of HTML markup,
EZ> it's about colors set by an HTML renderer as specified by the HTML
EZ> page that Emacs is about to display.

That is not fully true either.  In many cases shr sets colours which
have nothing to do with the html or css involved.

That is the real bug.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

James Cloos <cloos@jhcloos.com> writes:

> That is not fully true either.  In many cases shr sets colours which
> have nothing to do with the html or css involved.
>
> That is the real bug.

If I understand correctly, this is an issue with Emacs running under a
terminal?

I think the real fix here is to make Emacs ignore all colour specs if
Emacs can't determine the background colour of the terminal.

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

Re: Turning off colorization

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> If I understand correctly, this is an issue with Emacs running under a
LMI> terminal?

Not only.  I also see it for some html mail in an athena frame.

LMI> I think the real fix here is to make Emacs ignore all colour specs if
LMI> Emacs can't determine the background colour of the terminal.

Some colour changes are OK, but the backgound should be untouched.

For example, xilinx.com's Product Design Advisories html mail is
rendered fine.  The colouring is minimal and legible.  The unusual
colour therein is due to html like:  <span style="color:#ec891d;">.

That orange colour works on both black and white.

At least for the headlines where it is used.

But a lot of mail includes background-color: specs, and that is best
ignored.  And perhaps when background-color is seen but ignored,
foreground colours also should be ignored?

So, I guess, a local style is generally preferred, but it is OK to
override short sections with whatever is in the mail.

I am not opposed to having to specify shr/eww's local style, whether via
a css stylesheet or via emacs face customizations.  Even though that
means extra work.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

[Lars Magne Ingebrigtsen]

James Cloos <cloos@jhcloos.com> writes:

> LMI> If I understand correctly, this is an issue with Emacs running under a
> LMI> terminal?
>
> Not only.  I also see it for some html mail in an athena frame.

I don't know what that is.

> Some colour changes are OK, but the backgound should be untouched.

HTML should be rendered in a clear manner that tries to adhere to the
HTML being presented.  Background colours sometimes have meaning -- like
blocks of text being presented with particular background colour to
convey a warning.

If you have an example HTML document that shr or eww renders in an
illegible manner under X, OS X or Windows, please file a bug report that
includes the example document.

But if it's about rendering text under a terminal, I think the best
general fix is to disable all colourisation unless Emacs can determine
what the background colour actually is.  This is a general problem that
has plagued Emacs' colour selection thing for yonks, but hasn't really
been addressed.

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

Re: Turning off colorization

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 09 Nov 2014 02:30:10 +0100
> 
> But if it's about rendering text under a terminal, I think the best
> general fix is to disable all colourisation unless Emacs can determine
> what the background colour actually is.

Not by default, please.  Give users an option to do that, but don't
unnecessarily rob them of colors, just because we have a few cases
where the result is problematic.

> This is a general problem that has plagued Emacs' colour selection
> thing for yonks, but hasn't really been addressed.

I'm not aware of such a problem, perhaps you should file a bug report
with specific examples.

RE: Turning off colorization

[Mirek Kaim]

> From: Lars Magne Ingebrigtsen
>
> But if it's about rendering text under a terminal, I think the best
> general fix is to disable all colourisation unless Emacs can determine
> what the background colour actually is. This is a general problem that
> has plagued Emacs' colour selection thing for yonks, but hasn't really
> been addressed.

i think it's best to use 'do we have at least 256-color support' instead. how do you want to determine what the background rgb values are? the name of the color doesn't mean anything, people use themes for terminals. when theme is reasonable, it may work, more or less (probably less), but if colors are totally different than their names suggest, it's all bound to be wrong. the only solution to that is using 256 colors and not giving a damn about the current theme at all, at least when the html rendering is supposed to stay as close to the original as possible.


unic0rn

 		 	   		  

Re: Turning off colorization

[Eli Zaretskii]

> From: Mirek Kaim <mirek.kaim@outlook.com>
> Date: Mon, 10 Nov 2014 16:29:11 +0100
> Cc: "nljlistbox2@gmail.com" <nljlistbox2@gmail.com>,
> 	Eli Zaretskii <eliz@gnu.org>, "rms@gnu.org" <rms@gnu.org>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> i think it's best to use 'do we have at least 256-color support' instead. how do you want to determine what the background rgb values are? the name of the color doesn't mean anything, people use themes for terminals. when theme is reasonable, it may work, more or less (probably less), but if colors are totally different than their names suggest, it's all bound to be wrong.

Please take a look at lisp/term/xterm.el: modern terminal emulators
report their background color as rgb:NUM1/NUM2/NUM3 rgb triplets.
This allows Emacs to interpret the color itself, not its name.

RE: Turning off colorization

[Mirek Kaim]

> From: eliz@gnu.org
>
> Please take a look at lisp/term/xterm.el: modern terminal emulators
> report their background color as rgb:NUM1/NUM2/NUM3 rgb triplets.
> This allows Emacs to interpret the color itself, not its name.
>

my mistake. i recall seeing a method to check if the background is being reported pasted here by someone, and it didn't return rgb triplet, just the color name afair.

still, i think using the full 256-color palette for things like html rendering under the terminal should be the way to go - and by that i mean that either things are being displayed using a user-defined terminal/emacs theme combo (discarding the colors defined by a website), or colors are properly handled - and then the background, if not defined, should be a default specific for a web browser, not the default background in emacs, because then it's bound to be wrong.

either it'll behave like a proper web browser, handling everything and having own default colors, or it'll have to discard all colors alltogether to guarantee readable results in every case. there's no perfect 'inbetween' solution, imho. one can't just mix up colors defined by some terminal and/or emacs theme with colors defined by a website, because then what - 'oh, this combination will be unreadable, lets change this color a bit so that the user won't complain'? i saw something along that line here not so long ago - ensuring that the page will stay readable. why bother? all that's needed is proper color handling, as good as possible on target display (wether it's rgb gui or 256-color terminal, doesn't matter).

it is website's author responsibility to make it readable. all that's needed is proper display of all the colors defined. in that regard, turning off colorization for terminals unable to report their background color is kinda pointless. all that matters is if 256 colors are supported - because if not, then there's no sure way to display a website in readable manner without discarding all rainbowy stuff. on the other side, if 256 colors are supported, then the current background shouldn't matter and in case of a website display, shouldn't be used at all.


unic0rn

 		 	   		  

Re: Turning off colorization

[Yuri Khan]

On Tue, Nov 11, 2014 at 12:37 AM, Mirek Kaim <mirek.kaim@outlook.com> wrote:

> it is website's author responsibility to make it readable. all that's needed is proper display of all the colors defined. in that regard, turning off colorization for terminals unable to report their background color is kinda pointless. all that matters is if 256 colors are supported - because if not, then there's no sure way to display a website in readable manner without discarding all rainbowy stuff. on the other side, if 256 colors are supported, then the current background shouldn't matter and in case of a website display, shouldn't be used at all.

You’re talking about 256 colors as if it were a whole lot.

In fact, 256 is a very limited color space. It includes 16 base
colors, a 6×6×6 color cube, and some 24 shades of gray. The color cube
is typically configured with rather light colors, suitable for use as
foreground on black (hex RGB value starting at 0x5f or something). As
a consequence, there are very few dark non-gray colors in the
256-color palette.

The Web authoring guides of the ’95s talked about “web-safe” colors.
It was assumed these colors could be displayed on any web-enabled
device. Those were defined as a color cube with a linear step of 0x33
for each RGB axis, also giving a 6×6×6 cube, but different from the
xterm defaults.

Web-safe cube: 00 33 66 99 CC FF
xterm cube:    00 5F 87 AF D7 FF

Let’s see how web-safe values are rounded to xterm values.

00 → 00 error 0
33 → 5F error +44 decimal
66 → 5F error -7, notice aliasing
99 → 87 error -18
CC → D7 error +11 notice gap
FF → FF error 0

So the web-safe palette, when approximated in xterm, becomes a 5×5×5
color cube, aliasing the two darker shades of each axis and skipping
the midrange AF value. If anybody uses the 33 and 66 colors as
distinct, well, they are not so distinct any more.


Nowadays, nobody bothers about web-safe colors any more. We have the
Tango palette, the Solarized palette, and a zillion other palettes,
none mapping well to the xterm space.


Instead of coming up with clever heuristics about color remapping, we
had better push for true color support in terminal emulators,
libraries and applications.

https://gist.github.com/XVilka/8346728

RE: Turning off colorization

[Mirek Kaim]

> From: yuri.v.khan@gmail.com
>
> You’re talking about 256 colors as if it were a whole lot.
>
> In fact, 256 is a very limited color space. It includes 16 base
> colors, a 6×6×6 color cube, and some 24 shades of gray. The color cube
> is typically configured with rather light colors, suitable for use as
> foreground on black (hex RGB value starting at 0x5f or something). As
> a consequence, there are very few dark non-gray colors in the
> 256-color palette.

it's what a lot of people have. there's nothing wrong with having support for true color terminals - if it's available, by all means, use it. some fallback for those with 256 colors should exist, though. writing some converter that maximizes contrast while preserving the hue as much as possible should be doable, but that's not my point.

my point is that current background and terminal/emacs theme shouldn't matter when rendering a website. terminal theme usually redefines base 16 colors, right? checking the background color suggests doing some fancy matching of the website palette to that background color, and possibly to all base 16 colors as well. kinda pointless, imho. current background should NOT be used. at all.

agreed, mapping rgb to 256 (-16) colors is far from being perfect either, but if that's the only (colorful) option available, there's no other way without touching the current terminal theme.

> Nowadays, nobody bothers about web-safe colors any more. We have the
> Tango palette, the Solarized palette, and a zillion other palettes,
> none mapping well to the xterm space.

it so happens that i am using solarized palette. 16 colors, defined as rgb values in mintty config. works pretty well and doesn't have to do anything with 256-color palette. one can change the base 16 colors on the fly using escape codes to any rgb values whatsoever on quite a few terminals, even those without full truecolor support, but that's changing the terminal theme altogether and the escape codes vary across terminals as well as across the environment (screen, tmux), so it's kinda useless here.

> Instead of coming up with clever heuristics about color remapping, we
> had better push for true color support in terminal emulators,
> libraries and applications.
>
> https://gist.github.com/XVilka/8346728

as i've said, fallback for 256-color terminals should be in place, imho. without remapping colors to the 256-color palette, probably the only sane option to preserve readability on such terminals would be to render the website in 24 shades of gray. far from perfect, but readable. i'm all for truecolor support in all terminal emulators, but we're simply not there yet.

on different note, for truecolor terminals/gui mode, it would be possible to get a nice 'easy on the eyes' website rendering for those that don't care about original website colors that much - and prefer solarized palette. for each rgb color, hue would be preserved, but saturation would change and luminosity would be mapped to solarized values depending if it's a background or foreground color, for constant contrast across the website. the mapping function would need to know if the rgb values describe foreground or background color, but that shouldn't be a problem for website renderer.

proper mapping of rgb values to 256-color palette shouldn't be that hard though, nor cpu intensive. the trick would be to map colors using foreground-background pairs to preserve contrast, even at the cost of changing one of the hues dramatically. it certainly wouldn't be as pretty as the truecolor original or - especially - truecolor solarized variant of the original, but it should remain readable when done right. which is, i guess, the main point of all this.

one more alternative i can think of is using 24 shades of gray together with shades of a single (selectable) color for 'accents'. the renderer would have to choose where to use those accents though (links/buttons/headers/whatever), but it would be easier to navigate than plain grayscale variant.


unic0rn
 		 	   		  

Re: Turning off colorization

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  nljlistbox2@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Copyright: Copyright 2014 James Cloos
> OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
> Date: Sat, 08 Nov 2014 17:51:05 -0500
> 
> Some colour changes are OK, but the backgound should be untouched.

I disagree, sorry.  If the HTML specifies a certain background, Emacs
should by default follow that.  Otherwise, the foreground might be
illegible.  And anyway, this is simply wrong: we are supposed to
display the HTML pages as their authors intended, not as we see fit.

Re: Turning off colorization

[James Cloos]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> Some colour changes are OK, but the backgound should be untouched.

EZ> I disagree, sorry.  If the HTML specifies a certain background,
EZ> Emacs should by default follow that.

The reader's prefs always must take precedence over anything authors
suggest.

But perhaps eww and shr should be treated differently here?  Dealing
with HTML email is significantly different than browsing web sites.

I can understand wanting to present web sites similarly to how other
browsers do.  But I cannot understand willingness to permit email to be
unreadable.  Or even just uglier than plain text email.

As I earlier wrote, allowing a local stylesheet to override style
elements in the source is an acceptable method of fixing this.  That is
a normail web-browser capability, and gnus could support an additional
local stylesheet just for its buffers to constrain html mail more
tightly than eww does.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Turning off colorization

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: nljlistbox2@gmail.com,  larsi@gnus.org,  rms@gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Copyright: Copyright 2014 James Cloos
> OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
> Date: Sun, 09 Nov 2014 09:57:02 -0500
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Some colour changes are OK, but the backgound should be untouched.
> 
> EZ> I disagree, sorry.  If the HTML specifies a certain background,
> EZ> Emacs should by default follow that.
> 
> The reader's prefs always must take precedence over anything authors
> suggest.

Only if the user has stated her prefs explicitly (e.g., by customizing
something).  By contrast, your assertion to which I replied said "the
backgound should be untouched" unconditionally.  That is the part to
which I do not agree.

Re: Turning off colorization

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

  >   And anyway, this is simply wrong: we are supposed to
  > display the HTML pages as their authors intended, not as we see fit.

We have no obligation to the author of the page.
Emacs should do what the Emacs user wants.  

In many cases, users will want Emacs to display the page as the author
meant it to appear.  That may be the right default in most or even all
cases.  In other words, maybe we should see fit to follow what the
markup says, most of the time.  But it is not an obligation.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Eli Zaretskii]

> Date: Sun, 09 Nov 2014 15:07:44 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: cloos@jhcloos.com, nljlistbox2@gmail.com, larsi@gnus.org,
> 	emacs-devel@gnu.org
> 
>   >   And anyway, this is simply wrong: we are supposed to
>   > display the HTML pages as their authors intended, not as we see fit.
> 
> We have no obligation to the author of the page.
> Emacs should do what the Emacs user wants.  

I described what users want.

> In many cases, users will want Emacs to display the page as the author
> meant it to appear.  That may be the right default in most or even all
> cases.  In other words, maybe we should see fit to follow what the
> markup says, most of the time.  But it is not an obligation.

I _was_ talking about the default.

Re: Turning off colorization

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

  > > In many cases, users will want Emacs to display the page as the author
  > > meant it to appear.  That may be the right default in most or even all
  > > cases.  In other words, maybe we should see fit to follow what the
  > > markup says, most of the time.  But it is not an obligation.

  > I _was_ talking about the default.

So was I.  The point is, we should set up the default as we see fit,
which may or may not mean following what the HTML specifies.
To follow that may be the right thing in some cases, or maybe
even in all cases, but that is not automatic.
It is for us to judge.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Eli Zaretskii]

> Date: Mon, 10 Nov 2014 14:07:14 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: nljlistbox2@gmail.com, larsi@gnus.org, cloos@jhcloos.com,
> 	emacs-devel@gnu.org
> 
>   > > In many cases, users will want Emacs to display the page as the author
>   > > meant it to appear.  That may be the right default in most or even all
>   > > cases.  In other words, maybe we should see fit to follow what the
>   > > markup says, most of the time.  But it is not an obligation.
> 
>   > I _was_ talking about the default.
> 
> So was I.  The point is, we should set up the default as we see fit,
> which may or may not mean following what the HTML specifies.
> To follow that may be the right thing in some cases, or maybe
> even in all cases, but that is not automatic.
> It is for us to judge.

Since we both agree that if most of the users want to display an HTML
page as the author meant, this should be the default in Emacs, I think
there's nothing else left to argue about.

RE: Turning off colorization

[Drew Adams]

> Not every face that defines a color is controlled by font-lock.

Nor should it be.  Font-lock does not (should not) "own" property
`face'.

> There's nothing wrong with that, we even have infrastructure for
> doing so (facemenu.el).

Exactly (facemenu is one example).

Re: Turning off colorization

[Stefan Monnier]

>> Not every face that defines a color is controlled by font-lock.

No, but font-lock-mode is the standard way to control whether or not
a buffer is colorized/highlighted.  We introduced font-lock-face
specifically so that font-lock-mode can also be used for the case where
the highlighting is actually not applied via the usual
font-lock-keywords method.


        Stefan

Re: Turning off colorization

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 07 Nov 2014 10:28:51 -0500
> Cc: nljlistbox2@gmail.com, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> >> Not every face that defines a color is controlled by font-lock.
> 
> No, but font-lock-mode is the standard way to control whether or not
> a buffer is colorized/highlighted.  We introduced font-lock-face
> specifically so that font-lock-mode can also be used for the case where
> the highlighting is actually not applied via the usual
> font-lock-keywords method.

But we ourselves are inconsistent in this respect.  E.g.,
file-name-shadow-mode does its thing disregarding font-lock.  So what
you describe might be your aspiration (which I'm not sure I share),
but it certainly isn't adhered enough in core Emacs itself.

More generally, turning off font-lock certainly won't turn colors
globally in the entire Emacs display, because there are elements, like
window decorations and menus, which are not derived from buffer text,
and therefore cannot possibly be controlled by font-lock.  If we want
a single command to turn off all colors, we cannot use font-lock for
that.

Re: Turning off colorization

[Stefan Monnier]

> But we ourselves are inconsistent in this respect.  E.g.,
> file-name-shadow-mode does its thing disregarding font-lock.

I'm not sure I'd put file-name-shadow-mode in the same category.

`font-lock-face is intended more for things like Info-mode's
highlighting, of highlighting of list-packages or list-buffers, and
would seem appropriate for eww (tho, according to this discussion maybe
not).


        Stefan

Re: Turning off colorization

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

  > More generally, turning off font-lock certainly won't turn colors
  > globally in the entire Emacs display, because there are elements, like
  > window decorations and menus, which are not derived from buffer text,
  > and therefore cannot possibly be controlled by font-lock.

That's true but not an anomaly.  Font-lock is supposed to control the
automatic colorization of buffer contents.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Paul W. Rankin]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> M-x font-lock-mode will turn off colorization, but it's not a name
> that will come to a user's mind very easily.  How about making
> colorize-mode an alias for font-lock-mode?
>
> Also, how about putting it in the Options menu?

I develop a package that uses font-lock-mode extensively for coloured
syntax highlighting but also line-prefix, wrap-prefix and invisible text
properties. I also use font-lock-mode to manage a "element" text
property that is integral to the mode. If a user disabled something
called "colorize-mode" thinking it would merely make the colours
disappear, he/she might be unpleasantly surprised to see many things
vanish/break also.

Am I doing something wrong in using font-lock-mode to manage these text
properties? I tried to follow the docs to the letter.

For users wanting non-coloured text I have multiple levels of
highlighting as per the documentation regarding
font-lock-maximum-decoration.

Is the solution to this not more along the lines of a more accessible
font-lock-maximum-decoration? I think that many major modes do not
support multi-level font-lock-keywords, but in my view they ought to.

-- 
Paul W. Rankin
http://www.paulwrankin.com

Re: Turning off colorization

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

  > I develop a package that uses font-lock-mode extensively for coloured
  > syntax highlighting but also line-prefix, wrap-prefix and invisible text
  > properties. I also use font-lock-mode to manage a "element" text
  > property that is integral to the mode.

What job does the `element' property do?  Does it help set up the
highlighting, or does it do some other job?

If it does some other job, you want to have it done
regardless of whether Font Lock mode is enabled.
I think font lock has a hook for setting up such things,
but I don't remember its name.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Turning off colorization

[Stefan Monnier]

> Am I doing something wrong in using font-lock-mode to manage these text
> properties? I tried to follow the docs to the letter.

The way to decide is simple: font-lock-mode should be a cosmetic choice.
The user should be able to turn it off and still get the same
functionality, just with less visual effects (the user who turns off
font-lock might call it "clutter" ;-).


        Stefan

Re: Turning off colorization

[Paul Rankin]

On Mon, 10 Nov 2014, at 06:08 AM, Richard Stallman wrote:
>   > I develop a package that uses font-lock-mode extensively for
>   > coloured syntax highlighting but also line-prefix, wrap-prefix and
>   > invisible text properties. I also use font-lock-mode to manage a
>   > "element" text property that is integral to the mode.
>
> What job does the `element' property do?  Does it help set up the
> highlighting, or does it do some other job?
>
> If it does some other job, you want to have it done regardless of
> whether Font Lock mode is enabled. I think font lock has a hook for
> setting up such things, but I don't remember its name.

The text property (called `fountain-element') helps along fontification,
but it also helps along exporting to other formats, a la `htmlize'.
Actually the export engine I wrote was perhaps misguidedly based on
`htmlize'. The basic functionality is:

1. look at text block's `fountain-element' text property
2. check if `fountain-element' is correct
3. create exported element containing text formatted according to
   `fountain- element'

At the time I figured the `fountain-element' text property was a great
idea, but it is managed by `font-lock-mode', which is probably the wrong
way to do it. I'm currently looking at the parser in `org-element.el'
but it's a little overwhelming. If someone can recommend a good element
parser to study I would be very grateful :)

On Mon, 10 Nov 2014, at 08:03 AM, Stefan Monnier wrote:
> > Am I doing something wrong in using font-lock-mode to manage these
> > text properties? I tried to follow the docs to the letter.
>
> The way to decide is simple: font-lock-mode should be a cosmetic
> choice. The user should be able to turn it off and still get the same
> functionality, just with less visual effects (the user who turns off
> font-lock might call it "clutter" ;-).

Agreed, although my concern is more about non-coloured visual effects.
The mode makes extensive use of line-prefix and wrap-prefix to display
blocks of text indented according to syntax. The syntax, which I didn't
create, dictates indentation must remain cosmetic and not alter the file
contents (hence line-prefix and wrap- prefix a la `adaptive-wrap-mode').

So far so good. But if a regular user sees the option "colorize-mode"
and disables it, he or she will be surprised/confused to see cosmetic
indentation disappear also.

Did no one like my idea of utilising `font-lock-maximum-decoration'? I
feel like if an option called "Minimize Color" set this variable to 1
(either globally or for the current mode) and modes implemented multi-
level font lock keywords where 1 truly is the absolute minimum colour,
then this would be preferable. It seems like the control is already
there in font-lock, just that no one really uses it?

-- 
Paul W. Rankin
http://www.paulwrankin.com