Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup]

<address@hidden> 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