From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: minibuffer-exit when emacsclient executes Lisp code Date: Wed, 16 May 2007 16:41:08 +0200 Message-ID: <86d510rfuj.fsf@lola.quinscape.zz> References: <20070516140157.55B3B78EF@chatsubo.ninsei.hu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179326482 32339 80.91.229.12 (16 May 2007 14:41:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 May 2007 14:41:22 +0000 (UTC) Cc: Juanma Barranquero , emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 16:41:21 2007 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 1HoKgm-0004pT-V5 for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 16:41:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoKom-00057L-5z for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 10:49:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HoKog-00057B-Vf for emacs-devel@gnu.org; Wed, 16 May 2007 10:49:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HoKog-00056y-G4 for emacs-devel@gnu.org; Wed, 16 May 2007 10:49:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoKog-00056v-Ap for emacs-devel@gnu.org; Wed, 16 May 2007 10:49:26 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HoKgg-00076N-4s for emacs-devel@gnu.org; Wed, 16 May 2007 10:41:10 -0400 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id QAA14949 for ; Wed, 16 May 2007 16:41:01 +0200 X-Delivered-To: Original-Received: (qmail 4484 invoked from network); 16 May 2007 14:41:08 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 16 May 2007 14:41:08 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 8193B8F230; Wed, 16 May 2007 16:41:08 +0200 (CEST) In-Reply-To: <20070516140157.55B3B78EF@chatsubo.ninsei.hu> (karoly@lorentey.hu's message of "Wed\, 16 May 2007 16\:01\:00 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:71172 Archived-At: writes: > Juanma Barranquero wrote: >> Are you proposing throwing the trunk version and just replacing it >> with the multi-tty one? > > No, not at all. I mean that if there is indeed a consensus that > multi-tty will be merged soon, Maybe my pushing for getting multi-tty into the Emacs repository (which others have agreed to be a good idea) has left a wrong impression. This was not as much a consensus, I guess, that "multi-tty will be merged soon" but that we _really_ should get a handle on it. This is happening right now. Part of an evaluation is actually getting the stuff to compile (and then work) again on other platforms (by the way, multi-tty HEAD emacsclient does no longer compile at the moment on GNU/Linux/GTK because of some seemingly half-finished changes in connection with sockets). In parallel with the basic work on other platforms, some people might or might not be tempted to discuss the design and implications. While I am probably one of the more vocal people in that area, it does not mean that others don't form an opinion. > then perhaps emacsclient improvements should concentrate on the > version on the branch. The two versions are much different and > conflicts are sometimes hard to resolve correctly, leading to lost > fixes and new regressions. > > If we're not yet sure multi-tty is acceptable, then please ignore my > suggestion. This is unclear to me. multi-tty capability will be in Emacs 23 if we can get it to form an acceptable and stable part of Emacs. The point where a merge into trunk becomes feasible is when we have no major usability regression on _all_ platforms _and_ people agree that the basic design is sound. If there are still fundamental instead of incremental changes to be expected, a branch is a better place than the trunk. Since multi-tty is planned for Emacs 23, polishing the uni-tty emacsclient appears like a waste of effort. That does not mean that polishing the multi-tty emacsclient would be much better as long as the design is not cast into stone. At the current point of time, I should be very much surprised if we could arrive at the decision to merge multi-tty or even whether to aim for a merge before something like a month is over. Up to now, multi-tty has largely been a single-person project, with a restricted number of testers on a restricted number of platforms and uses. So you have to expect some growth pains, and it would be audacious to expect that this can happen without some fairly significant changes in the branch. And it is likely that once that I run out of yelling at the design (I am working intermittently on another detailed mail) that others will take up the buck. At the current point of time, I don't see that we are going to see this process finish at a point of time before unicode-2. I have not yet taken a look at unicode-2, however, and I seem to remember it also has some Windows-specific issues remaining (somebody correct me if I am wrong). The metric for unicode-2 would be the same: a merge into trunk seems reasonable as soon as no major functional regression can be expected to occur on all supported platforms. -- David Kastrup