From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Turning off colorization Date: Fri, 7 Nov 2014 08:42:51 +1100 Message-ID: References: <874muenb56.fsf@newcastle.ac.uk> <87egtivwop.fsf@fencepost.gnu.org> <87k33951ey.fsf@lifelogs.com> <87lhno9jeq.fsf@moondust.localdomain> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2b51a04738705073794e9 X-Trace: ger.gmane.org 1415310196 26795 80.91.229.3 (6 Nov 2014 21:43:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2014 21:43:16 +0000 (UTC) Cc: Emacs developers To: "N. Jackson" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 06 22:43:11 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XmUpj-00007P-52 for ged-emacs-devel@m.gmane.org; Thu, 06 Nov 2014 22:43:11 +0100 Original-Received: from localhost ([::1]:56175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmUpi-0000u2-NS for ged-emacs-devel@m.gmane.org; Thu, 06 Nov 2014 16:43:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmUpT-0000t6-A5 for emacs-devel@gnu.org; Thu, 06 Nov 2014 16:42:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmUpR-0006BE-1p for emacs-devel@gnu.org; Thu, 06 Nov 2014 16:42:55 -0500 Original-Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:45003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmUpQ-0006B8-MF for emacs-devel@gnu.org; Thu, 06 Nov 2014 16:42:52 -0500 Original-Received: by mail-wg0-f54.google.com with SMTP id n12so2283897wgh.13 for ; Thu, 06 Nov 2014 13:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aPS6BMqelZM/ymLP84ynVU2kZPt5PyS3JT6BFd4IsnA=; b=eHntICdykzxwrbZwEDcNY6mhOst+4NvLFzCZ8iI6DxzYlU2e1xVyBRlhoQ51r2iAFx RA1tu77wGVHS1+8V6c6fHnlDmbnr4ADBuiOTmLmltyySCEZAQnrVEC1fTizA8aS7SlEn IR8BE8WA1s6Jb5XUwWiaBvwLZIiqCTzlDeFzWXqLe3iWK+qdRmfn5Ct3kFNDHnl+2GB/ GU48w5/PWA7deCfsP4Gy9TxFx6qSmAzVllr39qIBMyPaqwB2JxX8/J2gFXUl4EOgb7IW 3rJiGyNsxjvu82SBodeorbDrruh8ew0VFaNYpOKqOhR8XR2lenms57GxOgBLNmUCc4pV y4Hw== X-Received: by 10.180.9.169 with SMTP id a9mr18462287wib.7.1415310171466; Thu, 06 Nov 2014 13:42:51 -0800 (PST) Original-Received: by 10.195.17.193 with HTTP; Thu, 6 Nov 2014 13:42:51 -0800 (PST) In-Reply-To: <87lhno9jeq.fsf@moondust.localdomain> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176491 Archived-At: --001a11c2b51a04738705073794e9 Content-Type: text/plain; charset=UTF-8 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 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 --001a11c2b51a04738705073794e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm always amazed at how a group of smart people can t= oo often over complicate a question. This thread started with s relatively = simple usability question on whether font-lock was a good term wrt font col= ours. We have then strayed off into related questions, but away from the or= iginal question.=C2=A0

I agree font-lock is not a very i= ntuitive 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 i= n programming at some level.=C2=A0

The other point= s 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 w= ho has a sight impairment which requires tweaking of colours, I can say thi= ngs have improved immensely. Originally, I use to spend hours defining an e= lisp 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 th= en modify your setup. However, the introduction of thems has made this a lo= t simpler. We do need to encourage package writers to use default values de= rived from the standard set of faces i.e. use inheritance rather than simpl= y defining new faces with their own colour settings as this will improve ho= w themes work and often gives a better result as too often, individual pack= ages will not use the full configuration i.e. don't define defaults for= monochrome, tty etc.=C2=A0

There are already them= es defined which will set colours that are typically better for red-green c= olour blind and even monochrome themes for those who prefer no colours. I t= hink this is a good approach. The range of vision impairments and individua= l 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 ta= stes/needs is the way to go.=C2=A0

The critical re= quirement 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 worthwh= ile ensuring the manual covers this and includes links to the customize-the= me 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.= =C2=A0

Tim


On 7 November 2014 07:13, N. J= ackson <nljlistbox2@gmail.com> wrote:
At 11:02 -0400 on Wednesday 2014-11-05, St= efan 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-0= 1/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

--001a11c2b51a04738705073794e9--