Re: RFE - support option for curses idea of term [tab]size.

[Greg Wooledge]

On Thu, Apr 29, 2021 at 07:39:37PM -0700, L A Walsh wrote:
>    It doesn't always do it correctly because it doesn't always know
> where it is in a line.  As such it has a bug that would be fixed by
> having it really know where it was at (from talking with libcurses)
> as well as what the tabstops were really set to.

First of all, "just link with libcurses" does not magically grant the
power to know the cursor position in all terminals.  Many of them have
no such capability at all, and of the ones that do, the means of
learning that information differs greatly.

Even curses applications don't try to ask the terminal where the cursor
is.  They *put* the cursor where they need it to be, and keep track of
where they left it.

Second of all, converting bash/readline to use curses instead of the
primitive terminal calls that it currently uses would involve a whole
new layer of complexity that I do not feel is justified, or even wanted.

Curses applications take control of the entire terminal.  They are
initialized, and they must be cleaned up.  At any time in the middle,
the stats of the terminal is not really well-defined.  The curses
application could be in the middle of some operation.  Any outside entity
that touches the terminal in any way could mess everything up.

But with shell scripts (or interactive shells), the normal operating
procedure is for the shell to spend a lot of its time waiting for an
external command to finish.  That external command may want to write
to the terminal, or even read from it.

This works out fine for bash as it currently exists, because bash turns
over control of the terminal in a relatively well-defined state, and
resumes control of the terminal when the external program is finished.
The only assumption bash makes upon resumption is that the cursor will be
in the leftmost column.