[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols
davesweeris at mac.com
Wed Aug 30 12:56:03 CDT 2017
> On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution <swift-evolution at swift.org> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution