emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-tty branch created


From: David Kastrup
Subject: Re: multi-tty branch created
Date: Wed, 16 May 2007 17:34:13 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Károly Lőrentey <address@hidden> writes:

> Juanma Barranquero wrote:
>
>> 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.

Uh what?  In its current form, Windows support is broken but it does
not represent a regression?  We must have different definitions of
"regression" then.  Actually, at the moment emacsclient does not
compile which _is_ a regression.  And such regressions will
_certainly_ occur until we get this to compile on all platforms.

make[1]: Entering directory `/rep/emacs-build/lib-src'
gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/rep/emacs/lib-src 
-I/rep/emacs/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -g -O2 
-fno-crossjumping /rep/emacs/lib-src/emacsclient.c  -DVERSION="\"23.0.51\"" -lc 
-o emacsclient
/rep/emacs/lib-src/emacsclient.c: In function ‘handle_sigcont’:
/rep/emacs/lib-src/emacsclient.c:960: error: ‘s’ undeclared (first use in this 
function)
/rep/emacs/lib-src/emacsclient.c:960: error: (Each undeclared identifier is 
reported only once
/rep/emacs/lib-src/emacsclient.c:960: error: for each function it appears in.)
/rep/emacs/lib-src/emacsclient.c: In function ‘handle_sigtstp’:
/rep/emacs/lib-src/emacsclient.c:984: error: ‘s’ undeclared (first use in this 
function)
make[1]: *** [emacsclient] Error 1
make[1]: Leaving directory `/rep/emacs-build/lib-src'
make: *** [lib-src] Error 2

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

My first impression is the following: there are serious design and use
problems that need to be addressed before finalizing the merge.  It
would appear, however, that multi-tty went through several stages in
the course of its development that were rather close to what would
constitute a robust design.  So scrapping the branch and
reimplementing from scratch would appear quite nonsensical, and the
design discussion will also be helped by you having actual experience
with several approaches.

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

I am still putting together some more detailed critique.  Note that
getting me satisfied is not the same as getting everybody else
satisfied, but of course addressing points raised by me on the list
will help your case also with other people choosing to mostly listen
at the moment.

It is quite too early to predict how things will progress.  My
impression is that the multi-tty branch is on a good track (and it
quite helps that you are not trying to block contributions and
criticism).  That's not enough to put forward a plan, but it's a good
sign.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]