From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Mattie Newsgroups: gmane.emacs.devel Subject: Re: user-controlled load-path extension: load-dir Date: Mon, 7 Mar 2011 16:47:27 -0800 Message-ID: <20110308004724.GA1952@event-horizon.homenet> References: <87ei6mz24h.fsf@lifelogs.com> <20110306072147.GA11067@event-horizon.homenet> <871v2i525h.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" X-Trace: dough.gmane.org 1299545269 10680 80.91.229.12 (8 Mar 2011 00:47:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2011 00:47:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 01:47:44 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pwl5S-0003E6-8O for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2011 01:47:42 +0100 Original-Received: from localhost ([127.0.0.1]:34772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwl5R-0003WJ-Kd for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2011 19:47:41 -0500 Original-Received: from [140.186.70.92] (port=55507 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwl5M-0003W8-Re for emacs-devel@gnu.org; Mon, 07 Mar 2011 19:47:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwl5L-0003b7-52 for emacs-devel@gnu.org; Mon, 07 Mar 2011 19:47:36 -0500 Original-Received: from mail-yw0-f41.google.com ([209.85.213.41]:50663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwl5K-0003aq-Vw for emacs-devel@gnu.org; Mon, 07 Mar 2011 19:47:35 -0500 Original-Received: by yws5 with SMTP id 5so2371890yws.0 for ; Mon, 07 Mar 2011 16:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=WuEZvGFms7RGNzqTWmmGPrStcB/oPvxNsFa9xbbqBnE=; b=Ykv8YKd8FA6cpJzSyt31iCASlthK/TfORaUAifziPX2aW+h9s19z6IhL8djxxl8T2p WxI1LrzwgLSH5QcsqXjUS9hPJl/SJRt1OeGj99GHE4LwuEQRKwv0fxfPQTakUYOxert1 iiQdj7vf8yipHcL6xFyz+HWwJjbfZGJIsq7Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GZh5wWAytgrRkPaQiE1fRqN9oqgbU2fGg3rmYR/rYLsBznIQ6Oogurs9/cWysaDL7f FQ9jZWnk6M13iNoWJub3ADDu0nqW9hj4sjnbcAa9Wo7hfesgijNPyr/6fmIPawRC6OWl ZagYtCe9Bqn/bemF+Fj2Tp75xaJdPZv/JaK3g= Original-Received: by 10.151.116.2 with SMTP id t2mr5217340ybm.268.1299545253722; Mon, 07 Mar 2011 16:47:33 -0800 (PST) Original-Received: from event-horizon.homenet (114.sub-75-196-84.myvzw.com [75.196.84.114]) by mx.google.com with ESMTPS id v15sm276188ybk.6.2011.03.07.16.47.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 16:47:32 -0800 (PST) Content-Disposition: inline In-Reply-To: <871v2i525h.fsf@lifelogs.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.213.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136858 Archived-At: --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2011 at 10:24:58AM -0600, Ted Zlatanov wrote: > On Sat, 5 Mar 2011 11:11:34 -0800 Chad Brown wrote:=20 >=20 > CB> On Mar 4, 2011, at 7:18 PM, Ted Zlatanov wrote: > >>=20 > >> By analogy consider some of the software that lets you put a snippet in > >> a conf.d directory, obviously implying that this is convenient for the > >> user. This is just a sampling from my machine: >=20 > CB> Those are all machine-wide configurations. For that, use site-lisp. >=20 > Bazaar has a plugins directory; files in it are automatically activated, > as an example of a user-level facility like this. Anyhow, my point is > that placing a file in a directory is inherently more modular and > convenient to the user than augmenting a single file. Do you disagree? >=20 > CB> If the user has to go through a set of steps to install and activate a > CB> package, how isn't that what ELPA does? >=20 > They are not packages, they are snippets of code. ELPA requires far > more structure and many more steps. For what I'm proposing, a lot less > work is required (just a y/n prompt the first time a snippet is found to > ensure it's not placed there maliciously). >=20 This whole security thing is a real non-issue. There is no security in Emacs, it (Emacs) simply uses the underlying system security model. What is really at issue is whether the user _trusts_ the code. Trying to address security issues in a software system that has no security API/model leads to some skewed thinking, and I am not just splitting hairs. Thinking in terms of trust leads to better reasoning. > On Sat, 5 Mar 2011 23:21:51 -0800 Mike Mattie wro= te:=20 >=20 > MM> There are ways to solve the problem you are looking at without wiring= more > MM> logic into Emacs. Use the .emacs file as a more sophisticated loader = for a > MM> complex configuration when necessary. >=20 > I can and do, sure. I don't think it creates a nice user experience. >=20 > MM> I have done this with my Grail project (on EmacsWiki), as has tidycon= fig. > MM> I would look at these solutions first before proposing code that has = to > MM> be wired into the bootstrap codepath. >=20 > Thanks for pointing those out. Would Grail or tidyconfig work as a core > option on startup (meaning the user doesn't have to install a package, > just customize a boolean)? Do they handle signing the snippets the > first time they are found? Can you give us a comparison of them and any > other similar solutions you know? They have to be GPL and assigned to > Emacs to be included. I doubt Grail would be included in-tree. Maybe I am wrong, but I get that vibe. I would certianly need to convert some recursive functions to iterati= ve versions before even bringing Grail to the table. I have been maturing Grail out-of-tree to ensure the code is robust, designed well, and is targetted at typical user needs. >=20 > MM> There are a number of issues a reliable loader should address: >=20 > MM> how does it handle errors ? >=20 > MM> how does it handle --batch ? >=20 > MM> how does it handle --daemon ? >=20 > MM> how simple,transparent,debuggable is the loader code ? >=20 > MM> I have not seen any code so far in your proposal unless I accidentally > MM> skipped or deleted a message with it. >=20 > I can write the code but haven't seen the need for actual code yet (I > could have just comitted some code to Emacs instead, but find that > option to be antisocial). >=20 > I'd rather use something that already exists such as Grail or tidyconfig > that you kindly pointed out. If you could tell us how any potential > solutions can help answer the questions above, that would be wonderful. > I can look at any solutions and evaluate them if you like. I can only speak for grail, but Grail essentially Handles the load-path issue. When it comes to load-path Grail is comprehensive. What grail does not do is automatically load code from a given directory. Directories that grail looks for are added to load-path when they exist. Grail looks for files such as keys.el commands.el, user.el and does load those when found. They are assumed to be user created files. When snippets are collected in a directory such as dist/elisp, or local/elisp, the user is expected to place a require or similar command in one of these recognized files to actually load the snippet/whatever at the start. As far as error-handling goes grail does shine a bit in that errors within a file are trapped, meaning that mistakes in one file does not cause the entire configuration to abort leading to a --debug-init situtation. In this regard Grail is extremely robust. I will be updating the documentation of Grail extensively over the next cou= ple few days to describe it's use, usefulness, limitations etc .. I will send y= ou a mail off-list when I have articulated Grail properly. >=20 > To answer your questions from my perspective, IMHO a loader should work > like package.el. IOW, whenever and however package.el is loaded > currently, this loader we're discussing should also be loaded, since > it's effectively a package manager but with snippets instead of > packages. I am seriously considering how to add the kind of functionality you want to Grail. I would like to add it to broaden the usefullness of Grail. I do not like the idea of hacking another load-path 'ish variable into Emacs when si= mply adding elisp to manage load-path is an option. Two similar variables is sim= ply bad design. >=20 > Ted >=20 >=20 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAk11fJwACgkQdfRchrkBInm9WQCg2ucKDf47YtS6IQlvqGDPtZyf bQEAn1XSrShwZDAkbahDs+ljMPTigrDq =ebZg -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--