emacs-devel
[Top][All Lists]
Advanced

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

Re: highlighting non-ASCII characters


From: Ted Zlatanov
Subject: Re: highlighting non-ASCII characters
Date: Tue, 30 Mar 2010 08:22:06 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Mon, 29 Mar 2010 22:51:02 +0200 Lennart Borgman <address@hidden> wrote: 

LB> However just hilighting non-IDN chars seems useful enough. I think it
LB> should be done everywhere (because it is simple and probably does not
LB> hurt, IDN seems mostly useful for variables to for examples), or
LB> optionally only in strings (the only URL context we can actually
LB> guess).

LB> For the moment I have implemented this as fontification. Having it as
LB> a char class that is flexibly initialized would be better. Perhaps my
LB> routines for reading the chars can be used there too.

Look at Categories in the ELisp manual (what Stefan referred to when he
mentioned category-table).  If you can implement your reader that way it
would be great.  It's much better than modifying regexp.c :)

LB> The homoglyph context thing is maybe more difficult. I did not try to
LB> read carefully so I do not know much. I guess there is something like
LB> char value ranges to use, or? Someone knows which document that where
LB> those ranges can be read (by some elisp code)?

The confusables text file will give you all of them for the category
table.  But you also need to group them by homoglyph (probably with a
hashtable), so I'd write a custom reader.  If you don't get to it, I
will eventually :)

The two text files (IDN and confusables) would have to live inside Emacs
somewhere and the reader will load them when it's loaded.

LB> My impression is that IDN is a work in progress so it might be good
LB> idea to read in the characters from a file if possible (and let the
LB> user reread that file later if necessary).

Re-reading the file is a really, really rare occurrence for the user so
I would make it an internal function.  You can always call it directly
while developing, but end users will never need to.

Ted





reply via email to

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