Re: face for non-ASCII characters

[Ted Zlatanov]

On Fri, 22 Apr 2011 14:20:45 +0200 Lennart Borgman <address@hidden> wrote: 

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

At the very least it's a burden on the user.  What programs do you know
that use this system?  If the prevailing norm is to do static installs,
that suggests that users prefer it (I can't believe no one thought
"let's do opportunistic installs!" before).

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

I think the difference here is between installing software and enabling
services.

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

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

OK, so we're talking about plugins, not package dependencies.  Those may
be useful in a limited context, e.g. within nXhtml itself.  Emacs may
even get facilities to support them generally some day.  But plugins are
not packages.

I don't think markchars.el is a plugin.  It does not depend on nXhtml
and does not enhance it in a special way; it's a general package.  So
perhaps our misunderstanding is semantic :)

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> A misunderstanding. I was referring to two versions in different
LB> locations on the users computers.

Ah.  package.el installs the two versions of the library in different
locations and will activate only one.  Thus the user has control over
the versions and can upgrade.  Does nXhtml do that?

In any case, as long as nXhtml puts its plugin directory in front of
package.el on the load-path, markchars.el will be loaded from the
install location nXhtml specifies.

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

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

OK, I'll mirror it.  I don't expect it to become a problem.

LB> I believe RMS rejection was not so much because of instability but
LB> insecurity and that the user should have control. It was after that I
LB> added the possibility to review and reject the opportunistic install,
LB> just before the library is going to be installed.

As I said, you have to make a proposal and defend it.  It may turn out
to be really great, we won't know until it's up for review.  But I think
you should frame it as a "plugin facility" instead of a package manager
to give it a good chance to be accepted.

Ted