none wrote:
>>> So anything between
>>> start of line and the first character could be aligned with tabs.
>> ... with tabs and (+) spaces !
>
> That is the point. If talking about unix the default width of
> a tab is 8 characters. But thats no reason to use this width in
> text editors. I guess all of them allow to redefine tab display
> width.
The reason not to redefine tabs are that tabs are 8 in every
conceivable context except editors where they are changed.
So no other medium will show those files correctly unless
their tabstops are all changed too.
This means printing with lpr/print, diffing tools like xdiff,
email readers, web pages, tty and DOS terminals using 'more'
or grep, and any other possible code viewing context
would all have to have their tabstops changed for the indents
to be viewed properly.
In many of these contexts (eg. web browsers and email readers,
DOS windows) changing tabstops is not possible.
The tabstops being 8 was all decided years ago, and has been
in the coding standards since; it's served us well I think,
and I see no reason to change it.
Most editors can get the tab key to do any indent widths you
want without having to redefine tab stops; the tab key can be
programmed by the editor to generate the appropriate number of
spaces to achieve the indent width desired without redefining
tabs. So I think you can get the behavior you want while typing
without redefining tabstops.
There is a tendency to think tab stops can be used in such
a way where each tab represents a single level of indent,
thereby allowing it to be viewed in different levels of indent
just by redefining the tabstops, but as nice as that may be
to have, it means indenting with spaces would have to be outlawed,
since spaces could then never match up with tabs, and that seems
out of the question.
I'm -1e9 on redefining tabstops, or changing the coding standards.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
