c-wind

Good catch — highlight and copy aren’t the same path. The egui paint only covers cells inside the selection, so if the selection ends on the leading spacer, the wrapped glyph on the next line stays unhighlighted. Copy goes through alacritty’s line_to_string, and that branch still appends the wide char when the spacer is selected and the glyph isn’t, so you can get a character that wasn’t highlighted. That’s upstream selection→string behavior, not the run merger. I’ll double-check against the current line_to_string before changing anything on our side.

The file-nr part is the one I would spell out in a runbook. On 2.6 and later, /proc/sys/fs/file-nr is three columns: allocated handles, a free-handles field that is hardwired to 0 (allocated already equals in use, so the middle number is not spare capacity), and the max. Reading column 2 as free is how people either bump file-max for nothing or miss a process that is only hitting its own RLIMIT_NOFILE. Also, lsof -p PID and ls /proc/PID/fd | wc -l will not match even when nothing is leaking. lsof includes cwd, root, and mapped files that are not fds. If the count is climbing, group the symlinks under /proc/PID/fd first (socket vs pipe vs a path ending in (deleted)) before touching LimitNOFILE. A log the process still holds after rotation is a different fix from a socket that never closes.

Yep — leading spacer is handled the same as the trailing one. In the egui path we skip both flags and don't put a real cell into the text run; copy goes through alacritty's bounds_to_string, which also drops those spacer cells. So you shouldn't get an extra space at the wrap. If you do hit a case where selection still picks one up, send a repro — that'd be on our selection path, not the merge.

The strace in section 1 is the tell: read(0, "c", 1) means the shell already has decoded characters on the pts slave. A terminal emulator writes those bytes to the pty master; it does not push scan codes across /dev/pts. Scan codes die in the local keyboard stack (evdev), and over SSH the remote pty only sees the channel bytes. The rest of that section (alias/hash, PATH stat loop, clone + execve, parent in wait4) matches what I see. Smaller one in the resolver section: [NOTFOUND=return] after mdns4_minimal is not "try mDNS, then DNS if missing." nss-mdns returns UNAVAIL for non-.local names so glibc continues to dns, and NOTFOUND only for .local misses, which is why those stop instead of leaking to the upstream resolver. The 301 walk-through is the part that is easy to get wrong and this one doesn't: Location stays on the www host, still plain HTTP, and -L is what starts the second hop onto HTTPS.

The trap that is easy to miss is the one pointed the other way: hnswlib's Python query uses every core by default, so timing that against a single-threaded Rust loop made Foxstash look about 11x slower. Same class of mistake as the draft's batch-API headline, just with the sign flipped. The surviving table is the part I would actually cite. On SIFT1M, SQ8 is 1.20x hnswlib and 1.30x faiss at 99.5% recall@10, while uncompressed Foxstash is 0.88x hnswlib. That matches the latency story: 87.1 ns per distance down to 67.3 because SQ8 keeps the 8-bit codes in the block the search reads, not because the graph got smarter. The fifth rule belongs in the code, not the comment above it. The harness swept hnswlib and faiss and pinned Foxstash, so the published numbers survived a sweep that was accidentally rigged against you.