Re: face for non-ASCII characters

[Ted Zlatanov]

On Thu, 21 Apr 2011 22:53:01 +0200 Lennart Borgman <address@hidden> wrote: 

LB> 2011/4/21 Ted Zlatanov <address@hidden>:
>>>> I'm not sure what you mean about dynamic loading.
>> 
LB> What I mean here is what can be used in nXhtml: If you (require
LB> 'somelib) and somelib.el is not on your computer then you can have it
LB> automatically downloaded from nXhtml repository (with a possibility to
LB> check the code before actually installing it).
>> 
>> I would be strongly opposed to opportunistic package installations in
>> general, although nXhtml can use it internally of course.

LB> Why is the word opportunistic used by you here? I do not have time to
LB> discuss if you do not take it seriously. Please describe exactly what
LB> it is you do not like instead.

"Opportunistic" means it's installed when you need it as you said.
"Dynamic loading" is a term easily confused with the Unix dynamic
libraries, that's why I avoided it.  I am not using "opportunistic"
disparagingly.

I am opposed to opportunistic installs because they destabilize the
working environment.  They may make sense in a tightly controlled
environment, but for a general audience (all Emacs users) I think they
are a bad idea.  Most package managers I've used (Perl, Python, Ruby,
Emacs, XEmacs, Unix distributions) do static installs.

This is different from autoloading, where you know the library is
available and you've scanned it for autoload cookies.

LB> You are greatly exaggerating. The difference between ELPA and nXhtml
LB> here is that nXhtml will propose that you can install a library to get
LB> things working while ELPA will not do that.

ELPA will install all the dependencies when it installs the library.  So
when the library is installed, you won't have surprises later.  If
you're talking about optional add-ons and plugins, that's a different
discussion :)

As I said, you should make the opportunistic/dynamic loading proposal
and maybe it will be accepted.  While it seems to me like a bad idea,
it's entirely possible it turns out to be good!  We won't know until
it's discussed directly.

LB> At first sight one might think that your proposal to mirror
LB> markchars.el into ELPA is not troublesome. However you may end up with
LB> two versions of markchars.el if you mirror it into ELPA now.

That would last for at most 1 day, until the nightly synchronization
catches up with the nXhtml repository.  I think that's OK.  The nXhtml
repository will still be the primary repository.

LB> I would be glad to have it in ELPA - if just the automatic
LB> installation could be fixed too.

Can you give a specific scenario where markchars.el in both the GNU ELPA
and in nXhtml would be a problem?  I want to understand what needs to be
fixed.

LB> But you are however of course free to do what you want.

Sure, but I'd rather collaborate if I can.  The easiest thing (just keep
markchars.el in the GNU ELPA) is not the best thing for the users.

Ted