Re: BUG REPORT tin 1.9.5 release 20091201 ("Rieclachan") [UNIX]

On Thu, Dec 10, 2009 at 08:34:02PM +0100, Dennis Preiser wrote:
> Last but not least a question: in cook.c:(w)expand_ctrl_chars() we use 
> the following code to compute j:
>
> | if (*wc == '\n')
> | 	ln = i + 1;
> | if (*wc == '\t') {		/* expand_tabs */
> | 	j = i + lcook_width - ((i - ln) % lcook_width);
> | 	for (; i < j; i++)
> | 		wbuf[i] = ' ';
>
> This gives wrong results when a line contains several TABs (but no  
> newlines).
>
> I think it is sufficient to use only j = i + lcook_width here (no need 
> for ln), but I'm not entirely shure whether this breaks anything else or 
> not.

the logic behind this was:

abcdefghi\t12\nfoo\tbar
         ^
i = 10, lcook_width = 8

with j = i + lcook_width the result woulod be 18, but 18 is no tabstop,
next tabstop would be i + 8 - i % 8 = 16, as linenbreaks can occur at any
position (i.e. at 20 after \t expansion in the above example if I did the
math right) we have to 'reset' the tabposcounter to zero after \n, so the
tabstop calculation restarts at line pos 0 (in the new line) and not at 20
(in the 'old' line).

urs
-- 
"Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;)" - Linus