[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: Fri, 22 Apr 2011 14:20:45 +0200

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

Oh, I see. Then my answer was inappropriate. My excuses. And I am glad
I was wrong.

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

I can surely see the problem, but if the opportunistic installer asks
(and make it possible to check) before each install I do not think it
is an additional problem when using Emacs.

For another comparison think about the firewalls. They effectively act
similar to such an opportunistic installer as I suggest when they ask
you if you want a program to be able to do that and that.

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

This can be done by an opportunistic installer. In fact the
opportunistic installer in nXhtml allows you to check the file.

> 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 :)

It is not clear all the time what dependencies there are since that
may depend on how you are using a library. That is why I think an
opportunistic installer is good.

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

I do not have time to discuss it much now, but please see my explanations above.

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

A misunderstanding. I was referring to two versions in different
locations on the users computers.

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

Please see just above.

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

Good. I am not sure either but want to give you my concerns. Please
feel free to handle it the way you think is best at the moment.

reply via email to

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