Re: [PATCH v9 0/9] Input/Output Terminal Abstraction

Hi Gran,

>>>> This expands on Marcel Holtman's 2023-12-22 RFCv4 patch for an
>>>> input/output terminal abstraction.
>>>>=20
>>>> Substantive changes from the v7 version:
>>>>=20
>>>> * Fixed a typo in the  ASCII C0 and C1 control code mnemonics.
>>>>=20
>>>> Grant Erickson (9):
>>>> term: Initial revision.
>>>=20
>>> I actually reverted it back to my version and included printf / =
vprintf helpers.
>>>=20
>>> What is the purpose of l_term_set_bounds? Is it important for =
non-TTY setups since for TTY compatible terminals, this should not be =
needed.
>>=20
>> It=E2=80=99s been a year and a half since I first deploy[ed] this, so =
bear with me as I attempt to clear some dust and cobwebs from some of =
the details.
>>=20
>>>=20
>>>> ell/term: Do not return -EPERM for 'putnstr' and 'vprint' if not
>>>> running.
>>>=20
>>> Why is that important. It seems like a hack. If you haven=E2=80=99t =
successfully acquired the terminal, there is no point in writing to it =
since you have no idea what termios setting are dealing with.
>>=20
>> Per the above, regrettably, at this point I don=E2=80=99t recall the =
issue that I had run into. For what they are worth, my output methods =
are:
>>=20
>> ...
>>=20
>>>> ell/term: Return error on writes if the output descriptor is =
invalid.
>>>=20
>>> Seems like a fix for the previous change.
>>=20
>> It might well be. Again, per the comment above about getting back =
into the context of a year and a half ago, it seems like there was a =
desire to be able to initialize an instance with the stdin / stdout file =
stream pointers and have things work as-is and then bootstrap into / out =
of those with the terminal as my line oriented UI/UX acquired / released =
the terminal as UI/UX elements were pushed/popped off the stack.
>=20
> Thinking about this further, I suspect my original changes about =
is_running (now, is_acquired) / -EPERM and -EBADF were about early =
prototyping and refining my stack based, line-oriented UI/UX.
>=20
> I suspect if we left the code as-it was in those two regards, the =
stack based, line-oriented UI/UX would work fine. If that=E2=80=99s not =
the case, I can revisit that specific issue later.

then I am starting to leave things out and see how far we get.

Regards

Marcel