bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: having bash display real tabs for tab characters...


From: Linda Walsh
Subject: Re: having bash display real tabs for tab characters...
Date: Thu, 11 Jul 2013 15:06:18 -0700
User-agent: Thunderbird

Revisiting this...

Chet Ramey wrote:
On 4/25/13 8:45 AM, Greg Wooledge wrote:

If you think Bash is misbehaving, submit a patch, or wait for Chet to
comment on one of these threads.

I don't plan to comment or make any changes.  The demand for this
feature seems vanishingly small.

----

 And growing.

        From the termcap source files:

# As the ANSI/ECMA-48 standard and variants take firmer hold, and as
# character-cell terminals are increasingly replaced by X displays, much
# of this file is becoming a historical document (this is part of the
# reason for the new organization, which puts ANSI types, xterm, Unix
# consoles, and vt100 up front in confidence that this will catch 95% of
# new hardware).

-----

95% of new HW supports variable tabs according to this document.
I wouldn't call that vanishingly small, but of growing importance.

In addition to ANSI standards, it also applies to "linux" terminals as
well as the console.

        I've switched to TS=2 upon login, mainly because of perl displaying
and lining up it's error messages and debugger messages based on tab
settings (if you have tab in your input file, it displays tab on the
output file.  You can fit alot more on the screen when you only indent
2 spaces vs. 8. (some like 4).  Whatever the user preference is -- a bad
trend is intermixing spaces & tabs to get non-8-space tabs.

This is bad because different people with different tab settings won't
have such files indented properly, whereas people who use tabs to indent
will find it portable to anyone else's system -- even if they prefer
a 6 space tab vs. 3.  If tabs have been used, you can change to your
favored indentation by changing the tab expansion in your editor and
a few other utils.  If a source has been indented with mixed
tabs/spaces, it needs to be run through a tab-conversion program leading
to many 'diffs', for those looking at diffs in source code (I know howto
tell diff to ignore all -w(hite) space change ("-w")), but many diff
utils don't support that.

I find it more than a little strange that someone on the POSIX committee
wouldn't realize the important of the ANSI standards.

        It seems like it would simplify the code to actually display a 'tab'
rather than having to calculate the expansion.

Please rethink this issue as it appears that it isn't as small as one
might think and is similar to the reason why hi-rez displays have been
slow to pick up in demand -- because of bad-implementations that tied
text size to pixel density (changing in HTML5), as pixels have redefined
to be 1/96th of an inch, regardless of HW).  This was fixed because
people couldn't follow standards using device independent character
sizing.

I would say people don't favor tabs heavily now, because tabs are fixed
in size.  I.e. the reasons behind your saying the demand for the feature
is vanishingly small is because of broken utilities that always expand
tabs to mod/8 columns regardless of user preferences.

Bash could be leading edge in this area by supporting a tab-set command
(so bash, as a side effect, would continue to know where the cursor is
on the line).







reply via email to

[Prev in Thread] Current Thread [Next in Thread]