Granularity question

[DevinBayly]

@bcolloran @hamilton
I thought I would create an issue to discuss the question of granularity for the extension to support. In reality, I now know enough about the code base to support single char deletion and insertion all the way up to just slapping the whole editor buffer into Iodide any time something happens in the external editor. I'm not suggesting that the latter be our approach, but I want to convey the full range of options.

That said, I would like to use whole buffer updates to initially cover some of the more problematic edge cases. For instance, line by line or char by char updates are fine when working within existing content of an editor. When the line count is changed and lines effectively shift their numbering is when this gets to be tricky. An option to tackle this could be creating more types of message to be sent from the external editor to iodide. However, I figure it would make the most sense that the documentation suggests and the proof of concept implements a case where deletion and insertion events on the line by line scale trigger whole buffer updates.

So here's a question: can we imagine scenarios when this would be the wrong thing to do? In cases where the document being worked on is very large this could present a problem, but I haven't tried to test out what the performance hits are when working with a large document. I can make that a todo though. Any thoughts to add here?

Also, is it wise to keep the api in #1 as slim as possible? Or would it be ultimately better to have messages that the editor plugin can share when these specific events occur? It'd be more things that people would have to implement when creating new external editor plugins too.

Anyways, I'm just putting some questions out there to get your inputs. Thanks!

[bcolloran]

@DevinBayly -- the notebook commenting feature we are pondering will depend on tracking insertions and deletions for each edit operation rather than blowing away the whole buffer. We may not get to that right away, but we are definitely heading there, so it's probably best to figure out how to make things work within the insertion/deletion paradigm if at all possible. Can you supply more details about one of these tricky cases: the info you are able to get from your text editor, what you attempt within iodide, the exact result etc? maybe we can help clear the way.

Re the API: i guess it's probably wise to keep the API relatively slim, but nothing is set in stone. we can certainly add interfaces to meet your needs

[DevinBayly]

Excellent, I had been looking for a forward facing reason to pick one or the other and now I've got that. In terms of the tricky cases I can lay them out as follows, and I believe I have a solution to test.

case 1

this is a line of text <cursor>
with a second line beneath

---> becomes

this is a line of text
<cursor>
with a second line beneath

The previous method I was using was to split the iomd on its newlines making an array and insert content into the correct place. That was difficult when the total number of lines increased or decreased like in the case above: went from two lines to three. The existing implementation is anything typed at the cursor when it has moved to the second line gets concatenated with the previous line two content leaving

this is a line of text
and I added some text<cursor>with a second line beneath

I believe shifting towards insertion without breaking the iomd into parts can make this easier, but I still have to explore that.