multi-tty branch created

multi-tty branch created

[Miles Bader]

Ok, I've put the multi-tty sources into CVS and arch branches on
savannah.

The CVS branch tag is called "multi-tty".

The arch branch is "emacs@sv.gnu.org/emacs--multi-tty--0".

-miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: multi-tty branch created

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Ok, I've put the multi-tty sources into CVS and arch branches on
> savannah.
>
> The CVS branch tag is called "multi-tty".
>
> The arch branch is "emacs@sv.gnu.org/emacs--multi-tty--0".

Good!  Of the people using not yet supported architectures, are there
some who would be willing to "pull a fast one", trying to pummel the
stuff until it compiles?  If it turns out that we can reach a state in
multitty which is _usable_ (not necessarily bugfree) for every party
involved at least in the use cases that worked previously, it might
actually work merging it into the trunk first or at least fast.

I don't know how others feel about it, but my personal feeling is that
_if_ we can have a basically regression-free multitty on all platforms
soon, it would help to speed the Emacs 23 development process.

Apart from the not yet supported platforms, people should of course
also try multitty on those platforms that are supposed to be
supported.

What is the current state of synchronization between trunk and
multi-tty?

Anyway, now looking for the required disk space...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: multi-tty branch created

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> What is the current state of synchronization between trunk and
> multi-tty?

The last sync-point on the trunk has the tag "multi-tty-base".

-miles

-- 
We live, as we dream -- alone....

Re: multi-tty branch created

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>> What is the current state of synchronization between trunk and
>> multi-tty?
>
> The last sync-point on the trunk has the tag "multi-tty-base".

Thanks.  I did a diff already, and it seems like just some very recent
changes are missing here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: multi-tty branch created

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> Ok, I've put the multi-tty sources into CVS and arch branches on
>> savannah.
>>
>> The CVS branch tag is called "multi-tty".
>>
>> The arch branch is "emacs@sv.gnu.org/emacs--multi-tty--0".
>
> Good!

I've checked it out, compiled it, not yet used it.  README.multi-tty
does not yet reflect the availability on Savannah.  It also sports
quite a list of problematic areas, but those seem to be no regressions
per se and should not make things worse mostly.  Is the GTK+ situation
as described in there?  My current version is 2.10.11, so it _might_
work for the multiple X case, but README.multi-tty basically mentions
2.10 as something to come into being only in the future:

   Update: I am still having problems with GTK+ 2.8.10.  I have the
   impression that the various multidisplay fixes will only get
   released in GTK+ 2.10.

One thing that is mentioned that calling emacsclient from a different
user will not work.  I think that this is really a non-issue since
file accessibility from a different user would also be different and
there is no really useful strategy short of using tramp for getting
this to work.

It might be at some point be interesting to write a "trampclient"
which pingpongs the data across an emacsclient socket or a pseudotty
or whatever, but I don't think that this should for now be considered.

emacsclient operation in multitty is different as compared to
previously.  So people can't avoid multitty completely, meaning that
we can't bluntly state "situation can't be worse than previously, no
regression" but need to evaluate multitty somewhat more closely before
finding it suited for trunk, even if the compilation problems on
DOS/Windows/Mac have been tackled.

The precondition for trunk in my opinion would be that it does not
impede workability for those people who are working on different parts
of Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: multi-tty branch created

[Robert J. Chassell]

Today's CVS snapshot of the multi-tty branch, Sun, 2007 May 13 16:56 UTC
GNU Emacs 23.0.51.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20, multi-tty)

    Debian GNU/Linux, testing, on a i686
    Linux kernel:  2.4.25 

seems to work fine; that is to say, I downloaded and built it, ran
another instance in X with an Enlightenment window manager and, at the
same time, text instances, one in an RXVT shell in Enlightenment using
emacsclient -t and another in a virtual console.

(GTK has been working fine.  I have been running earlier versions
using baz for version control.)
    
-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: multi-tty branch created

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 2148 bytes --]

David Kastrup wrote:
> I've checked it out, compiled it, not yet used it.  README.multi-tty
> does not yet reflect the availability on Savannah.

I updated it a little.

> Is the GTK+ situation as described in there?

No, it has much improved.  AFAIK GTK still doesn't fully support
multiple displays, but the remaining bugs are mostly memory leaks, not
crashes.

