@MSGID: <20230829165341.499@kylheku.com> 168bb729
@REPLY: 1@dont-email.me> 0b20608b
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230829165341.499@kylheku.com>
@RFC-References: <20230803112254.131@kylheku.com>
1@dont-email.me> <20230804101131.699@kylheku.com> 1@dont-email.me>
<20230805084100.353@kylheku.com> 1@dont-email.me> 1@dont-email.me>
<20230829162831.608@kylheku.com> 1@dont-email.me>
@TZUTC: -0000
@PID: slrn/pre1.0.4-9 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-08-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 30.08.2023 01:42, Kaz Kylheku wrote:
>> On 2023-08-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> [...]
>>>     typeset -i  rows cols
>>>     stty size | read rows cols
>> 
>> I no longer trust the size, except on first invocation.
>
> This is only called initially once in my ksh-code, later I use the
> discipline function to update the variable on LINES changes:
>
>   function LINES.set { .kosta.rows=${.sh.value} ; .kosta.update ;}
>
> (That`s Kornshell-specific, of course.)

By the way, likewise, my code check $LINES and $COLUMNS to detect
a change:


  [ $LINES -eq $basta_old_lines -a 
      $COLUMNS -eq $basta_old_cols ] || basta.prepare_term

but beyond that basta.prepare_term function won`t rely on $LINES; the
terminal is queried to determine its size, from which we subtract the
number of lines needing to be protected, and set LINES accordingly,
punching that into the TTY with stty.

I found that not trusting LINES eliminated the rare glitches I was still
seeing where the scrolling region got set wrong, clobbering the status.

A good change also was not doing the cursor position check when there is
pending input in the TTY. In Bash we can use the read function to detect
whether input is pending.  If input from the user is pending, we can`t
be starting a transaction to query the terminal; we would have to read
and discard the user`s input to get to the termina`s response.

Skipping the check is likely okay because most of the time the cursor
does not stray into the status line. 

If the user has run some program that has wrecked the scroll region,
*and* is rapidly typing ahead, then we won`t catch the bad cursor
position.

I think I have it debugged close to as well as it can be; I put
almost 30 commits into this thing since I started the git repo.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- slrn/pre1.0.4-9 (Linux)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441