1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Display of special characters in aliases.

Discussion in 'Support' started by vefatica, Jul 31, 2016.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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
     
    #1 vefatica, Jul 31, 2016
    Last edited: Jul 31, 2016
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Look at the pics; see the change. It's a global alias (shralias), used by all TCC versions.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Need more convincing?
    upload_2016-7-31_23-40-10.png
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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?
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
  10. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Not in this regard. It had some changes in DEDUPE and some help text updates.
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Yes.
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    With ANSI off, it gets it right.
    upload_2016-8-1_1-44-58.png
     
  14. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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 ...
    
     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.).
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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?
     
  18. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.

    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].

    No.

    If you want to print non-printable characters (why??), don't use ANSI. They don't go together.
     
  19. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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?
     
  20. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    How is that relevant to this topic?
     
  21. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    That's the alias which has displayed correctly until recently
     
  22. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    The alias still *works*, it's just not displaying the escape sequence when you enable ANSI (which thinks it's an invalid sequence and discards it). This scarcely requires you to throw everything out the window.
     
  23. evensenm

    Joined:
    Jul 29, 2016
    Messages:
    35
    Likes Received:
    1
    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.
     
  24. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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
     
  25. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  26. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    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.
     

Share This Page