Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup <dak@gnu.org>]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Klaus Zeitler wrote:
>>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
>>     Lennart>     Lennart> Yes, it is probably due to a change a
>> while ago to avoid problems
>>     Lennart> if the minibuffer was active. How are you calling emacsclient? Is
>>     Lennart> it to open files or to eval some elisp code?
>>
>> 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
>>
>> Klaus
>
> 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")

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

-- 
David Kastrup