Question on Tab Width Configuration

adalbert2 wrote on Mon Sep 12 14:17:50 MEST 2005:

Hi there,

I think the issue is not completely EPIC specific but there is a configuration
 possibility in the Perl EPIC -> Editor category in the preferences window
too, so I'd like to discuss this here:

In the General -> Editors -> Text Editors category of the preferences window
one can configure the "Displayed tab width". The same configuration is possible
in Perl EPIC -> Editor. I do not understand what this is good for. From
my point of view the tab with was always and should ever be 8. I'm working
on UNIX platforms for a long time and from time to time I'm confronted with
users who adjust tab width to a different value (often 4) and use this for
indenting source code. This then leads to strange looking printouts because
almost any printer driver "thinks" that tab stops are located every 8th
character. I don't know how this issue is handled by printer drivers on
the windows platform but on UNIX it does not make sense to choose another
value than 8.

The problem behind seems to be that people misuse tabs for indentation.
The widely used and powerful programmer's editor s (X)Emacs and vi allow
for configuration of an "indentation level" independently from the tab width.
And this then is taken to perform indentation. I did not find such configurations
in the eclipse editor. 

In the EPIC editor there is a configuration item called "Insert tabs/spaces
on indent". It is unclear to me what this should mean. At least it does
not seem to work when entering text (Eclipse 3.1.0, EPIC 0.3.11). AFAIK
indentation is done in EPIC through the PerlTidy program

Any hint would be apreciated.

Regards

Adalbert

jploski wrote on Mon Sep 12 15:48:11 MEST 2005:

Adalbert,

Since you are not referring to tab characters in your post, let me define
some terms first to avoid misunderstandings:
indentation = amount of whitespace at the beginning of a line,
tab key (on the keyboard),
tab character (character with ASCII code),
space bar (on the keyboard),
space character (character with ASCII code 32),
next tab stop = column to which the caret moves when you hit the tab key.

From an editor user's perspective only "tab stops" matter. When I hit the
TAB key, I want the cursor to move to the next tab stop righthand of my
current caret position. Tab stops can be thought of as distributed throughout
the page, located at every 4th (or 8th, if you prefer) column. It would
be also imaginable, though uncommon to have variably distributed tabstops
(first tab stop at column 8, second at 12; I think you can set it up in
vim).

Another common wish is that an the text looks the same no matter with which
editor on what PC it is edited (or printed). This is mostly true for a single
user and becomes arguable for multiple users with different preferences.
 
Anyway, looking at the text file's ASCII representation, there are two ways
of representing the "move to the next tab stop" command issued by hitting
the tab key:

The first way is to use a tab character. Interpretation of this character
is then up to the editor (or printer) - it depends on how tab stops are
configured locally. Vi/emacs can be set up to encode this information in
the text file itself in a special line of text. Needless to say, this is
not very elegant or portable.

The second way of representing the "move to the next tab stop" command is
by filling the space up to the next tab stop with the necessary number of
space characters. This works very well for maintaining the text look, but
it calls for some additional support in the editor, so that hitting backspace
at a tab stop position or (arguably) also before a "move to the next tab
stop" command does not just remove 1 character in front of the caret.

My advice is to use space characters rather than tab characters and to place
tab stops every 4 columns (in other words, tab width 4). 8 seem too many
given my typical editor width. When you use spaces, it has the nice property
that you can hit the tab key for indentation AND to offset comments at the
end of a line without worrying that the text will become messed up when
someone else views it using a different tab width. Changing a tab width
would adjust the amount of spaces used for indentation, but it would not
affect the spaces placed after text. For version controlled projects, I
recommend that contributors agree on the same tab width.

If complete tab safety is the goal, I discourage aligning text in columns
visually, except for indentation. Comments can be placed between lines just
as well as after them. Other cases (such as aligning = characters in consecutive
assignments for aesthetic reasons) might be simply not worth the effort.

Given all of the above considerations, I am not 100% satisfied with the
way EPIC handles tabs - both other editors I use (Eclipse JDT and vim) do
it better, though I cannot pinpoint the exact reason at the moment. Next
time I have a tab problem, I will file an RFE.

AFAIK, printing under Windows occurs at low level through the GDI API. This
means that each dot on every page can be set by the application itself -
the printer driver does not interpret tabs then.

PerlTidy is an external program which can be called by EPIC on request to
reformat a source file. It is not integrated very well and is in particular
not used for live formatting while you are typing text.

Take care -
JPL