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
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.