| Geth | Terminal-Widgets/main: 7 commits pushed by (Geoffrey Broadwell)++
|
00:11 | |
| japhb | So ... it turned out #36 triggered a cascade of refactorings and improvements. On the plus side, cursor movement in WrappableBuffer has several less bugs after that. | 00:14 | |
| patrickb: ^^ | |||
| Geth | ¦ Terminal-Widgets: japhb self-assigned FeatReq: Full line highlight mode github.com/japhb/Terminal-Widgets/issues/34 | 00:16 | |
| Terminal-Widgets/main: aeffb96038 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/Viewer/RichText.rakumod Support line highlighting to edge of RichText widget |
01:29 | ||
| Terminal-Widgets/main: 22362e8509 | (Geoffrey Broadwell)++ | examples/rich-text-viewer.raku Allow toggling highlight-line-to-content-edge in rich-text-viewer |
|||
| japhb | patrickb: And that closes #34 too: ^^ | 01:30 | |
| japhb chews on #35 ... | 02:18 | ||
|
05:07
disbot12 left
05:08
disbot13 joined
|
|||
| patrickb | Yay! I'm gonna incorporate these into the debugger right away. | 07:56 | |
| Geth | Terminal-Widgets: patrickbkr++ created pull request #37: Fix clicking below the last line in a wrappable buffer |
09:43 | |
| patrickb | In WrappableBuffer there is this optional optimization with `span-line-start($start)`. Can I get a quick explanation how to use that? I guess I somehow need to feed my domain knowledge into that function (in my case each line group I inserted encompasses exactly one logical line). | 12:10 | |
| Also, is using `post-process-line-group()` the right approach to add additional highlighting to lines? I'd like to highlight the line where the program is currently stopped. | 12:26 | ||
| Additionally I'd like to modify the color of the line number when there is a breakpoint on that line. Currently I just prefixed the line number as a separate span to each line. (This will change once we have figured out how to do it properly, but it'd still be nice to be able to signify breakpoints now.) | 12:29 | ||
| japhb | span-line-start() is used to reduce the cost of span-line-chunk() by potentially skipping line groups that *could not possibly be visible*, before the normal loop continues to refine the chunk of visible lines that will be handed back. Basically allows subclasses to put a bound on the cost of span-line-chunk(), no matter how long the buffer gets. | 17:18 | |
| If it can't optimize, it just returns (0, 0). If it *can*, it returns the index (NOT id) of the first line group that span-line-chunk() should consider, and the line number within the buffer of the first line of that line group, as ($lg-index, $first-line-number) | 17:21 | ||
| Yes, post-process-line-group() is exactly the place to put special highlighting and such. The contract there is that you can change the spans of each line however you desire *except* that you understand this is happening *after* line wrapping -- so it shouldn't try to change the line count -- and happens *every time you refresh the widget*, meaning it should attempt not to be too slow. | 17:25 | ||
| It really does sound like setting the wrap width of the main content lines is a valuable thing. | 17:27 | ||
| For breakpoints, I would consider 🛑 as an icon between the line number and actual code line. | 17:29 | ||
| (Could be easily nerfed back for older symbol sets as well, so that's no biggie) | 17:30 | ||
|
17:31
japhb left
17:37
japhb joined
|
|||
| japhb | 🛑 for Uni13, 8 | 17:44 | |
| 🔴 for Uni7 | |||
| ● with red coloring for Uni1 | 17:47 | ||
| red o for ASCII I suppose | |||
| ... I'm such a Unicode nerd | 17:48 | ||
| lizmat | agree with adding a visual marker, rather than just changing the color | 17:57 | |
| because just changing the color may well be invisible to a portion of the potential users | |||
| japhb | o/ lizmat | ||
| lizmat | japhb o/ | 17:58 | |
| japhb | Exactly what lizmat said | ||
| Geth | Terminal-Widgets/main: f6911a6722 | (Patrick Böker)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Fix clicking below the last line in a wrappable buffer |
18:17 | |
| Terminal-Widgets/main: 47a7a596aa | (Geoffrey Broadwell)++ (committed using GitHub Web editor) | lib/Terminal/Widgets/WrappableBuffer.rakumod Merge pull request #37 from patrickbkr/fix-set-cursor Fix clicking below the last line in a wrappable buffer; needs one additional fix after this. |
|||
| Terminal-Widgets/main: 9c5042d28c | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Follow-up fix for merged PR |
18:20 | ||
| Terminal-Widgets/main: dbf76b4c85 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Clarify wrap-prefix references, since other prefix types are coming |
18:25 | ||
| Terminal-Widgets/main: 77d2feb6a9 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Allow WrappableBuffer users to reserve some line width |
18:39 | ||
| japhb | patrickb: This ^^ allows you to mark some of the horizontal space of a WrappableBuffer as reserved-width, which will be subtracted from line wrap width automatically. That's the space in which you can stuff your line numbers, breakpoint markers, etc. (You can also override the calculation of available-wrap-width if you want to do some dynamic magic.) | 18:41 | |
| Commented on #35; let me know if I can close it now. | 18:45 | ||
| Geth | ¦ Terminal-Widgets: japhb self-assigned How to create a source view widget with line numbers? github.com/japhb/Terminal-Widgets/issues/35 | ||
| patrickb | oh wow, that was fast! | 19:10 | |
| I think I still need a bit more help Re span-line-start. Is it oblivious about wrapping? Because as a user of the class I wouldn't know how to account for the dynamics wrapping brings in. | 19:11 | ||
| What is $start exactly? The logical first line of the chunk? (i.e. the line number of the input text?) | 19:12 | ||
| If so, it's trivial, if I happen to know that line-groups equal lines. | 19:13 | ||
| So just given line group index equals line number, I can just return `($start, 0)`? | 19:14 | ||
| patrickb tries | 19:15 | ||
| Returning $start, $start makes it work. I think I need to return the line-group index (which equals the line number) and the logical line number of the first line of that line group. (also equals to the requested line number) | 19:37 | ||
| I think I won't be able to get the `span-line-start` optimization to work. `$pos` is the *display* line number of the first visible line. So $pos needs to take wrappings into account. To calculate tha value, I'd have to iterate through `%wrapped-lines` and sum up the line counts. That defeats the optimization as that's exactly what `span-line-chunk` does already. | 20:24 | ||
| Actually this issue is closely related to the discussion about the line number prefix thing. | 20:42 | ||
| github.com/japhb/Terminal-Widgets/...3849642095 | |||
| Both of these revolve around the issue of having the hard line number of the first visible line number available. | 20:43 | ||
|
20:57
librasteve_ joined
|
|||
| japhb | You always have the buffer's hard line count available (that's updated at insert time). Wouldn't you want to base the space you need on that number, since it is by definition the widest the number could be in the current buffer? | 22:14 | |
| patrickb: Are you going to do syntax highlighting of the Raku source? If so, using what library? | 22:33 | ||
| patrickb | syntax highlighting is already in. | 22:34 | |
| Uses Rainbow. | |||
| The debugger was the sole reason for me to create Rainbow. :-P | |||
| I want to have the widest number that can possibly be lu | 22:36 | ||
| in the visible screen area. | 22:37 | ||
| that's why I'm interested in the first hard line number on the screen. I can then add the widget height and take the width of that line number. | 22:38 | ||
| japhb | But that means that as you scroll back and forth across lines 10, 100, 1000 you'll cause the display to twitch. Which, if you're following execution path, will happen with great regularity. | ||
| patrickb | That's true. Maybe a bad idea. But at least most graphical editors do it this way... | 22:39 | |
| japhb pulls up Rainbow to take a look at that too .... | 22:40 | ||
| I think we should (between us) go for "works" before "ideal". I already have enough trouble fighting my instincts to overdo it. :-) | 22:41 | ||
| patrickb | Agreed. But my gut feeling is, that the "give me the topmost visible hard line number" is actually a really good thing to have. | 22:42 | |
| Given that I currently have 3 issues in mind that all hinge on this. | 22:43 | ||
| 1. the line number thing | |||
| 2. the optimization of span-line-start | 22:44 | ||
| 3. keeping the scroll position stable in light of the width and thus the wrapping changes | 22:45 | ||
| 4. I'd like to persist the scroll position when switching between different files and even restarts. That should really be a hard line position and not a display line position I'm persisting. | 22:46 | ||
| I'm off to bed. Good night! | 22:48 | ||
| Geth | Terminal-Widgets/main: 8a6159ea97 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Discuss refreshes in WrappableBuffer.clear.WHY |
22:51 | |
| Terminal-Widgets/main: 1d4902de8d | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Make several formerly-private WrappableBuffer attributes visible |
|||
| japhb | Good night! | 22:54 | |
|
23:07
librasteve_ left
|
|||
| japhb | Did you do the grammar in git.sr.ht/~patrickb/Rainbow/tree/m...ar.rakumod by hand? | 23:10 | |