Re: support for tty frames from windowed emacs session

Re: support for tty frames from windowed emacs session

[Kim F. Storm]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: "Anthony R. Cassandra" <arc@cassandra.org>
> > Date: Fri, 7 Mar 2003 18:37:44 -0600
> > 
> >   "Note that creating a frame on a tty (via "gnuclient -nw ...") does
> >    not work.  GNU Emacs doesn't support this functionality."
> > 
> > Is the README accurate in its statement?
> 
> Yes, AFAIK.

I would like to know more specifically what functionality is
requested here.  What qualifies as a "tty" in this regard?
A serial port, a pty, etc?

> 
> > Myself and some others would really like this functionality, and I
> > want to see if it is worth exploring trying to make it happen.
> 
> Please do.  IMHO, this is an important feature that needs motivated
> individuals willing to sit down and code it.
> 

I never thought I needed this -- why is it important?

Maybe to have multiple displays using dumb TTYs attached to serial ports?
But who has a TTY anymore?

What kind of TERMINFO entry would be used for the tty?

If we create more than one such frame on different ttys, should they
be able to use different TERMINFO entries?

What about the setup of the tty (ioctls, etc)?  Shall emacs do that?


> > Are there major technical problems, philosophical problems or is it
> > simply as matter of having the appropriate man-power for a lower
> > priority feature?
> 
> The latter, I think.  But I don't think this is regarded as lower
> priority; it's just that the available resources are so scarce that
> even important features are not worked on.

Although there might not be _major_ technical problems, I don't think
it will be trivial to implement.

> 
> I suggest to move the rest of this discussion to emacs-devel@gnu.org.

Done :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: support for tty frames from windowed emacs session

[Alex Schroeder]

storm@cua.dk (Kim F. Storm) writes:

> I never thought I needed this -- why is it important?

You work at home using X and leave the session running.  At work, you
ssh to your home machine and want to access the same Emacs session.
You don't have X at work.  So you can't tunnel some X to work...

Alex.

Re: support for tty frames from windowed emacs session

[Romain FRANCOISE]

Alex Schroeder <alex@gnu.org> writes:

>> I never thought I needed this -- why is it important?

> You work at home using X and leave the session running.  At work, you
> ssh to your home machine and want to access the same Emacs session.
> You don't have X at work.  So you can't tunnel some X to work...

This is one case, another would be the one where you leave Emacs running
in GNU screen on one machine then create X frames from there on other
machines (or the same).

-- 
Romain FRANCOISE <romain@orebokech.com> | I live my life alone, alone,
it's a miracle -- http://orebokech.com/ | I think I like it this way.

Re: support for tty frames from windowed emacs session

[Anthony R. Cassandra]

>I would like to know more specifically what functionality is
>requested here.  What qualifies as a "tty" in this regard?
>A serial port, a pty, etc?

>From any sort of non-X/windowed terminal.

>I never thought I needed this -- why is it important?

Here a common situation: I have my home machine and my work machine,
both running gnu-emacs in X, both with their own context including
normal files and especially email buffers (separate email accounts).

These are two separate contexts, as my work and email logically should
and are separated.  However, from home I want access to my work
context and from work I want access to my home context (both via ssh).
Since both these machines are behind firewalls, getting an X
connections forwarded (even with ssh) is not always easy or desirable
(such as if I want to access via an MSWindoze ssh client.)  What I
presently have to do is ensure that I have quit my email (vm) before
leaving work or leaving home because vm is quite tempermental if
another emacs session has accessed its INBOX.

I would prefer to establish my ssh connection (via an xterm, but
without X forwarded) and just connect to the running emacs on the
remote machine.  Essentially I want the same behavior as
'make-frame-on-display' gives me, only without the reliance on X.

BTW: xemacs along with gnuserv/"gnuclient -nw" gives exactly this
functionality "out-of-the-box" (my friend confirmed this last night).

>What kind of TERMINFO entry would be used for the tty?

