Updated multi-tty support for Emacs

Updated multi-tty support for Emacs

[Károly Lőrentey]

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

I have updated my Emacs patches for multi-tty support.  The new
version has (I think) pretty reliable support for multiple tty
devices.  Plus, X support has been fixed, and now it is possible to
have simultaneous termcap and X frames (although this mode is still
somewhat unstable).

The attached patch should apply cleanly against any recent CVS HEAD.
Instructions for direct access to my arch branch and the latest
patches may be found at

	http://lorentey.web.elte.hu/project/emacs.html

There is a (silly) screenshot of a tty+X combo session at

	http://lorentey.web.elte.hu/images/emacs/multi-tty-screenshot.png

Please let me know what you think about this project.  I badly need
testers, so if you think this would be useful for you, please give it
a try and tell me your results.  (Note that Mac, MSDOS and Windows
support is broken at the moment, and I will probably need some help
with these ports later.)  Please read the README.multi-tty file for
compilation instructions and known issues.

The huge size of the patch is due to my converting of dozens of global
variables into frame-local or display-local parameters.  It was a
pretty straightforward job, but I had to change a lot of code, and I
had to made a few ,,design'' decisions.  Therefore, I would also like
comments and suggestions on the implementation from knowledgeable
Emacs hackers -- please rip my code apart and tell me how
ugly/inefficient/buggy it is.

My goal is of course to have my branch merged into CVS HEAD at some
point in the future.  Long ago, when I converted from XEmacs to Emacs,
this was the one feature that I sorely missed.

Some use cases:

  * Emacs is notoriously slow at startup, so most people use another
    editor or emacsclient for quick editing jobs from the console.
    Unfortunately, emacsclient was very awkward to use, because it did
    not support opening a new Emacs frame on the current virtual
    console.  Now, with multi-tty support, it can do that.  (Note that
    emacsclient starts up even faster than vi!)

  * Some Gnus users (including me) run Gnus in an X frame in its own
    Emacs instance, which they typically leave running for weeks.  It
    would be nice if they could connect to this instance from a remote
    ssh session and check their messages without opening a remote X
    frame or resorting to gnus-slave.


