Latest indent request

[Robert Oliver]

In article <5516 at sneaky.TANDY.COM>, gordon at sneaky.TANDY.COM (Gordon Burditt) writes:
> In article <755 at rabbit1.UUCP> robert at rabbit1.UUCP (Robert Oliver) writes:
> >After working on many varied computers, operating systems, and terminals,
> >it's my opinion that tabs should not be stored in files and expanded
> >upon output.
> I don't care much about transmission savings or file space savings.  
> I want tabs in files for editing purposes.  If it is necessary to add 
> or delete a conditional or loop, I want to be able to add or delete 
> 1 tab stop, not to have to count spaces.
> 
> # define BAR	72	/* Cost of a BAR as a percentage of a BARF */
> # define FOOM	02000	/* Bit in dp->missile.control for self-destruct */
>              ^       ^  tabs
> If it is necessary for me to change the value of BAR from 72 to 2, 
> I do NOT want the comment to move.  With a tab there, it won't.  With
> spaces there, it will.  Granted, there are cases where running over a
> tab stop will cause movement where I don't want it, but even these cases
> are usually easier to fix with tabs there than spaces.
> 
Depends on how you perform the edit, and (referring back to my original posting)
how well your editor supports the spaces rather than tabs concept.  Your methods
of thinking are still oriented towards the stored tab concept, and the editors
you use were designed for that.

Even so, in your example I see no reason why editing 72 to 2 should cause a 
problem.  In "vi" terms, don't use "cw2<esc>"; that will cause the unwanted 
shift.  Instead, simply use "R2 <esc>".  Granted, in other examples, extra 
spaces will be needed, and might annoy you.  

But that's still a limitation of vi; not an inherent defect in my proposal to 
eliminate stored tabs.  What if vi could handle all white-space like a tab?  
Then a new form of the cw command would do just what you want.  An editor 
designed for the current Unix tab conventions shouldn't be used to judge my 
proposed tab conventions.

Concerning your comment about adding or deleing a conditional or a loop,
again, a non-stored-tab editor should do just fine.  Using the example of
inserting a loop, and thus needing to shift a block of text to the right,
and using vi (only becuase I'm most familiar with it), here's a comparrison:

VI -- range insert tab at beginning of line
'a,.s/^/<tab>/

New Coke VI version 1 -- range insert of tab at beginning of line
'a,.s/^/<tab>/

Yes--that might work!  The editor just converts it to the correct number of 
spaces.

New Coke VI version 2 -- range move of all text in line to column 8
'a,.s/^.*$/#8&/		(or some such syntax)

Deleting a loop construct could work the same way.  And the possibilities are 
endless.  Non-tab-storing editors could have all sorts of abilities I haven't i
thought of.  The last example above is my favorite.  You wouldn't believe how
useful column edits are for lining comments up.  Commands like "move all
text beyond column  50 which matches the pattern /\*.* to column 55" is
great.  And watching it happen to every line on a screen is statisfying.  
Comments that got shifted left or right when you globally changed two variable
names suddenly line up!  Some move left; some move right; some stay the same.
I should film that and set it to Mozart some time.

But I digress.  And I don't want to discourage comment!

By all means, keep at it.  Hack away at my proposal.  I must admit that
your posting gave me pause.  And *I* had to shift out of the stored-tabs
concept I'm currently used to in Unix and relate back to other non-Unix editors
to reorient myself.  I hadn't covered editing ease thoroughly in my original
posting; I appear to have concentrated mostly on input mode rather than editing
existing documents.  I'm considering this further and want to see if I can 
think of some way in which editing a file with stored tabs is easier than 
one with only spaces, even with the proper editor for the given universe.

Any more suggestions, anyone?

One thought that occurred to me is that conversion of tabs to spaces on input
causes some information to be lost when the file is saved.  It's hard to 
quantify, since only slightly less is lost in the stored tabs universe.  There,
though you retain tab placement information, you loose the tab width 
information.  Which means you can loose correct alignment with non-tabbed but
space-aligned columns (my main argument against stored tabs).

Did anyone ever expect to read entire articles on one ASCII control character?
-- 

Robert Oliver			
Rabbit Software Corp.		(215) 647-0440
7 Great Valley Parkway East     ...!{cbmvax,cuuxb}!hutch!robert
Malvern, PA  19355		...!psuvax!burdvax!hutch!robert