Deal with multiple editor tabs editing the same file.

[pencilcode]

Deal with multiple editor tabs editing the same file.

[theanandramakrishna]

From seeing how my kids use it, I would go with option A.
On Mar 22, 2014 5:11 AM, "David Bau" [email protected] wrote:

In multi-tab browsers, when you open two editing sessions to the same
file, it is too easy to lose track of which tab has your most recent edits
and overwrite them by accident.

We should either avoid this situation or make it less confusing.

A few possible alternative ideas for the user model here:

(A) Make it less confusing: Edits in one tab are immediately reflected in
all tabs editing the same file. So it doesn't matter which tab you use;
they're all equivalent and in sync.

(B) Avoid this situation, favoring the new tab: Opening a new tab for
editing a file closes (or moves to the parent directory) the old tab that
was editing the same file. Unsaved edits should be transferred from the old
tab to the new tab.

(C) Avoid this situation, favoring the old tab: Opening a new tab for
editing a file that is already open in another tab opens the file in a
read-only mode, with a message that the file is already open for edit in
another tab.

We could use localStorage to detect the multiple-tab case: a tab editing a
file can "ping" its editor-start-time and last-alive-time timestamps into
localStorage while it is open; and a new editor tab can see the other tab's
presence in localStorage, etc.

Interested in comments about whether we think A, B, or C (or something
else) is the way to go.

Reply to this email directly or view it on GitHubhttps://github.com//issues/55
.

[davidbau]

Makes sense. I think you're right. Option A is probably the most forgiving.

Thinking about implementation: I think the technique to use to sync tabs in the same browser will be localStorage events. It's a new API and slightly different on different browsers.

http://stackoverflow.com/questions/4679023/bug-with-chromes-localstorage-implementation

[sidthekidder]

Hi, is this issue still open.? I'm interested in implementation of this feature. So I was going through the codebase, and needed some help in identifying the parts of code to work on.

As far as I could see, the view listens for ~pickblock and ~selectpalette events, and logs it. We could use that function to also set a localStorage item. And then have a handler listen to "storage" events ~pickblock and ~selectpalette. The handler would call get localStorage and then call fireEvent of the window.pencilcode.view object to execute the just-saved object.
Is this the right approach.? (I'm unsure of how to use the view.js function fireEvent in controller.js)

[davidbau]

Hello, sorry for the slow response (I've been at a conference). This is a pretty interesting bug to take on.

pickblock and selectpalette aren't the right events to track - those are all "getting ready to make a change but not necessarily making a change."

I would listen to "change" events from the underlying editors, in the dropletEditor.on('change' and the session.on('change',... in view.js.

These underlying events might not be exposed the way you need; if you need a new event from view.js to controller.js, then just wire one up by calling fireEvent in view.js and calling on('yourevent',...) in controller.js.

[sidthekidder]

I tried it out and apparently it didn't require anything in controller.js. So I added some code in view.js -

/* placed in setPaneEditorData() */
window.addEventListener("storage", function(e) {
    dropletEditor.setValue_raw(localStorage.getItem('dropletEditorValue'));
 }, false);

session.on('change', function() {
...
    localStorage.setItem('dropletEditorValue', dropletEditor.getValue());
...
});

It looks sweet to see two tabs syncing across, typing in one and seeing blocks form in the other. I used the dropletEditor.setValue_raw() function since using setValue() triggers the session.on('change') listener again, which we don't want.

I didn't make a PR since this needs to be polished probably -

1. Currently it would be triggered on any localStorage event, and though the actual text wouldn't be affected, it might be inefficient and slow down the tab.
2. Controller logic in view.js - What you said above, using fireEvent we could access controller.js from view.js, but actually this I think requires access to dropletEditor in view.js triggered from controller.js. We can call a view function from controller, but those functions are defined in global scope thus cannot access pane.dropletEditor. So it was a problem.
3. To ensure cross-browser compatibility and for modularity, this npm module https://github.com/bevacqua/local-storage could be integrated - more robust in handling localStorage events.

Any recommendations.?

[davidbau]

Terrific. Go ahead an open a PR, and we can take a closer look and discuss there.

Question on the local-storage wrapper:

• Do you know how big it is (pencilcode is too big already, so I want to be careful about picking up new dependencies)
• Do you know which browser incompatibilities it deals with?