Re: face for non-ASCII characters

[Ted Zlatanov]

On Sat, 16 Apr 2011 17:28:48 +0200 Lennart Borgman <address@hidden> wrote: 

>> I'd like to keep markchars.el a standalone library, so the attached does
>> not require idn.el.

LB> Ok. Do I understand it correctly that you use idn.el if it is
LB> available, otherwise not?

Yes, `idn-is-recommended' is autoloaded.  It may be a problem with the
fboundp call, which will return true even if the library is not
available:

(when (autoload 'coocoo "coo")
  (fboundp 'coocoo))

=> t

so maybe (require 'idn nil t) is a better approach, and we can define a
stub replacement for `idn-is-recommended'.  I didn't dig too much into
it because of the possibility of inclusion I mentioned.

>> The major change is that instead of detecting the range at the font-lock
>> keyword level, I run non-IDN detection at the word markup level (just
>> like confusables detection).  I think that results in cleaner, easily
>> extensible code--take a look and see what you think.

LB> I have no special opinion about it. Just use what is easiest to
LB> maintain and understand. I guess it works the same?

Effectively it's the same, yes.

>> `markchars--render-nonidn' is not optimized: it steps through the word
>> in the buffer and assigns the properties to each individual character
>> instead of each range it finds.  I don't think that's a big deal but it
>> could be done better.  I couldn't reuse your non-IDN detection logic
>> because it was not word-oriented.

LB> Please suggest a better inferface from idn.el if possible to fix
LB> this.

This is the stepping algorithm at the buffer level, idn.el can't help.

>> I would use a char-table for idn.el instead of a bool-vector.  Also
>> perhaps idn.el's .txt files and confusables.txt should simply be part of
>> Emacs, so the IDN and confusables properties can be looked up like the
>> other properties.  Emacs already does that for many properties, see for
>> example:
>> 
>> (format "%S" (mapcar 'car char-code-property-alist))
>> (get-char-code-property ?q 'titlecase)
>> 
>> I think that inclusion would benefit everyone, but the original .txt
>> files are large so I'll leave it up to the experts.

LB> That was why I used a boolean vector. But I am not an expert on
LB> this.

The char-table is meant for character lookups, that's why I suggested
it instead of a bool-vector.

>> If they are
>> included, `markchars--render-nonidn' would be much much smaller.

LB> I do not understand what you mean here.

The function wouldn't need to assign a special property, the character
would already have it.  And the highlighting could just look for that
special property instead of hunting for it with a function.

Ted