Juanma Barranquero wrote:
> In the merge, the execvp wrapper for Windows has been moved to below
> the point where execvp is used; i.e, execvp is used in fail, but
> 
>  #undef execvp
>  #define execvp w32_execvp
> 
> happens quite a bit later. That's an error, I think.

That's right.  Could you please fix it?

>> I hope most people would agree that the new emacsclient features are a
>> definite improvement.
> 
> As long as the features currently in the trunk are maintained, yes.

They should be.  If anything is lost, then that's a bug.

At the very least, emacsclient works good enough not to impede unrelated
Emacs development.

>> Keep in mind that improving emacsclient behaviour is one of the primary
>> results of the multi-tty branch.
> 
> Then it should continue to be done in the multi-tty branch until
> merging it to the trunk does not represent a regression.

I don't believe it represents a regression in its current form.  As we
know, Windows support is broken, but thankfully people are working on
that now.  I argue that it is not a good idea to keep the trunk's
emacsclient a moving target.  The more changes you make to it now, the
more probable I create a new regression while merging (i.e.,
reimplementing) your changes in multi-tty.

If there is a good chance that Emacs 23 will be released without
multi-tty, then of course things are different.  I think people should
look at the code and report if it is basically sound or not.  If not,
then it's better to have that decided early than to waste more time
developing it.

You can also decide to keep a subset of multi-tty changes (C-level
changes, Lisp interface, emacsclient improvements, environment
implementation, Lisp package adaptations, etc.) and discard/reimplement
the rest.  For example, David has already expressed his dissatisfaction
with the environment implementation.

-- 
Karoly