kiyoon / jupynium.nvim

Selenium-automated Jupyter Notebook that is synchronised with NeoVim in real-time.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Automatically open homonymous file with `JupyniumLoadFromIpynbTab`

egolep opened this issue · comments

commented

It would be very handy if we can automatically get Jupynium to open a new file called as the .ipynb file with the right .ju.* type (i.e. .ju.py for a python notebook,.ju.jl for a julia notebook and so on).
Maybe, this can be done only if the current buffer is empty/without name?

One problem is that, what if the file already exists? We don't want to open a file randomly and overwrite everything. Maybe I can make it confirm if you want that or not. Thanks for the suggestion!

commented

In my idea, the file that contains all the code, results and markdown is the actual notebook, so if the .ju.* file gets overwritten I loose nothing. But I realize now that this is my personal take and not the actual general rule or general desired behavior for everyone.
The optional behavior you are suggesting is probably the best choice!

Yeah, I saw some people putting notebook in a temp dir, maybe because ju.py files are easier to version control. But if you don't care about ju.py content, you can also just make a random name before loading as well

commented

Yeah you are probably right.
I don't want to waste your time, so just one last question: if I would like to try implement this by myself, where should I start watching? Worst case scenario, I implement some functions for myself using those offered by the plugin.

The event handlers are in event_control.py. I'd like to make an improvement and I'm happy for feedback like this, but I don't think this kind of functionality should be a default or adding too many options can confuse people. I want it to have sane defaults that people can be happy getting into it at first.

So I'm thinking I should make an API. Basically I can let you execute any custom javascript on the browser, can get the return value of that in lua. That way, you can check ipynb information after it being loaded, and you can modify buffername as you want.

im loving this plugin so far, but when I first started with it I was very (extremely) confused about the UX flow of how to actually use it. I think the 2 main reasons were 1) there are a lot of different commands that need to be executed in a specific order (some level of automation would be useful), and 2) I didn't understand what .ju files were or that I needed to create them myself.

So I think for new users it would be quite sensible to have some sort of automatic association between a ipynb and a ju file, especially given that a ju file is a mandatory part of the plugin. this could maybe go both ways: 1) create/open a ju file will open and sync the associated ipynb on disk, and 2) opening an ipynb will create a ju file and open it - I think there already is a console app to do the conversion so we can make a call to that and pass it the ipynb. both with confirmation of overwriting, of course

@sho-87 Yeah I agree that it's confusing. Thanks for the feedback! The difficulty to make it user friendly is that, 1. I don't know if the notebook server is hosted on the local machine or not and 2. I don't know where the notebook root directory is. There are too many use cases and different workflow making it difficult to automate many things.

So if you open ipynb with vim, you want it to be converted to ju.py automatically?

@egolep Refer to https://github.com/kiyoon/jupynium.nvim#lua-api for how to use the API. Basically you can test the javascript from F12 developer mode console in firefox, and write your own script. Using this you can get info of name of notebook and kernel language etc. You can map a key or make a command that executes :JupyniumLoadFromIpynbTab and then set the filename.

So if you open ipynb with vim, you want it to be converted to ju.py automatically?

maybe. I'm not sure what the best option is here. certainly there should be some way to indicate to the user that a .ju.py file is needed, but this could be as simple as updating the readme to indicate that.

I'm just thinking about new user expectations and there are 2 parts of the flow that should be considered:

  1. opening/creating a ju file so the plugin can work
  2. connect and sync to a notebook instance so the user can start doing things

I think your concerns above are valid for (2), where there are a lot of unknowns that can complicate the matter. But currently it's not so clear how (1) works either because theres no clear link between an ipynb and ju file...

If you map out the potential user flows for (1), the use cases are probably either:

  1. they want to create a brand new notebook and start fresh work
  2. they want to use an existing notebook and continue what they were working on

the first can be handled by a readme update that explicitly tells them to create a .ju.py file, which can eventually be downloaded as a ipynb if they want to keep a copy of that as well

the second is more complicated because it requires quite a few steps that happen outside of nvim, and its the outsourcing to the browser that makes this step unintuitive. if there was a way to go from an existing notebook to a .ju.py from within vim it would makes things a lot simpler. a few options could be: an autocommand that triggers a conversion on a ipynb load, a dialog/prompt asking if the user wants to convert their opened ipynb to a ju when they open the file in vim, a new command that the user can trigger manually.

any of those would work as it would eliminate the complicated user flow of go to vim and start server > go to browser > open ipynb file > go back to nvim > JupyniumLoadFromIpynbTab > remember to save buffer as a ju file

Thanks for the suggestions. The list of things could be improved:

  1. Readme indicating you need to make ju.py file
  2. Could be a good idea to make a video showing quickly how to use the plugin.
  3. Make a command JupyniumIpynbToJuPy that will convert ipynb file to ju.py file within vim. Could detect language automatically as well and try to use the correct filename, and ask if they want to overwrite, name it differently, or cancel.
  4. Make an autocmd to launch above, but also provide option to switch it off.

sounds like a solid plan! if I have time this weekend I'll make a PR to update the readme text to help improve clarity for new users

For reference, there is a vim plugin, jupytext.vim, that does something similar to what is discussed here (opening an ipynb file with vim automatically converts it to a python file with jupytext). Maybe this plugin can be useful for examples of workflow/features.

In my opinion this is a useful feature to have. Many projects/repos have only ipynb files and it would be nice to be able to edit them directly with jupynium.nvim.

@vandalt I haven't used the jupytext plugin, and it sounds like it's worth a try before I implement anything to get inspiration from the workflow. Thanks for the pointer!

Closing this as we implemented the API to customise this, and with #68 you can now directly use Jupytext to convert automatically.