<div dir="ltr">Here's the previous discussion on this issue: <a href="https://lists.cuis.st/mailman/archives/cuis-dev/2019-April/000057.html">https://lists.cuis.st/mailman/archives/cuis-dev/2019-April/000057.html</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 4:13 AM Phil B <<a href="mailto:pbpublist@gmail.com">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I recall running into an issue re: Encoder changes Hernan did a while back and now I'm having a nearly identical issue related to the recent changes.<div><br></div><div>Specifically: multi-ranges and the brittleness of that code in that if you don't provide the exact right hacked version of the 'range' (i.e. sometimes it's an Interval, sometimes it's a collection of Interval), things will fail.  So now I'm having a problem after the latest changes with #noteSourceRange:forNode: complaining because I'm passing it a collection of ranges where it now expects a single range.  I'm only passing it a collection of ranges because the *previous* changes to Encoder would break if you only passed in a single range.  Of course, if I change my code back to passing a single range (i.e. undoing my fix for the last Encoder change), it breaks things elsewhere where it's expecting a collection of ranges.  Essentially the solution that I used previously was to create a MessageNode with a sourceRange: parameter that was a collection... that no longer appears to be viable.<div><br></div><div>Can this be either cleaned up (i.e. auto-detect or just use multi-ranges everywhere) or better document (and stick with!) the approach?</div><div><br></div><div>Thanks,</div><div>Phil</div></div></div>
</blockquote></div>