Re: Cream Tabstop customization

[Steve H. <dig...@mi...>]

From: "Walter Mundt", Tue, 16 Mar 2004 10:40:47 -0500 (EST)
> Elias Pschernig
> >
> > No, you are right. Just, your method 3 looks normalyl like:
> >
> > |Level one
> > |...Level two
> > |......Level three
> > |------->.Level four
> >
> > Changing the tab width to anything but 8 results in a complete
> > mess. That's exactly why it is so important for cream to support
> > it. Vim, Anjuta and GEdit all get it right, for example. Hitting
> > <tab> indents with spaces (typically 2,3,4) - but as soon as there
> > are 8 consecutive spaces somewhere, they get replaced by a tab.
> 
> This is exactly what I'm talking about. Even though nobody uses an
> editor with fixed tabs anymore, many people still don't bother to
> customize tab width, and so will indent with all spaces. A large
> number of editors will then do as Elias described, and automatically
> substitute tabs wherever they'll fit, also by default. This results
> in Elias's picture above, and in such wonders as:
> 
> ....doSomethingComplicated(param, param2, ...
> ------->------->------->...param8, param9, ...);

AH, so with these options you are able to slowly "fix" mixed code. Or
at least deal with it. But we all agree that it's not the ideal,
right?


> > I completely agree that it is a very bad format. I even suggested
> > once on a quite big project to change the format - but the
> > maintainers were against changing all files in CVS for what they
> > saw as a very minor issue.
> 
> I don't necessarily agree that it's such a bad thing. Speaking
> personally, I rarely if ever find it useful to change the tab width
> of a piece of code from that in which it was written to begin with.
> Even when things are all done with tabs, changing tab sizes
> frequently doesn't work out right; more intricate code will be
> carefully formatted with internal spaces so that things line up
> vertically where there are logical connections, and these alignments
> are frequently lost when tab sizes are changed. Furthermore, while I
> have a preferred tab-width, my preference isn't that strong, and I
> will work with whatever tab width the project at hand is using.
> 
> Finally, extant code in my experience is rarely all-tabs or
> all-spaces, so one is almost always forced to reconfigure one's
> editor to whichever tab width the author wrote the code with. That's
> usually 8, so I personally will just leave my tabs at 8 and write
> all my code with tabs at 8 just so I don't have to keep adjusting
> it.
> 
> Thus, the reasons for this, while they have historical origins, are
> currently perpetuated by the default settings in various text
> editors and in vast amounts of existing source code. And, of course,
> through people (like me) who have to deal with the aforementioned
> code writing new code in the same manner because
> reconfiguring their editor is too much trouble.

Ok, if my assumptions are correct above, I understand the usefulness
of having independent control of both tabstop and shiftwidth. Now the
question is how Cream could implement this so that it would be out of
the way for a less experienced text editor user (a non-programmer).
Vim has a number of options related to tabs. These three are linked by
Cream:

  1. &tabstop
  2. &softtabstop
  3. &shiftwidth

This one can be set independently via menu or Ctrl+T (although it is
also linked to AutoWrap):

  4. &expandtab

and two are unset by Cream:

  5. &shiftround
  6. &smarttab

So if we are proposing de-linking 1, any thoughts on the relationship
of the remainder? Can 2 and 3 stay connected?


-- 
Steve Hall  [ dig...@mi... ]

Cream... the Vim text editor in sheep's clothing!
  http://cream.sourceforge.net