[Top][All Lists]

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

Re: face for non-ASCII characters

From: Lennart Borgman
Subject: Re: face for non-ASCII characters
Date: Sat, 16 Apr 2011 17:50:07 +0200

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.


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

reply via email to

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