feat(buftype): add possibility of saving files locally

[massimo-rizzoli]

Necessary for building pdfs locally. The feature is added as an opt-in
setting. The added variable 'g:AirLatexBuftype' has default value 'NOFILE'
which has the usual behaviour (sets 'buftype' to 'nofile'). The value
'NORMAL' creates a normal buffer (sets 'buftype' to '') which allows for
local saving of the files. Any other value will not be accepted and will
have the same effect as the default.

[da-h]

I like this one.

Could you please adapt the README.md to document the new feature?

Best
da-h

[massimo-rizzoli]

Lately I have been using this feature and I have noticed that the buffer name includes the project name (e.g. 'Overleaf Project/main.tex' would be the buffer name for the 'main.tex' file).
This makes the use of the local saving a bit cumbersome, since it is necessary to create a folder with the correct name and also requires to operate in the parent directory.
For these reasons, I have changed the naming of the buffer locally.
I have not pushed the change because I was worried it might break something, but let me know what you think about it.
Best,
Massimo Rizzoli

[da-h]

Hi & sorry for letting you wait for so long with this!

I think it is an great idea to let the user mirror overleaf projects partially or fully locally.
I was thinking about splitting the websocket-part into a seperate base-project anyway. This would enable a second use for the more cumbersome part in this project, namely reverse-engineering the rather undocumented (?) api to the overleaf server, which seems to be stable in the current airlatex-project version.

My long-term idea is to use this core to implement a git-plugin that mirrors what has been done on the server as a dedicated overleaf branch. But on the way i can also imagine airlatex to just download the whole project state or just overwriting everything on the server (for simplicity) upon user request. In the case of the git-plugin, git would solve the merge conflicts.

On the way to such a general solution, you are very welcome to finish your solution and update this MR, for example by setting buftype as you suggested. I am not sure how to handle multiple projects, but I think the feature is so important that if someone needs it, it can be restricted to only a single project or so. Do you maybe have an idea?

Best,
da-h

[massimo-rizzoli]

I am only answering now because I have been quite busy the last couple of weeks.

Regarding the last commit, this is what can be done as of now, if choosing the option with locally writable buffers:

• multiple projects can be opened at the same time with no conflicts;
• there is no need to manually create the project folder: it will be detected if it is the working directory and created automatically otherwise (if there is already a local save, it is sufficient to move to the correct location);
• Overleaf files can always be opened without needing to write them locally.

What is not possible is instead:

• upload local edits to Overleaf (i.e. if files have been modified while not connected to Overleaf, it will not be possible to overwrite the Overleaf ones with the local ones).

This was not something I had planned, but since you mentioned it, I just wanted to address it.

I have solved the conflict problems by renaming the buffers to their actual file name only at the latest possible time. First I guarantee to be inside of a folder named after the Overleaf project and only then I change the file name from 'OverleafProject/filename' to just 'filename'. I have done this by adding an autocommand for each DocumentBuffer that calls a function just before writing the buffer. This happens only the first time a buffer gets written in a session, since afterwards it will be linked to a local file and so it will have a full and valid path.

Anyway, I think that the biggest hassle right now is the necessity to manually move around, but it only happens with editing and saving multiple projects locally at the same time. On the other hand, for one project you would just need to go to the directory you want to save the files in once, then for all the following files of the same project, you would just need to save them and that would be it.

Best,
Massimo Rizzoli

[dmadisetti]

Just leaving a comment here in case anyone continues work on this branch.

In my fork, I built a FUSE system such that compiled files and artifacts look "local" to programs like vimtex (which seems to work). I could have extended this fuse system to mirror overleaf source contents, but I got lazy and added dropbox integration instead since I get pro though my institution (also makes image uploads easier too). FUSE is particular to Linux (no OSX), but works OK:

relevant PR: dmadisetti#27

So nothing is actually on disk, and everything is still synced. I have git integration too, which is useful, but I find myself using it only for checkpointing / major changes since edits are live