feat: core.send_code_block

[frere-jacques]

Editors like vscode or pycharm or tools like jupyter notebooks let you send code blocks devided by a delimiter, eg. in python '#%%' or '# %%' to the repl.

The plugin jupytext is also to mention here, as it creates a .py representation of jupyter notebooks, in which in case of the py:percent style, the code blocks are delimited with '# %%'.

I wrote this feature which lets you define multiple code_deviders in the repl_definition and let you send the lines between those to the repl. Optionally one can choose to move the cursor to the next block in order to iterate easily through the file.

I also updated the doc and the readme to reflect for the changes and included two commands to the core.named_maps.

I hope you like, what I did here, and see the comfortable workflow provided by it.

I asked here #386 (comment), whether this would be possible, but then had fun, implementing it myself.

[nickeisenberg]

This is a cool feature. I had an issue with send_code_block_and_move. It would only move the cursor to the end of the current code block rather than the start of the next code block. I ended up replacing

  if move then
    vim.api.nvim_win_set_cursor(
      0, { math.min(mark_end + 2, buffer_length), 0 }
    )
  end

with the following

  if move then
    -- Start searching from the line after the current block's end
    local last_block = true
    local next_block_start = mark_end + 2
    while next_block_start < buffer_length do
      local line_text = buffer_text[next_block_start + 1]
      if line_starts_with_block_devider(line_text, block_deviders) then
        -- Move the cursor to the next block divider
        vim.api.nvim_win_set_cursor(0, { next_block_start + 1, 0 })
        last_block = false
      end
      next_block_start = next_block_start + 1
    end

    if last_block then
      vim.api.nvim_win_set_cursor(0, { buffer_length, 0 })
    end

  end

and it seemed to work. What do you think?

[frere-jacques]

I have to have an look onto that later on.
I use my fork since I made that issue here on a regular basis and don't have issues with that.

For me the cursor moves to the next #%% and if I call the method a second time, the code block beneath is send.

Did you test it with multiple code blocks, from start to end?

[frere-jacques]

Had a short glance on what I did there.

So the part after if move is so small, because when it is determined what lines need to be send, ie. from where to where does the codeblock span, we already know where the cursor needs to go next, which is mark_end+2 or if the buffers end is reached the buffer end.

If there should be an actual bug, I rather would fix the identification of the marks than to put big logic in this move part.

[frere-jacques]

I saw that there are some recent commits. Do you mind to test my branch
https://github.com/frere-jacques/iron.nvim/tree/combined_additions

Or the specific feature branch:
https://github.com/frere-jacques/iron.nvim/tree/feature_send_code_block

[nickeisenberg]

I noticed something else that does not seem intended. With the following:

# %%
def foo(x):
    return x
       
foo(1)
# %%

print("hello")

# %%
def baz(x):
    return x
       
baz(2)
# %%

You can see that print("hello") is not in a code block, but if you put the cursor next to print("hello") and run send_code_block, it will run this as a block even though print("hello") is not surrounded by its own block_dividers. This doesnt cause any problems really, it would just be nice if it did not happen. A quick fix that I can see is that if you specify a start_block_divider and a end_block_divider.

[frere-jacques]

Okay, I think we simply have a differenf jnderstanding of the intended behaviour.

In context of this functionality a code block are all lines between two block_deviders and on edge cases the start and end of the buffer.

This matches the behaviour of editors like Pycharm, Jupyternotebooks etc.

So you should not think about language spevific code blocks but custom defined seperation of your file.

Since this is exactly how it works in many different places I strongly oppose to redesign this to something else.

[nickeisenberg]

Gotcha, ive never used this feature before in other editors. I just downloaded vscode and I see what you mean now. Ill check your other branch now,

[nickeisenberg]

combined_additions seems behind still, bracked_paste_python is not updated in your combined_additions branch. Could you merge the master into your changes and then I can merge that into master so that the code block feature can be available to everyone? It might be easier to just delete this PR and then make a new one and add your changed into that.

[frere-jacques]

I think I would need to make separate Pull requests. I assume one feature I merged there is in cobflict with the recent merge, as it sets the repl file type to the language file type.

See my comment in the other ticket.

[frere-jacques]

So I updated the feature_branch feature_send_code_block and updated the Pull Request.

[frere-jacques]

I am happy I could contribute and improve the plugin.

Really nice that the work here continues!

[nickeisenberg]

Thanks for the addition! I will try to stay more on top of the PRs

[frere-jacques]

@nickeisenberg that would be nice. Looking forward to the discussion about the other additions.

One already has some discussion, but with one of the recent PR setting buffer type to iron there is even more discussion needed.

The other is a straight forward fix.

[nickeisenberg]

I can take a look at that file type issue discussion, if you have a strong opinion on it, we can always change it.