Provide mechanism for sharing file contents via sockets/IPC

[Varriount]

The current mechanism of using a dirty file is inefficient - the entire file must be saved often (at least once every couple of keystrokes for automatic suggestion). This is fine on systems with a ram-based temp directory, but not so on Windows systems.

What might be more efficient is some methods of communicating file contents changes to nimsuggest, possibly via another command.

[Araq]

Pretty sure it's fine for windows too. We should benchmark it rather than simply assuming it's a problem.

[timotheecour]

• on OSX /tmp is not using RAM (see also https://superuser.com/questions/448585/is-there-an-implementation-of-tmpfs-for-mac-os-x)

• see also rationale for NimLime stopping support for nimsuggest here:

Nimsuggest has, quite frankly, been more trouble than it's worth to support. The TCP mode disconnects after a single command (which is really inefficient) and the standard input mode is a pain to support across platforms. Furthermore, Nimsuggest requires that "dirty" (modified) files be written to disk. If one wants to get suggestions on every keystroke, one either has to suffer major performance penalties (lets save a dirty file to disk every keystroke!) or write a complex caching/state management algorithm.

/cc @Varriount @Araq

[Araq]

Furthermore, Nimsuggest requires that "dirty" (modified) files be written to disk. If one wants to get suggestions on every keystroke, one either has to suffer major performance penalties (lets save a dirty file to disk every keystroke!) or write a complex caching/state management algorithm.

I debunked this months ago, showing you you can save to disk thousands of times per second. On my Windows computer without SSD. (And Windows is really bad at this.) I don't know why you bring it up again, it is a non-issue, not backed up by any numbers whatsoever.

[Varriount]

I'm more frustrated by the communication methods EPC is undocumented, and TCP and stdin have the faults I've previously mentioned.