echoerr truncates long lines

[Stefano Piccardi]

When an output line includes some Unicode characters U+FF01 through U+FF5E, ECHOERR truncates the line at width %_COLUMNS while ECHO doesn't. Look at the missing dangling 81st character in the ECHOERR line below.

C:\>ver

TCC LE 13.04.52 Windows 7 [Version 6.1.7601]
 
C:\>chcp
Active code page: 437 
 
C:\>option //ErrorColors=207

C:\>echo %@repeat[x,%@inc[%_COLUMNS]]
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
 
 C:\>echo %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],%@inc[%_COLUMNS]]   
ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ
ｘ
 
 C:\>ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],%@inc[%_COLUMNS]] 
ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ

C:\>

 

[rconn]

JP Software does not provide any support for TCC/LE.

 

[JohnQSmith]

JP Software does not provide any support for TCC/LE.

Same thing happens in

TCC  13.04.57  Windows XP [Version 5.1.2600]

Oh... and another thing! Why didn't anybody ever tell me about that

option //ErrorColors=207

thing.

That's freekin' cool!

 

[Steve Fabian]

Same TCC 13.04.57, same WinXP SP3 home, I created an environment variable longer than 1000 characters, ECHOERR displays it correctly. On my laptop (XP pro SP3) I went over 2222 character, nicely wrapped.

 

[JohnQSmith]

Same TCC 13.04.57, same WinXP SP3 home, I created an environment variable longer than 1000 characters, ECHOERR displays it correctly. On my laptop (XP pro SP3) I went over 2222 character, nicely wrapped.

Did you make it a high range unicode string like in post 1?

This works fine

ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],80]

This doesn't

ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],1000]

 

[rconn]

Nothing to do with TCC; it's a bug in the Windows WriteConsoleOutputCharacter API. It also has nothing to do with Unicode characters in a specific range; it's any non-ASCII (>127) character. (Though it gets somewhat odd-looking trying to use one of those 0xFEE0+n characters, since Windows interprets that as a double-wide character. I can't imagine what the OP was trying to do here ...)

IMO it's not significant enough to merit kludging up a (much slower) workaround.

 

[JohnQSmith]

It also has nothing to do with Unicode characters in a specific range; it's any non-ASCII (>127) character.

I can live with that. Kinda makes sense too; by sticking to only low ASCII characters, the chance of the terminal failing to interpret it drops to almost zero. Also changes it from a bug to a design feature.

 

[dcantor]

I can live with that. Kinda makes sense too; by sticking to only low ASCII characters, the chance of the terminal failing to interpret it drops to almost zero. Also changes it from a bug to a design feature.

But not a TCC design feature (nor a TCC design error). I'd still call it a bug, but a Microsoft bug.

Dave C.
former tracker and classifier of bugs in a previous life

 

[Stefano Piccardi]

it gets somewhat odd-looking trying to use one of those 0xFEE0+n characters, since Windows interprets that as a double-wide character. I can't imagine what the OP was trying to do here ...)

Charle's SAFECHARS plugin uses that encoding. That's the context where I noticed this issue.

 

[Stefano Piccardi]

Nothing to do with TCC; it's a bug in the Windows WriteConsoleOutputCharacter API. It also has nothing to do with Unicode characters in a specific range; it's any non-ASCII (>127) character.

Thanks for having added a workaround in version 13.04.59, it works fine.