bug#51877: 27.2; term: error in process filter

[Eli Zaretskii]

> Date: Thu, 20 Jan 2022 13:01:12 -0900
> From: Christopher Howard <christopher@librehacker.com>
> Cc: larsi@gnus.org, 51877@debbugs.gnu.org
> 
> On Thu, Jan 20, 2022 at 10:02:10PM +0200, Eli Zaretskii wrote:
> > I don't think this would help.  Can you manually modify the function
> > term-emulate-terminal to use 'raw-text instead of
> > locale-coding-system, and then re-run the scenario in which you get
> > these problems?
> 
> This seems to generate the same result, except with more elaborate debugger 
> output:
> 
> ```
> Debugger entered--Lisp error: (args-out-of-range "l \3\220\0332Nn\f\217" 0 
> -48)
>   substring("l \3\220\0332Nn\f\217" 0 -48)
>   (insert (substring decoded-substring 0 (- term-width old-column)))
>   (while (> (+ (length decoded-substring) old-column) term-width) (insert 
> (substring decoded-substring 0 (- term-width old-column))) (delete-region 
> (point) (line-end-position)) (term-down 1 t) (term-move-columns (- 
> (term-current-column))) (add-text-properties (1- (point)) (point) 
> '(term-line-wrap t rear-nonsticky t)) (setq decoded-substring (substring 
> decoded-substring (- term-width old-column))) (setq old-column 0))

Ouch!  This code evidently assumes that every character takes just one
column on display, because it uses column counts as indices into
strings.  That assumption obviously breaks with binary garbage, where
many bytes are displayed as octal escapes, which take no less than 4
columns.

So my conclusion is that this can never work, unless this central
assumption of term.el is removed, and the code redesigned and
reimplemented not to depend on column counts.

IOW, i its current shape, term.el is utterly incapable of supporting
display of raw bytes.

Sorry.