Re: face for non-ASCII characters

[Lennart Borgman <lennart.borgman@gmail.com>]

2011/4/22 Ted Zlatanov <tzz@lifelogs.com>:
> On Fri, 22 Apr 2011 14:20:45 +0200 Lennart Borgman <lennart.borgman@gmail.com> 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).

Web browsers do it all the time.

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

There is no difference that I can see when it comes to stability
(which was what I believe you suggested as the most important).

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

?? Elisp libraries work the same way AFAICS.

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

I can't find any sense in what you say here. Could explain what
differences you see?

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

No, it did not make sense to finish the system for opportunistic
install (since ELPA was to be used). I made it more as an example of
how it can  be built. (But it works, of course.)

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

Yes.

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

Why not mirror idn.el too then?

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

I think it would make most sense as an enhancemen to ELPA since the
libraries within ELPA should be good to use so we do not have to worry
about something bad getting installed this way.