https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4189
--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2009-11-02 17:01:41 PDT ---
Given that I'm the one who sent that message, yes, that's exactly what I'm
referring to.
> To me it is not obvious why it is a problem if editor A renders tab as 4 spaces
> where editor B renders tab as 8 spaces.
As long as all the space characters before the first non-whitespace character
in a line are tabs (no spaces), and as long as no tab characters appear *after*
the first non-whitespace character on a line, that will probably work.
Even with a convention such as the Kernel Normal Form convention of "first line
of a multi-line statement is indented solely with tabs, all subsequent lines of
that statement are indented with the same number of tabs as the first, plus 4
additional spaces", that *might* work, although if an editor has 4-space tabs,
that indentation would be indistinguishable from the indentation of a line
indented one more indentation level. For example, with an editor using 8-space
tabs, you might see
if ((foo = bar(arg1, arg2, arg3,
arg4) != NULL)
bletch(foo);
but, with an editor using 4-space tabs, you'd see
if ((foo = bar(arg1, arg2, arg3,
arg4)) != NULL)
bletch(foo);
so that the continuation of the if statement isn't as clearly set off from the
"true" arm of the if statement as it is with 8-space tabs.
If a convention such as
if ((foo = bar(arg1, arg2, arg3,
arg4) != NULL)
bletch(foo);
were used, that might work better - as long as the indentation of the
continuation line is done as the same number of tabs as the first line,
followed solely by spaces.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