[-- Attachment #2: emacs--multi-tty--0--patch-33.2004-01-02.patch.gz --]
[-- Type: application/octet-stream, Size: 94073 bytes --]

[-- Attachment #3: Type: text/plain, Size: 15 bytes --]


-- 
Károly

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

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

Re: Updated multi-tty support for Emacs

[Andreas Schwab]

lorentey@elte.hu (Károly Lőrentey) writes:

> Please let me know what you think about this project.  I badly need
> testers, so if you think this would be useful for you, please give it
> a try and tell me your results.  (Note that Mac, MSDOS and Windows
> support is broken at the moment, and I will probably need some help
> with these ports later.)

Also it won't build on any non-glibc system, due the unconditional use
of getpt() in emacsclient.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Updated multi-tty support for Emacs

[Lőrentey Károly]

Andreas Schwab <schwab@suse.de> writes:
> lorentey@elte.hu (Károly Lőrentey) writes:
>
>> Please let me know what you think about this project.  I badly need
>> testers, so if you think this would be useful for you, please give it
>> a try and tell me your results.  (Note that Mac, MSDOS and Windows
>> support is broken at the moment, and I will probably need some help
>> with these ports later.)
>
> Also it won't build on any non-glibc system, due the unconditional use
> of getpt() in emacsclient.

I fixed this by eliminating the pty-proxy kludge from emacsclient.
patch-35 compiles and runs fine on Solaris with GCC.  (I suspect I may
have inadvertently used some GCC extensions (conditional lvalues) --
tell me if you succeed to compile the branch with another compiler.)

Thanks for reporting this!

-- 
Lőrentey Károly

Re: Updated multi-tty support for Emacs

[David Kastrup]

lorentey@elte.hu (Lőrentey Károly) writes:

> Andreas Schwab <schwab@suse.de> writes:
> > lorentey@elte.hu (Károly Lőrentey) writes:
> >
> >> Please let me know what you think about this project.  I badly need
> >> testers, so if you think this would be useful for you, please give it
> >> a try and tell me your results.  (Note that Mac, MSDOS and Windows
> >> support is broken at the moment, and I will probably need some help
> >> with these ports later.)
> >
> > Also it won't build on any non-glibc system, due the unconditional use
> > of getpt() in emacsclient.
> 
> I fixed this by eliminating the pty-proxy kludge from emacsclient.
> patch-35 compiles and runs fine on Solaris with GCC.  (I suspect I
> may have inadvertently used some GCC extensions (conditional
> lvalues) -- tell me if you succeed to compile the branch with
> another compiler.)

Conditional lvalues _are_ a GNU extension.  You can work around by
saying something like

*(condition ? &a : &b) = ...

but it will in general be better just to write

if (condition)
  a = ...;
else
  b = ...;

Even if a stupid compiler does not catch the code duplication, only
one branch gets executed, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Updated multi-tty support for Emacs

[Lőrentey Károly]

David Kastrup <dak@gnu.org> writes:
> lorentey@elte.hu (Lőrentey Károly) writes:
>> (I suspect I may have inadvertently used some GCC extensions
>> (conditional lvalues) -- tell me if you succeed to compile the
>> branch with another compiler.)
>
> Conditional lvalues _are_ a GNU extension.

Yep, I know; I suspect I may have accidently used some rvalue macros
like FRAME_TTY as lvalues.  I tried not to, but you never know.  Is
there a gcc option to disable these cumbersome non-portable
extensions?  I will try a recompilation with -pedantic tomorrow, to
see what happens.

-- 
Károly

Re: Updated multi-tty support for Emacs

[David Kastrup]

lorentey@elte.hu (Lőrentey Károly) writes:

> David Kastrup <dak@gnu.org> writes:
> > lorentey@elte.hu (Lőrentey Károly) writes:
> >> (I suspect I may have inadvertently used some GCC extensions
> >> (conditional lvalues) -- tell me if you succeed to compile the
> >> branch with another compiler.)
> >
> > Conditional lvalues _are_ a GNU extension.
> 
> Yep, I know; I suspect I may have accidently used some rvalue macros
> like FRAME_TTY as lvalues.  I tried not to, but you never know.  Is
> there a gcc option to disable these cumbersome non-portable
> extensions?  I will try a recompilation with -pedantic tomorrow, to
> see what happens.

Well, you could try with -ansi -pedantic.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Updated multi-tty support for Emacs

[Andreas Schwab]

lorentey@elte.hu (Károly Lőrentey) writes:

> I have updated my Emacs patches for multi-tty support.  The new
> version has (I think) pretty reliable support for multiple tty
> devices.  Plus, X support has been fixed, and now it is possible to
> have simultaneous termcap and X frames (although this mode is still
> somewhat unstable).

I have now tried out your patch and have a few fatal issues:

- Starting Emacs in X with stdin redirected (which is the normal case
  when starting from a window manager) causes it to exit immediately
  with SUGHUP.

- The same happens with a non-X Emacs after having used "emacsclient
  -t" at least once and calling delete-frame (which should give an
  error instead for trying to delete the only frame).

Another minor error: emacsclient --frame doesn't work (it is mapped
to "-f" which is not a valid option).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Updated multi-tty support for Emacs

[Lőrentey Károly]

Andreas Schwab <schwab@suse.de> writes:
> I have now tried out your patch and have a few fatal issues:
>
> - Starting Emacs in X with stdin redirected (which is the normal case
>   when starting from a window manager) causes it to exit immediately
>   with SUGHUP.
>
> - The same happens with a non-X Emacs after having used "emacsclient
>   -t" at least once and calling delete-frame (which should give an
>   error instead for trying to delete the only frame).

Oops, there is a serious bug during initialization.  I will fix this
as soon as possible.

> Another minor error: emacsclient --frame doesn't work (it is mapped
> to "-f" which is not a valid option).

I think this is fixed in the latest revisions.

Thanks for the bug reports!

-- 
Károly

(Note: The holidays are over, so I can't hack Emacs full time anymore;
please allow me a few days to answer multi-tty-related messages.  I am
continuing development, albeit a little slower.)

Re: Updated multi-tty support for Emacs

[Lőrentey Károly]

Lőrentey Károly <lorentey@elte.hu> writes:
> Andreas Schwab <schwab@suse.de> writes:
>> I have now tried out your patch and have a few fatal issues:
>>
>> - Starting Emacs in X with stdin redirected (which is the normal case
>>   when starting from a window manager) causes it to exit immediately
>>   with SUGHUP.

OK, patch-49 has a fix for this and similar issues.  It works by
defining a dummy output device (with empty input/output hooks), and
using that instead of a real termcap device during the Emacs bootstrap
procedure (until init_display).

-- 
Károly