> One thing that is mentioned that calling emacsclient from a different
> user will not work.  I think that this is really a non-issue since
> file accessibility from a different user would also be different and
> there is no really useful strategy short of using tramp for getting
> this to work.

I agree with your reasoning but the item is about something slightly
different:

	Login: fred
	Password:
	fred$ emacs
		M-x server-start

Meanwhile, in another session:

	Login: barney
	Password:
	barney$ su fred
	Password:
	fred$ emacsclient -t
	(Fails due to Emacs not being able to open the tty device.)

The use case: fred sits down before barney's console to show him
something under his own account.

> emacsclient operation in multitty is different as compared to
> previously.  So people can't avoid multitty completely, meaning that
> we can't bluntly state "situation can't be worse than previously, no
> regression" but need to evaluate multitty somewhat more closely before
> finding it suited for trunk, even if the compilation problems on
> DOS/Windows/Mac have been tackled.

Hold your horses.  There is always "emacsclient --current-frame" to
prevent emacsclient from creating a new terminal.  This retains much of
the functionality of the original emacsclient, including, I believe,
things like C-#, and does not use multi-tty features.

I hope most people would agree that the new emacsclient features are a
definite improvement.

> The precondition for trunk in my opinion would be that it does not
> impede workability for those people who are working on different parts
> of Emacs.

Keep in mind that improving emacsclient behaviour is one of the primary
results of the multi-tty branch.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On 5/16/07, Károly Lo"rentey <karoly@lorentey.hu> wrote:

> There is always "emacsclient --current-frame" to
> prevent emacsclient from creating a new terminal.  This retains much of
> the functionality of the original emacsclient, including, I believe,
> things like C-#, and does not use multi-tty features.

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.

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

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

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 1924 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[David Kastrup]

Károly Lőrentey <karoly@lorentey.hu> 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

Re: multi-tty branch created

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 1459 bytes --]

David Kastrup wrote:
> Károly Lőrentey <karoly@lorentey.hu> writes:
>> 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.

Clearly, I meant that it does not represent a regression for UN*X users.
 That's why there was a second sentence after the first.  I wasn't
arguing for putting anything on the trunk *now*.  I was simply asking
for consideration of my time when changes are made to emacsclient on the
trunk.  My Emacs-related work load has suddenly increased, and topping
it with extra merging work is really not welcome.  Is that an
unreasonable viewpoint?

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

Yes, the current problem is simply a side-effect of the much needed
porting effort.  This phase will pass soon.

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

OK.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Jason Rumney]

David Kastrup wrote:
> 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.
>   

That was my fault. A variable was moved from main() to global scope in 
the multi-tty branch, which broke the Windows build for reasons I did 
not understand. But I could not find any real use of that variable 
outside main() so I tried moving it back. It turned out that the use of 
that global variable was hidden inside a macro in code that is 
conditionally compiled only when there are file system sockets (ie, not 
Windows) so I missed it.

I have now renamed it to avoid confusion with the many other local 
variables of the same name that shadow it, and fixed the original bug by 
moving its definition below the header file it depends on.

Re: multi-tty branch created

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On 5/16/07, Károly Lo"rentey <karoly@lorentey.hu> wrote:
  > 
  > > There is always "emacsclient --current-frame" to
  > > prevent emacsclient from creating a new terminal.  This retains much of
  > > the functionality of the original emacsclient, including, I believe,
  > > things like C-#, and does not use multi-tty features.
  > 
  > 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.

I fixed that in CVS. 

Re: multi-tty branch created

[David Kastrup]

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

> David Kastrup wrote:
>
>> One thing that is mentioned that calling emacsclient from a
>> different user will not work.  I think that this is really a
>> non-issue since file accessibility from a different user would also
>> be different and there is no really useful strategy short of using
>> tramp for getting this to work.
>
> I agree with your reasoning but the item is about something slightly
> different:
>
> 	Login: fred
> 	Password:
> 	fred$ emacs
> 		M-x server-start
>
> Meanwhile, in another session:
>
> 	Login: barney
> 	Password:
> 	barney$ su fred
> 	Password:
> 	fred$ emacsclient -t
> 	(Fails due to Emacs not being able to open the tty device.)
>
> The use case: fred sits down before barney's console to show him
> something under his own account.

