groupware question

groupware question

[Robert J. Chassell]

Is anyone on this list using the groupware feature in Emacs mentioned
in

    (emacs)Multiple Displays

With `make-frame-on-display', two or more people, close together or
far apart, can work on the same file at the same time.  Is this not
what `extreme programmers' so sometimes, or two people writing
documentation together?  I do not use the feature because I use a
dial-up telephone connection that is too slow for a remote display
using X.  However, I imagine it is a wonderful feature, but wonder how
it works out in practice.

(I would love someone to take the code in, say, tramp and enable
connections to character-only terminals as well as to X sessions.
Unfortunately, I don't know how to do this.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: groupware question

[Stephen J. Turnbull]

>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:

    Robert> (I would love someone to take the code in, say, tramp and
    Robert> enable connections to character-only terminals as well as
    Robert> to X sessions.  Unfortunately, I don't know how to do
    Robert> this.)

If you understand the security implications and can live with them,
wouldn't enabling TCP/IP with emacsclient do what you want?  (Using
emacsclient on a local terminal would only annoy the remote X user, of
course!)

I've done cooperative editing this way, by the way, and discovered
that I really don't want to work that way with the person I tried it
with.  He kept making typos, and correcting my indentation style.
Unforgivable!  ;-)

We found a second Emacs window on a temp buffer for chat (or it could
visit a log file) was useful.

We also found that it was hard (in XEmacs, GNU Emacs might do better)
to keep the window-frame mapping consistent across frames (eg, if one
of you does find-tag, the other doesn't automatically see the result
if it's a different buffer).

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: groupware question

[Robert J. Chassell]

       Robert> (I would love someone to take the code in, say, tramp and
       Robert> enable connections to character-only terminals ....

   If you understand the security implications and can live with them,
   wouldn't enabling TCP/IP with emacsclient do what you want?  (Using
   emacsclient on a local terminal would only annoy the remote X user, of
   course!)

I never thought of that!  Thank you.  Unfortunately, I cannot figure
out what to do.  I just tried and failed.  :-(

What do I do?  Here is the situation:  I have a non-root account, bob,
on two machines, 123.456.789.123 [that remote machine has no name] and
on megalith.rattlesnake.com [my machine].  I am running X on my
machine.  I connect to the remote machine twice using ssh over a slow
telephone connection.  So now I have two xterms connected to
123.456.789.123.

On one remote connection I start `emacs -nw -f server-start'.  That
is fine.  On the other remote connection, I start `emacsclient foo'.

That starts an Emacs window in the xterm showing first remote
connection, the one where I started `emacs -nw -f server-start'.

How do I get it to show the file in the xterm showing the other
remote connection?



   I've done cooperative editing this way, by the way, and discovered
   that I really don't want to work that way with the person I tried it
   with.  He kept making typos, and correcting my indentation style.
   Unforgivable!  ;-)

I feared this sort of thing can be a problem.  But I have enjoyed
good, cooperative work with people, so I think it depends on the
person and the situation.

   We found a second Emacs window on a temp buffer for chat (or it could
   visit a log file) was useful.

Yes, this makes good sense.  I would think in terms of one frame,
which may be in an Xterm, for chat (using a non-X equivalent of
`talk-connect') and another for work.

   We also found that it was hard (in XEmacs, GNU Emacs might do better)
   to keep the window-frame mapping consistent across frames ...

Hmmm.... that could be a problem I had not thought of.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: groupware question

[Stefan Monnier]

> We also found that it was hard (in XEmacs, GNU Emacs might do better)
> to keep the window-frame mapping consistent across frames (eg, if one
> of you does find-tag, the other doesn't automatically see the result
> if it's a different buffer).

The technical problems I've had with "one Emacs for two people" had
mostly to do with multiple simultaneous minibuffer activations.

Or also with pieces of code which try to reuse an existing window/buffer if
it already exists, leading to the problem such as your *Help* buffer is
shown on the other guy's display and you just sit there wondering what is
Emacs waiting for.

But it was mostly irrelevant because in the end, either we wanted really
close interaction, in which case "one typist, 4 eyes" worked better (the
typing part was never the bottleneck), or otherwise a system based on
CVS-with-frequent-commit worked just as well if not better by decoupling us
just enough (this way we could edit the same text and compare afterwards to
resolve the conflict, rather than fight over who'd get to write his code,
without the other being able to show concretely what he intended to write).


        Stefan

Re: groupware question

[Robert J. Chassell]

Stefan Monnier <monnier@IRO.UMontreal.CA> wrote

   The technical problems I've had with "one Emacs for two people" had
   mostly to do with multiple simultaneous minibuffer activations.

   Or ... such as your *Help* buffer is shown on the other guy's
   display and you just sit there wondering what is Emacs waiting for.

   ... mostly irrelevant ..., either we wanted really close
   interaction, in which case "one typist, 4 eyes" worked better ...

   or otherwise a system based on CVS-with-frequent-commit...

This is both interestng and helpful.  It is good advice.

It should become a standard part of some document -- perhaps in the
Emacs manual in a general node on remote cooperation.  The node could
describe `talk-connect'

    (By the way, in which Texinfo file is `talk-connect' currently
    documented?  I just looked and could not find it!)

and `make-frame-on-display', for fast connections, (emacs)Multiple Displays

In addition the node could describe the `emacsclient' hack, and for
sufficiently fast connections, the use of VNC and maybe something
such as `gnomemeeting'.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: groupware question

[Stephen J. Turnbull]

>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:

    Robert> I connect to the remote machine twice using ssh over a
    Robert> slow telephone connection.  So now I have two xterms
    Robert> connected to 123.456.789.123.

Oh, that's even better, because you do have the secure circuit.

    Robert> On one remote connection I start `emacs -nw -f
    Robert> server-start'.  That is fine.  On the other remote
    Robert> connection, I start `emacsclient foo'.

    Robert> That starts an Emacs window in the xterm showing first
    Robert> remote connection, the one where I started `emacs -nw -f
    Robert> server-start'.

    Robert> How do I get it to show the file in the xterm showing the
    Robert> other remote connection?

emacsclient doesn't seem to support this.  :-(  gnuclient (XEmacs's
version) has a -nw option (no-window-system), which connects to the
server and shows the emacs window on the gnuclient's TTY.

   I've done cooperative editing this way, by the way, and discovered
   that I really don't want to work that way with the person I tried it
   with.  He kept making typos, and correcting my indentation style.
   Unforgivable!  ;-)

    Robert> I feared this sort of thing can be a problem.  But I have
    Robert> enjoyed good, cooperative work with people, so I think it
    Robert> depends on the person and the situation.

Oh, certainly!  It was just a cautionary example.  It's not like I
can't work with that guy at all, it's just that (as Stefan points out)
sometimes it's better to have a communication buffer bigger than one
character!  I suspect we could have worked out a protocol if needed,
but in fact we were sitting at neighboring desks.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: groupware question

[Richard Stallman]

    Or also with pieces of code which try to reuse an existing window/buffer if
    it already exists, leading to the problem such as your *Help* buffer is
    shown on the other guy's display and you just sit there wondering what is
    Emacs waiting for.

We ought to be able to solve that by changing display-window.
Would someone like to try doing this?