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.
---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net