Sync on save?


#1

Does anyone know of a way to save a file to a server on every local Atom save? I was using shared directories but a bug in Atom keeps me from using fuse directories and my chromebook doesn’t support NFS. So I want something that does a simple file sync, maybe using rsync, on every save.

Edit: I found several packages that claim to do this. I don’t know how I missed them. I’ll give them a try and report back here.

Meanwhile, can anyone recommend one they like?


#2

good question… here’s how I like to do that: https://gist.github.com/reqshark/096e92dd4e851d187092

EDIT:
btw I don’t really like doing that additional require('fs').readFile() call, after sending over the filePath to a different process. it seems like a wasted read() since we can getText referenced somewhere nearer or more direct to the stack from atom’s text buffer https://atom.io/docs/api/v1.2.4/TextBuffer#instance-getText

the trade-off there undoubtedly means ditching UDP’s connectionless/lightweight send() operation, since a getText buffer could be larger than the MTU for UDP (and therefore data-loss). maybe an IPC style connect and delivery of the getText buffer makes more sense… but I’m still on the fence since my original thought was let’s off-load file I/O and network away from the editor


#3

That looks great. It should be made into a package/npm module, which would be easier than doing the gist. (grin).

All you have to do is start up a separate process that keeps running. On each save send the file to the process. Most people don’t realize that all of the Atom editor runs in a single process which can only use one core/thread. You won’t be able to see any load on the editor even if you do a ton of work in the other process.

I started work on an autocomplete framework that was replaced by autocomplete-plus.
I had a separate process with a mirrored text buffer for each loaded file. Every time any typing paused the change was sent to the process and the buffer updated. Then expensive matching code ran to calculate the autocomplete using all mirrored buffers. The typing in the editor saw no pauses at all.


#4

That looks great. It should be made into a package/npm module

thank you,

I don’t really know where to start… I started reading the atom docs from the opposite direction, and so the beginner area is still very undiscovered–technically I am less than a newb in that department.

If you would like to git init the repo and npm or the apn project, feel free to add me as collaborator to the atom pkg. I would be more than happy to assist on any code review :smile:

what people may or may not realize is neither here nor there, so let’s defer to the facts:

  • node’s default threadpool is around 4 (last time i checked somewhere around iojs 2.5 or node 3ish??). That doesn’t mean we’ll get 4 cores right off the bat before calling into libuv… it’s more of a system default triggered in the course of network or file I/O exposure to the various javascript core modules reaching into their respective libuv operations.
  • one node binding dependency alone calling into kernel API opens threads (cores) and what have you, since the binding just converts function arguments into whatever lame C++ V8 type is trending or thankfully it’s just an UN-null terminated C string, A.K.A.node’s buffer class.

You won’t be able to see any load on the editor even if you do a ton of work in the other process.

my thought exactly.

I had a separate process with a mirrored text buffer for each loaded file. Every time any typing paused the change was sent to the process and the buffer updated.

@mark_hahn, please elaborate here. I wish to know more about how you were able to achieve a ‘mirrored text buffer’. Can you explain what that is please, I have very limited experience with text editor buffers… although I once was able to achieve that sort of thing by re-writing the zeromq binding as a damn python ctype ffi direct import since there was no support for shared libs outside of the bundled Sublime Application’s isolated dialect… of course what i really wanted was to just use the python binding to zmq… eh so this hack here actually solves the problem: https://github.com/reqshark/sublimezmq I would like to do that in atom withj node-nanomsg, I think it will be easier since we’re dealing with a javascripti instead of the damn python 3 import scenarios, etc. etc.


#5

All one needs to do to contribute to Atom is to submit a pull request. If looking for ideas you might ask @leedohm for advice. He is the ringleader here on the forum. I myself prefer to develop packages that contribute to Atom.

I am interest in exploring advanced methods of syncing to remote servers. You have a good well-documented start. I’d like to make remote access totally transparent with no extra UI. I’d like to forget where stuff is physically located.

I got excited last night when I discovered autofs and ssfs. You should check them out. Unfortunately my laptop has a problem running autofs right now.


#6

When I get a chance I’ll elaborate. I have working code for the buffer mirroring.


#7

I got excited last night when I discovered autofs and ssfs

interesting, I was just starting to read a bit about NFS yesterday, I’ll take a look at look those today.

When I get a chance I’ll elaborate. I have working code for the buffer mirroring

Take your time. I’m in no rush