| 15 Dec 2025 | |||
| patrickb | When not wrapping, one sometimes wants to scroll right. In that case I want the line numbers to stay visible and only the code to scroll. | 15:58 | |
| japhb | Oh! | 15:59 | |
| japhb adds that to his list | |||
| patrickb | Intuitively I'd try to solve that with two different widgets. One for line numbers and one for the content. | 16:00 | |
| In general I think that approach has the potential to get behavior pretty right in all cases. But it depends on the ability of introspecting the wrappings of the code widget. | 16:01 | ||
| japhb | Yeah, though I'd want a solution that transparently does the right thing when the user changes wrapping modes | ||
| Right | |||
| patrickb | Also things get annoyingly complex when the line number width changes. (scroll down past line 99 and suddenly the line numbers are one space wider, potentially causing more wrappings, which potentially causes a change in the line numbers) | 16:03 | |
| japhb | One of the things I did in the big TextContent refactor is to have RenderSpans (at least the ones that were actually rendered, not manually created) know which StringSpan they came from. So you can always look at a span in the wrapped text and know exactly where it came from, and handle that accordingly. | ||
| Part of this is going to be allowing mouse clicks and cursor movements to be traced back to the actual source location correctly. | 16:04 | ||
| (Without every widget needing to figure that out for themselves) | |||
| Wider can only mean more wrapping, so at least that recursion is monotonic | 16:05 | ||
| Wider line numbers I mean | |||
| patrickb | True. In general this could cause cycles (flapping back and forth) and the solution has to be to stay at the wider line number width even though the number that caused the widening has been pushed out of view. | 16:06 | |
| japhb | nodnod | 16:07 | |
| AFK to perform Parental Taxi Service. BBIAB. | 16:09 | ||
| patrickb | I guess the easiest and robust solution is to always calculate line number width assuming no wrapping at all. Then do wrapping calculation, adjust the line numbers, but not the line number width. | 16:23 | |
| japhb | BAK | 16:34 | |
| Nodnod | |||
| I think I see a couple ways to do all of this, with *either* the line numbers/marks being a separate widget with tied scrolling like a scrollbar, *or* with it being one widget that knows how to scroll "in the middle". | 16:41 | ||
| patrickb | 👍🏼 | 17:16 | |
| 16 Dec 2025 | |||
| Geth | Terminal-Widgets/main: 2d9a39172b | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Implement duospace graph wrap and refactor a bit |
06:30 | |
| 17 Dec 2025 | |||
| Terminal-Widgets/main: 5 commits pushed by (Geoffrey Broadwell)++ | 04:08 | ||
| 27 Dec 2025 | |||
| Terminal-Widgets/main: 87bed4bfb0 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Adjust hard-line-count when removing a LineGroup |
03:47 | ||
| Terminal-Widgets/main: 4f90fbb1e6 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Improve a comment |
|||
| Terminal-Widgets/main: 38f1f0af8b | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Add a string-runs utility sub to wrap-lines string-runs() splits a string into alternating whitespace and NON-whitespace substrings. It does *NOT* handle non-breakable spaces yet. (All whitespace is treated the same.) |
|||
| Terminal-Widgets/main: 4e50990c98 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Start building WhitespaceSquashMode support |
08:54 | ||
| Terminal-Widgets/main: fabaaaf24a | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod WIP: Sketch of word-span-loop |
|||
| Terminal-Widgets/main: 60d3f8ca73 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Cleaner way to modify ws text |
08:57 | ||