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.