Leading whitespace stripped from messages skip_parameter and window_open both ate spaces after the trailing-param :. Now preserved per RFC 1459/2812.
\x0F (format reset) ignored
Previously a no-op, so the last \x03 color bled to end-of-line. Now resets to default in render and is zero-width in line-wrap.
Control bytes inflated line width \x02 bold, \x1D italic, \x1F underline, \x16 reverse, and mIRC \x03[fg[,bg]] args were each counted as a visible column, causing premature wrapping. All now zero-width, matching the renderer.
First byte after \x03N,N was silently eaten by a .no_colors fallthrough — now jmp .line.
Bare \x03 now resets to theme default instead of picking irc_colors[0] by accident.
text_nextline is also called backwards during scroll-up — a DF check in .skip_color avoids esi corruption.
New skip_mirc_color_args consumes the exact same byte span as the renderer's dec_to_esi, replacing two duplicated blocks.
Remaining (out of scope)
Visual bold/italic/underline rendering is not implemented.
Width accounting is fixed so wrapping is correct, but draw_channel_text still skips those bytes without changing font attributes — needs an attribute-aware draw path, a separate larger change.
## This PR Fixes
- **Leading whitespace stripped from messages**
`skip_parameter` and `window_open` both ate spaces after the trailing-param `:`. Now preserved per RFC 1459/2812.
- **`\x0F` (format reset) ignored**
Previously a no-op, so the last `\x03` color bled to end-of-line. Now resets to default in render and is zero-width in line-wrap.
- **Control bytes inflated line width**
`\x02` bold, `\x1D` italic, `\x1F` underline, `\x16` reverse, and mIRC `\x03[fg[,bg]]` args were each counted as a visible column, causing premature wrapping. All now zero-width, matching the renderer.
- First byte after `\x03N,N` was silently eaten by a `.no_colors` fallthrough — now `jmp .line`.
- Bare `\x03` now resets to theme default instead of picking `irc_colors[0]` by accident.
- `text_nextline` is also called backwards during scroll-up — a DF check in `.skip_color` avoids `esi` corruption.
- New `skip_mirc_color_args` consumes the exact same byte span as the renderer's `dec_to_esi`, replacing two duplicated blocks.
## Remaining (out of scope)
- **Visual bold/italic/underline rendering is not implemented.**
Width accounting is fixed so wrapping is correct, but `draw_channel_text` still skips those bytes without changing font attributes — needs an attribute-aware draw path, a separate larger change.
Digit-parser mismatch between width calc and renderer.
The new .skip_color parser in text_insert_newlines/text_nextline consumes at most 2 fg + 2 bg digits, but the renderer's dec_to_esi consumes all consecutive digits. For non-standard color codes with 3+ digits (e.g. \x03123), line-wrap width and rendered output desync.
Make the width parser consume the same byte span as dec_to_esi.
Undocumented behavior change in draw_channel_text.
The full \x03fg,bg path now does jmp .line instead of falling through to .no_colors, removing an implicit inc edx that previously ate the first character after a background-color code. This looks like a genuine bug fix, but it is outside the PR's stated scope and not mentioned in the description.
Please confirm if it is intentional or not.
New code duplication introduced by this PR.
The ~30-line .skip_color/.skip_color_comma/.skip_color_done block is added verbatim to both text_insert_newlines and text_nextline.
Both copies are correct, but since the duplication is created here, factor it into a shared helper while it's fresh.
Issues I see here:
- [x] **Digit-parser mismatch between width calc and renderer.**
The new `.skip_color` parser in `text_insert_newlines`/`text_nextline` consumes at most 2 fg + 2 bg digits, but the renderer's `dec_to_esi` consumes *all* consecutive digits. For non-standard color codes with 3+ digits (e.g. `\x03123`), line-wrap width and rendered output desync.
Make the width parser consume the same byte span as `dec_to_esi`.
- [x] **Undocumented behavior change in `draw_channel_text`.**
The full `\x03fg,bg` path now does `jmp .line` instead of falling through to `.no_colors`, removing an implicit `inc edx` that previously ate the first character after a background-color code. This looks like a genuine bug fix, but it is outside the PR's stated scope and not mentioned in the description.
Please confirm if it is intentional or not.
- [x] **New code duplication introduced by this PR.**
The ~30-line `.skip_color`/`.skip_color_comma`/`.skip_color_done` block is added verbatim to both `text_insert_newlines` and `text_nextline`.
Both copies are correct, but since the duplication is created here, factor it into a shared helper while it's fresh.
The color code counting logic seems overly complicated at first sight.
Did I really wrote a routine that counts characters backwards?
From what I remember, we just might need to scan backwards to find newlines.
How did you validate its correct behavior?
The color code counting logic seems overly complicated at first sight.
Did I really wrote a routine that counts characters backwards?
From what I remember, we just might need to scan backwards to find newlines.
How did you validate its correct behavior?
Burer
changed title from ircc: fix text formatting issues (#376) to apps/ircc: fix text formatting issues (#376)2026-06-07 16:57:16 +00:00
Burer
marked the pull request as work in progress 2026-06-28 13:22:15 +00:00
fix leading whitespaces being trimmed ,formatting clear chars ignored,
bold/italic/other control bytes counted toward line width in
text_insert_newlines and text_nextline, causing incorrect wrapping,
leading spaces stripped from PRIVMSG content
- Factor duplicated .skip_color from text_insert_newlines and
text_nextline into a shared skip_mirc_color_args matching the
renderer's dec_to_esi byte span.
- Guard text_nextline backward scans (DF check) so forward-parsing
\x03 args doesn't corrupt esi during scroll-up.
- Document the silent jmp .line that stops .no_colors from eating
the byte after \x03N,N.
- Document the .color_reset branch for bare \x03.
text_insert_newlines already inserts soft newlines into the buffer, so
text_nextline normally just finds them; its column-count path only fires
on a spaceless line wider than the textbox. Handling mIRC colors there -
especially in the backward scroll scan - added complexity for a
negligible edge and desynced forward/backward width. Color skipping
stays in text_insert_newlines (wrapping) and draw_channel_text (render).
Now to clean up the obviously LLM generated flood of comments, bump the version number of IRCC and preferably add some screenshot of before and after so we can see what it does :)
This code is looking a lot better!
Now to clean up the obviously LLM generated flood of comments, bump the version number of IRCC and preferably add some screenshot of before and after so we can see what it does :)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hidnplayr
Doczom
Burer
dunkaist
This PR Fixes
skip_parameterandwindow_openboth ate spaces after the trailing-param:. Now preserved per RFC 1459/2812.\x0F(format reset) ignoredPreviously a no-op, so the last
\x03color bled to end-of-line. Now resets to default in render and is zero-width in line-wrap.\x02bold,\x1Ditalic,\x1Funderline,\x16reverse, and mIRC\x03[fg[,bg]]args were each counted as a visible column, causing premature wrapping. All now zero-width, matching the renderer.\x03N,Nwas silently eaten by a.no_colorsfallthrough — nowjmp .line.\x03now resets to theme default instead of pickingirc_colors[0]by accident.text_nextlineis also called backwards during scroll-up — a DF check in.skip_coloravoidsesicorruption.skip_mirc_color_argsconsumes the exact same byte span as the renderer'sdec_to_esi, replacing two duplicated blocks.Remaining (out of scope)
Width accounting is fixed so wrapping is correct, but
draw_channel_textstill skips those bytes without changing font attributes — needs an attribute-aware draw path, a separate larger change.85b0585685toc449fb9d71Issues I see here:
Digit-parser mismatch between width calc and renderer.
The new
.skip_colorparser intext_insert_newlines/text_nextlineconsumes at most 2 fg + 2 bg digits, but the renderer'sdec_to_esiconsumes all consecutive digits. For non-standard color codes with 3+ digits (e.g.\x03123), line-wrap width and rendered output desync.Make the width parser consume the same byte span as
dec_to_esi.Undocumented behavior change in
draw_channel_text.The full
\x03fg,bgpath now doesjmp .lineinstead of falling through to.no_colors, removing an implicitinc edxthat previously ate the first character after a background-color code. This looks like a genuine bug fix, but it is outside the PR's stated scope and not mentioned in the description.Please confirm if it is intentional or not.
New code duplication introduced by this PR.
The ~30-line
.skip_color/.skip_color_comma/.skip_color_doneblock is added verbatim to bothtext_insert_newlinesandtext_nextline.Both copies are correct, but since the duplication is created here, factor it into a shared helper while it's fresh.
See comment above.
The color code counting logic seems overly complicated at first sight.
Did I really wrote a routine that counts characters backwards?
From what I remember, we just might need to scan backwards to find newlines.
How did you validate its correct behavior?
ircc: fix text formatting issues (#376)to apps/ircc: fix text formatting issues (#376)eae9ab3518to9ebd6fa97d@hidnplayr
Hi! Finally reached this PR again.
I simplified code according to your comment, so check the current version, please.
This code is looking a lot better!
Now to clean up the obviously LLM generated flood of comments, bump the version number of IRCC and preferably add some screenshot of before and after so we can see what it does :)
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.