Re: [Help-bash] bash doesn't display tabs for tabs -- ignores tabstops.

[Greg Wooledge]

On Tue, Apr 23, 2013 at 11:42:34PM -0700, Linda Walsh wrote:
> Was my elaboration clear enough -- ?
> 
> It's a display issue not a content issue -- except when you cut/paste
> from the terminal to another buffer under X.

You forgot to copy the mailing list.  Also, X has nothing to do with
this.  This is solely between bash and the terminal.

> That bash ignores what characters it displays on the screen and the
> needs of 'X' to be able to pick up those characters as they were
> typed and not modified by bash, isn't surprising, since also doesn't maintain
> integrity of pasted input.

Pasting has nothing to do with bash.  Pasting is between X and the
terminal.  Totally separate issue.

> However I can think of no good reason why bash should not pay attention
> to terminal settings and use the TAB char -- at least, as an option.

How would bash KNOW what the terminal's tabstops are set to?  It can't.

> I.e. bash expanding tabs would be useful on terminals that didn't do
> their own expansion, though I can't think of any that don't off hand.

I am reluctant to speculate on this matter, but you appear to be grasping
at straws, so I will proffer some guesswork.  Everything from here
downward is totally guesswork and may be completely wrong.

Imagine that you're writing bash and that you want to include a feature
that lets people edit their commands.  Some of these commands may include
a literal tab character, even as difficult as it is to do such a thing.

When the command editor is invoked, bash must reconstruct the command
on the terminal, bearing in mind that bash knows very little *about*
the terminal beyond the contents of $TERM and whatever it can glean
from the system's termcap/terminfo database.

If the command to be edited contains a literal tab, bash must present
the command on the screen in an editable format.  The user must be able
to move the cursor to any part of the command, and the cursor's position
must make sense to the user, and bash must always know where the cursor
is in the REAL command in memory.

Suppose bash wrote a literal tab to the terminal when in this mode.
The terminal may do anything with it.  The terminal may move the cursor
to the 8th column, or the 5th column, or the 13th column, or anything.
Bash wouldn't know where the cursor went.

So instead, bash does its own expansion of the tab using the standard
8-space tabstops that 99.9999% of the people in the world use.  Bash
moves the cursor to the next (8*n+1)th column when rendering the command
on the screen.  When you move the cursor to the tab character while
editing, bash puts the cursor at the beginning of the whitespace region
that it uses to render the tab.  When you move the cursor one space to
the right, bash jumps the cursor to the next character beyond the end of
that region.