On the master branch, the output of DOS doors *do* go through sbbs_t::rputs(), but only on Windows. This was done for the CP437->PETSCII and CP437->UTF8 character translations.
In the *nix version of external(), it has the character translations built into it (doesn't rely on any con_out.cpp functions).
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat Mar 15 14:50:40 2025
Copied from IRC:
```
<DigitalMan> I'm running the terminal-abstraction branch now on cvs.synchro.net <DigitalMan> I see the line counter /auto-pause isn't working right <DigitalMan> e.g. there's a blank line before messages when new-scanning that's not normally there
<DigitalMan> here's what looks like on master: https://1drv.ms/i/s!ApZPvWcrEaRQgZHvOw6Z8IRccjFIgt8?e=F86G2A
<DigitalMan> Actually, that's the terminal-abstraction branch (has the blank line)
<DigitalMan> here's what it looks like from master: https://1drv.ms/i/s!ApZPvWcrEaRQgZHvPCb5kKfKI-T8oK4?e=2ZPWgb
<DigitalMan> another, different example: the xtrn->doors menu on master (vert.synchro.net) pauses before the title scrolls off: https://1drv.ms/i/s!ApZPvWcrEaRQgZHvPVt1Z2OBXxE-PIE?e=HmQBJk
<DigitalMan> but not on the terminal-abstraction branch: https://1drv.ms/i/s!ApZPvWcrEaRQgZHvPhOQGu_BBR2dmZ0?e=aa8JvD
<DigitalMan> while in getstr insert mode (e.g. hitting Ctrl-V while being prompted for an email subject) and then hitting Ctrl-U or Ctrl-T (anything that save/restoresline) the prompt disappears
<DigitalMan> (this one I observed and reported before and I thought you'd fixed)
<DigitalMan> there's extra hit-a-key pauses before screen-clears when view general text files
<DigitalMan> that's probably enough for now, but pretty easy to see the differences by comparing vert and cvs right now
```
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 14:12:01 2025
```
js_console.cpp:409:33: error: ‘CON_PROP_LASTLINELEN’ was not declared in this scope; did you mean ‘CON_PROP_LASTCRCOL’?
409 | { "last_line_length", CON_PROP_LASTLINELEN, CON_PROP_FLAGS, 317},
| ^~~~~~~~~~~~~~~~~~~~
| CON_PROP_LASTCRCOL
```
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 14:16:51 2025
Rather than renaming `lastlinelen` to `lastcrcol`, I would *add* `lastcrcol` and when a newline is sent, copy `lastcrcol` to `lastlinelen`.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 14:34:06 2025
Rather than renaming `lastlinelen` to `lastcrcol`, I would *add* `lastcrcol` and when a newline is sent, copy `lastcrcol` to `lastlinelen`. (but not sure why it matters)
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 18:42:09 2025
I'm not sure what you mean... the current code depends on the variable being the column the last CR was sent from, or the last column if a wrap is expected to have happened. lastlinelen is quite misleading. Having another similar but subtly different variable that nobody uses doesn't seem like a good idea.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 18:42:13 2025
Anyway, the point is that if we fundamentally change how Synchronet behaves at line endings, we need to ensure doors aren't broken because they inherently make their own assumptions about what's happening.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 19:31:50 2025
I'm not clear why Terminal::dec_row() is messing with the lncntr: it shouldn't. The line counter is the number of potentially unread/acknowledged lines of displayed text. I don't see how moving the cursor up the screen should impact that number.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:01:16 2025
The intent was lastlinelen was the length of the last line that was printed. Usually, that's the same thing as the column of the last CR sent. I'd don't think it's a good idea (or necessary) to rename console object properties as part of this MR, especially before the behavior matches that of the master branch.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:11:07 2025
If the property name is misleading, then it's probably the implementation that needs to be fixed, not the name.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:16:06 2025
So if I print 20 lines, then move up and re-print a line, then print four more lines, there will be a pause. Previously the line counter was reset to zero and unacked lines would scroll off. I'll add it to the discussion topics.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:18:05 2025
I'll switch the property name back. As you discovered, changing the implementation breaks existing code in subtle ways.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:31:21 2025
Maybe just just take notes of where you think existing (master branch) behavior or naming is wrong/bad and we can take that on later. I thought the intention of this branch/MR was to "work-alike" the current master branch behavior, at least as much as possible.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:32:48 2025
That said, I'm happy to see the background-attribute of the current getkey(K_EDIT) is restored when the insert indicator is used, so that change (fix) is a good one.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:36:09 2025
If anything moves the cursor up and re-prints a line, it should only be doing so when the current text on the screen is assured to have been read, in which case the line counter should be zero. The other use case (for moving the cursor up) would be animations or sprites for "full screen" games/doors, where the line-counting/auto-pausing of scrolling text wouldn't be used anyway.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:51:24 2025
The idea is to improve things without breaking existing stuff, not to implement full bug compatibility for the dark and dusty corner cases nobody has noticed. I felt that changing the name to something more accurate fit that goal, but have no problems not making that change.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:53:55 2025
Having curattr being the current attribute was a similar experiment that didn't pan out either. I didn't bother creating a new property for that yet, though it's something that would be trivial to add... coming up with a good name is the hard part for that one.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:57:07 2025
In which case it doesn't matter since it will be cleared on user interaction.
I've wanted to to a few animation things in the past with line counting enabled, but couldn't use the built-in pause support for (ie: Animate drawing boxes, cool transitions, etc).
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 20:59:57 2025
If you have a demo/test for it, sure, but it's never been on my feature radar: once a script (or display file) starts moving the cursor around, I expected the script to be in full control of any output and input (and not depend on SBBS auto-pausing).
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:08:34 2025
In this case, I would wonder: in what situation is lastlinelen not the length of the line line printed? I suppose one were to print "something\r", it'd be wrong (until such time as a linefeed was sent, then it'd be correct), but the only known use case for the lastlinelen is for *not* counting initial blank lines after user input, so it was not a problem. If we change it so that lastlinelen was only updated upon an output LF, I think that'd be a backward compatible change to the implementation and keep the intent of the variable/problem name. But I don't think there's any reason to pursue such a change as part of this MR.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:09:20 2025
In this case, I would wonder: in what situation is lastlinelen not the length of the line line printed? I suppose one were to print "something\r", it'd be wrong (until such time as a linefeed was sent, then it'd be correct), but the only known use case for the lastlinelen is for *not* counting initial blank lines after user input, so it was not a problem. If we change it so that lastlinelen was only updated upon an output LF, I think that'd be a backward compatible change to the implementation and keep the intent of the variable/property name. But I don't think there's any reason to pursue such a change as part of this MR.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:12:49 2025
I'm not sure what you're saying, but it seems like you're fine with how it is. The reason to change the JS property was simply to avoid someone trying to use it for something else and being frustrated that it doesn't do what they expect.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:21:22 2025
That demo seems to work on the master branch too, except that it prematurely auto-pauses on line 22. So yeah, your abstraction adds support for a new use case. :-)
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:31:09 2025
Yeah, it hasn't been a problem. But I also don't think anyone's used lastlinelen but me (in C++) and it's behaved how I expected where/when I've needed and used it so most likely nobody's had an opportunity to be frustrated with it. A simple use/test would likely show the property behaving as expected:
```
print("test");
print("last_line_length = " + console.last_line_length); // Prints 4, as advertised
```
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:53:25 2025
All implementations of Terminal::clearscreen() would need this, yeah?
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 21:56:24 2025
It seems the master branch doesn't do this clearing, but probably should have. --- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 22:23:34 2025
Master does it in outchar as part of the fall-through from the FF case.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 22:25:10 2025
On the master branch, a direct call to clearscreen() e.g. from JS, for an ANSI terminal user, would not go through outcom() (and thus not hit any FF case):
```
void sbbs_t::clearscreen(int term)
{
clear_hotspots();
if (term & ANSI)
putcom("\x1b[2J\x1b[H"); /* clear screen, home cursor */
else if (term & PETSCII)
outcom(PETSCII_CLEAR);
else
outcom(FF);
row = 0;
column = 0;
lncntr = 0;
}
```
Probably a bug.
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 22:31:21 2025
Does console.clearscreen() not work? You said clearscreen example worked (unless you lucked out and the ;eval command exactly wrapped?)
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 22:40:45 2025