Re: [Mutt] #2988: Mutt should recognize tab (width)
#2988: Mutt should recognize tab (width)
Comment (by Derek Martin):
{{{
Trouble is that the tab is a hardware feature (or pseudo hardware
feature) designed to allow for the alignment of text on a terminal
device; a full tab has a width of 8, but tab stops are at column
positions, not absolute character widths. If the user starts typing
at column 0 and types 3 characters and then hits tab, that tab
character has a practical width of 5, not 8.
Also, the user can set the hardware tab stops to whatever value he
wants, and in the case where they do, assuming a width of 8 is not
really much better than using 1. For example, if the user uses a ts
with of 3, and has 4 such tabs in the e-mail, mutt will think the line
is as much as 20 columns wider than it actually is...
It's also possible to specify tab stops at arbitrary terminal columns.
One might do this for the convenience of, say, editing source files,
or even editing mail (e.g. set a tab at column 2 or 4 to indent the
first line of a paragraph, instead of indenting to column 8, which
looks retarded). I'm not suggesting that changing the tabs from the
defaults is a common practice; but it seems logical to me that Mutt
should behave sanely when it is done...
Perhaps the smartest thing to do, in the absence of a way to determine
what the terminal settings for tab stops actually are, is to ignore
the hardware tabs completely: Mutt could instead, *only for the
purpose of display*, expand tabs to an equivalent number of spaces to
simulate tab stops, which then makes this a non-problem (space has a
width of 1). I believe that GUI MUAs, lacking the concept of hardware
tabs, essentially behave this way (i.e. they choose their own tab
stops which are AFAIK generally not user-configurable), so I don't
think it's unreasonable for Mutt to do so also. But for that matter,
Mutt's pseudo-tabs could be user configurable, if that were
desirable.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2988#comment:>