Running the current buffer in Iron Repl by pressing <F5> ?

[evoludigit]

Hello,

congratulations for your plugin, I could open the ipython terminal using my virtualenv in a splitted horizontal view and I'm grateful for that :-).

now, I would like to mimic the Python IDLE editor, and run the active buffer entirely, by pressing F5.

I could not find what mapping nor the command I should use for that.

thanks a lot.

[hkupty]

That's interesting. The easiest way for us to do that is to dump the whole buffer into the repl, like so:

map <F5> <Cmd>lua require("iron").core.send(vim.api.nvim_buf_get_option(0,"ft"), vim.api.nvim_buf_get_lines(0, 0, -1, false))<Cr>

Try that and let me know what do you think. Sorry for not answering before.

Best regards,
Henry

[evoludigit]

Thank you very much for this reply, and sorry for getting back late as well. The solution works only for a single line file.

Three print statements in a row don't make it:
print("line 1")
print("line 2")
print("line 3")

translate in the REPL to:
print("line 1")print("line2")print("line 3")

Thanks again.

[hkupty]

Weird. I just tested against master version, on linux, running nvim from the terminal and it pasted the whole file in in the repl. What's your setup?

[evoludigit]

Hello again,

I'm working on Windows.

Having setting up IronREPL from scratch on my Windows laptop, it works better:

• each line is separated in the REPL

The following screen capture illustrates the three problems I encounter:

• the ^[ characters appears after each line.
• a space is inserted before the cursor location in the original file (here, the cursor was on the last character of the file).
• there's no automatic execution of the code

The mapping :

map <F5> <Cmd>lua require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), vim.api.nvim_buf_get_lines(0, 0, -1, false))<Cr>

The lua file

local iron = require('iron')

iron.core.add_repl_definitions{
  python = {
    venv_python = {
      command = "MyPath\\to\\ipython.exe" 
    },
  }
}
iron.core.set_config{
preferred = { python = "venv_python"},
repl_open_cmd = 'rightbelow 10 split'

[baogorek]

Also having some trouble on Windows 10 with extra characters and no automatic carriage return. If I have some time I may try to jump in here with you and figure some stuff out. Been meaning to learn about vim plugins but I am starting from zero. @HkUmpy you're doing God's work by the way.

Update (2019-11-19): I've managed to get rid of the bad characters and I have automatic execution by changing my custom command to "ipython --simple-prompt". Unfortunately now I've lost the carriage returns, exactly like @evoludigit in his first post.

[baogorek]

New strategy I'm working on here: loop through the lines and send them one by one to the REPL. The code below sends only lines 4 through 8. Notice the "\n\r" send at the end which forces the execution on Windows:

lua my_table = vim.api.nvim_buf_get_lines(0, 4, 8, false); for i = 1, table.getn(my_table) do require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), my_table[i]) end; require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), "\n\r")

Seems like it should be simple but I'm having trouble getting start and end rows for a visual selection. Working with this vimscript function:

function! Show_position()
    let new_list = [getpos("'<")[1], getpos("'>")[1]]
    return new_list
endfunction         

It seems like it's giving me the right numbers, but it's looping through every line which isn't great. Going to see if I can hook this up today.

[baogorek]

I've got two lua functions that work with iPython in Windows. Use them with ipython --simple-prompt as the custom command. The first runs the entire file top to bottom:

lua my_table = vim.api.nvim_buf_get_lines(0, 0, -1, false); for i = 1, table.getn(my_table) do require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), my_table[i]) end; require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), "\n\r")

The second runs a visual selection, and depends on the Show_position() vimscript function from my last post:

lua local lower, upper = unpack(vim.api.nvim_call_function("Show_position", {})); my_table = vim.api.nvim_buf_get_lines(0, lower - 1, upper, false); for i = 1, table.getn(my_table) do require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), my_table[i]) end; require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), "\n\r")

The first command works fine either as a directly entered command or mapped to a key. The second command works beautifully every time when I run it manually but is always one command set behind when it's mapped to a key sequence in init.vim. I feel like I just can't win here!

[hkupty]

First of all, sorry for taking this long to answer. Couldn't get much time to devote attention to my projects, unfortunately.