Still a non-issue in my book: the same won't work with X frames,
either, unless the X11 authentication is seriously insecure.

The way to do this kind of thing is an ssh session, and those will
work with either text or X11.

>> emacsclient operation in multitty is different as compared to
>> previously.  So people can't avoid multitty completely, meaning
>> that we can't bluntly state "situation can't be worse than
>> previously, no regression" but need to evaluate multitty somewhat
>> more closely before finding it suited for trunk, even if the
>> compilation problems on DOS/Windows/Mac have been tackled.
>
> Hold your horses.

You would not want me to: my concerns are likely similar to those of
others, so you want to get them discussed and refuted.

> There is always "emacsclient --current-frame" to prevent emacsclient
> from creating a new terminal.  This retains much of the
> functionality of the original emacsclient, including, I believe,
> things like C-#, and does not use multi-tty features.

Still, environments do no longer work the same even if you don't use
multi-tty features.

> I hope most people would agree that the new emacsclient features are
> a definite improvement.

We are not talking about the features when wanting to avoid
regressions.

>> The precondition for trunk in my opinion would be that it does not
>> impede workability for those people who are working on different
>> parts of Emacs.
>
> Keep in mind that improving emacsclient behaviour is one of the
> primary results of the multi-tty branch.

But we don't want secondary results interfering with the work of those
who don't make use of the primary results.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: multi-tty branch created

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 3174 bytes --]

David Kastrup wrote:
> "Károly Lőrentey" <karoly@lorentey.hu> writes:
>>> emacsclient operation in multitty is different as compared to
>>> previously.  So people can't avoid multitty completely, meaning
>>> that we can't bluntly state "situation can't be worse than
>>> previously, no regression" but need to evaluate multitty somewhat
>>> more closely before finding it suited for trunk, even if the
>>> compilation problems on DOS/Windows/Mac have been tackled.
>> Hold your horses.
> 
> You would not want me to: my concerns are likely similar to those of
> others, so you want to get them discussed and refuted.

Yes.  But saying that multi-tty is somehow more suspect because it
changes emacsclient sounds strange to me.  Well of course it changes it.
 The entire point of the branch is to fix how emacsclient works.  D'oh!

I was arguing that all the existing functionality is retained by design.
 If there is a feature that was lost, then that's a bug.

>> There is always "emacsclient --current-frame" to prevent emacsclient
>> from creating a new terminal.  This retains much of the
>> functionality of the original emacsclient, including, I believe,
>> things like C-#, and does not use multi-tty features.
> 
> Still, environments do no longer work the same even if you don't use
> multi-tty features.

Yes they do.  "emacsclient --current-frame" does not create a new set of
local environment variables, but reuses the original environment of the
Emacs process.  It should work exactly the same as emacsclient on the
trunk.  Does it not?

