Using Ranges for external editor modifications

[DevinBayly]

This issue relates to an attempt to send information about multicharacter ranges to iodide from the external editor. What has me the most stuck at the moment is where to start in terms of creating a reducer that can actually access and make calls to the monaco editor instance running in the Iodide Notebook. @bcolloran any thoughts to offer here?

[bcolloran]

@DevinBayly can you point me at the code you have so far so i can see how you're thinking about this?

i think we'll need to do a bit of surgery to get this working. there are a couple ways we could do it --

1. via redux is probably but best, but i'm not certain of that. in this case, we'd need to implement a reducer case that knows how to handle an "UPDATE_TEXT_RANGE" action that correctly replaces the range indicated (probably not too hard?). (as i think about it for a sec, this is probably the direction we'll need to end up going in the long run for iodide anyway...)
2. we could have a special message that interacts directly with the monaco instance and uses its updating APIs (maybe this one, but i'm not sure https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor.ieditoperationbuilder.html ),

[DevinBayly]

oof, haven't put code down to this yet. I was mostly wandering through the src tree in iodide looking for clues about how information in the state triggers changes down stream in areas I care about like the editor. I sort of believed there could be some more info on the editor state than just line, col, like "range", but i didn't know how the text to include in the range was meant to look so I put up this issue to get your thoughts.

I agree that option 1 seems like the best way to go. It's just a matter of making the editor visible to the reducer scope right? Perhaps I'm jumping the gun and the reducer is only meant to update the state and that will ultimately trigger the correct changes though, and then we are back to my suggestion above. Either way some surgery is likely needed as you say.

[bcolloran]

yea the way the data flow is meant to work in a redux app is that you update the app state and the presentational components (in this case the Monaco instance) will update based on that. that part of the pipeline should be working already -- if we update state.iomd in the Redux store, then Monaco will update to reflect the changes

[DevinBayly]

gotcha, yes the basic presentational updates are in working order. I think I need some suggestions about where to look to better understand how the monaco instance handles a change in the state.iomd. With this info I could probably write a way to detect a large input or deletion action and have it perform a ranged modification. Also if you can suggest where to look for understanding how to add fields to the state object that might be helpful too, but if that's something we shouldn't modify lightly then never mind.