Re: minibuffer-exit when emacsclient executes Lisp code

[rentey <address@hidden>]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <address@hidden> writes:
> 
>> 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
>>> => 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.
> 
> --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.)

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.

> 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.

(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?

> 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.

-- 
Karoly

signature.asc
Description: OpenPGP digital signature