Skip to content

Startup script repl #392

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Conversation

mrsalo
Copy link

@mrsalo mrsalo commented May 3, 2019

@justinmk
Copy link
Member

justinmk commented May 3, 2019

what is step-by-step the workflow for using this? That should be mentioned in the README.

I would think invoking something from Nvim would be more useful, rather than making the user choose from a list.

@mrsalo
Copy link
Author

mrsalo commented May 3, 2019

I updated the README. I don't know if this is already enough documentation.
I would also prefer the invocation through nvim, but it has one flaw:
When I use the :term feature to start a terminal and then e.g. IPython I am perfectly able to connect to the current instance. But the current buffer (the one i get using nvim.current.buffer) is the terminal buffer where IPython runs and not the one I wanted to modify through the REPL initially.
Hope this gif makes it a little bit clearer:
Peek 2019-05-03 14-06

@justinmk
Copy link
Member

justinmk commented May 5, 2019

Actually, I don't think it makes sense to put this in pynvim repo. Most pynvim users won't have the scripts/ AFAIK. So if anything this should be a plugin or maybe contrib/ in the neovim repo.

@mrsalo
Copy link
Author

mrsalo commented May 6, 2019

Ok, what would you think of putting it in the pynvim module or in a submodule and not as a startup script but as a function?
If you think it's not worth the hassle that`s also fine. Just found it easier to use than the standard procedure.

@justinmk
Copy link
Member

justinmk commented May 7, 2019

Ok, what would you think of putting it in the pynvim module or in a submodule and not as a startup script but as a function?

That was my first thought. I guess it makes sense because then Nvim core only needs to look for that function. The function can be mentioned by nvim_set_client_info. I think open_repl might be a good name.

self.nvim.api.set_client_info(
name, VERSION.__dict__, "host", host_method_spec,

Add open_repl to host_method_spec.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants