Re: face for non-ASCII characters

[Lennart Borgman]

2011/4/16 Ted Zlatanov <address@hidden>:
> 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

This is not a problem if autoload is setup correctly.

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

I think autoloading and checking if the function is defined is the
best way. (Autoloading of `idn-is-recommended' should of course not be
setup if idn.el is not available.)

> Effectively it's the same, yes.

Good.

>>> `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.
...
> The char-table is meant for character lookups, that's why I suggested
> it instead of a bool-vector.

So using a char-table instead in idn.el would make the interface
better? (But we need someone good at this to tell if that is usable
here performancewise.)

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

I see, thanks.

> Ted
>
>
>