I found this line on fts/common.lua:

    new[#new] = new[#new] .. "\13"

\13 is "carriage return". I need to figure out if it's a windows machine so I can select between \13 and \13\10 (crlf).

Would you mind @baogorek trying the branch ttempt-fix-lf to check if it fixes your line-endings issues on windows?

Best regards and sorry once again,
Henry John Kupty

[baogorek]

Hi @hkupty,

Here's the verdict on the branch attempt-fix-lf:

• Using the default iPython REPL (v 7.9.0 running Python 3.6.8), your new branch successfully removes the crazy characters in the default iPython console, but still will not execute the command block with the ctr key combo in visual mode, leaving the block hanging in the console.

• Using that same iPython REPL with the flag --simple-prompt (as shown in my own plugins.lua), ctr executes the entire block, but the newlines are lost.

Henry, I finally have a set of keymappings for this set of tasks that works. Along with the plugins.lua that uses the --simple-prompt version of iPython, this init.vim file contains 3 keymappings, the last being the one that sends a visual selection to the iPython editor. It works! And it's fast. But it does require the --simple-prompt iPython flag. You'll see from this emacs QA that things got more complicated for IPython around version 5.

One final note is that, for whatever reason, the nmap-ed <Plug>(iron-send-line) is way slower than the vmap-ed custom version. I'll still use it but I'm just curious as to why.

Ben

Update after a few hours of developing: I am feeling the limitations of --simple-prompt, especially loss of tab completion. It would be sweet to get the real iPython working.

[hkupty]

It's nice to see that it improved the situation.

I'm planning to do the following:

• Verify if there are any other places that deal with line endings in the code;
• Verify if either windows, ipython or ipython on windows require any special line-ending;
• If this is the best we have for windows, then:
  • Check for windows also before starting the ipython interpreter, so we start --simple-prompt for windows.
  • try to find a way to deal with new-lines on --simple-prompt

Out of curiosity, have you tried the mapping I suggested as answer to this issue with my branch?
I think it might work better now as the line ending is somewhat better.
map <F5> <Cmd>lua require("iron").core.send(vim.api.nvim_buf_get_option(0,"ft"), vim.api.nvim_buf_get_lines(0, 0, -1, false))<Cr>

---

Regarding your keymaps, I think your mapping <localleader>s clashes with iron's default <localleader>sl, which leaves nvim pending for a while waiting for your input. You can disable
that by setting let g:iron_map_defaults = 0, but you'll have to map ctrand cp yourself or you can unmap <localleader>sl, which is also mapped to <Plug>(iron-send-line).

[baogorek]

• First, let g:iron_map_defaults = 0 really sped up my single line submit. Thank you!

• Regarding finding a way to deal with new-lines on --simple-prompt, I know it's hideous, but this vmap works perfectly on my system (depends on Show_position from earlier in thread):

vmap <localleader>s :lua lower, upper = unpack(vim.api.nvim_call_function("Show_position", {})); my_table = vim.api.nvim_buf_get_lines(0, lower - 1, upper, false); for i = 1, table.getn(my_table) do require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), my_table[i]) end; require("iron").core.send(vim.api.nvim_buf_get_option(0, "ft"), "\n\r");<Cr><Cr>

• Something's blocking me from mapping F5, but I mapped xyz to your command, while still in the test branch, and here's what it does:
  • In regular iPython, it sends all the code of the original file, but does not execute it. If I switch to
    the console and press enter, there is a syntax error to a bad character that is invisible in the
    console. After entering the code, it's showing up as a "?" (as in print('first line')?)
  • In --simple-prompt iPython, all the code is executed but without newlines, leading to syntax
    errors.

[hkupty]

It looks like I might have got the order wrong. In linux it's \n only. In win, it's \r\n, not \n\r. I just pushed a fix for that. Hopefully that'll fix it definitely :)

[baogorek]

@hkupty I wish I had good new for you. I stayed on the same branch and ran :PlugUpdate and I saw a small change indicated. I disabled my custom functionality, restarted vim and tried everything over again. Unfortunately, it just didn't seem any different.

I'm happy to keep testing changes as long as you keep sending them, but I am bearish on the default iPython doing what we want it to, at least in its current incarnation. I bet if we went back to version 4 it'd be a delight.

[hkupty]

There might be a way, based on prompt-toolkit's documentation:

A side effect of this is that the enter key will now insert a newline instead of accepting and returning the input. The user will now have to press Meta+Enter in order to accept the input. (Or Escape followed by Enter.)

I'll try to implement esc+enter for ipython and I'll let you know :D

[hkupty]

Great news. I found another hardcoded linefeed (\n or \13), specifically in python's unique formatting (bracketed paste + return, which itself is a form of esc+enter), and I made that one also use system-dependant line ending.

I'm really glad you're helping me out here as I don't have a windows machine to test this.

[baogorek]

Glad there are still unexplored avenues. I updated this morning. iPython is still acting the same (had to manually press enter to get the syntax error). I tried it with ordinary python 3.6.8 and it behaved more like simple-prompt mode on iPython, executing automatically but no line breaks. Screenshots at the bottom. You'll see I have a few shell commands in the mix. These work perfectly when visually highlighting and pressing ctr to send to Powershell.

Happy to help and you're doing me a huge solid by building these tools. I've been looking for something that gets me Slimux-like functionality on Windows. Cygwin makes most REPLs unusable and WSL makes me go through 20 steps to see a plot.

If you'd like to interactively debug over Hangouts or something, I'm free most of the weekend (on Eastern Standard Time).

[hkupty]

Based on what you described, I might have actually swapped CR and LF when implementing the windows version. I just pushed yet another commit (hopefully the last one). If this doesn't work, then I think we'll be faster doing a Hangouts sessions.

As iron provides APIs, as well as other projects I have, like nvimux, we might think of a way of integrating them to get some functionality like that. :)

[baogorek]

Let's jump on Hangouts. Nothing is changing for me when I make these updates. My gmail id is the same as the github id.

[baogorek]

One of the things I'm learning about is this "Prompt Toolkit," which I think is causing all the issues for iPython. The rlipython tries to bring readline back but it's got some issues with IPython 7.