[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turning off colorization

From: Tim Cross
Subject: Re: Turning off colorization
Date: Fri, 7 Nov 2014 08:42:51 +1100

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. 


On 7 November 2014 07:13, N. Jackson <address@hidden> 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?:


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.

N. Jackson



Tim Cross

reply via email to

[Prev in Thread] Current Thread [Next in Thread]