| Summary: | Visual indicator if line is going to be split up | ||
|---|---|---|---|
| Product: | [Applications] konversation | Reporter: | David L Emerson <demerson3x> |
| Component: | inputline | Assignee: | Konversation Developers <konversation-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | hein, rmatov101 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
oversized message with printable characters
input line ending with blank space and posted sizes |
||
|
Description
David L Emerson
2006-05-27 22:07:19 UTC
the message should just be split up into multiple messages (automatically) imho. I reported this bug because I was having trouble programming a bot. If the line splits, the bot's data gets screwed up. Also, the bot may need a different amount of padding than I need when I say it, due to nick length or bot prefixes. We now have two fixes in this area. 1) You can set the input box to grow as text is entered. 2) Lines that are too long are properly split, and are properly displayed has having been split. Has this problem been sufficiently alleviated? The short answer is no. Although the growing input box is certainly helpful -- in terms of giving one an approximate idea of how much text has been typed (2 lines vs. 4 lines) -- a precise counter would still be very useful (especially when considering variable-width fonts and word wrap). I also now understand that the limiting factor on IRC is the byte count, rather than the character count. Since some characters take multiple bytes, a byte count would really be more appropriate. Konversation is actually smarter than this thread is aware of: First of, it correctly calculates the number of available bytes for a message payload (i.e. it figures out how long the protocol preamble will be for the receiving end and substracts it from the 512 byte buffer limit imposed by RFC 1459) and then splits up the text input according to the actual number of bytes used (i.e. it is aware of variable-length encodings). Furthermore, it tries to do the split at the nearest occurrence of whitespace. Given that, truncation is a non-issue. Closing. I REPEAT COMMENT #2: I reported this bug because I was having trouble programming a bot. If the line splits, the bot's data gets screwed up. Renaming this - as established a character count isn't useful, but a visual indicator of when the line is going to be split up might be. Or perhaps an option to not allow typing beyond the limit. *** Bug 281309 has been marked as a duplicate of this bug. *** Created attachment 78911 [details]
oversized message with printable characters
This is when one can see how large is message because all characters are printable.
Created attachment 78913 [details]
input line ending with blank space and posted sizes
This is what happens when one adds blank spaces at the end of the line.
Input line looks normal, but posted message is large. It happened to me to post over 4k of characters without noticing that space bar on a keyboard was stuck and line was extremely long.
This does not have chance to happen in a normal usage, but it happened because space bar stuck pressed and I left computer for a while. When I was back nothing on the screen would tell me that there are kilobytes of characters ready to be posted. Pressing Enter all that was posted and message field was emptied with my nick repeated periodically.
It is like a hidden bomb that is waiting to be activated.
|