|JAVACC: Adjstments to column number for tab (\t) chars firstname.lastname@example.org (2001-05-03)|
|Re: JAVACC: Adjstments to column number for tab (\t) chars email@example.com (2001-05-18)|
|Re: JAVACC: Adjstments to column number for tab (\t) chars firstname.lastname@example.org (Barry Kelly) (2001-05-29)|
|Date:||18 May 2001 23:49:26 -0400|
|Keywords:||Java, history, comment|
|Posted-Date:||18 May 2001 23:49:26 EDT|
A post from email@example.com is quoted below. As a meager
response let me comment to this effect.
The default interpolation of tab (\t) as designating the next fixed
position column is fairly common in legacy systems. I do not know, but
suspect, that this actually reflect very old hardware standards. The
tab (\t) cipher in the ASCII control character subset is, like most of
the control characters, hardware oriented. Some of the legacy is line
hardware oriented, some of it is terminal (or as we used to say, tube)
oriented. Tab, of course, relates to screen control.
Fixing the tab points at every eighth position is an efficiency design
concept, as multiple spaces do not need to be transmitted. Any fixed
positioning concept would work fairly well. I would not be surprised
if the standard of tab points at every eight position across the
screen came from DEC equipment. It is not inconceivable that fixed
position tabulation arrived with TTY devices, predating raster scan
technology. But whatever, the purpose was to afford a technique of
columnarization with efficient encoding (and minimum
transmission). Eight byte fixed width columns evolved as a popular
standard. (A side effect of this standardizing was the tendency to
name every thing that would be listed in columnar format with seven
character or less names tags).
Early PC era interfaces reflected this stuff. I believe the atleast
the monochrome video adaptor would respond to tabs with an assumed
8byte fixed column width. (I am not sure if you needed ANSI.SYS
engaged at boot time or not).
The demanding world of the personal computer market place rapidly lead
to editors that took over the screen in software, and early on you had
settable fixed position tabbing. You could set the tab to mean every n
bytes. A second strategy, rather more wide spread, was settable
tabbing, but the tab simply meant n more bytes from the current
position. Both of these settable approaches create problems when
files are created under one set of editor controls and views (by
someone else) under another set of controls. You get what looks like
column misalignment or strange indentation.
It is only as the PC market matures that extremely versatile word
processors could do settable fixed position tabulation (and then this
is also embellished with flexible setting of tab positions within
So as Java tools come into the picture the background is complex. If
the functions in you package have a default fixed position tabbing, it
is no surprise that it is sanely set at eight. It is perhaps a
surprise that it is a hard coded, apparently non resettable value.
I do not know your tool well enough to know if this mild suggestion
will work. But if in the material you are processing the tab cipher
does not have the fixed position semantic, then consider trying to
intercept the cipher and change it to some other value, so that the
function you list will not see tab (\t). Then handle you special
Another alternative is to cease using the column variable. It may be
that you have learned that the package has a use for this var that you
did not previously understand. set up you own column_too to track the
positioning that you need to process.
Clearly, the column variable is 'hardware' screen oriented. You seem
to not want that, but instead want something like a source column,
... or so I gather from your phrasing " ... throwing off my
beginColumn and endColumn fields of my Tokens which I am trying to use
to show the selection in a JTextArea."
So anyway, you ask "This seems to assume a tab width of 8. Is this
documented anywhere ?" To which I would suggest that no it is
not. Instead it is just the universal background silent legacy
standard. The column variable is tracking it, and you want some other
value, which you may need to construct independently.
Date: 3 May 2001 13:41:11 -0400
I noticed that the generated JavaCC generated
ASCII_UCodeESC_CharStream.java adjusts the column numbers
when dealing with tabs (\t). Here is the snippet of the code -
private final void UpdateLineColumn(char c)
case '\r' :
prevCharIsCR = true;
case '\n' :
prevCharIsLF = true;
case '\t' :
column += (8 - (column & 07));
This seems to assume a tab width of 8. Is this documented anywhere ?
Is there a way to turn this off. This is throwing off my beginColumn and
endColumn fields of my Tokens which I am trying to use to show the
selection in a JTextArea.
Has anyone run into this before ?
[Eight-character tab stops on Teletypes were standard when I started using
computers in the late 1960s. -John]
Return to the
Search the comp.compilers archives again.