Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Display of special characters in aliases.

May
12,845
164
Below, the way v19 (and earlier) displays my alias is (IMHO) correct and preferred to the way v20 displays it.
upload_2016-7-31_22-4-44.png
 
Last edited:
And even though the alias displays incorrectly in v20, it works correctly in v20. That is, the Esc clears any command line in progress and the @ keeps it out of the history.
 
I see the pics, but nothing changed in v20 (and it's not reproducible here).

Are you using the same Unicode font & codepage in all TCC versions?
Some of my older TCCs, left in states of disarray, have other fonts. But v19 and v20 both use Andale Mono (Unicode), bold 16. All my TCCs (all my consoles) use CP437.
 
I didn't investigate all the ramifications, but this little change, near line 850 in ANSI.C made things better.

Code:
  if (state == 1)
  {
  if (*s == ESC && *(s+1) == '[' ) state = 2; // added test of 2nd character
  else ...
 
Better yet:
Code:
  if (state == 1)
  {
  if (*s == ESC && ( *(s+1) == '[' || *(s+1) == ']') ) state = 2;

That seems to work for ANSI32.dll (I can build my own and inject it into a non-ANSI tcc v20). I don't know about TCC's internal ANSI capabilities.
 
You are begging for trouble here -- you're expecting unknown escape sequences to be displayed as though they weren't escape sequences. The ANSI standard says to throw away unknown escape sequences. And you're also assuming that they're not going to get pre-processed by TCC as escape sequences for the parser. Your assumption is only going to be correct as long as you (1) only do <Esc>@ (and never any other character), and (2) I don't decide at some point in the future to create a new TCC escape sequence using @.

And your fix won't work, because you're only considering <Esc>[ and <Esc>], and overlooking all of the other possible ANSI escape sequences (0x20 - 0x2F, P, X, ^, _, etc.).
 
4NTv8 and every version of TCC from v11 to v19 show my alias correctly with ANSI enabled. V20 does not.

Every escape sequence listed in the help's ANSI reference and in "What's new" begins with ^e[ or ^e].

If you decide to use @, it would be a suffix, "^e[...@"... right?
 
4NTv8 and every version of TCC from v11 to v19 show my alias correctly with ANSI enabled. V20 does not.

4NT and every version of TCC from v11 to v19 didn't support ANSI, they supported a small subset of ANSI (basically just the colorization). V20 supports a much fuller set.

Every escape sequence listed in the help's ANSI reference and in "What's new" begins with ^e[ or ^e].

There are a number of additional ANSI combinations that v20 supports that aren't in the documentation yet. And they don't begin with ^e[ or ^e].

If you decide to use @, it would be a suffix, "^e[...@"... right?

No.

If you want to print non-printable characters (why??), don't use ANSI. They don't go together.
 
I can't wait to see the additional combinations. I thought we had just about everything useful in a Windows console and I can't imagine what new ones might do ... trigger a reboot, maybe. Has there been much outcry for more escape sequences?

Perhaps you can suggest another keystroke alias that can be issued anywhere on the command line and will cause TCC to exit without further ado and without entering anything in the command history?
 
vefatica is right in that something has changed in v20 regarding ANSI (probably directly related to adding general ANSI support for all console windows). But I think Rex is definitely right in how it works (and how it should work) in v20. I remember playing around with ANSI sequences back in the days of MS-DOS v6 (with ANSI.SYS loaded in the CONFIG.SYS file) and with calling BBS's and using ANSI terminal emulation with almost all my BBS connections, and I remember that anytime I used an ESC character (ASCII 27) followed by a character that isn't recognized by ANSI.SYS (like when putting only an ESC character and then other text, where the following character is very likely not to be recognized as part of a valid ANSI sequence), then upon displaying it on the screen (e.g. putting it in a text file and then later doing TYPE TEXTFILE.TXT), the ESC character would be discarded, and I think the following character was discarded as well. This is always the case as far as I remember. Since Rex says that the previous versions of TCC didn't directly support ANSI except for just a subset, I'm guessing that displaying them on screen as a result of certain commands like ALIAS didn't cause them to be interpreted (if it was in one of the aliases that displayed on the screen), but they would be interpreted as a result of other commands like ECHO and TYPE that display to the screen. Now that there seems to be (more or less) nearly full ANSI support, the ANSI sequences seem to be interpreted anytime they are displayed on the screen by any command (either just in TCC or in all console apps, depending on settings), and like I say, I think this is the way it's supposed to be, which again was the way it worked back in the old DOS days. I tested the alias though, and it seems to execute properly, even though it doesn't display on the screen the way you'd expect it to. If you want to see it when displaying aliases on screen, and assuming you're loading all your aliases on startup from a file, you can always add the alias directly to the file instead of adding it at the command line (and assuming you're using "^e" instead of trying to directly enter the ESC character). Then when you display aliases on the screen, you'll actually see the "^e" in the alias instead of either the ASCII 27 character or the character not appearing at all.
 
Actually, this works at the command line. It displays satisfactorily and works. But will it be read correctly from my SHRALIAS dump file ... let you know when I logout/login.
upload_2016-8-1_21-57-9.png
 
Yup! That works. It's read back from the dump file just fine; and the alias works. I don't think that was the case 20+ years ago when I started using that alias.
 
I haven't had any reason so far to use aliases that contain unprintable characters, but I can suggest an approach. Perhaps what's needed is a way to display an alias in hex like
Code:
alias /X @@ctrl-f10
1B 40 65 78 69 74

Just a random thought. I have no dog in this fight.
 

Similar threads

Back
Top