horizontal scrolling?

[cmyr]

Currently, text which doesn't fit within the window is clipped, and there is no support for horizontal scrolling.

I can think of two general approaches:

1. Introduce support for horizontal scrolling if lines overflow the view. This is Sublime's behaviour. In this case, we would also want to think about how the gutter view behaves during scrolling; options are to either treat it as part of the content and allow it to scroll as well, or to float it over the content and keep it visible. I'm inclined towards keeping it visible.

2. Always wrap lines, don't support scrolling. This is the behaviour (afaict) of Xcode. I think it's appropriate there, but I wouldn't particularly want this feature if I were writing python, say. But I don't really feel like a zealot on this point.

[raphlinus]

This is another feature that did partially work at some point, but has regressed. (It was even the case that the shadows drawn by the shadow view changed to give a visual indication).

What has always been missing, though, is the core measuring the maximum width and conveying it to the front-end (so scrolling would only happen if the window were narrow). This is made even more complex by the fact that the width is really pixels, not "characters," so the core needs to be able to measure text. That's the same measurement needed for line wrapping. Of course, for ASCII characters in a monospace font, the correspondence between characters and pixels is straightforward.

I definitely would want to keep the gutter visible while horizontally scrolling. I wouldn't want to force wrapping.

For extra added bonus, it might be worth thinking about whether text drawing in the horizontal scrolling case should draw a partial line. My preliminary measurements of Core Text show it performing very poorly for 1MB+ lines. If the core has to have accurate measurement, it could present a partial line for display, similar to what it does for vertical scrolling. However, I'm not convinced this would be worth the added complexity.

[cmyr]

I've been thinking about this as well in terms of line wrapping non-monospaced text; it is not clear to me that the core could ever be capable of independently calculating correct widths, because that will depend on the particular implementation details of a particular frontend's drawing system, which might be taking into account things like accessibility preferences that could affect drawing? Or a TUI's lack of support for variable-width fonts?

I guess it's feasible that implementing some generic type-layout stuff in the core could provide results that were "good enough". The only perfect system I can imagine is one where the core and the frontend coordinate, with the core querying the frontend for layout information. Although maybe this could be simplified to having the frontend just provide information on font support and attributes, and then the core runs its own layout engine?

None of these solutions feel especially elegant to me.

Re: partial lines: I think the core should always provide full lines, and then if a given frontend chooses to optimize around selectively drawing partial lines then that's an implementation detail. When I look at this project, I think one of the biggest engineering challenges will be keeping as clean, consistent and interpretable RPC API as possible. Sending partial lines seems like unnecessary complexity.

Again it isn't clear to me that the core has to be involved in horizontal scrolling. As far as it is concerned can't the document view can be infinitely wide and always visible?

[raphlinus]

My thinking regarding measurement is that the front-end supplies a "measure text" method; takes a string and attributes, returns a (float) width. It would probably be defined on arrays, to cut down on the number of individual RPC requests. The core would cache the results (generally on a "word" granularity), which would also cut down on the traffic. Further, there would be special casing for monospace fonts, so when dealing with large code and log files, there would be basically no RPC traffic for this.

This seems to me a little complicated, but not horribly bad. And efficiency should be decent given the optimizations mentioned above.

I agree on letting the front-end handle horizontal scrolling itself. But it's a conversation I've had with @rtsuk and it's something to consider as a possibility.

[cmyr]

Okay glad you're leaning in that direction, it seems like the best approach.

[raphlinus]

See #145 for the current thinking on this. Maybe close this issue to make sure the latter is considered main?