Indent with tabs, align with spaces
Oliver Zheng
Is that possible? It solves the tab/space indentation debate, but how
is this done in Vim? For example, the code:
int main() {
<tab>if (1)
<tab><tab>int a = test(
<tab><tab>.............param1,
<tab><tab>.............param2,
<tab><tab>............);
}
would look perfectly fine no matter what tabwidth is, in whatever
editor. How do I enable this? It seems that Vim coerces all
indentation whitespace to tabs plus some spaces that aren't long
enough for the width of a tab. Does Vim also make this language
dependent? (E.g. For python, I would assume it has a different scheme
of handling automatic indentation.)
Thanks,
Oliver
Erik Hahn
>
> Hi,
>
> Is that possible? It solves the tab/space indentation debate, but how
> is this done in Vim? For example, the code:
>
> int main() {
> <tab>if (1)
> <tab><tab>int a = test(
> <tab><tab>.............param1,
> <tab><tab>.............param2,
> <tab><tab>............);
> }
>
> would look perfectly fine no matter what tabwidth is, in whatever
> editor. How do I enable this?
Check out this [1] script.
1. http://www.vim.org/scripts/script.php?script_id=231
--
v4sw5RUYhw2ln3pr5ck0ma2u7Lw3+2Xm0l6/7Gi2e2t3b6AKMen5+7a16s0Sr1p-8.12/-6.56g6OR
Erik Hahn
>
>
> Is that possible? It solves the tab/space indentation debate, but how
> is this done in Vim? For example, the code:
>
> int main() {
> <tab>if (1)
> <tab><tab>int a = test(
> <tab><tab>.............param1,
> <tab><tab>.............param2,
> <tab><tab>............);
> }
>
> would look perfectly fine no matter what tabwidth is, in whatever
> editor. How do I enable this?
Check out this [1] script.
Oliver Zheng
>
> Check out this [1] script.
>
> 1. http://www.vim.org/scripts/script.php?script_id=231
I did. However, it looks like this only "automatically converts" tabs
to spaces during the middle of a line. For the example I gave:
int main() {
<tab>if (1)
<tab><tab>int a = test(
<tab><tab>.............param1, // [1]
<tab><tab>.............param2,
<tab><tab>............);
}
the script does not treat the param line [1] any differently than any
other line. It's not really context aware of the programming language.
Even if I *manually* space my way to param1 after the initial 2 tabs,
Vim will convert my spaces to tabs when I >> or <<. Is there no way to
let Vim recognize that spaces are a part of the contents and not
indent? Of course, it would be much better if Vim could automatically
insert spaces to the appropriate column when I break a statement into
multiple lines.
Cheers,
Oliver
Brett Stahlman
On Dec 22, 4:14 pm, "Oliver Zheng" <mailinglists+...@oliverzheng.com>
wrote:
>
> > Check out this [1] script.
>
> I did. However, it looks like this only "automatically converts" tabs
> to spaces during the middle of a line. For the example I gave:
>
> int main() {
> <tab>if (1)
> <tab><tab>int a = test(
> <tab><tab>.............param1, // [1]
> <tab><tab>.............param2,
> <tab><tab>............);
>
> }
>
> the script does not treat the param line [1] any differently than any
> other line. It's not really context aware of the programming language.
>
> Even if I *manually* space my way to param1 after the initial 2 tabs,
> Vim will convert my spaces to tabs when I >> or <<. Is there no way to
> let Vim recognize that spaces are a part of the contents and not
> indent? Of course, it would be much better if Vim could automatically
> insert spaces to the appropriate column when I break a statement into
> multiple lines.
for leading indent and spaces for subsequent alignment makes far more
sense than mixing tabs and spaces at the beginning of a line.
Fortunately, mixing of tabs and spaces happens only if your tabstop
setting is not the same as your shiftwidth: e.g., ts=8, sw=4. I
typically set both 'ts' and 'sw' to 4 since I prefer indents to appear
as 4 spaces. To those who say "but a tab is supposed to be 8 spaces",
I say "a tab isn't any amount of spaces - it is simply an indent
level". If you use tabs only for leading indent, an indent level can
be whatever you want it to be when you're viewing the file. Almost as
importantly, it can be whatever someone else wants it to be when he's
viewing the same file...
>
> Cheers,
> Oliver
Gary Johnson
> Even if I *manually* space my way to param1 after the initial 2 tabs,
> Vim will convert my spaces to tabs when I >> or <<. Is there no way to
> let Vim recognize that spaces are a part of the contents and not
> indent? Of course, it would be much better if Vim could automatically
> insert spaces to the appropriate column when I break a statement into
> multiple lines.
There is no way that I know of. The problem is the interface
between the function that determines how much a particular line
should be indented (based on the language, rules for that language,
etc.) and the code that actually performs the indentation as you
type or when you execute <<, >>, = and the like. That function
returns one number: the number of spaces by which the line should
be indented. There is no mechanism to split this into so-many tabs
followed by so-many spaces.
The 'preserveindent' and 'copyindent' options try to preserve the
pattern of spaces and tabs used to indent a line, but I don't think
they will do what you want.
I think your best bet is to write a formatting function that will
repartition the indenting whitespace code according to your rules
after you have typed it.
Regards,
Gary
pansz
> If you use tabs only for leading indent, an indent level can
> be whatever you want it to be when you're viewing the file. Almost as
> importantly, it can be whatever someone else wants it to be when he's
> viewing the same file...
No, this is a false illusion, you cannot expect a non-constant indent
level anyway, consider the following code.
suppose we have 4 space as indent level:
{
foobar1(); // comment1
if (fb2()) { // comment2
fb3(); // comment3
switch (x) { // comment4
case 1:
fb4(); // comment5
break;
default: // comment6
break;
}
}
}
now we change the indent level to 3:
{
foobar1(); // comment1
if (fb2()) { // comment2
fb3(); // comment3
switch (x) { // comment4
case 1:
fb4(); // comment5
break;
default: // comment6
break;
}
}
}
Got the idea? If anyone wants to change the indent level, the code is
ruined anyway.
Simply use only space for indent solves all problem above, personally I
do recommend not to use tab size other than 8 at all.
pansz
> If you use tabs only for leading indent, an indent level can
> be whatever you want it to be when you're viewing the file. Almost as
> importantly, it can be whatever someone else wants it to be when he's
> viewing the same file...
>
>> Cheers,
>> Oliver
(Sorry I had just learned how to set plain-text message in thunderbird,
then send this message again.)
Oliver Zheng
> Simply use only space for indent solves all problem above, personally I
> do recommend not to use tab size other than 8 at all.
That is very unfortunate that Vim does not support such an
uncompromising way of solving the issue. (I know Emacs does =P)
Is there plans for this feature? How do users submit feature requests anyway?
Oliver
pansz
Strange to hear that, that is the way I am using now, and I don't see
any problems using only space for indent in Vim.
What do you really want?
--
Pan, Shi Zhu
Oliver Zheng
> Strange to hear that, that is the way I am using now, and I don't see
> any problems using only space for indent in Vim.
Different people have different preferences regarding tabs vs spaces,
and mine are to use tabs for indentation since that what tabs are for.
Spaces are used for indentation due to the limitation of editors
(something I thought Vim of all editors could do) to interpret
indentation vs alignment.
Why tabs:
http://www.movementarian.org/docs/whytabs/
http://www.derkarl.org/why_to_tabs.html
> What do you really want?
As my original email in the thread describes, I want tabs for
indentation and spaces for alignment. Any whitespace that appears
after non-whitespace should be spaces. The Vim script Smart Tabs
handles this correctly.
The problem is when there are *multi-line* statements, which as Gary
mentioned Vim does not handle properly. When a statement is split over
multiple lines, alignment should not be solved using indentation.
E.g.:
foo (int a,
.....int b,
.....int c);
should not be
foo (int a,
<tab>int b,
<tab>int c);
I thought this would have been something Vim users would have
complained about. Emacs has a fix for it (with a few line of
configuration scripting), but it sounds like Vim's plugins cannot
extend into the editor for language-specific support. Is this correct
that this behavior cannot be reproduced in Vim with plugins?
Regards,
Oliver
pansz
> I thought this would have been something Vim users would have
> complained about. Emacs has a fix for it (with a few line of
> configuration scripting), but it sounds like Vim's plugins cannot
> extend into the editor for language-specific support. Is this correct
> that this behavior cannot be reproduced in Vim with plugins?
>
> Regards,
> Oliver
>
Vim indent behavior for any specific language is scriptable of course,
only c-style-indent is built-in since it is widely used. You can just
disable the built-in c-style-indent and make your own indent script in
~/.vim/indent/c.vim
So, I've just proved that vim is *capable* of doing what you want with
some script work. The reason that you cannot do it now may have two reasons:
1. there is one script in vim.sf.net, but you cannot find it.
2. or nobody has written a script yet.
Anyway, you can visit the vim homepage and registered as a vim user to
vote or request new features.
Tony Mechelynck
See
:help 'copyindent'
:help 'preserveindent'
:help 'expandtab'
For Python, Vim forces hard tabs to 8 columns, because that's what the
Python standards say they are. You can still have "soft tabs" of a
different width, of course, or use 'expandtabs' to convert tabs to
spaces as you type them. Language-dependent settings of this kind are
usually set by a filetype-plugin.
See
:help ftplugins
:help filetype-plugins
Best regards,
Tony.
--
What does it mean if there is no fortune for you?
Tony Mechelynck
See
Matt Wozniski
>
> Is that possible? It solves the tab/space indentation debate, but how
> is this done in Vim?
As of right now, it isn't possible without hacking vim's C code to
change how cindent() and 'indentexpr' work. 'preserveindent' and
'copyindent' are steps in the right direction, but nowhere close to a
working solution.
~Matt
invid
set softtabstop=4
set shiftwidth=4
set tabstop=4
set expandtab
invid
set softtabstop=4
set shiftwidth=4
set tabstop=4
set expandtab
On Mon, Dec 22, 2008 at 1:57 PM, Erik Hahn <erik...@gmx.de> wrote:
Brett Stahlman
indent***". The distinction is very important. To align end of line
comments within a block, you use spaces. Not only does using space for
leading indent waste an excessive amount of space in source files with
relatively short lines and high levels of indent, it also forces
everyone viewing the file to use the indent level preferred by the
original author.
Brett Stahlman
Brett Stahlman
.
>
> As my original email in the thread describes, I want tabs for
> indentation and spaces for alignment. Any whitespace that appears
> after non-whitespace should be spaces. The Vim script Smart Tabs
> handles this correctly.
value, and Vim will not mix spaces and tabs for leading indents.
.
.
Gary Johnson
> Oliver Zheng ??????:
> > I thought this would have been something Vim users would have
> > complained about. Emacs has a fix for it (with a few line of
> > configuration scripting), but it sounds like Vim's plugins cannot
> > extend into the editor for language-specific support. Is this correct
> > that this behavior cannot be reproduced in Vim with plugins?
> >
> > Regards,
> > Oliver
> >
>
> Vim indent behavior for any specific language is scriptable of course,
> only c-style-indent is built-in since it is widely used. You can just
> disable the built-in c-style-indent and make your own indent script in
> ~/.vim/indent/c.vim
>
> So, I've just proved that vim is *capable* of doing what you want with
> some script work. The reason that you cannot do it now may have two reasons:
> 1. there is one script in vim.sf.net, but you cannot find it.
> 2. or nobody has written a script yet.
I may be missing something, but for the reasons I gave before, I
really don't see how a script can be used to get the requested
behavior unless the script intercepts every keystroke and
re-implements vim's internal formatting and indenting code. How are
you thinking this could be done?
Regards,
Gary
fritzophrenic
On Dec 23, 8:52 am, Brett Stahlman <brettstahl...@comcast.net> wrote:
>
> As I mentioned in an earlier post, simply set ts and sw to the same
> value, and Vim will not mix spaces and tabs for leading indents.
>
The desired behavior is for Vim to automatically do something like
this:
{tab}{tab}{tab}if (a == b &&
{tab}{tab}{tab}....c == d &&
{tab}{tab}{tab}....e == f)
{tab}{tab}{tab}{
{tab}{tab}{tab}{tab}foo();
{tab}{tab}{tab}}
Note that actual TAB characters are used for indent, but spaces are
used for alignment.
As far as I know, the format on the 2nd and 3rd lines is not possible
for Vim to do automatically.
Richard Hartmann
> As far as I know, the format on the 2nd and 3rd lines is not possible
> for Vim to do automatically.
:set copyident
will preserve it once you do it manually.
And I love how many other people are doing this. I always code with
:set list
and I often feel very alone.. ;)
Richard
Max Waterman
>
> On Dec 23, 8:52 am, Brett Stahlman <brettstahl...@comcast.net> wrote:
>
>> As I mentioned in an earlier post, simply set ts and sw to the same
>> value, and Vim will not mix spaces and tabs for leading indents.
>>
>>
>
> True, but this is not what is being asked.
>
> The desired behavior is for Vim to automatically do something like
> this:
>
> {tab}{tab}{tab}if (a == b &&
> {tab}{tab}{tab}....c == d &&
> {tab}{tab}{tab}....e == f)
> {tab}{tab}{tab}{
> {tab}{tab}{tab}{tab}foo();
> {tab}{tab}{tab}}
>
> Note that actual TAB characters are used for indent, but spaces are
> used for alignment.
>
I'm curious how the distinction between 'indent' and 'alignment' has
been made. I see them as exactly the same thing; as English words, I
mean. It's obvious from the diagram above what is meant, but the purpose
of the 'indent' is to 'align'...
...or am I missing something?
How is the difference between the two instances above best described?
Perhaps 'block indentation' as apposed to 'line-wrapping indentation'?
I wonder if it's getting to the point where vim would have to be a
compiler in order to make these distinctions accurately. Perhaps that's
something that is easier for something like Emacs to do.
I would like to be able to make use of a real compiler in order to do
this kind of code parsing. I'm told that the gcc people, for example,
aren't really interested in doing this.
Max.
Oliver Zheng
<davidmax...@fastmail.co.uk> wrote:
> How is the difference between the two instances above best described?
> Perhaps 'block indentation' as apposed to 'line-wrapping indentation'?
The difference is it allows for a variable width display of tabs.
Different people have different preferences for their tab width.
Personally, I prefer 8 columns for a tab, but the guy next door might
like 3. A scheme that has tabs for indents allows for everybody's
preference.
The spaces are particular to the statement. The width of alignment
depends on the previous line of the statement, not on how wide I
prefer my tabs to be.
So it seems like there is no feature available. I guess I'll request
this feature on vim.org.
Thanks guys.
Oliver
Max Waterman
On Tue, Dec 23, 2008 at 3:57 PM, Max Waterman <davidmax...@fastmail.co.uk> wrote:How is the difference between the two instances above best described? Perhaps 'block indentation' as apposed to 'line-wrapping indentation'?The difference is it allows for a variable width display of tabs. Different people have different preferences for their tab width. Personally, I prefer 8 columns for a tab, but the guy next door might like 3. A scheme that has tabs for indents allows for everybody's preference.
I guess my question/thought isn't particularly relevant, but IMO the words are confusing - they're both there for 'alignment' and 'indentation'.
So, I suppose you can forget what I said, if you feel like it ;)
The spaces are particular to the statement. The width of alignment depends on the previous line of the statement, not on how wide I prefer my tabs to be.
The diagram helps that though.
So it seems like there is no feature available. I guess I'll request this feature on vim.org.
I think vim would benefit from such a thing too, so long as it didn't require it to become a compiler (or the parser part of a compiler, at least), which might mean it becomes hugely bloated, especially when it needs it for many languages.
We'll see :)
FWIW, and not directly related, but I attempted to come up with some Qt/C++ syntax rules for vim, and it was mostly done by someone on this list (thanks!), but the result only worked some of the time and the times it didn't work were kind of annoying - to the point that I ended up not using it. I *really* think there's a place for tools like g++ to output the parsed code (in xml, for example) so that tools such as vim can make use of it.
FWIW2, our org have set our indentation 'style' - no tabs at all :); your question reminds me of someone who objected to me posting with very long lines, since it forced him to scroll in order to read to the end of the line. I responded that by wrapping the lines, I would force *everyone* to view them at the length I decided on - at least this way people can wrap them to the width of their window. I think the tab/space thing is at least valuely similar.
Max.
Tony Mechelynck
"if") with varying levels of indent within your block, your comments
will move when you change the 'tabstop' setting.
Like him, I recommend leaving 'tabstop' at 8. If you want other levels
of indent, you may for instance ":set sts=4 sw=4". And in some files
that may be exported to systems (such as email) where tab stop settings
are uncertain, I use 'expandtab' to replace my tabs by spaces as I type
them.
Best regards,
Tony.
--
Burn's Hog Weighing Method:
(1) Get a perfectly symmetrical plank and balance it across a
sawhorse.
(2) Put the hog on one end of the plank.
(3) Pile rocks on the other end until the plank is again
perfectly balanced.
(4) Carefully guess the weight of the rocks.
-- Robert Burns
Tony Mechelynck
Don't. I use ":set list lcs=tab:\|_,eol:¶,nbsp:~" (and, in the light of
another thread, I don't forget to set 'encoding' to UTF-8 first, not
afterwards, if the locale is something else).
Best regards,
Tony.
--
You'd better beat it. You can leave in a taxi. If you can't get a
taxi, you can leave in a huff. If that's too soon, you can leave in a
minute and a huff.
-- Groucho Marx
Tony Mechelynck
It's hard for Vim to guess that in
if (a == b &&
c == d &&
e == f)
you want c aligned with a (and not, let's say, one level of indent
further than the "if"). However, as others have repeatedly said, with
":set autoindent copyindent" (and maybe 'preserveindent' but I'm less
sure what it does), when you hit Enter after "c == d &&", the third line
will get the exact same mixture of tabs and spaces as the second one.
Best regards,
Tony.
--
Shit makes the flowers grow and that's beautiful
Matt Wozniski
>
> On 24/12/08 01:04, Oliver Zheng wrote:
>>
>> So it seems like there is no feature available. I guess I'll request
>> this feature on vim.org.
>
>
> if (a == b &&
> c == d &&
> e == f)
>
> you want c aligned with a (and not, let's say, one level of indent
> further than the "if").
Unless you're using, say, cindent, or an indentexpr, which give you
absolute control over that sort of thing.
> However, as others have repeatedly said, with
> ":set autoindent copyindent" (and maybe 'preserveindent' but I'm less
> sure what it does), when you hit Enter after "c == d &&", the third line
> will get the exact same mixture of tabs and spaces as the second one.
Which is still a far cry away from properly using tabs for indenting
blocks and spaces for aligning code automatically. Like I said
before, vim just isn't capable of doing the right thing here, and
changing that would require making a way for indentexpr's to specify
"number of spaces of indent" and "number of spaces for alignment"
independently.
~Matt
bill lam
> See
> :help ftplugins
> :help filetype-plugins
I think that OP does not satisfy with these plugins. I would really
use language specific pretty print program to do that job. Anyway
division of labour is what *nix meant, perhaps with the exception of
emacs.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩169 僧皎然 尋陸鴻漸不遇
移家雖帶郭 野徑入桑麻 近種籬邊菊 秋來未著花
扣門無犬吠 欲去問西家 報到山中去 歸來每日斜
bill lam
> :help ftplugins
> :help filetype-plugins
I think that OP does not satisfy with these plugins. I would really
Tony Mechelynck
> On Tue, 23 Dec 2008, Tony Mechelynck wrote:
>> See
>> :help ftplugins
>> :help filetype-plugins
>
> I think that OP does not satisfy with these plugins. I would really
> use language specific pretty print program to do that job. Anyway
> division of labour is what *nix meant, perhaps with the exception of
> emacs.
>
In the case of Vim, division of labour means you can customize the
behaviour of Vim, even separately for different filetypes, just by
dropping an appropriate script in the appropriate directory. Anyone can
write the script (not only Bram and not only you), and no need to recompile.
When the internal :vimgrep command was added (shortly after :helpgrep)
to do essentially what the external :!grep already did, I thought it was
progress: maybe it was less division of labour between Vim and an
external grep program, but no need to search the web for grep if you
were on a platform (such as Windows) where it wasn't standard, and the
regular expressions were Vim regular expressions, which are well
documented in the Vim help and are the same as those used in :s or / And
of course (but you won't regard that as an advantage) the
process-calling overhead was totally eliminated.
Best regards,
Tony.
--
"What the hell are you getting so upset about? I thought you
didn't believe in God."
"I don't," she sobbed, bursting violently into tears, "but the
God I don't believe in is a good God, a just God, a merciful God. He's
not the mean and stupid God you make Him out to be."
-- Joseph Heller, "Catch-22"
Teemu Likonen
> On Tue, 23 Dec 2008, Tony Mechelynck wrote:
>> See
>> :help ftplugins
>> :help filetype-plugins
>
> I think that OP does not satisfy with these plugins. I would really
> use language specific pretty print program to do that job.
The GNU "indent" utility seems to be full-featured tool for indenting C
code. So if gg=G does not do what user wants then maybe
:%!indent --preferred-indent-style-and-options
will.
Antony Scriven
This is verging on the autistic. The main problem with
complicated indentation schemes is getting all programmers
in a group to follow them. Complicated suggestion: write
a (simple) map to insert the correct number of spaces for
you. Simple suggestion: just use two extra levels of
indentation for continuation lines, like many people. --Antony
Richard Hartmann
<antoine.m...@gmail.com> wrote:
> Don't. I use ":set list lcs=tab:\|_,eol:¶,nbsp:~" (and, in the light of
> another thread, I don't forget to set 'encoding' to UTF-8 first, not
> afterwards, if the locale is something else).
if &encoding == "utf-8"
set listchars=eol:$,trail:·,tab:»·,extends:>,precedes:<
else
set listchars=eol:$,trail:-,tab:>-,extends:>,precedes:<
endif
That way, I can work on legacy/broken systems, as well.
Richard
Richard Hartmann
> Which is still a far cry away from properly using tabs for indenting
> blocks and spaces for aligning code automatically. Like I said
> before, vim just isn't capable of doing the right thing here, and
> changing that would require making a way for indentexpr's to specify
> "number of spaces of indent" and "number of spaces for alignment"
> independently.
If anyone would write a patch for that, I am sure a lot of people who
use vim_extended would merge that, as well.
Richard
Sir Robert Burbridge
Max Waterman wrote:
> I feel the need to make my tuppence worth...so I'm gonna :
>
> I'm curious how the distinction between 'indent' and 'alignment' has
> been made. I see them as exactly the same thing; as English words, I
> mean. It's obvious from the diagram above what is meant, but the purpose
> of the 'indent' is to 'align'...
>
> ...or am I missing something?
>
> How is the difference between the two instances above best described?
> Perhaps 'block indentation' as apposed to 'line-wrapping indentation'?
>
> I wonder if it's getting to the point where vim would have to be a
> compiler in order to make these distinctions accurately. Perhaps that's
> something that is easier for something like Emacs to do.
>
> I would like to be able to make use of a real compiler in order to do
> this kind of code parsing. I'm told that the gcc people, for example,
> aren't really interested in doing this.
>
> Max.
>
Max,
The difference between indentation and alignment (in English, as you
say), is subtle, but it's there. You alluded to it yourself when you
said, "but the purpose of the 'indent' is to 'align'". "Indentation" is
refers to a line's (or block's) horizontal distance from the margin,
whereas "alignment" refers to its horizontal distance from other
(usually nearby) lines. So you're right that indentation (varying the
distance from the margin) is for the sake of alignment (adjusting the
x-distance from other lines) ... which is exactly why they are not the
same! It's why something is considered "aligned" (well) only when there
is uniformity of indentation, but something can be considered indented
(well) when the indentation varies quite a bit -- such as in code.
Etymologically, "align" is related to "line" -- it means "to line up";
whereas "indent" is related to "dent" -- it means, "to dent inward" (ok,
"indent" is a little more complex than that, but it's a reasonable
synopsis that captures the spirit of it!).
Hope that helps shed some light on it.
-Sir Robert Burbridge
Gene Kwiecinski
>>>
>>> if (a == b &&
>>> c == d &&
>>> e == f)
>>>
>>>you want c aligned with a (and not, let's say, one
>>>level of indent further than the "if").
>This is verging on the autistic. The main problem with
>complicated indentation schemes is getting all programmers
>in a group to follow them. Complicated suggestion: write
>a (simple) map to insert the correct number of spaces for
>you. Simple suggestion: just use two extra levels of
>indentation for continuation lines, like many people. --Antony
It's even worse, because people have their own styles, which they take
personally, and will fight you to the end before changing them.
Eg, me personally, and this is just personal preference and not judging
"right" or "wrong", but I'd personally put the joining operators in the
left margin, because the right margin would be too ragged to see what
joins what, especially when mixing ands and ors. So I'd have
if( a == b
&& c == d
&& e == f )
or to mix it up with different conditionals
if( ( ( a == b )
&& ( c == d ) )
|| ( e == f ) )
which is already starting to look rather lispy, but it aligns the
equations and lets you know "up front" (ie, in the left margin) what's
anded and what's ored. And if you were to say it aloud, how would your
inflection describe it? Typically:
*If*
<pause>
ay equalequal bee andand cee equalequal dee
<pause>
*oror* ee equalequal eff
<pause>
*then* ..."
Ie, you wouldn't use the "andand"s and "oror"s at the *end* of the
test-equality clause (vs assignment, where it'd be "equal" vs
"equalequal"), but at the beginning to introduce the clause.
Anyhoo, try getting 'vim' or *any* editor to autogenerate *that*...
You'd have to compile 'vim' with '+lex +yacc'...
Matt Wozniski
>
> On Wed, Dec 24, 2008 at 12:17 AM, Matt Wozniski wrote:
>
>> On Tue, Dec 23, 2008 at 11:26 PM, Tony Mechelynck wrote:
>>
>>> However, as others have repeatedly said, with ":set
>>> autoindent copyindent" (and maybe 'preserveindent' but
>>> I'm less sure what it does), when you hit Enter after
>>> "c == d &&", the third line will get the exact same
>>> mixture of tabs and spaces as the second one.
>>
>> Which is still a far cry away from properly using tabs
>> for indenting blocks and spaces for aligning code
>> automatically. Like I said before, vim just isn't
>> capable of doing the right thing here, and changing that
>> would require making a way for indentexpr's to specify
>> "number of spaces of indent" and "number of spaces for
>> alignment" independently.
>
> This is verging on the autistic. The main problem with
> complicated indentation schemes is getting all programmers
> in a group to follow them.
In my case, that is not a problem at all - I follow the
established coding standards for any project I'm on, but
I would like to be able to use this indentation scheme for
any project that I write myself. Such projects usually have
few other people touching the code, so the convenience of
having them display properly aligned regardless of the value
of &tabstop that people prefer far outweighs the necessity
of having every committer using the same coding style.
> Complicated suggestion: write
> a (simple) map to insert the correct number of spaces for
> you.
Still wouldn't help for, eg, gg=G. Yes, I realize that
I can code with my preferred style manually. But coding in
*any* coding style manually is more frustrating than it's
worth.
> Simple suggestion: just use two extra levels of
> indentation for continuation lines, like many people.
I'd prefer to use noexpandtab instead. Using two levels of
indentation means that I can't make code line up for
readability, and using spaces instead of tabs means that
other people might think my code is too narrow or too wide
and have no way of automatically fixing it. Right now
I need to err on the side of what looks prettier to me, but
I wish I didn't have to - I'm sure many people think that my
code, with shiftwidth=2, is far too narrow, and if vim
supported using tabs for indent level followed by spaces for
alignment, I wouldn't need to choose between making things
look more readable for me and making things look more
readable for others.
~Matt
nico
wrote:
> I would like to be able to make use of a real compiler in order to do
> this kind of code parsing. I'm told that the gcc people, for example,
> aren't really interested in doing this.
http://clang.llvm.org/features.html#applications
Tony Mechelynck
> On Wed, Dec 24, 2008 at 05:12, Tony Mechelynck
> <antoine.m...@gmail.com> wrote:
>
>> Don't. I use ":set list lcs=tab:\|_,eol:¶,nbsp:~" (and, in the light of
>> another thread, I don't forget to set 'encoding' to UTF-8 first, not
>> afterwards, if the locale is something else).
>
> set listchars=eol:$,trail:·,tab:»·,extends:>,precedes:<
> else
> set listchars=eol:$,trail:-,tab:>-,extends:>,precedes:<
> endif
>
> That way, I can work on legacy/broken systems, as well.
>
>
> Richard
The characters I use are all below 0xFF, but the Pilcrow mark (0xB6) is
represented differently in Latin1 and in UTF-8, so I mustn't change
encodings after setting the value. My encoding-handling snippet is near
the top of my vimrc, framed within "if has('multi_byte')" so on
trimmed-down versions (such as my tiny "vi" build) I may remain in
Latin1 and use the same 'listchars'. What I don't understand though, is
that vi displays a hollow box in konsole, a reverse-video question mark
on /dev/tty, while Vim displays the Pilcrow mark in both -- and yet, my
.vimrc has "scriptencoding latin1"... Maybe the terminals don't
understand a Pilcrow mark in Latin1...
OK, let's do it slightly differently -- and remember that vi has no
expression evaluation, so every :if counts as a comment there: it's no
use trying to set values for it in an else-clause.
set list listchars=eol:$
if has('multi_byte')
set listchars=eol:¶
endif
set listchars+=tab:\|_
silent! set listchars+=nbsp:~
...it works: vi now displays a dollar sign, and vim a Pilcrow mark.
Best regards,
Tony.
--
No good deed goes unpunished.
-- Clare Boothe Luce
pansz
> The GNU "indent" utility seems to be full-featured tool for indenting C
> code. So if gg=G does not do what user wants then maybe
>
> :%!indent --preferred-indent-style-and-options
>
> will.
That is not going to work for someone who insists hard tabs should be
used in source code. Since gnu indent never use hard tabs at all.
For me it works just perfect, since our project forbids use of hard tabs
in source code at all. (Makefile is the only exception, but we use cmake
and we never write Makefile ourselves.)
Max Waterman
However, I have further thoughts (*all my own opinion, of course*) :
1) tabs are for tabulating - kind of like making tables - not (just) for indenting. It's supposed to cause the 'cursor' to move to next tab stop'; ie there's nothing to say you can't use then *within* a line, mixed with other text,
2) spaces are not for indenting *or* aligning (using the current parlance) - they're for separating words. For example, what happens if I want to view with a variable width font - ie the problem most of us are seeing with these email messages?
This leads me to think that the person requesting this feature should use tabs and not spaces, and put a tab in the middle of the text to which he wishes to align.
<tab>if (<tab>thisIsTrue ) {
<tab><tab>DoThis();
}
...or something like that.
Of course, the flexibility to do what is asked/wanted would be nice, but I don't consider this particular case as being something that *should* be done because it's *the right way*. On the contrary, IMO, it's more a side case that is *the wrong way* but would be nice to be able to do. Yeah, I'm not afraid to say it's wrong (if that's what I think) ... religious or not :p ... let the flames begin ;)
Max.
Max Waterman
Max Waterman
Actually, the llvm project sounds cool too.
I wonder if there's an 'editor' plugin project, so, for example, we can just plug in 'vim' into 'eclipse' and it'll just work. ...or perhaps this concept is fundamentally flawed.
Max.
Matt Wozniski
> This leads me to think that the person requesting this feature should use
> tabs and not spaces, and put a tab in the middle of the text to which he
> wishes to align.
>
> <tab>if (<tab>thisIsTrue ) {
> <tab><tab>DoThis();
> }
>
> ...or something like that.
>
> Of course, the flexibility to do what is asked/wanted would be nice, but I
> don't consider this particular case as being something that *should* be done
> because it's *the right way*. On the contrary, IMO, it's more a side case
> that is *the wrong way* but would be nice to be able to do. Yeah, I'm not
> afraid to say it's wrong (if that's what I think) ... religious or not :p
> ... let the flames begin ;)
I think you're still misunderstanding things. One last go at
explaining why this is the Right Way (which won't make much sense
unless you're using a fixed width font): consider a vim set up with
:set list listchars=tab:>- tabstop=8 shiftwidth=8 noexpandtab
Assuming this indent/alignment style is used, you could get code that
looked like this:
int main() {
>-------int returnval = 5; /* This is the value that I will return.
>------- It's nonzero, which means failure. */
>-------return returnval; /* This is where I return it. */
}
Note the nicely aligned comments at the end of the lines. If a person
viewing this code then decided that a tabstop of 8 is too wide, and
wanted to use tabstop=3 for more compact code, all he would need to do
is change tabstop to 3, and he would see this:
int main() {
>--int returnval = 5; /* This is the value that I will return.
>-- It's nonzero, which means failure. */
>--return returnval; /* This is where I return it. */
}
And the comments still line up! The advantage of this indentation
scheme is that changing tabstop will allow changing the width of the
code to fit personal preferences without hurting the alignment of
anything that was lined up. Compare this to what happens with the way
vim works now - let's say someone writes the same chunk of code with
:set ts=8 sw=8 noet:
int main() {
>-------int returnval = 5; /* This is the value that I will return.
>------->------->------- It's nonzero, which means failure. */
>-------return returnval; /* This is where I return it. */
}
Now, when our friend wants to display it with tabstop=3, things don't work out!
int main() {
>--int returnval = 5; /* This is the value that I will return.
>-->-->-- It's nonzero, which means failure. */
>--return returnval; /* This is where I return it. */
}
This is why using tabs for indenting a block, and spaces for aligning
code and comments within that block, is the nicest coding style to
work with. It allows anyone to change the width with which a tab is
displayed and change the width and look of the code, without screwing
up the alignment of comments and code.
~Matt
pansz
> Assuming this indent/alignment style is used, you could get code that
> looked like this:
Let's add something more, okay?
> int main() {
> .-------int returnval = 5; /* This is the value that I will return.
> .------- It's nonzero, which means failure. */
> .-------if (foobar)
> .-------.-------return 0; /* This is where I return it.*/
> .-------else
> .-------.-------return 1; /* This is where I return it.*/
> }
Now we change the tab size to 3:
> int main() {
> .--int returnval = 5; /* This is the value that I will return.
> .-- It's nonzero, which means failure. */
> .--if (foobar)
> .--.--return 0; /* This is where I return it.*/
> .--else
> .--.--return 1; /* This is where I return it.*/
> }
The comment will not get aligned after you changed the tab size. mixed
tab and spaces does not help.
There's *no* way to use a variant tab size and retain a reasonable
output. Fix the tab size to 8 or use only spaces is the ultimate
solution anyway.
Max Waterman
On Wed, Dec 24, 2008 at 9:24 PM, Max Waterman wrote:This leads me to think that the person requesting this feature should use tabs and not spaces, and put a tab in the middle of the text to which he wishes to align. <tab>if (<tab>thisIsTrue ) { <tab><tab>DoThis(); } ...or something like that. Of course, the flexibility to do what is asked/wanted would be nice, but I don't consider this particular case as being something that *should* be done because it's *the right way*. On the contrary, IMO, it's more a side case that is *the wrong way* but would be nice to be able to do. Yeah, I'm not afraid to say it's wrong (if that's what I think) ... religious or not :p ... let the flames begin ;)I think you're still misunderstanding things.
My observation is purely ideological - ie countering your claim that what you describe is 'the right way'.
What you suggest isn't any more 'right' than other ways that use spaces for indentation/alignment/whatever, or schemes that mix them with tabs. Your objectives, perhaps, are 'the right way' - I think there's no doubt about that.
Tabs are there for alignment - indenting is just a special case since it's at the beginning of the line.
What you have below will work (though not in vim, perhaps) if tabs were used the way they were designed to be - ie you put them at the position you want to align, for all text that is supposed to be aligned at that position. Of course, for comments like you have below, in the extreme case (eg long files/pages) this may well result in having a tabstop for every character....though I'm not even sure what that means when characters can have a variable width.
If the user wants to use a variable width font, then even your scheme will fall over - IINM, using only tabs whenever you want alignment is the only thing that will work.
However, I don't deny that this would be a useful thing to have, especially since we (almost?) all use fixed width fonts for coding, and that maintaining the indentation of comments/etc so that they align with other text is a desirable goal. So, I'd be happy if this feature were available too :)
My point is that all these methods are pretty much a hack anyway...but perhaps a worthwhile one because we don't all want to be using Microsoft Word for editing source code.
There are other 'hacks' that get around the problem you describe too. For example, not putting multi-line comments on the end of a line, but put them before the line they pertain to - that would avoid the problem altogether.....actually, that makes me think of a case where vim sort of does do what you describe.
If I enter :
<tab>/*
then hit return, it gives me :
<tab>/*
<tab><space>
It's a very limited example, but anyway. Perhaps you would want to be able to do this :
<tab>/*<space>hello
<tab><space><space><space>there
Of course, you can get around this by not putting words on the same line as the /* :
/*
<tab>hello
<tab>there
*/
What I was trying to point out is that, this could be achieved (theoretically) with :
<tab>/*<tab>hello
<tab><tab>there
Changing where the tab stops are would allow another user to adjust it to their preference.
Yes, I have serious doubts about the plausibility of this - horrible memories of trying to make tabs 'play ball' during my early years on computers are coming back to haunt me.
I think I recall seeing some IDEs that allow variable width fonts - I suspect they do something similar to tabs, or perhaps they do their own thing.
Really I think the ultimate is to have a new tab mechanism altogether where you can tag characters as being grouped in the same 'alignment'. Well, I don't know...
For the short term, more practical view point, a change to allow what you want would be desirable.
However, without the editor being able to parse the code correctly (ie as well as a compiler would) then most implementations of syntax/style automation are going to not work in some cases - especially with languages like C++, which are terribly difficult to parse (so I'm told). I see this 'all the time' with vim - it just gets it wrong. IMO, the way forward is to actually have a plugin for a parser, like someone else mentioned.
Anyway, my opinion makes no difference here, and I'm kind of done thinking about it, interesting though it is :) If you find no value in my thoughts (because they're wrong or whatever), then that's fine...no problem.
Later,
Max.
Tony Mechelynck
[...]
> Of course, the flexibility to do what is asked/wanted would be nice, but
> I don't consider this particular case as being something that *should*
> be done because it's *the right way*. On the contrary, IMO, it's more a
> side case that is *the wrong way* but would be nice to be able to do.
> Yeah, I'm not afraid to say it's wrong (if that's what I think) ...
> religious or not :p ... let the flames begin ;)
>
> Max.
If you're saying yourself that that's what you want to do and that it is
the wrong way, who can disagree? Some people will agree that they want
to do it too, others will agree that it's the wrong way. :-)
Makes me think of "creado quia absurdum" ("I believe because it is absurd").
Best regards,
Tony.
--
Real World, The n.:
1. In programming, those institutions at which programming may
be used in the same sentence as FORTRAN, COBOL, RPG, IBM, etc. 2. To
programmers, the location of non-programmers and activities not related
to programming. 3. A universe in which the standard dress is shirt and
tie and in which a person's working hours are defined as 9 to 5. 4.
The location of the status quo. 5. Anywhere outside a university.
"Poor fellow, he's left MIT and gone into the real world." Used
pejoratively by those not in residence there. In conversation, talking
of someone who has entered the real world is not unlike talking about a
deceased person.
Max Waterman
On 25/12/08 03:24, Max Waterman wrote: [...]Of course, the flexibility to do what is asked/wanted would be nice, but I don't consider this particular case as being something that *should* be done because it's *the right way*. On the contrary, IMO, it's more a side case that is *the wrong way* but would be nice to be able to do. Yeah, I'm not afraid to say it's wrong (if that's what I think) ... religious or not :p ... let the flames begin ;) Max.If you're saying yourself that that's what you want to do and that it is the wrong way, who can disagree? Some people will agree that they want to do it too, others will agree that it's the wrong way. :-) Makes me think of "creado quia absurdum" ("I believe because it is absurd").
Max.
Best regards, Tony.
Matt Wozniski
>
> Matt Wozniski 写道:
>> Assuming this indent/alignment style is used, you could get code that
>> looked like this:
>
> Let's add something more, okay?
> The comment will not get aligned after you changed the tab size. mixed
> tab and spaces does not help.
Fair enough, I should have stipulated that this will only allow
correct alignment on lines with the same indent level - but that, in
and of itself, is more than is available in any other way.
> There's *no* way to use a variant tab size and retain a reasonable
> output. Fix the tab size to 8 or use only spaces is the ultimate
> solution anyway.
Except that still leaves the problem of what to do when Jane wants
more, or fewer, spaces per indent level than John wants.
~Matt
Teemu Likonen
> Teemu Likonen 写道:
>> The GNU "indent" utility seems to be full-featured tool for indenting C
>> code. So if gg=G does not do what user wants then maybe
>>
>> :%!indent --preferred-indent-style-and-options
>>
>> will.
>
> That is not going to work for someone who insists hard tabs should be
> used in source code. Since gnu indent never use hard tabs at all.
I think the definition of "never" can be adjusted with these options:
-nut, --no-tabs
Use spaces instead of tabs.
See INDENTATION.
[...]
-ut, --use-tabs
Use tabs. This is the default.
See INDENTATION.
Richard Hartmann
> The comment will not get aligned after you changed the tab size. mixed
> tab and spaces does not help.
You are cheating by trying to align across several levels of logical nesting.
It's obvious that there is no flexible method of alignment in that situation,
today. You would need a meta-tab or something similar if you wanted
to achieve this in a text interface.
I still maintain that this is not needed in the real world as maintaining
perfect alignment of behind-code comments is not practicable with
more than two or three level of indentation, anyway. _Especially_
with sw=8 which you seem to prefer.
> There's *no* way to use a variant tab size and retain a reasonable
> output. Fix the tab size to 8 or use only spaces is the ultimate
> solution anyway.
You definition of reasonable differs from mine.
The case you constructed serves as justification to force everyone
touching your code to adhere to your rules. Not a nice thing to do
at best, actively harming collaboration at best.
Point in case, the Perl guidelines suggest sw=4 using soft tabs.
What would happen if you edited those files and saved them?
Even if you were not to change any of the existing lines, you
would mess up the file for everyone not using sw=8.
Also, please keep in mind that many people code in Terminals
that are 80 chars wide. Forcing them to use sw=8 is just plain
unfair.
Richard
pansz
> You are cheating by trying to align across several levels of logical nesting.
programming.
> It's obvious that there is no flexible method of alignment in that situation,
> today. You would need a meta-tab or something similar if you wanted
> to achieve this in a text interface.
Yes there is one method: use spaces.
> I still maintain that this is not needed in the real world as maintaining
> perfect alignment of behind-code comments is not practicable with
> more than two or three level of indentation, anyway. _Especially_
> with sw=8 which you seem to prefer.
No, I don't say sw=8, I'd say ts=8 and sw=(what ever you want). i.e.
don't rely on hard tab to do indent, tabs are used to create tables, not
indent. Using spaces to do indent isn't the right way either, but in
fixed-width-font world especially in programming, spaces are the most
natural way for indent.
> You definition of reasonable differs from mine.
> The case you constructed serves as justification to force everyone
> touching your code to adhere to your rules. Not a nice thing to do
> at best, actively harming collaboration at best.
If there is collaboration at all, developers need to use the same rule
or the same coding style in the project anyway. At least the same coding
style should be retained within one module. I see this to be a
reasonable rule.
> Point in case, the Perl guidelines suggest sw=4 using soft tabs.
> Forcing them to use sw=8 is just plain unfair.
Again, I'm saying ts=8 and sw=(what ever you want). And that is
*recommended* by official vim documents. If someone claims that spaces
waste more bytes than hard tabs, he can :set noet, which will change all
leading 8 spaces into hard tabs and there isn't too much bytes wasted by
the space character.
>
> Richard
Pan, Shi Zhu
Richard Hartmann
> If there is collaboration at all, developers need to use the same rule
> or the same coding style in the project anyway. At least the same coding
> style should be retained within one module. I see this to be a
> reasonable rule.
And with tabs, people are a lot more flexible.
That as may be, let's agree to disagree.
Richard
pansz
>
> And with tabs, people are a lot more flexible.
>
> That as may be, let's agree to disagree.
But by using hard tabs for indent you're *forcing* a non-standard
tab-size, and you're forcing tab size to be the same as indent size. (In
vim, that means you're forcing ts=sw)
Indent size of 8 is too big for most programmers (except Linus Thorvald
and some kernel hackers), if you use hard tabs for indent you *forced*
that hard tab size should be the same as indent size and those people
viewing your code will have to change the tab size to a smaller value in
order to view your code more comfortably.
If you do not use hard tabs in source code, we can still keep tab size
as the standard 8 and view the code as indent size 4, since 4 spaces
will always be 4 spaces. Keep tab-size as 8 does not mean I want to use
shift-width or indent-size as 8, I use shift-width as 4 and keep
tab-size to 8.
Think considerably what is discouraging collaboration when you *force*
other programmers to change the standard tabsize=8 into 4 just in order
to view your code?
>
>
> Richard
Brett Stahlman
On Dec 24, 10:43 pm, pansz <panshi...@routon.com> wrote:
> Matt Wozniski 写道:
>
> > Assuming this indent/alignment style is used, you could get code that
> > looked like this:
>
> Let's add something more, okay?
>
> > int main() {
> > .-------int returnval = 5; /* This is the value that I will return.
> > .------- It's nonzero, which means failure. */
> > .-------if (foobar)
>
> > .-------.-------return 0; /* This is where I return it.*/
> > .-------else
>
> > .-------.-------return 1; /* This is where I return it.*/
> > }
>
> Now we change the tab size to 3:
> > int main() {
> > .--int returnval = 5; /* This is the value that I will return.
> > .-- It's nonzero, which means failure. */
> > .--if (foobar)
> > .--.--return 0; /* This is where I return it.*/
> > .--else
> > .--.--return 1; /* This is where I return it.*/
> > }
>
> The comment will not get aligned after you changed the tab size. mixed
> tab and spaces does not help.
reasonable to me.
Brett S.
Brett Stahlman
On Dec 23, 10:01 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> On 23/12/08 15:49, Brett Stahlman wrote:
>
>
>
>
>
>
>
> > On Dec 22, 7:41 pm, pansz<panshi...@routon.com> wrote:
> >> Brett Stahlman 写道:
>
> >>> If you use tabs only for leading indent, an indent level can
> >>> be whatever you want it to be when you're viewing the file. Almost as
> >>> importantly, it can be whatever someone else wants it to be when he's
> >>> viewing the same file...
> >> No, this is a false illusion, you cannot expect a non-constant indent
> >> level anyway, consider the following code.
>
> >> suppose we have 4 space as indent level:
> >> {
> >> foobar1(); // comment1
> >> if (fb2()) { // comment2
> >> fb3(); // comment3
> >> switch (x) { // comment4
> >> case 1:
> >> fb4(); // comment5
> >> break;
> >> default: // comment6
> >> break;
>
> >> }
> >> }
> >> }
>
> >> now we change the indent level to 3:
>
> >> {
> >> foobar1(); // comment1
> >> if (fb2()) { // comment2
> >> fb3(); // comment3
> >> switch (x) { // comment4
> >> case 1:
> >> fb4(); // comment5
> >> break;
> >> default: // comment6
> >> break;
>
> >> }
> >> }
> >> }
>
> >> Got the idea? If anyone wants to change the indent level, the code is
> >> ruined anyway.
> > No. I didn't say use only tabs. I said "use tabs only ***for leading
> > indent***". The distinction is very important. To align end of line
> > comments within a block, you use spaces. Not only does using space for
> > leading indent waste an excessive amount of space in source files with
> > relatively short lines and high levels of indent, it also forces
> > everyone viewing the file to use the indent level preferred by the
> > original author.
> > Brett Stahlman
> >> Simply use only space for indent solves all problem above, personally I
> >> do recommend not to use tab size other than 8 at all.
>
> Yes, and Shizu wrote that as soon as there are statements (such as an
> "if") with varying levels of indent within your block, your comments
> will move when you change the 'tabstop' setting.
What do you mean "the comments will move"? Comments within a single
block will not be affected at all by the change of tabstop, as the
tabstop change affects all lines within the block equally. Of course,
comments from different blocks will not be aligned, but you shouldn't
expect them to be. Consider that with the style you recommend below
(ts=8 and sts=4), you will have much worse problems than comments from
different blocks not aligning...
Brett S.
>
> Like him, I recommend leaving 'tabstop' at 8. If you want other levels
> of indent, you may for instance ":set sts=4 sw=4". And in some files
> that may be exported to systems (such as email) where tab stop settings
> are uncertain, I use 'expandtab' to replace my tabs by spaces as I type
> them.
>
> Best regards,
> Tony.
> --
> Burn's Hog Weighing Method:
> (1) Get a perfectly symmetrical plank and balance it across a
> sawhorse.
> (2) Put the hog on one end of the plank.
> (3) Pile rocks on the other end until the plank is again
> perfectly balanced.
> (4) Carefully guess the weight of the rocks.
> -- Robert Burns- Hide quoted text -
>
> - Show quoted text -
Brett Stahlman
evaporates!!! If everyone adheres to the rule (and you just stated
that such rules were necessary), then even comments in different
logical blocks will be aligned (though I still maintain that trying to
achieve alignment of comments in different logical blocks is a bit
silly). If there must be a standard within a collaborative coding
group, the standard of "tabs for leading indent" offers advantages
over the "spaces for indent" method without any corresponding
disadvantages. The source files will be smaller, but more importantly,
each programmer viewing the code (even ones within the collaborative
group) can view indents as whatever width he prefers. Setting ts=8 and
sw=(whatever you want) pretty much ensures that when someone with a
different setting tries to view the source, everything will be screwed
up unless he deduces what settings you used to create the file and
changes his own settings to match. Of course, this is possible (and
not overly difficult for a Vim user) but with "tabs for leading
indent", the file just looks right naturally. Why require special
effort when it's unnecessary. Of course, you can ensure that the code
will "look right" (according to your definition of rightness) by using
expandtab, but I would advise against it for 2 reasons:
1) expandtab forces everyone to view indents as you do. As we've
already seen, there are a lot of different ideas about the "proper"
width of an indent, and I would argue that there isn't (and doesn't
need to be) agreement on which one is correct.
2) expandtab can waste a lot of space, especially when ts=8 and there
are lots of nested indents.
The bottom line is, there are a lot of significant advantages to "tabs
only for leading indent", and so far, the only disadvantage I've heard
is that comments in different logical blocks wouldn't be aligned for
someone using a different tabstop setting. Considering that pretty
much *nothing* would be aligned (code included) if a file with ts=8
and sw=(whatever you like) is viewed with different settings, the
argument against tabs for leading indent seems pretty weak to me.
Brett S.
Brett Stahlman
On Dec 25, 9:31 pm, pansz <panshi...@routon.com> wrote:
> Richard Hartmann 写道:
>
> > And with tabs, people are a lot more flexible.
>
> > That as may be, let's agree to disagree.
>
> I agree it is good to be flexible.
>
> But by using hard tabs for indent you're *forcing* a non-standard
> tab-size, and you're forcing tab size to be the same as indent size. (In
> vim, that means you're forcing ts=sw)
spaces for leading indent so that people who don't like to view
indents as 8 spaces can keep their ts=8, rather than simply setting
their tabstop to match their viewing preferences. If it were not
possible to change tabstop to something other than 8, I can understand
why people would mix tabs and spaces for leading indent. Perhaps this
was the historical origin of the sw != ts stragegy. Are there still
editors in existence that hardcode a tabstop at 8 spaces? Granted, if
so, such a user might be forced to view an indent as 8 spaces, which
may be wider than he would prefer. (However, I would argue that
someone using an editor that doesn't support changing tabstop will be
used to putting up with all sorts of inconveniences;-) Perhaps the
argument against changing ts to match viewing preferences has to do
with the existence of legacy code? i.e., people who edit legacy code
and write new code want to be able to have the same settings for both?
If so, I understand the argument, but it just seems to me that mixing
tabs and spaces for leading indent was a solution to a problem
(inability to change tabstop from 8 spaces), which is a bit of a
historical anachronism, and it seems a shame to perpetuate this
solution now that the problem no longer exists and the "tab as
indentlevel" approach is much simpler and cleaner (and IIUC is the
only approach that ever would have been used if it weren't for the
hardcoded tabstop limitations of early editors). Is there still a
valid reason not to set ts=sw and set ts to match indent preferences?
Brett S.
>
> Indent size of 8 is too big for most programmers (except Linus Thorvald
> and some kernel hackers), if you use hard tabs for indent you *forced*
> that hard tab size should be the same as indent size and those people
> viewing your code will have to change the tab size to a smaller value in
> order to view your code more comfortably.
>
> If you do not use hard tabs in source code, we can still keep tab size
> as the standard 8 and view the code as indent size 4, since 4 spaces
> will always be 4 spaces. Keep tab-size as 8 does not mean I want to use
> shift-width or indent-size as 8, I use shift-width as 4 and keep
> tab-size to 8.
>
> Think considerably what is discouraging collaboration when you *force*
> other programmers to change the standard tabsize=8 into 4 just in order
> to view your code?
>
>
>
>
>
pansz
> with the existence of legacy code? i.e., people who edit legacy code
> and write new code want to be able to have the same settings for both?
> If so, I understand the argument, but it just seems to me that mixing
> tabs and spaces for leading indent was a solution to a problem
> (inability to change tabstop from 8 spaces),
of source codes, he will have to change the tab size from time to time
to read those who uses hard tabs with non-standard size. life would be
much easier if those sources use only spaces for indent.
Most text files uses tab-size as 8 and it is very common that a Linux
software source file contains not only C, thus it is heretical not to
keep ts=8. For Makefiles, assemblers, vim help files, and many script
languages of configuration files they have a standard tab-size=8, those
are not legacy code and ts=8 works perfect.
Only in C and C++ world there is a divergence, yes it is easy to change
the tab-size only for C, but if we must set ts=4 in 25% of C codes in
project X and ts=6 in 35% of C codes and ts=8 in the other 40% C codes
of project X things are really in a mess.
Richard Hartmann
> Yes, that is what I'm stating, for programmers who have to read all kind
> of source codes, he will have to change the tab size from time to time
> to read those who uses hard tabs with non-standard size. life would be
> much easier if those sources use only spaces for indent.
Either the file you are editing is broken (in which case your own style
guide would not help you either. Obviously, whoever created and
maintained it did not heed it) or tabs will work perfectly if used as
intended.
No one is stopping you from using a width of 8. The thing we object
to is that you are forcing _everyone else_ to use _your_ style. Sorry
to say so, but this makes you part of the problem the rest of us is
facing.
I am not saying you must change your ways and I sincerely hope
you did not take the above personally. I just do not
understand you or your reasoning.
Richard
Gene Kwiecinski
>guide would not help you either. Obviously, whoever created and
>maintained it did not heed it) or tabs will work perfectly if used as
>intended.
>No one is stopping you from using a width of 8. The thing we object
>to is that you are forcing _everyone else_ to use _your_ style. Sorry
>to say so, but this makes you part of the problem the rest of us is
>facing.
Agreed again. And if tabs "messing up" trailing comments is a huge
issue, then don't have trailing comments. Instead of
ptr += sizeof( foo ); // skip past header
use
// skip past header
ptr += sizeof( foo );
and be done with it.
I tend to do that for whole blocks vs individual lines, but hey, if
someone's so traumatised by different tabstops messing up alignment of
comments, the above's an easy fix...
But seriously, if someone uses some weird-ass indentation level like
ts=5 or whatnot, the *first* thing I do after "inheriting" the code is
either play games with ts=## and et/noet and try to get rid of it all
"cleanly", else do a global s&r for spaces and tabify 'em all, then
worry about stragglers and trailing comments later on.
Gene Kwiecinski
>>or the same coding style in the project anyway. At least the same
coding
>>style should be retained within one module. I see this to be a
>>reasonable rule.
>And with tabs, people are a lot more flexible.
Absolutely. And as for leading indentation, whether tabs or spaces
makes no difference to me, as I convert everything to tabs and ts=8
anyway. >:D
That being said, if I have lots of nesting going on and too many levels
means I start the line halfway across the screen, I'll stick a modeline
at the very end of the file that'll specify ts=4 or even ts=2, depending
how much of a rat's nest it happens to be.
As for hairy alignments to pretty-up an overly long conditional, etc.,
hey, if a few spaces can't preserve the alignment someone wants, then
just indent it to the next tablevel and leave the rest of us alone. I
object to someone "committing" a file to his/her own preferred style via
endless leading spaces with ts=3 or something, just so he/she can have a
nicely-aligned table of conditionals in an if() statement.
It's an *editor*, not a word-processor.