tuck@iris.ucdavis.edu (Devon Tuck) (08/16/90)
I need some advice about how you feel special characters "should" be handled by an editor. We have an editor here called COED which has a full screen edit mode. The author mediated about what to do with special characters when it was created, and decided that they would simply be printed to the screen and treaded by the internals of the editor as one character. Of course this causes a serious problem when I edit a file that has a tab (Ctrl-I) in it, for example: Suppose you have a line of text that starts with one tab, then several characters following. When this displays on the screen, it looks fine, but if I move to the first column and then hit the right arrow key, then in COED's buffer I am at the first letter following the tab, however on the screen I am sitting in the middle of a blank "tab field". If I type a letter, I clobber the first letter of my line, but on the screen I am still six characters to the left of it. It would be nice if the editor treated the tab as a single field, so that the first right arrow key would move me to the first character that visually appears on the screen. The author doesn't want to make this change because the editor is usually used for FORTRAN and editting files that never contain tabs. He claims that if we treated tabs specially we should treat all characters specially (CTRL-A, CTRL-B, etc). What I am looking for is ideas for an elegant, but simple way to handle special characters. What do other editors out there do? I know that Vi shows tabs as whitespace but only lets your cursor sit on one space in the tab field, and that other characters are represented as ^A, ^B, etc. Thanks, your input is important to me, Devon Tuck tuck@iris.ucdavis.edu
ant@mks.com (Anthony Howe) (08/16/90)
Ah. A holy war, a crusade to free the holy lands of infidel programmers who don't handle tabs!!!! Isn't life grand :) >Suppose you have a line of text that starts with one tab, then several >characters following. When this displays on the screen, it looks fine, but >if I move to the first column and then hit the right arrow key, then in >COED's buffer I am at the first letter following the tab, however on the >screen I am sitting in the middle of a blank "tab field". If I type a >letter, I clobber the first letter of my line, but on the screen I am still >six characters to the left of it. Serious bug if you ask me. There seems to be two accepted ways to handle tab characters. 1) Insert spaces in the text buffer to replace the tab (simple), or 2) Handle tabs as a single field (trickier) much like vi and dare I say - Word Perfect. [...] >contain tabs. He claims that if we treated tabs specially we should treat >all characters specially (CTRL-A, CTRL-B, etc). Not all control codes are visual. The only visual ones that come to mind are BS (^h), CR (^M), LF (^J), VT (^K), FF (^L), DEL (^? or 127), and HT (^i). All the other ones tend to be used for communication protocals and other assorted duties and shouldn't appear in a text file unless you're imbedding things like printer control sequences and then the accepted methods to display them seems to be either ^A, ^B a la vi or inverse A or B, etc. If an editor failed to handle these accepted ASCII characters in an acceptable way then I would assume that it was a design flaw instead of the stuborness of an intractable programmer. Either way, I would find a better editor, fix the Bug myself, or write my own. I like the third option better because then you can take it with you where ever you go and never have to change. The only other temporary solution I can think of is to turn off tab expansion by either the OS or the terminal. This way tabs will appear as a single space. ...and there was blood across the sands trailing off in all directions, giving one the impression of a gaint red ink blot. - ant -- __ "Those who love seek a philosphy _ . .-|- / _\ . . |_ _. _ _ . . and, because of this, are fond of (_\ |\| | |(_/ |\/| |\ _\ o (_ (_) |\/| solitude." _Musashi_ bk2 p224 Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2L 6W9