da-h / AirLatex.vim

Overleaf / ShareLatex in Vim
MIT License
79 stars 8 forks source link

feat(buftype): add possibility of saving files locally #39

Open massimo-rizzoli opened 2 years ago

massimo-rizzoli commented 2 years ago

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 commented 2 years ago

I like this one.

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

Best da-h

massimo-rizzoli commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

What is not possible is instead:

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