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 15:51:16 +0200 Message-ID: <86mz04ri5n.fsf@lola.quinscape.zz> References: <464A1C4B.8060504@gmail.com> <464AEAD4.8010102@gmail.com> <86hcqduh7n.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1179323492 20066 80.91.229.12 (16 May 2007 13:51:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 May 2007 13:51:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?K=C3=A1roly_L=C5=91rentey?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 15:51:29 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 1HoJua-0001FI-0i for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 15:51:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoK2Z-0002F3-21 for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 09:59:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HoK2R-000266-4S for emacs-devel@gnu.org; Wed, 16 May 2007 09:59:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HoK2Q-00025c-5h for emacs-devel@gnu.org; Wed, 16 May 2007 09:59:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoK2Q-00025X-0y for emacs-devel@gnu.org; Wed, 16 May 2007 09:59:34 -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 1HoJuP-0001ml-MM for emacs-devel@gnu.org; Wed, 16 May 2007 09:51:18 -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 PAA13039 for ; Wed, 16 May 2007 15:51:10 +0200 X-Delivered-To: Original-Received: (qmail 1644 invoked from network); 16 May 2007 13:51:16 -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 13:51:16 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 52BEF8F230; Wed, 16 May 2007 15:51:16 +0200 (CEST) In-Reply-To: (=?iso-8859-1?Q?=22K=E1roly?= Lo"'s message of "Wed\, 16 May 2007 14\:58\:40 +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:71165 Archived-At: "K=C3=A1roly L=C5=91rentey" writes: > David Kastrup wrote: >> "Lennart Borgman (gmail)" writes: >>=20 >>> Klaus Zeitler wrote: >>>> My script calls emacsclient with --eval to evaluate lisp code. >>>> Here's a simple example: >>>> 1. in your emacs do M-x to enter the minibuffer >>>> 2. in a shell type e.g.: emacsclient --eval cvs-emacs >>>> =3D> emacs quits the minibuffer >>>> >>> Unfortunately there is currently no way to distinguish your case >>> from the more normal case where emacsclient is used to open a >>> file. In the later case I think the change does what is needed, but >>> for your (a bit more unusual) usage it breaks it. >>=20 >> --eval '(find-file "xxxx") > > Well said. It is not clear to me if this bug report is for the > multi-tty branch or the trunk, but with the multi-tty emacsclient, a > more useful heuristic would be whether or not the client requested > the creation of a new frame. (Incidentally, the freeze issue was to > be resolved by better user feedback and an elaborate C-g-based > protocol to let the user manually return to top-level from frozen > frames. I like this simple approach even better.) It may be too simple (which is the common problem with simple solutions). And if one falls in love with the simplicity, one tends to build complex workarounds around it in order to be able to keep it... More at the bottom. > To reduce conflicts and parallel effort, I think people should look > at the multi-tty emacsclient, and (if possible) stop enhancing the > trunk version. The two versions are considerably different. To a degree that instead "conflicts" and "parallel effort", "wasted effort" would probably be more accurate. The multi-tty emacsclient is actually quite more similar in functionality to "gnuclient". >> I think we should probably try to address this in connection with >> another issue: a suitable way for opening a tty: open a frame only >> once it is "needed". One problem we currently have is that it is >> not really pleasing to specify Emacs frame geometries, colors, >> toolbar or menubar presence by using .emacs and/or customize: that >> way, the initial frame will first get mapped wrongly, then flicker >> into shape/position. So one would want to have a delayed mapping, >> basically happening when sit-for is called. If this point is never >> reached, we don't need a mapping at all. > > The flickering issue may not be strictly relevant for the > emacsclient case, since the parameters that apply on the new frame > are (or at least should be) already known at the time the frame is > created. Sure, that's why I wrote "in connection with another issue": maybe one problem can be solved in a way that gives an obvious solution for the other problem. > (Multi-tty) Emacs is dumped with a dummy (no-op) terminal, and > creates the first real terminal only on the second run. One way to > reduce flickering would be to delay terminal initialization until > after .emacs is loaded. Is this what you mean? Wouldn't that make > it harder to debug .emacs errors? Not really. There is -debug-init (which could well cause an immediate mapping to facilitate debugging), there is the *Message* buffer, and there might also be stderr for messages (if the process is started from some window manager or similar, stderr might still possible be available in some internal log or window or console from the window manager) while we are not yet mapped. And even if we have the equivalent of (while t) in our .emacs, having a mapped frame will probably not help significantly. Probably less than using stdin/stdout/stderr (basically, the -batch environment) would before top-level is entered the first time. Of course, this has the disadvantage that communication will have to occur keeping in mind output and keyboard locales. Maybe Emacs should retain some minimal knowledge about its controlling tty for that purpose? >> In a similar vein, if emacsclient never reaches a point where it >> would be interested in looking at tty input, maybe it is not worth >> mapping a frame (and stealing the minibuffer). Of course, the >> question when to call "top-level" remains. > > I think something like (run-at-time 0 nil 'top-level) would work fine. This is asking for trouble, since quite a lot of not-top-level code may call sit-for and consequently timers. --=20 David Kastrup