https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6673

I'm not a fan of strings of cryptic magic numbers.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6674

native/socket doors won't, DOS doors won't, so maybe you're thinking of JS mods?
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6681

I was thinking of WWIV doors (and presumably other stdio doors)
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6682

There's a comment explaining what each one is.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6683

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6769

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6784

Another apparent line counter issue/symptom:

On vert.synchro.net (running master), notice the single blank line between the space free and the protocol selection menu:
```
Batch: U

1.5T bytes free

[Y] YMODEM-1K (SEXYZ) [G] YMODEM-G (SEXYZ)
[Z] ZMODEM-windowed (SEXYZ) [9] ZMODEM-streaming (SEXYZ)
[S] ZMODEM-segmented (SEXYZ) [L] Local Copy

Protocol or Quit:
```

On cvs.synchro.net (running this branch), two blank lines after space free:
```
Batch: U

1.5T bytes free


[Y] YMODEM-1K (SEXYZ) [~] YMODEM-G-stdio (SEXYZ)
[G] YMODEM-G (SEXYZ) [2] YMODEM (SZ)
[3] YMODEM-G (SZ) [4] ZMODEM (SZ)
[Z] ZMODEM-windowed (SEXYZ) [0] ZMODEM-stdio (SEXYZ)
[9] ZMODEM-streaming (SEXYZ) [S] ZMODEM-segmented (SEXYZ)
[L] Local Copy

Protocol or Quit:
```
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6814

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6816

JS property aliases are not normally enumerable (just mentioned in the docs). ---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6819

Rather than renaming `lastlinelen` to `lastcrcol`, I would *add* `lastcrcol` and when a newline is sent, copy `lastcrcol` to `lastlinelen`.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6819

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6838

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6839

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6842

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6849

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6852

Ok, but defining "line length" as "the horizontal position when CR was sent" is very non-obvious.

Did you want the property name changed back as well?
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6853

It the JS property name that I was referring to.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6854

If the property name is misleading, then it's probably the implementation that needs to be fixed, not the name.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6855

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6857

I'll switch the property name back. As you discovered, changing the implementation breaks existing code in subtle ways.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6860

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6861

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6862

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6863

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6864

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6865

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6866

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6867

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6867

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6868

Sure:

```
console.clear();
console.print("Line 1\r\n");
console.print("Line 2\r\n");
console.print("Line 2 is very important!");
sleep(1000);
console.up();
console.left(18);
console.print("\x01I<-- Very Important!\x01N");
sleep(2000);
console.left(19);
console.cleartoeol();
console.print("\r\n");
console.cleartoeol();
for (var i = 3; i < 29; i++)
console.print(format("Line %d\r\n", i));
```
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6869

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6870

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6871

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6876

All implementations of Terminal::clearscreen() would need this, yeah?
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6877

It seems the master branch doesn't do this clearing, but probably should have. ---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6879

Master does it in outchar as part of the fall-through from the FF case.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6881

Yeah, I missed the one in the header, fixed now.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6882

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6883

Yeah, no real way to guess at if anyone has tried using it and been frustrated.

```
print("Test\r");
print("last_line_length = " + console.last_line_length); // Prints 0, as advertised
```

:smiley:
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6885

Does console.clearscreen() not work? You said clearscreen example worked (unless you lucked out and the ;eval command exactly wrapped?)
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6886

Aha!

```
if (autopause)
sbbs->CLS; // outchar(FF);
else
sbbs->clearscreen(sbbs->term_supports());
```
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/506#note_6887

So now console.clearscreen(false) needs to be fixed.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net