From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Very interesting analysis of "the state of Emacs" Date: Wed, 30 Apr 2008 09:08:09 -0600 Message-ID: References: <481693C3.70901@emf.net> <4816CDB6.6000006@pajato.com> <4817D79F.8040508@gmail.com> Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209568176 21193 80.91.229.12 (30 Apr 2008 15:09:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Apr 2008 15:09:36 +0000 (UTC) Cc: Stephen Eilert , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 30 17:10:12 2008 connect(): Connection refused 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.50) id 1JrDvk-0004kw-Jj for ged-emacs-devel@m.gmane.org; Wed, 30 Apr 2008 17:09:12 +0200 Original-Received: from localhost ([127.0.0.1]:57892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrDv3-0006zH-H7 for ged-emacs-devel@m.gmane.org; Wed, 30 Apr 2008 11:08:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrDuz-0006z5-VG for emacs-devel@gnu.org; Wed, 30 Apr 2008 11:08:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrDuv-0006yC-8S for emacs-devel@gnu.org; Wed, 30 Apr 2008 11:08:25 -0400 Original-Received: from [199.232.76.173] (port=41681 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrDuv-0006y9-5Q for emacs-devel@gnu.org; Wed, 30 Apr 2008 11:08:21 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JrDum-0008VI-Go; Wed, 30 Apr 2008 11:08:12 -0400 Original-Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m3UF8Bnb022183; Wed, 30 Apr 2008 11:08:11 -0400 Original-Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3UF8AD9008943; Wed, 30 Apr 2008 11:08:10 -0400 Original-Received: from opsy.redhat.com (vpn-248-74.boston.redhat.com [10.13.248.74]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3UF8ABO021734; Wed, 30 Apr 2008 11:08:10 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 4E251508248; Wed, 30 Apr 2008 09:08:09 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Miles Bader's message of "Wed\, 30 Apr 2008 14\:12\:44 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:96226 Archived-At: >>>>> "Miles" == Miles Bader writes: Miles> One thing I've heard a lot is that it's annoying to wait 5 Miles> minutes for gnus to finish reading in a huge group or Miles> something. I haven't seen 5 minute pauses since the bad old days -- faster machines have made elisp look faster. However, I do experience the occasional annoying pause when an nntp server is down. In cases like this it would be nice to have an asynchronous gnus that connects in the background. Also, blocking operations sometimes mess with other applications running in Emacs. E.g., if blocked too long ERC seems to time out its connection to irc servers. Miles> Of course Gnus could be rewritten to do potentially lengthy stuff in the Miles> background (and that's what usually happens with such things ... e.g., Miles> "M-x man"), but it's probably not easy, and in many cases not even Miles> desirable -- when the wait is short, I think it's less confusing for the Miles> user for such actions to be synchronous. My ideal is that no Emacs operation be allowed to block Emacs for "very long" (like, less than 1 second would be nice). It is easy to make an async operation look like it is blocking, if that is desirable. However, in general I think it probably is not. I rather like how M-x man works, or async vc-diff or vc-annotate, and I don't think they are super confusing to the new user. So, instead of having "g" in gnus block Emacs entirely, it could simply block operations in the *Group* buffer and present a message somewhere saying what is happening. Tom