From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: async 1.0 Date: Sun, 24 Jun 2012 16:01:16 -0500 Message-ID: References: <87vcij7rvi.fsf@mithlond.arda> <82d34r8ej9.fsf@gmail.com> <87r4t4zr9l@ch.ristopher.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340571741 32693 80.91.229.3 (24 Jun 2012 21:02:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jun 2012 21:02:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 24 23:02:20 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sitwp-00084e-3r for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2012 23:02:19 +0200 Original-Received: from localhost ([::1]:38931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sitwp-0005jJ-2Y for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2012 17:02:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sitwm-0005jA-B4 for emacs-devel@gnu.org; Sun, 24 Jun 2012 17:02:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sitwk-00008W-9r for emacs-devel@gnu.org; Sun, 24 Jun 2012 17:02:15 -0400 Original-Received: from mail-gg0-f169.google.com ([209.85.161.169]:56120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sitwk-00008B-2H for emacs-devel@gnu.org; Sun, 24 Jun 2012 17:02:14 -0400 Original-Received: by ggm4 with SMTP id 4so2963044ggm.0 for ; Sun, 24 Jun 2012 14:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:references:mail-followup-to:date :in-reply-to:user-agent:mime-version:content-type; bh=ZZgiJSLEHOmo8Cxd2iaQ5+pmlu2N6CM2dM4199+CBIY=; b=JW3sBoZv5A1ONErRwd2X8Q/idWYX38nc6cbRjYgLKRsPmqtIKygh0/7HbrJljFpDmU H/WC2FZcceQfH1lMSvB+HYxsIN9+E+uiN6+QyvzXNbYcLDlMibE+1chQkr+j4x/Qc232 l4KSxrJxvHLWsVxU/HYnyQwUAGmZXIsmjYliQS9k3QV7MFRNG+b31lCFCHmg52ekHR6E XtyHBzVP0X2tJ82FiK1ITi0yLqbgrbbJQ0N9DKrsepEsODjhi3JH4kuyo0Lt9ftenTSK Na7R7rhKQw1KcvQRcPk4L6Cx6vi+nG3W0ATXjMC0U3tc24l99i5AqaFIU4y8cGNJgH8T z7Xw== Original-Received: by 10.42.145.7 with SMTP id d7mr4182638icv.45.1340571730917; Sun, 24 Jun 2012 14:02:10 -0700 (PDT) Original-Received: from vulcan.local (c-98-215-105-167.hsd1.il.comcast.net. [98.215.105.167]) by mx.google.com with ESMTPS id uy3sm4933221igc.14.2012.06.24.14.02.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 14:02:10 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id C9893F053892; Sun, 24 Jun 2012 16:01:16 -0500 (CDT) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: <87r4t4zr9l@ch.ristopher.com> (Christopher Schmidt's message of "Sun, 24 Jun 2012 16:02:59 +0100 (BST)") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.161.169 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:151140 Archived-At: >>>>> Christopher Schmidt writes: > Whilst this is an incredibly interesting package, I do not think that > async.el should be a "core service" that may be used by other core packages. I think that it should definitely be a core service, but _of course_, "opt-in" until it is discovered that each particular use of async.el cannot break in any way (and I'm open to the thought that this may never be true, and it will be opt-in forever). For example, I have changes to dired to make it asynchronous. They work great here, and I'm not sure what all your doom and gloom is about. However, I wouldn't imagine enabling such a change by default; I would add a `dired-use-async' variable. *However*, such a variable loses a lot of value if dired is part of Emacs but async isn't. How can I modify dired (and it does require core modifications to support async.el) if the changes rely on macros contained in a package from ELPA? Dired gets byte-compiled as part of the Emacs bootstrap, yet those macros are not present until the user installs async.el from ELPA. Do they have to re-compile dired to establish the proper definitions in byte-code? Further, even though enabling `dired-use-async' purports to make dired async, it doesn't really. The user has to additionally install async through ELPA for that variable to become meaningful. This is a needless burden on the user, not all of whom are familiar and comfortable with installing packages through ELPA. Async should be something people can just turn on, not something they have to jump through hoops to get. So, I think async.el should be a core services so that other core services can rely on its definitions at compile time, as Emacs is being built. Otherwise, changing dired, eshell, smtpmail, etc., to use async.el ends up being way too hacky to be worth doing. I believe requiring distribution through ELPA would kill chance at real adoption for async.el. > smtpmail-async would break my setup. It would break my setup in a way very > hard to fix. Can you explain that a bit more? Otherwise, it sounds like FUD. > Other than that, GNU Emacs has excellent asynchronous process and network > facilities already. Why not use them? And these would be? I'm not aware of any core service that lets me asynchronously call lambdas. > If this package makes it into GNU Emacs, please make every single usage > opt-in by default. I wouldn't dream of enabling this by default for unsuspecting users. It needs years of battle testing before I'd even begin to have that kind of confidence. > If async.el somehow finds its way on my machine, the very first form in my > init.el will be responsible for redefining all `async-'-functions to > unconditionally signal an error. Again, a bit FUD-y. > Slightly off topic... I do not agree with GNU ELPA not being applicable for > core services. I think every single package that is not absolutely > necessary for running a bare Emacs should be moved to GNU ELPA. In > particular I am thinking of packages like CEDET, Calc, Calendar, ECB, ERC, > Gnus, Org-mode, all prog-modes, eshell, mh-e, rmail, shell, term etc. On > top of that, IMO every single core package should have a copy on GNU ELPA so > one can to overwrite the native GNU Emacs one with the one from GNU ELPA. > This would decouple all packages from the Emacs release cycle and allow bug > fixes to be distributed instantly. On top of that, this would make actual > core emacs development, test, release and bug management a lot easier.[1] This is a discussion for another thread, please. John