Remove --output argument

[mwouts]

Default destination is computed from extension. Fixes #1 on Windows

[goerz]

There is a case in which jupytext_file is not just the notebook file with the ipynb extension changed to md/py: The plugin supports the FileReadCmd event, which is when you open vim, and then type e.g. :read notebook.ipynb (which is different from :edit notebook.ipynb, the BufReadCmd event). In that case, the jupytext_file is determined in

jupytext.vim/plugin/jupytext.vim

Line 305 in ea120db

let l:jupytext_file = l:head."/.".i."__".l:tail.".".l:extension

and that's when the --output is required in read_from_ipynb. Incidentally, that line is also the one I was concerned about in Windows, as it uses an explicit '/' to combine paths.

However, :read of a notebook isn't something terribly useful. It's really only there because I modeled the plugin after gnupg.vim, which does the same thing. I think I want to drop that (undocumented) feature entirely, which should eliminate the need for --output, and make the code shorter and simpler (removing the problematic line L305).

Thus, I will add some modifications on top of your pull request before merging it in.

[goerz]

Actually, I don't think I want to get rid of the --output after all (despite removing the :read functionality): The vim plugin still needs to calculate the md/py file (jupytext_file) internally, because it acts differently depending on whether that file already exists or not: If it exists, it will skip the ipynb→md/py conversion and directly load the md/py file. Conversely, if jupytext_file does not exist, it will created it as a temporary file, but remove the file when the buffer closes.

In theory, I could just rely on the assumption that the vim plugin generating the same jupytext_file as the jupytext program itself, and then --output would not be necessary. I'd like to avoid unnecessary assumptions, though, so it's better to have the -output explicitly with the file name that the vim plugin calculates. With L305 removed by getting rid of the :read functionality, there really shouldn't be a problem with Windows, including filenames with spaces. If it still breaks, it's because I'm incorrectly escaping file names, and that can be fixed separately.

For now, I'll just leave the pull request open. If mwouts/jupytext#146 was handled in some way, that is, if the vim plugin could get the pairing information from a system call to jupytext, the situation would change: then I could distinguish the two cases based on the notebook metadata, and I could get rid of the jupytext_file variable.

[mwouts]

I see! Sure, then removing the --output argument is not adequate, then. And there might be another way to fix the issue on windows when the file name as a space. Maybe we can simply replace fnameescape with shellescape on line 336, and you avoid the problematic \ in the notebook name in the --output argument in the below?

jupytext --from=md --to=ipynb --output=C:\Users\Marc\Documents\Notebook\ renamed.ipynb --update "C:\Users\Marc\Documents\Notebook renamed.md"

[mwouts]

@goerz , I close this PR in favor of PR #4, which solves the same issue (notebooks with space in the name on windows) by just changing fnameescape to shellescape.

[goerz]

Yes, that's right. Thank you!