Add ListMessageSplitter and apply to rules command#376
Add ListMessageSplitter and apply to rules command#376ShadowJonathan wants to merge 3 commits intomatrix-org:mainfrom
Conversation
Gnuxie
left a comment
Gnuxie
left a comment
There was a problem hiding this comment.
Thanks @ShadowJonathan , this is something we have needed for awhile.
I think some documentation about how the implementation works will go along way, as I don't think I quite understand what this is doing 😸
I think testing the public methods of MessageListing would help too, but probably not a requirement for the moment
Thanks!
|
(A general note for maintainers) Maybe time to take a look at this adhoc string concatenation and fallback mess and instead consider using templates for the messages. I guess even duplicate templates for the text fallback is better if stripping html isn't good enough. |
- added documentation - moved sending to splitter function
src/ListMessageSplitter.ts
Outdated
| // Returns: | ||
| // `sized` != null, if sized was adequate, or had to be split | ||
| // `rest` != null, if sized was not adequate (and had to be split), | ||
| // or the first item is too big to be split at the desired size. |
There was a problem hiding this comment.
How is the caller going to handle a first item that is too big to split?
There was a problem hiding this comment.
The idea here is that the listings are split to be fit into a single message, if the first item is too big, it has to go into the next message.
So, "sized" (what goes into the current message still) is "null" for this, "you cannot put more of this in the currently composing message"
There was a problem hiding this comment.
Ok, sorry, my message assumed that a listing item could be over the limit here so i was confused about how this method would handle that situation
| // (Replaced at the end of the loop) | ||
| while (current_item !== undefined) { | ||
| // Add the new item tentatively | ||
| // Add the new item to `sized` tentatively. |
There was a problem hiding this comment.
tentatively? Wouldn't it be safer/clearer to guard the push with sized.size() + current_item.size()?
There was a problem hiding this comment.
no, because there might be things about a listing's size that are optimised or changed as result of an item being added.
For example, if sized has no items in it, it will not emit a <ul></ul>, reducing 8 bytes of the final size. If it does have an item, it'll add that and the item.
So it is safer to try, and then back off to the last version of the listing if it becomes too big.
There was a problem hiding this comment.
Ohh, I see what you mean. That is quite unfortunate .
There was a problem hiding this comment.
I also don't want to duplicate logic to calculate it, as that's prone to desync if the original logic is updated.
|
Thanks for taking the time to document this in the detail you have, it's much clearer now 😸 |
Gnuxie
left a comment
Gnuxie
left a comment
There was a problem hiding this comment.
Just some style pointers since this seems to have been written in a very rustic way 👍
Let me know if you need help, i don't mind refactoring the style for you
2 participants
Fixes #294
This adds a class where one could add "headers" and "items", and it'll internally split it nicely to fit inside an encrypted message, allowing enormous listings to be posted to the chat.
This also alters the
rulescommand to use this class for this.