Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
Also, as I mentioned, the gEdit plugin that enables elastic tabstops
has a option to automatically do conversions. So you can work with
elastic tabstops enabled, but when saved, the file gets converted back
to using spaces.
What will happen when you commit your changes?
Will everybody have to work with your formatting, casted into spaces?
If any commit converts tabs to spaces, then elastic tabs do not solve
any problem any more or less than any other tab handling does.
In this case the stored text has only spaces. If you check it out again,
and wish to edit it, you need an editor, that detects where those spaces
should be tabs (magical guessing according to your taste)
Such conversion (to spaces / from spaces) can be applied to any form of
tabs that you have in your source code
NOTE: The conversion of tabs to spaces can be defined in 2 ways:
1) tabs a converted to an as many spaces as needed, so the look on the
pc of the converter does not change
2) tabs and consecutive tabs (as well as consecutive spaces) are
converted to a single space nly (except in strings or other white space
sensitive areas)
The first solution does not solve anything, as the checked in text still
expresses the format of the one writer who converted it. => Format is
still part of the content, not applied to a content
The 2nd form will work (exceptions see further down) but requires are
really good formater for any one wanting to work with this text
Same thing should apply to code formatting, which is what Elastic
Tabstops does. You press the Tab key, which inserts the char $09 -
nothing more! Now the editor does the formatting for you, but doesn't
modify the source code contents to do it.
I'd agree with different tabstop codes, so that the formatting can be
undone or suppressed at any time.
Tab stops in the source (white space insensitive area / outside strings
etc) are formating.
They are formatting, because they cause different layout, unless they
can be ignored / handled same as spaces
After all Graeme would only need a single (or 2) tab char in the source,
in order to align comments at the end of several lines
I need maybe between 1 and 10 tab stops per line so my editor shows the
comments aligned (using normal tabs)
If all editors are to handle them elastic, then they carry format into
the content
content, and thus would track only changes in the content,
regardless of
whitespace and line breaks.
Line breaks are interesting.
Since some people write:
if a then begin
or:
if a then
begin
the line break itself embeds formatting into the content.
If you want to archive, what you describe (format free content) then all
whitespaces (including tabs, newline) must be stored as simple space
(except some basic interpreters, which have linebreak as part of the
language)
Applying tabs and linebreaks is eye candy, that your editor should apply
on top of the content.....
Linebreaks could be used for paragraph like grouping of statements,
that represent a logical entity in your code, yet are not presented as a
procedure of their own.
---------------------------
I may have shlightly disconnected from reality while writing the above....
Martin
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