As I said, the one and only truly incompatible change in the multi-tty
branch is that even without any emacsclient connections,
`process-environment' is nil by default, and there is a new
`environment' function for listing all variables.  I don't think you can
argue with a straight face that all hell will break loose if we make
such a change, or that it is unacceptable to make our hackers adapt
existing code for these changes.  After all, we are working on a new
major version, and there aren't all that many Emacs packages that care
about environment variables.  A sizable portion of the few that do
simply call getenv and setenv, or let-bind `process-environment', which
works fine with multi-tty as well.  I have presented my reasons for the
change; I still think the client-local environment semantics are the
right way to go, although the implementation may be improved.

>> Keep in mind that improving emacsclient behaviour is one of the
>> primary results of the multi-tty branch.
> 
> But we don't want secondary results interfering with the work of those
> who don't make use of the primary results.

As I have explained, "emacsclient --current-frame" is the way people can
get back the original behaviour.  If there are serious bugs, the legions
of people who're now testing multi-tty will likely report them before
the merge.  Is that not sufficient to prevent undue interference?

I encourage people on supported platforms to try their favourite
emacsclient options in the multi-tty branch, and report anything that
breaks.

-- 
Karoly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Stefan Monnier]

> Hold your horses.  There is always "emacsclient --current-frame" to
> prevent emacsclient from creating a new terminal.  This retains much of
> the functionality of the original emacsclient, including, I believe,
> things like C-#, and does not use multi-tty features.

For the sake of transparent backward compatibility, I'd make --current-frame
the default, and use -nw as an argument to force the use of the new
multi-tty feature.  This way you only get the new feature when you ask
for it.  I normally prefer using an X11 frame over a tty frame, so I'd only
want to use -nw in those cases where it matters (typically when the
bandwidth is limited).


        Stefan

Re: multi-tty branch created

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 1081 bytes --]

Stefan Monnier wrote:
> For the sake of transparent backward compatibility, I'd make --current-frame
> the default,  and use -nw as an argument to force the use of the new
> multi-tty feature.  This way you only get the new feature when you ask
> for it.  I normally prefer using an X11 frame over a tty frame, so I'd only
> want to use -nw in those cases where it matters (typically when the
> bandwidth is limited).

You assume that emacsclient now opens a tty frame even if X is
available.  That's not the case.  Emacsclient works like Emacs: it
prefers X, and falls back to the tty only if X is unavailable or the
user forces opening a tty frame by supplying "-t" (the emacsclient
equivalent to "-nw").

	$ emacsclient
		==> X frame
	$ emacsclient -t
		==> tty frame
	$ emacsclient -c
		==> no new frame

I agree that "-t" should be renamed "-nw"; in fact this idea is even in
the README file.  However, multi-character short options are a pain to
implement.  I'd prefer if someone with more getopt experience would do
it instead. :-)

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Stefan Monnier]

>> For the sake of transparent backward compatibility, I'd make --current-frame
>> the default,  and use -nw as an argument to force the use of the new
>> multi-tty feature.  This way you only get the new feature when you ask
>> for it.  I normally prefer using an X11 frame over a tty frame, so I'd only
>> want to use -nw in those cases where it matters (typically when the
>> bandwidth is limited).

> You assume that emacsclient now opens a tty frame even if X is
> available.  That's not the case.  Emacsclient works like Emacs: it
> prefers X, and falls back to the tty only if X is unavailable or the
> user forces opening a tty frame by supplying "-t" (the emacsclient
> equivalent to "-nw").

> 	$ emacsclient
> 		==> X frame

There are *many* different ways to create new frames (one per "session",
one per file, reuse old ones or not, ...).  I hope you got it right ;-)

> 	$ emacsclient -t
> 		==> tty frame
> 	$ emacsclient -c
> 		==> no new frame

Maybe it's OK.  Note that when I added the --display argument, I was
careful to not automatically use the $DISPLAY envvar, in order to preserve
backward compatibility, so users have to say --display "$DISPLAY" if they
want it.

My experience with Emacs is that when introducing a new feature, any minor
backward incompatibility will slow down adoption, so it's easier to just let
new features disabled by default.  See the comment-style variable for
another example ;-)

> I agree that "-t" should be renamed "-nw"; in fact this idea is even in
> the README file.  However, multi-character short options are a pain to
> implement.  I'd prefer if someone with more getopt experience would do
> it instead. :-)

I see.  Yes, it's a problem with the current argument scheme, indeed.


        Stefan

Re: multi-tty branch created

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 1373 bytes --]

Stefan Monnier wrote:
>> 	$ emacsclient
>> 		==> X frame
> 
> There are *many* different ways to create new frames (one per "session",
> one per file, reuse old ones or not, ...).  I hope you got it right ;-)

I hope so as well, but there is always room for tweaking the defaults if
I happened to choose something wrong.

I find that the current default settings fit me like a glove, but that's
no big wonder. :-)  I'm very interested in what others think about the
behaviour of emacsclient, and if there is anything that doesn't work for
them as well as it could.

> Maybe it's OK.  Note that when I added the --display argument, I was
> careful to not automatically use the $DISPLAY envvar, in order to preserve
> backward compatibility, so users have to say --display "$DISPLAY" if they
> want it.

Emacsclient can now consistently open a frame even if X is not
available, so I would argue existing users will find the new default
easier to use as well.  If they do object, but only then, should we
consider reverting the default to the old behaviour.  I personally find
the new emacsclient is really rather more pleasant to use than the old
one.

I wouldn't like to hide the new feature set because we're afraid
somebody somewhere might find it offensive, but if people did object,
then I'd easily accept such a decision.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Stefan Monnier]

> I wouldn't like to hide the new feature set because we're afraid
> somebody somewhere might find it offensive, but if people did object,
> then I'd easily accept such a decision.

Usually, it's not due to a fear that someone somewhere will not like it, but
that someone right here finds it plain wrong.


        Stefan

Re: multi-tty branch created

[Jason Rumney]

Miles Bader wrote:
> Ok, I've put the multi-tty sources into CVS and arch branches on
> savannah.
>
> The CVS branch tag is called "multi-tty".
>
> The arch branch is "emacs@sv.gnu.org/emacs--multi-tty--0".
>
> -miles
>   

Is the branch using a specific ChangeLog file, like ChangeLog.unicode on 
the emacs-unicode-2 branch?

I've fixed my first compilation error - some MULTI_KBOARD specific code 
was added to keyboard.c without being in a conditional block.
Next there are 20 compilation errors in w32console.c, which is what I 
was expecting.

Re: multi-tty branch created

[Karoly Lorentey]

Jason Rumney wrote:
> Is the branch using a specific ChangeLog file, like ChangeLog.unicode on
> the emacs-unicode-2 branch?

Not yet.  A file such as that will show up once we had a chance to
convert the Arch logs into a flat file.

> I've fixed my first compilation error - some MULTI_KBOARD specific code
> was added to keyboard.c without being in a conditional block.
> Next there are 20 compilation errors in w32console.c, which is what I
> was expecting.

Sounds promising.  The branch relies on MULTI_KBOARD being enabled; you
can even consider the entire branch an extension of that feature.  I
suggest enabling it everywhere; it has negligible costs.

-- 
Karoly

Re: multi-tty branch created

[Jason Rumney]

Karoly Lorentey wrote:
> Sounds promising.  The branch relies on MULTI_KBOARD being enabled; you
> can even consider the entire branch an extension of that feature.  I
> suggest enabling it everywhere; it has negligible costs.
>   

It does not rely on it that much. Only a three or four such errors were 
present, and they were easily taken care of with #ifdef MULTI_KBOARD blocks.
My objective at the moment is to get the w32 port compiling, linking and 
generally working with the featureset of emacs 22. That is the point 
that is required for merging to the branch I think. Further work on 
porting the multiple keyboard support etc to w32 will just slow that 
progress down at this stage.

Re: multi-tty branch created

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 790 bytes --]

Jason Rumney wrote:
> Karoly Lorentey wrote:
>> Sounds promising.  The branch relies on MULTI_KBOARD being enabled; you
>> can even consider the entire branch an extension of that feature.  I
>> suggest enabling it everywhere; it has negligible costs.
> 
> It does not rely on it that much. Only a three or four such errors were
> present, and they were easily taken care of with #ifdef MULTI_KBOARD
> blocks.

OK, that sounds fine.  We can work on such niceties later, if indeed it
is a good idea at all.

> My objective at the moment is to get the w32 port compiling, linking and
> generally working with the featureset of emacs 22. That is the point
> that is required for merging to the branch I think. 

You are right; thank you for working on this.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch created

[Ken Raeburn]

On May 14, 2007, at 06:21, Karoly Lorentey wrote:
> Jason Rumney wrote:
>> Is the branch using a specific ChangeLog file, like  
>> ChangeLog.unicode on
>> the emacs-unicode-2 branch?
>
> Not yet.  A file such as that will show up once we had a chance to
> convert the Arch logs into a flat file.

If ChangeLog.multi-tty is where new changes in CVS are to be logged,  
creation of the file doesn't have to wait for the Arch log  
conversion, does it?  Just fill in the earlier log data once the  
conversion is done, and in the meantime, work being done now can be  
logged.

Ken

Re: multi-tty branch created

[Manoj Srivastava]

Hi,
On Sun, 13 May 2007 22:31:55 +0900, Miles Bader <miles@gnu.org> said: 

> Ok, I've put the multi-tty sources into CVS and arch branches on
> savannah.
> The arch branch is "emacs@sv.gnu.org/emacs--multi-tty--0".

        I have successfully branched this privately, applied a set of
 changes that make it a better fit for a Debian system, and compiled,
 built, and used it on a Debian machine using fvwm (as opposed to  a
 desktop environment).  The multi-tty binary behaves nominally. 

        manoj
-- 
If the facts don't fit the theory, change the facts. Albert Einstein
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C