TZUTC: -0800   
   MSGID: 57403.sync_sys@1:103/705 2c2d4bef   
   PID: Synchronet 3.20c-Linux master/80337c044 Mar 01 2025 GCC 12.2.0   
   TID: SBBSecho 3.23-Linux master/80337c044 Mar 01 2025 GCC 12.2.0   
   BBSID: VERT   
   CHRS: UTF-8 4   
   open https://gitlab.synchro.net/main/sbbs/-/issues/880   
      
   Just dumping my notes here.  At some point, we should have a chat about   
   these.  Ideally before Mode7 support is finalized.   
      
   **Extra ports not binding**   
      
   - \*Interfaces is intended to be a list of interfaces   
   - We're specifying ports in other places, but we also need to specify the same   
   port in interfaces.   
   - Seems we could just comment out other ports in default   
      
   **What terminal settings make sense in user?**   
      
   - Should every other terminal that has options get a new user field? Would   
   allow per-terminal settings, likely overkill.    
      
   **Autoterm**   
      
   - Separate set of flags (but keep current values)   
   - Specific ownership of flags between terminal and answer.cpp   
   - Charset detection? Or new Autocharset? terminal vs. term_type()   
   - terminal is sometimes user-supplied, may have more information   
   - term_type() is authorative, not used by AR_TERM   
   - Some config to map user-supplied terminals to term_type() values? For things   
   that can be autodetected (ie: ANSI, RIP, VT-52, VIDTEX, etc) this is likely   
   not useful, but for retro terminals, would not require all clients to follow   
   SyncTERM conventions. Note that few retro modems support terminal type, and   
   those that do tend to default to "dumb".    
   - Could collaberate with Zimodem and FujiNet at least to develop a registry.    
      
   **Term menu at login**   
      
   - This is the solution many BBSs use for things that can't be auto-detected   
   - Could query undetected bits in autoterm   
   - No reason to be in C/C++   
      
   **P\_\* values (charset)**   
      
   - Should P_NATIVE be sufficient for new charsets, or do we need a new P\_\*   
   for every charset? This goes back to he question of conversion from every   
   charset to every other charset.   
      
   **AR\_\* values (charset and terminal)**   
      
   - AR\_ currently exists for every supported terminal type   
   - Keep this going or add an actual AR_TERMTYPE?   
   - For AR_TERM, the values may be user-supplied   
   - It would be beneficial if AR_TERM was based on term_type() instead is it too   
   late?   
   - Would we want a separate AR for terminal/term_type()?   
   - AR\_ currently exists for every supported charset   
   - Keep this going, or add an actual AR_CHARSET   
      
   **^A-codes**   
      
   - Added ^A^\[ to indicate already translated to target charset.   
   - No way to turn this off at present.   
   - Added automatically when things are loaded due to charset match.   
   - Could have ^A^\\ added at end as well.   
   - Use ^B codes for terminal/charset "stuff"?   
   - Maybe ^A ESC performing code extension?   
   - Would be nice to actually have all ECMA-48 attributes:   
     - Bold   
     - Faint   
     - Italic   
     - Underline   
     - Slow blink   
     - Fast blink   
     - Negative   
     - Concealed   
     - Crossed-out   
     - Default font   
     - Alt font 1   
     - Alt font 2   
     - Alt font 3   
     - Alt font 4   
     - Alt font 5   
     - Alt font 6   
     - Alt font 7   
     - Alt font 8   
     - Alt font 9   
     - Fraktur   
     - Double underline   
     - FG (Default, black, red, green, yellow, blue, magenta, cyan, white)   
     - BG (Default, black, red, green, yellow, blue, magenta, cyan, white)   
     - Framed   
     - Encircled   
     - Overlined   
     - Ideogram underline or right side line   
     - Ideogram double underline or double right side line   
     - Ideogram overline or left side line   
     - Ideogram double overline or double left side line   
     - Ideogram stress marking   
      
   **@-codes**   
      
   - Likely fine... when someone asks for something, they can get it, namespace   
   is not limited.   
   - Is there some minimum set we want for each charset and terminal?   
      
   **Charset/lang**   
      
   - Lang-as-charset as in mode7 branch is iffy (apparently not used now?)   
   - It's likely that a lang should have a charset attached. Should support UTF8   
   as the codepage though, which means conversion from UTF8 to every supported   
   codepage. On the other hand, simply supporting CP858 or CP850 would at least   
   get the ones there's already translation for (ie: Spanish and French).   
   - "Supporting CP850" could be as simple as not including the replaced   
   characters in the default config. The most troubling ones would be the bullet   
   (0xF9), square root (0xFB), left and right block characters as well as the   
   combined single and double line drawing (single-only and double-only are both   
   there).   
   - Assuming there's a lang codepage, should choosing the lang also choose the   
   codepage, or do they need to be separate items?   
   - Conversion from PETSCII to CP437 is troubling, not sustainable.   
   - No conversion from PETSCII to UTF-8?   
   - Do we want every charset to have a translation mapping to ever other   
   charset? Everything through Unicode? Keep PETSCII as "special"?   
   - Retro charsets generally have international variants. (PETSCII has Danish,   
   French, German, Greek, Hungarian, Japanese, Norwegien, Russian, Spanish,   
   Swedish, Swiss) (C64 PETSCII alone has Danish, Hungarian, Spanish, and Swedish)   
   - The retro i18n issue brings up the question of codepages again.   
   --- SBBSecho 3.23-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/13 705 105/81 106/201 124/5016 128/187 153/757 7715 154/10   
   SEEN-BY: 154/30 110 203/0 218/700 221/0 226/30 227/114 229/110 114   
   SEEN-BY: 229/206 317 400 426 428 470 550 700 705 240/1120 5832 266/512   
   SEEN-BY: 280/464 5003 5006 291/111 292/8125 301/1 320/219 322/757   
   SEEN-BY: 341/66 234 342/200 396/45 423/120 460/58 467/888 633/267   
   SEEN-BY: 633/280 281 384 410 418 420 2744 712/848 770/1 902/26 5020/400   
   SEEN-BY: 5075/35   
   PATH: 103/705 280/464 633/280 229/426