I am not intimately familiar with all the possible terminfo and
termcap stuff aside from knowing there is a lot of cryptic syntax to
figue out and a lot of possible cases to worry about.  Personally, I'd
be happy if is just supported some basic terminal types such as what
is established via my ssh connection in the xterm.  However, the
developer side of my personality would probably not be satisfied with
a point solution, and would want to solve the whole problem.

>What about the setup of the tty (ioctls, etc)?  Shall emacs do that?

These are exactly the sorts of issues I am not currently familiar
enough with, which is why I am hoping someone with a little more
experience in these areas could give me a sort of feasibility
assessment on the effort required to add this support.

>Although there might not be _major_ technical problems, I don't think
>it will be trivial to implement.

Yes, I believe to do it properly would not be, though this is just
based on my cursory looks, and the bewilderment I experience, in
termcap files.

-tony

Re: support for tty frames from windowed emacs session

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 08 Mar 2003 23:06:23 +0100
> 
> I would like to know more specifically what functionality is
> requested here.

It's in etc/TODO:

  * Support simultaneous tty and X frames.

> What qualifies as a "tty" in this regard?

Any character-mode display, I think.

> I never thought I needed this -- why is it important?

Alex explained why.

> If we create more than one such frame on different ttys, should they
> be able to use different TERMINFO entries?

Probably.

> Although there might not be _major_ technical problems, I don't think
> it will be trivial to implement.

Trivial, no.  But neither is it rocket science, I think.

Re: support for tty frames from windowed emacs session

[Kim F. Storm]

Alex Schroeder <alex@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I never thought I needed this -- why is it important?
> 
> You work at home using X and leave the session running.  At work, you
> ssh to your home machine and want to access the same Emacs session.

I can see that this is useful, yes.

> You don't have X at work.  So you can't tunnel some X to work...

So, from the user's pov, running gnuclient -nw in, say xterm, would
behave like running emacs -nw, except that it will connect to the
running emacs and use the xterm as the tty, rather than starting a new
emacs on the xterm tty.

Although this is conceptually different from a make-frame-on-tty
function which would be useful to make an emacs frame on any tty
device, it would probably use the same fundamental code.

So it mostly boils down to supporting both windowing and non-windowing
frames at the same time.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: support for tty frames from windowed emacs session

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 09 Mar 2003 16:52:11 +0100
> 
> So it mostly boils down to supporting both windowing and non-windowing
> frames at the same time.

Yes.  IIRC, currently we have lots of code that assumes all frames
are of the same type.

Re: support for tty frames from windowed emacs session

[Kim F. Storm]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: storm@cua.dk (Kim F. Storm)
> > Date: 09 Mar 2003 16:52:11 +0100
> > 
> > So it mostly boils down to supporting both windowing and non-windowing
> > frames at the same time.
> 
> Yes.  IIRC, currently we have lots of code that assumes all frames
> are of the same type.

It seems that a major obstacle is that `window-system' (and similar)
is a variable rather than a function taking a frame as argument.

We might be able to tweak it at the C level so that reading
window-system reflects the window-system of the selected frame, but
that may not be sufficient.

How does Xemacs solve this?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: support for tty frames from windowed emacs session

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 09 Mar 2003 22:58:35 +0100
> 
> It seems that a major obstacle is that `window-system' (and similar)
> is a variable rather than a function taking a frame as argument.

That's one problem, yes.

I think there's more to it, though.  It might be that the C display
code only uses either the X path or the tty path, but not both.  But
I'm not sure, and don't have time to refresh my memory by looking at
the code, sorry.

Re: support for tty frames from windowed emacs session

[Richard Stallman]

    I think there's more to it, though.  It might be that the C display
    code only uses either the X path or the tty path, but not both.  But
    I'm not sure, and don't have time to refresh my memory by looking at
    the code, sorry.

That would be easy to fix.

    > It seems that a major obstacle is that `window-system' (and similar)
    > is a variable rather than a function taking a frame as argument.

We would want to get rid of all uses of window-system.
We already have a way to check whether a display has a window system:
display-multi-frame-p.