> On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution
> <[email protected]> wrote:
>
> I agree with what you said and I wonder myself if it is possible at this
> time for Swift to do what I mentioned in that article, given the current
> roadmap.
>
> Everyone would have to rewrite the agenda of Swift 5 to incorporate
> most of what I was talking about. Additionally, Swift's
> syntax and XCode would begin to overlap. It would definitely require a "smart
> editor," but then I also think that all terminals should be smart likewise.
> The distinction between code and code editor would become less clear.
However pretty printing things like matrices get handled, if that isn't 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, consistent 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 not 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.
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.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
