Issues

Known issues

Here is the list of pending, still unsolved issues, which encompass both problems and suggestions.

Client side

• An option should exist to turn all collaborators’ highlighting on or off. hue_bias might be t for the current random choice, nil for no hightlighting at all, or some constant between 0.0 and 1.0. Also, in the t case, each server should use a different bias.
• For all function reading strings (through read-string or completing-read), optional arguments should exist to preset the responses, and interaction should only occur when these arguments have not been given.
• When sending a chat message, the client should check for colorg mode before querying for the message text, not after.
• Sending a chat message should send the current region if one is active, instead of querying for a message text.
• Should colorg give some visual feedback, likely over the closest visible header, when another collaborator is modifying hidden text? It could use the color associated with that contributor, somewhere on the header. What if many contributors play within the same hidden region then?
• The polling rate should progressively vary between maybe more than once per second when the local user is very active, to maybe only a few times per minute when that user looks like being away.
• Whenever the local buffer and the remote resource differ, Emacs ediff could be automatically launched to attempt a reconciliation?
• If a single contributor modifies more than one resource almost simultaneously on a server, for which there are separate buffers in the local client, the highlight for that contributor appears in only one of the modified buffers, rather than in all of them.

Server side

• Clashing modifications between collaborators are not satisfactorily handled yet. When modifications coming from different clients clash, a region should never be deleted more than once, and insertions should all be kept, so no work is lost unexpectedly. There is no clash by definition for overlapping changes coming from a single client, it is assumed that the user knows what she is doing! This is fairly tedious to implement correctly.
• A chat message sent to a given user should go to all clients sharing the same user identification on that server.
• Chat messages should be aimed not only at a user, but also at a resource, then aiming all users of that resource.
• Clients should automatically get disconnected if no polling occurred for a long while. For example, users at the remote end might have killed their Emacs, and the server may not indefinitely accumulate a client’s outgoing queue, which is never emptied.
• The internal representation of resources should not be strings, as their immutability implies inefficiencies.