emacs-tangents
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO crdt-stop-session, selecting deleted buffer, fails to remove se


From: Jean Louis
Subject: Re: TODO crdt-stop-session, selecting deleted buffer, fails to remove session from the list
Date: Thu, 22 Oct 2020 02:47:36 +0300
User-agent: Mutt/+ (1036f0e) (2020-10-18)

I think you should at least post this to emacs-tangents@gnu.org as it
is related to Emacs, not yet to Emacs development. I make copy there,
OK? There could be people with good ideas.

You have that account on Savannah to contribute to Emacs or ELPA? I
hope so.

* Qiantan Hong <qhong@mit.edu> [2020-10-22 02:31]:
> I find that it require some non trivial refactoring to do this
> — currently I just assume that client always open any buffer server is 
> sharing.
> 
> So to solve the problem there’s two way:
> 
> - Keep the invariant "client always open any buffer server is sharing”.
> If client try to kill a shared buffer, warn them and say if doing so, it will
> cause the client to leave the whole session. This is very simple to do.
> 
> - Change the model and not keeping the invariant
> "client always open any buffer server is sharing”. This will require
> non-trivial work. After doing so, however, we can allow feature like
> lazily pull buffer from server (only when the client need it).
> 
> What do you think?

My suggestion is that you install Gobby collaborative editor and look
inside, I did, then follow the well established model, you almost have
it by same model.

My opinion is that client should connect:

- immediately to the buffer shared, if it is the only one

- to the selection of buffers if there are multiple

- and to be given option to connect to other available buffers, but
  not automatically

> - Keep the invariant "client always open any buffer server is sharing”.
> If client try to kill a shared buffer, warn them and say if doing so, it will
> cause the client to leave the whole session. This is very simple to do.

It is not good to kill the session by closing the buffer, as client
did not decide to kill the session, and in the mean time, server could
provide other files, right?

It is better to ask user if the session should be also disconnected,
and not do it automatically.

If there are other available files that appeared in the mean time,
user shall be informed in that message.

Generally option 2 seem logical more than option 1, which looks not
well planned for multi users having multi sessions with multi buffers.

Jean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]