From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: face for non-ASCII characters Date: Fri, 22 Apr 2011 09:20:00 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87vcy6nzan.fsf@lifelogs.com> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1303482028 6579 80.91.229.12 (22 Apr 2011 14:20:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2011 14:20:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 16:20:24 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 1QDHDa-0000Ob-1A for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2011 16:20:22 +0200 Original-Received: from localhost ([::1]:43481 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDHDZ-0007Do-BG for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2011 10:20:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDHDV-0007DX-VL for emacs-devel@gnu.org; Fri, 22 Apr 2011 10:20:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDHDU-0004j7-SN for emacs-devel@gnu.org; Fri, 22 Apr 2011 10:20:17 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:36445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDHDU-0004it-FV for emacs-devel@gnu.org; Fri, 22 Apr 2011 10:20:16 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QDHDS-0000GU-Iu for emacs-devel@gnu.org; Fri, 22 Apr 2011 16:20:14 +0200 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2011 16:20:14 +0200 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2011 16:20:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 74 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.hsd1.il.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:5O3QBqbsh32o2zWcF7JQUGWohPk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:138643 Archived-At: 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. 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