emacs-devel
[Top][All Lists]
Advanced

[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 18:01:12 +0200

2011/4/16 Ted Zlatanov <address@hidden>:
> On Sat, 16 Apr 2011 17:50:07 +0200 Lennart Borgman <address@hidden> wrote:
>
>>> 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.
>
> LB> I think autoloading and checking if the function is defined is the
> LB> best way. (Autoloading of `idn-is-recommended' should of course not be
> LB> setup if idn.el is not available.)
>
> OK, but then this:
>
> (defcustom markchars-what
>  `(markchars-simple-pattern
>    markchars-confusables
>    ,@(when (fboundp 'idn-is-recommended) '(markchars-nonidn-fun)))
> ...
>
> will always add `markchars-nonidn-fun' to `markchars-what' and that will
> break users without idn.el.

Why? (fboundp 'idn-is-recommended) only returns true if the function
is defined or autoloaded. If idn.el is not available the function
should not be autoloaded, or?

> LB> So using a char-table instead in idn.el would make the interface
> LB> better? (But we need someone good at this to tell if that is usable
> LB> here performancewise.)
>
> I think it's slightly better for characters to use char-table instead of
> bool-vector.  Semantically it's cleaner: you're using a char-table,
> which is meant for characters, instead of a bool-vector, which is for
> general data.  But it's a really small difference so don't bother if you
> don't feel like it :)

I sounds like a good idea, I am just waiting for some more info about
performance.

> OK, so after we resolve the autoload issue above and find out if the
> confusables.txt and idn*.txt files can be turned into Emacs character
> properties, we can publish 0.2, right?  Is there anything else it needs?
>
> Ted
>
>
>



reply via email to

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