-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement "save as" #6528
Comments
Comments from Jason W; "Ever since macOS implemented Autosave as a core OS feature, in apps that use macOS conventions, "Duplicate" has replaced "Save As…" in the File menu" That's fascinating. Maybe I should close this ticket. |
Does duplicate also fork the timetravel state, so that the undo history is carried to the new document? |
No, it just copies the file and nothing else. It is also intelligent at suggesting a new filename. For what it is worth, nobody has ever complained about this behavior (not forking the timetravel state), so maybe this very simple solution is just fine. |
from pete bois: save as for collaborators- in Colab we have 'save a copy' which makes a private copy- sharing permissions are not inherited, by design. This seems to be basically the same as "Duplicate". |
I'm at the JupyterLab meeting at they are talking about the subtle issues with realtime collab and their "save as":
jupyterlab/jupyterlab#14130
It occurs to me that "Save As..." is not implemented in any way at all in CoCalc, but it is a very standard thing that people would find valuable, and it's standard in operating systems.
Save as = make a copy and open new document, closing the existing document.
An obvious question is what happens for all the other people with the same document open at the same time. I think the same thing should happen, i.e., the current document should close and the new one should open for them too. I don't think we have to have the same behavior as JupyterLab here, since it sounds like their behavior is possibly constrained by limitations of their realtime sync implementation, rather than what is the most natural thing from the user perspective.
Another obvious question:
It might be optimal to duplicate TimeTravel back to the last snapshot (which is all that is needed for undo), and maybe put a link to the previous document someday. The undo would then work at least (since that just needs back to the last snapshot).
Third obvious question: what happens to all other sessions that have the file open? Should they switch too. @jasongrout says "NO!". I'm not sure. I can't think of a good argument for making everybody else switch, and it's hard to implement that in a robust way. Google docs also doesn't answer this -- they only have "rename file".
WORKAROUND: Use "Duplicate", which is very similar.
The text was updated successfully, but these errors were encountered: