| Geth | Terminal-Widgets/main: 628c19a57b | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Continue building WrappableBuffer ... including an explicit API (span-line-start) for computing jumps through the cached lines to make span-line-chunk more efficient in large buffers when the class consuming WrappableBuffer can do so. |
03:52 | |
| Terminal-Widgets/main: 504ee557ba | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/Viewer/Log.rakumod Drop Log.span-line-chunk in favor of adding Log.span-line-start |
|||
| Terminal-Widgets/main: d8a9e396a7 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod First working wrapping path in WrappableBuffer |
07:35 | ||
| Terminal-Widgets/main: 122f163d8e | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/Viewer/Log.rakumod Log shouldn't override scroll width when wrapping |
|||
| Terminal-Widgets/main: 2919ebdd26 | (Geoffrey Broadwell)++ | examples/dir-tree.raku Set log wrapping style in dir-tree example |
|||
| Terminal-Widgets/main: cf1ca3c0bb | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/WrappableBuffer.rakumod Add wrap-mode-sensitive WrappableBuffer.update-scroll-maxes |
08:02 | ||
| Terminal-Widgets/main: 94d5bd2d52 | (Geoffrey Broadwell)++ | lib/Terminal/Widgets/Viewer/Log.rakumod Fix Log scrolling bugs when in wrapped modes |
|||
|
11:31
librasteve_ joined
11:39
Geth left,
Geth joined
|
|||
| patrickb | bike shedding: How should external widgets be named? | 15:38 | |
| Terminal::Widgets::Plugins::TerminalEmulator? | 15:39 | ||
| japhb | That's not a bad idea, giving all external widgets a namespace | 15:40 | |
| patrickb | Or Terminal::Widgets::TerminalEmulator | ||
| japhb | I think that change represents an incorporation into core. | 15:41 | |
| patrickb | also TerminalEmulator or Anolis? (that's how the underlying emulation distro is called) | ||
| Anolis is pretty non descriptive | |||
| japhb | Yeah, I'd say Terminal::Widgets::Plugins::TerminalEmulator. Descriptive is good. | 15:42 | |
| patrickb | TerminalEmulator is squatting the generic name preventing other impls to emerge | ||
| japhb | Maybe Terminal::Widgets::Plugins::TerminalEmulator::Anolis then? | ||
| patrickb | Oof, that's pretty long and puts an abstraction in a place where we possibly (or even probably) will never need one. | 15:43 | |
| japhb | I do think things that have a category namespace will want that as well: Terminal::Widgets::Plugins::Input::Calendar for instance | ||
| I've gotten in the habit of import-then-alias for the length reason. | 15:44 | ||
| `use Terminal::Widgets::Foo::Bar::Baz; constant Baz = Terminal::Widgets::Foo::Bar::Baz;` | 15:45 | ||
| ^^ that sort of thing | |||
| I usually end up with 0 or 1 of these per new module; I don't generally need a pile of these, just need to clarify some code that would otherwise be hard to read repeating long module names | 15:46 | ||
| patrickb | I'm unsure if that's an argument pro or contra such deeply nested names. :-P Before you brought this up I'd have chosen either Terminal::Widgets::Plugins::TerminalEmulator or Terminal::Widgets::Plugins::Anolis | ||
| japhb | I'm totally fine with either of those, honestly | ||
| hence the 'Maybe' above. ;-) | |||
| patrickb | Ah! | ||
| I guess I'll go with Anolis then and hope for tags and description to fix the discoverability. | 15:47 | ||
| japhb | :+1: | ||
| patrickb | Thanks for the quick bike shedding session! | ||
| japhb | You betcha | 15:48 | |
| Oh, you might want to look at the dir-tree example again, and work your way down to a long pathname. The right pane of that example has wrapping-with-prefix enabled; hope you like it. | 15:49 | ||
| patrickb looks | 15:50 | ||
| japhb | Also, I'll be enabling both wrapping and filling in the core code, so that will hopefully be useful down the line. | ||
| patrickb | what's filling? | 15:51 | |
| japhb | Like a paragraph in HTML -- if you widen the widget, it backfills earlier narrower lines to make use of the extra horizontal space | 15:52 | |
| (Wrap and Fill being separate modes, naturally. There's often a reason for the hard lines in the source, after all.) | |||
| patrickb | ohhh | 15:54 | |
| that's pretty advanced stuff. | |||
| the wrap with prefix is pretty impressive | |||
| how does it know what prefix to use? | 15:55 | ||
| japhb | I *think* I see a way for Wrap and Fill to be minor variants with a common core. | ||
| In the particular case of dir-tree, it's specified in the example code. | |||
| patrickb | currently this feels like magic. | ||
| japhb | I love that. :-) | ||
| patrickb | if this works generally, it would solve loads of issues. E.g. the issue with the source code widget that has line numbers prefixed. | 15:56 | |
| (It wouldn't solve scrolling though.) | |||
| japhb | That's the big use case, yeah. (viewing source code) | 15:57 | |
| What do you mean by scrolling in this particular case? | |||
| Or rather "solve scrolling" | |||
| 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 | |