Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup <dak@gnu.org>]

"Károly Lőrentey" <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> 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.)

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.

-- 
David Kastrup