Aquileo | Recent changes to tickets

Aquileo | #256 SIGBUS crash in libjxl during JXL decoding

2026-07-11T20:23:02.288000Z

confirmed: if I use a different directory entry, the problem doesn't happen - so it's the cache file conflict. The new APC verbs sound like resolve my feature request #139 as well.

Aquileo | #256 SIGBUS crash in libjxl during JXL decoding

2026-07-11T17:46:27.851000Z

status: open --> closed

Aquileo | #256 SIGBUS crash in libjxl during JXL decoding

2026-07-11T16:57:47.392000Z

Actually, digging into this, if you have two systems connected to the same BBS and are replacing the same file in the cache from both of them, you're almost certainly overwriting the file data while SyncTERM is reading it!

You should not do that. :D

Aquileo | #265 SSH hangs at "Opening Channel" when SFTP subsystem opens but FXP_INIT never completes

2026-07-11T16:52:38.438000Z

status: open --> pending

Aquileo | #266 Any-event mouse tracking (1003) reports no-button motion as button 96 (SGR) / 0x80 (legacy)

2026-07-11T16:51:38.408000Z

status: open --> closed

Aquileo | #265 SSH hangs at "Opening Channel" when SFTP subsystem opens but FXP_INIT never completes

2026-07-11T16:17:00.193000Z

I've made it abortable now, but this should maybe do the SFTP update in the background rather than block the shell until it completes, leaving it open pending a decision on that.

Aquileo | #263 Shift+Down opens the Alt-M ANSI Music picker (keycode collision)

2026-07-11T15:39:23.657000Z

status: open --> closed

Aquileo | #261 Custom screen mode Column settings don’t persist

2026-07-11T14:29:49.184000Z

status: open --> closed

Aquileo | #261 Custom screen mode Column settings don’t persist

2026-07-11T14:29:36.395000Z

Aquileo | Any-event mouse tracking (1003) reports no-button motion as button 96 (SGR) / 0x80 (legacy)

2026-07-09T01:07:06.438000Z

Expected. cterm.adoc on 1003: "If no button is pressed, it acts as though button 0 is." → Pb = 32. xterm instead uses its button-3 sentinel → Pb = 35 (not in ctlseqs, but settled by button.c: FirstBitN(0) → -1 → BtnCode()'s if (button < 0) result += 3, then the SGR path subtracts the X10 bias: 32+32+3-32 = 35).

Actual. Pb = 96. In term.c:4741-4761, my_ffs(0) returns 0, so the no-button case is forced to bit = 4 → button = 3 — which is also wheel-up's pre-remap value. The if (button >= 3) button += 61 remap (there to produce xterm's 64/65) then promotes the sentinel to 64, and += 32 for motion yields 96. The sentinel is applied before the remap that reserves that range.

Two details I checked rather than assumed, and both sharpen the report:

Mode 1002 is unaffected — the no-button case returns early at the MM_BUTTON_EVENT_TRACKING guard before reaching the sentinel. Only 1003.
The legacy encoding is worse than the SGR one. Without 1006, Cb = ' ' + 96 = 0x80 — a non-ASCII byte, where xterm sends 'C' (67). Arguably the more serious
symptom, since 0x80 is ambiguous in an 8-bit/UTF-8 stream.

Suggested fix, either: if (bit == 0) bit = 1; (matches cterm.adoc, gives 32), or keep the button-3 sentinel but apply it after the wheel remap (matches xterm, gives 35). I recommend flagging (2) as what xterm-targeted hosts expect, while noting (1) is what SyncTERM currently documents — and that whichever is chosen, cterm.adoc and the code should agree.