From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: howto: 2 users interactively edit the same file ? Date: 31 Oct 2005 19:04:16 +1100 Message-ID: <8764reun7j.fsf@tiger.rapttech.com.au> References: <87ll0bvd9t.fsf@tiger.rapttech.com.au> <87acgrsieb.fsf@thalassa.informatimago.com> Reply-To: timx@spamto.devnul.com NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1130747046 9286 80.91.229.2 (31 Oct 2005 08:24:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2005 08:24:06 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Oct 31 09:24:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EWUvq-0008TF-Jl for geh-help-gnu-emacs@m.gmane.org; Mon, 31 Oct 2005 09:22:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EWUuJ-0006cH-JH for geh-help-gnu-emacs@m.gmane.org; Mon, 31 Oct 2005 03:20:43 -0500 Original-Newsgroups: gnu.emacs.help Original-Lines: 114 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Original-NNTP-Posting-Host: ppp4-97.lns1.syd7.internode.on.net Original-X-Trace: duster.adelaide.on.net 1130745857 59.167.4.97 (31 Oct 2005 18:34:17 +1050) Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!logbridge.uoregon.edu!newsfeeds.ihug.co.nz!ihug.co.nz!news.xtra.co.nz!news-south.connect.com.au!duster.adelaide.on.net!not-for-mail Original-Xref: shelby.stanford.edu gnu.emacs.help:135119 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:30710 Archived-At: Pascal Bourguignon writes: > Tim X writes: > > > Matt Carlson writes: > > > >> Hi all, > >> I'm trying to figure out how to accomplish the following: My friend > >> and I need to work with the same file at the same time. It would be > >> nice to be able to code simultaneously and see each others changes > >> in something like real time. I've googled everywhere and found only > >> information on how emacs handles locks.. I'd like both he and I to > >> be able to edit the same file and see each others changes as close to > >> instantaneously as possible. > >> > >> The sky is the limit with emacs, so I'm sure there's a way to do this, > >> I'm just in need of some direction as to how to do it, or even what > >> words to google. > >> > >> It would be very nice to have a shell open in one buffer to chat > >> with the other person editing the file, and then the file we're both > >> editing open in another.. Thanks in advance, > >> > >> -regards, > >> Matt > >> > > > > I would say fairly confidently, you have not a hope in hell of doing > > what you want. It is actaully very complicated to achieve multiple > > real-time editing of a document and emacs has none of the necessary > > infrastructure to achieve this. Issues which would need to be resolved > > (most non-trivial) include - > > > > 1. Emacs does its editing in buffers and changes are only written > > to disk when you save the buffer. There is no way for two eamcs > > instances to communicate information regarding buffer > > contents. There is also no way to ensure one user doesn't save > > the file and then have it over written by the second user when > > they save the file. > > > > 2. Conflict resolution. If two users change the same section of > > text at about the same time, which one will take precedence? > > > > In a way, what you want is a shared buffer which two separate emacs > > sessions can operate on at the same time. This would need shared > > memory with a coordination layer which would ensure both users have > > equal access to modifying the memory and some way of rsolving conflict > > and merging changes. Very difficult. > > > > About the best you can do would be to use CVS to manage the > > files. Using CVS won't give you real-time, but it will simplify the > > merging of changes. You would have to ensure you both inform the other > > once you have made some changes and checked them into CVS. There will > > be times when CVS cannot resolve conflict - in these situations, you > > will have to work it out together. > > Actually, it's quite easy to do, but indeed, not with two emacs > instances: with only one! > > Just launch emacs, and use make-frame-on-display to open another X > window, on another workstation. Then the two (or more, there's no > limit AFAIK on the number of frames you can open) users can edit the > same file in the same buffer at the same time. > > Only the mini-buffer interaction is mutually exclusive: when a user > type M-x, the other is locked until the first validates or cancels the > command. > > IIRC, this has already been mentionned in this thread. > Hi Pascal, Have you actually tried this? I find it amazing this will work. The big problem is how can emacs, which doesn't support threads, handle simultaneous input from two distinct frames? I can't see how it can handle input from two different input devices simultaneously either. The physical displaying of the frame on another display is easy enough to understand - this is a feature of X windows which emacs is able to take advantage of when it is built with X lib support - but coping with input from two sources at the same time is a very different matter. I'm very much looking forward to seeing how this can be done and wish I had a second computer handy so that I could experiment for myself. I've redirected windows to remote displays before under X and that works quite will - it will be interesting to see how emacs can deal with the concurrency of two users. I hope the OP will keep us informed as to progress. BTW, the blocking nature of the minibuffer is a configuration setting and can be disabled. There was a thread on this here a while back. ,----[ C-h v enable-recursive-minibuffers RET ] | enable-recursive-minibuffers's value is nil | | Documentation: | *Non-nil means to allow minibuffer commands while in the minibuffer. | This variable makes a difference whenever the minibuffer window is active. | | You can customize this variable. `---- Setting this variable to t will allow minibuffers to be active within minibuffers, effectively removing the default "blocking" behavior. Tim -- Tim Cross The e-mail address on this message is FALSE (obviously!). My real e-mail is to a company in Australia called rapttech and my login is tcross - if you really need to send mail, you should be able to work it out!