|
Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.4 has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.4.md) | This channel is logged for historical purposes; logs at irclogs.raku.org/mugs/index.html Set by japhb on 3 March 2024. |
|||
|
00:41
timo joined
|
|||
| timo | ohai | 00:41 | |
| it'd be cool if Terminal::LineEditor could offer some hooks or mechanism to allow "cooperation" with other systems asynchronously. for example, if i have some code that i evaled and ran in liz's REPL that did somethinglike `Promise.in(1).then({ say "hi" });` that will of course mess up my editor line. so ideally, I could give the code I'm running after evaling it a special $*OUT and $*ERR that would | 00:43 | ||
| ask Terminal::LineEditor to handle the outputting for it | |||
| also, it'd be cool if I could change the "prefix" of the editor asynchronously, for example to put a counter of active work items in the ThreadPoolScheduler (which there could be a separate one for the evaled code too) in front of the input | 00:45 | ||
| maybe it'd be helpful / easier to put a second line above the Terminal::LineEditor's input line? where I can put stuff manually, and then above that anything being printed "to the scrollback buffer" | |||
| also, building a cooperative $*IN that allows the user to switch between inputting into the REPL's own Prompt which is backed by Terminal::LineEditor (optionally), and every $*IN.get or $*IN.prompt or whatever | 00:49 | ||
| japhb | timo: These are all great ideas! Would you mind turning them into T::LE issues? | 01:51 | |
| I've definitely thought that it might be nice for async updates to the input line, the prompt, or other surrounds. That opens up a ton of capabilities | 01:52 | ||
| timo | and a lot of headaches :) | ||
| japhb | Some of these things would be best as part of patrickb's TLI debugger, but I'm all for more capabilities in the base library if they benefit the Raku REPL. | 01:53 | |
| timo: Well, yes. But I'm an implementor willing to be tortured, or I wouldn't have written half the Terminal::* code that I have. ;-A) | |||
| timo | i'm thinking it'd be nice to have something a little bit more powerful than just the single line (or later a multi-line instead of scrolling input field) that's not a full TUI widget library / framework | 01:54 | |
| i got half of this stuff because the array of completions ended up with a Nil inside it which caused a warning to be spat out during raw mode | 01:55 | ||
| japhb | timo: Well we need a multi-line text box input as a widget anyway, so that was definitely on the list | ||
| timo | yeah i remember that that was on the to-do already | ||
| japhb | timo: That's broken behavior, AKA a bug. The code shouldn't just crash with weird data from the app (or REPL, in this case); that's not helpful to the user. | 01:57 | |
| timo | yes. well, it didn't crash, it just warned. | 02:00 | |
| oh, wait | |||
| actually it did throw an exception, because Nil was coming into a parameter that was typed Str:D | |||
| Died because of the exception: | |||
| Type check failed in binding to parameter '$content'; expected Str but got Nil (Nil) | |||
| in method replace at /var/home/timo/raku/ecosystem/REPL/../Terminal-LineEditor/lib/Terminal/LineEditor/EditableBuffer.rakumod (Terminal::LineEditor::EditableBuffer) line 209 | |||
| japhb | Yeah, feels like the code should protect against its API being used badly and at the very least give an error that the user might actually be able to do something with. | 02:01 | |
| The error you pasted is LTA from the point of view of the library's user trying to figure out what they got wrong with their use of it. | 02:02 | ||
| Also ... the security side of me says "Naughty japhb, you didn't sanitize inputs you don't control!" | |||
|
09:18
lizmat_ joined
09:21
lizmat left,
lizmat_ left,
lizmat joined
10:02
greenfork left,
greenfork joined
23:09
japhb left
23:32
japhb joined
|
|||