<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I agree with what you said and I wonder myself if it is possible at this</div><div class="">time for Swift to do what I mentioned in that article, given the current</div><div class="">roadmap.</div><div class=""><br class=""></div><div class="">Everyone would have to rewrite the agenda of Swift 5 to incorporate </div><div class="">most of what I was talking about. Additionally, Swift's</div><div class="">syntax and XCode would begin to overlap. It would definitely require a "smart</div><div class="">editor," but then I also think that all terminals should be smart likewise.</div><div class="">The distinction between code and code editor would become less clear.</div></div></div></blockquote><br class=""></div><div>However pretty printing things like matrices get handled, if that <i class="">isn't</i> simply part of the OS's text handling facilities, every "smart" editor will handle it differently (like different HTML rendering engines, except without the common HTML spec) and the "dumb" editors will show something that's shockingly different. It really seems to me that getting good, <i class="">consistent</i> support for "multi-line lines" in regular text editors will probably take a new OS which has that functionality baked-in its APIs at a low enough level that there isn't a way to <i class="">not</i> support it without just completely rolling your own text system (I suppose removing and replacing the existing APIs would work, too, but from a certain PoV that essentially is a new OS). In particular, if rows are no longer fixed-height, you've decoupled the cursor's logical position from its on-screen position... apps that were written/compiled before pretty print came into the API would render everything after an extra tall line at the wrong y position.</div><div><br class=""></div><div>I think getting easy unicode input is probably doable for the big three OSs, though, especially if the USB consortium would release a unicode-aware HID spec.</div><br class=""><div class="">- Dave Sweeris</div></body></html>