Skip to content
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

Make a bigger deal out of disabling the save key #56

Closed
CreRecombinase opened this issue Sep 14, 2020 · 6 comments
Closed

Make a bigger deal out of disabling the save key #56

CreRecombinase opened this issue Sep 14, 2020 · 6 comments

Comments

@CreRecombinase
Copy link

This is a fun package that had been useful, but as a consequence of using it I lost a lot of work. Here's my sad story: I was working on an overleaf document using this plugin, when I decided I would rather simply work on it locally and sync it back manually later. I C-x C-w to write the buffer to a file foo.tex , which, as expected, saved the contents to a file. What I did not know, was that C-x C-s was still mapped to atomic-chrome-send-buffer-text, which was neither saving my changes to foo.tex, nor updating my overleaf document. It was not until I several hours later, when I went to convert my tex document to pdf with C-c C-c, that I realized that I had never left atomic-chrome, and instead of TeX-command-master, I got atomic-chrome-close-current-buffer, and lost a days work.
I fully take responsibility for using a package without carefully reading the docs, and I should have been checking the minibuffer to ensure that my saves were indeed happening. On the other hand, of the dozens (hundreds?) of emacs packages and minor-modes I have used, I have never used a single package that overwrites C-x C-s (even in settings where it makes no sense, who saves the contents of the minibuffer???). I'm not sure what the fix is here, but I just thought you should know.

@ndokos
Copy link

ndokos commented Oct 1, 2020

I have the feeling that that's a typo and C-c C-s was meant instead. If so, please fix it ASAP. If not, fix it anyway...

@yonatan
Copy link

yonatan commented Dec 13, 2020

Note that just changing the key binding is not enough, you will also need to remove the (set-buffer-modified-p nil) here, which was added to address issue #37 otherwise emacs thinks that "no changes need to be saved".

@yonatan
Copy link

yonatan commented Dec 13, 2020

By the way, I use atomic-chrome (and thank you so much @alpha22jp for publishing it!) to edit shaders, which sometimes hang my machine and force me to power-cycle so being able to save is extremely useful for me.

Sorry for not writing a proper patch, I'm not sure how to handle the breakage for #37 :(

@sten0
Copy link

sten0 commented Jan 12, 2021

I agree, one of the great things about Emacs is we're safe from the flakiness of web things, where text entered into forms will be lost from something as simple as a page reload--not to mention a browser crash (or OOM killed process), forgetting there's a long-running tab and restarting the browser for a security upgrade, etc.

Let's clearly define the expected behaviour of Atomic Chrome. I suspect it's something like this:

  1. Instead of keeping the buffer entirely in memory and exclusively pushing it into the websocket, allow normal Emacs auto-save to function correctly.
  2. The big question is "where should these files go"? This can be set in buffer-auto-save-file-name.
  3. I'm guessing ~/.emacs.d/atomic-chrome/buffer-name/foo would be reasonable.
  4. Are there any multiplatform considerations? IIRC Windows file systems support a much-restricted character set for file names. Is there already a library that will do character substitutions? For example, replacing colons ":" with double underscores "__"?
  5. Whenever the user manually saves, using C-x s or C-x C-s, the buffer should be saved to disk [edit: in addition to the existing behaviour of being pushed into the websocket]. This is analogous to saving a draft.
  6. A nice to have extension to this behaviour would be to ask the browser for the URL of the page that is being edited, and save this such that it won't appear in the text-area edited of the form that is being edited in the browser, nor in the buffer that is being edited in atomic-chrome. I imagine that injecting a file-local variable will do the trick.
  7. [edit: Are there any pitfalls involving buffer-revert or recover-session?]
  8. [edit: Is there a future follow-up issue for an enhanced recover-session for atomic-chrome?]
  9. Did I miss anything?

Please comment!

@alpha22jp, if you'd like the next Debian stable release to carry this work, the deadline is Feb 10th, but please give me a few extra days [edit: because I will need a few days to test the new release before uploading to Debian].

Regards,
Nicholas

@CreRecombinase
Copy link
Author

Can't you just (for now at least) not disable C-x C-s? atomic-chrome-send-buffer-text is not analogous to save, so just use something else.

@alpha22jp
Copy link
Owner

@CreRecombinase

I modified key binding for atomic-chrome-send-buffer-text to C-c C-s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants