From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: face for non-ASCII characters Date: Fri, 22 Apr 2011 19:12:15 +0200 Message-ID: References: <87tydym9fs.fsf@lifelogs.com> <87lizam8zt.fsf@lifelogs.com> <878vv7imqp.fsf@lifelogs.com> <87k4erh6q3.fsf@lifelogs.com> <874o5uie42.fsf@lifelogs.com> <87y635dll9.fsf@lifelogs.com> <87r58vbj7o.fsf@lifelogs.com> <87fwpba03q.fsf@lifelogs.com> <874o5rqr5z.fsf@lifelogs.com> <87mxjjpal4.fsf@lifelogs.com> <87vcy6nzan.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1303492367 1949 80.91.229.12 (22 Apr 2011 17:12:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2011 17:12:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 19:12:43 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QDJuM-0001Xf-NR for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2011 19:12:43 +0200 Original-Received: from localhost ([::1]:41511 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDJuM-0006iA-0O for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2011 13:12:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDJuI-0006hp-6P for emacs-devel@gnu.org; Fri, 22 Apr 2011 13:12:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDJuG-00077Q-SA for emacs-devel@gnu.org; Fri, 22 Apr 2011 13:12:38 -0400 Original-Received: from mail-ew0-f41.google.com ([209.85.215.41]:44657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDJuG-00077I-Jl for emacs-devel@gnu.org; Fri, 22 Apr 2011 13:12:36 -0400 Original-Received: by ewy9 with SMTP id 9so248065ewy.0 for ; Fri, 22 Apr 2011 10:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=eVQ1tm4FzQolnhNT74K6gDI2KY0TDYw252RVtFSE4iY=; b=paLLdbZPKESj+bEwZAdoWemN44SMYhte1e3b2H8Sdm9jIXrCfL/BVhTUJNrEAtf8no iBOi+KtNUeRJHEFWSteMx5hMrDso/1cKElMHX8pcyKSoNDr+CZuqLSIqSn+tTc+D5yc7 4I++e53EPk4zFh7QW0k/fEatdLK9acZaDBT/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=D8x6EZ2wvXuAVZKAmucPxtuidnDYpxhWxv8ZwI7aVCKSsKWUdi8ajCPM7KxL7DBmO1 Gapo8PPe19hu+8tBXTJV9p6k9za3OQJ9Mndo0l7NTedX6mTNZogEDDrvIFK4VzmaR25T qkXKtevl6S64mMhAqU5tRQOprhq9zgXKCbC4o= Original-Received: by 10.213.103.80 with SMTP id j16mr299598ebo.96.1303492355469; Fri, 22 Apr 2011 10:12:35 -0700 (PDT) Original-Received: by 10.213.23.8 with HTTP; Fri, 22 Apr 2011 10:12:15 -0700 (PDT) In-Reply-To: <87vcy6nzan.fsf@lifelogs.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.215.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138644 Archived-At: 2011/4/22 Ted Zlatanov : > On Fri, 22 Apr 2011 14:20:45 +0200 Lennart Borgman 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. =C2=A0What programs do you k= now > that use this system? =C2=A0If the prevailing norm is to do static instal= ls, > 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 ac= t > 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. = =C2=A0So >>> when the library is installed, you won't have surprises later. =C2=A0If >>> 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. =C2=A0Emacs ma= y > even get facilities to support them generally some day. =C2=A0But plugins= are > not packages. > > I don't think markchars.el is a plugin. =C2=A0It does not depend on nXhtm= l > and does not enhance it in a special way; it's a general package. =C2=A0S= o > 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. =C2=A0package.el installs the two versions of the library in differen= t > locations and will activate only one. =C2=A0Thus the user has control ove= r > the versions and can upgrade. =C2=A0Does 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. =C2=A0The easiest thing (jus= t 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. =C2=A0I 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. =C2=A0It may turn o= ut > to be really great, we won't know until it's up for review. =C2=A0But I t= hink > 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.