Matt Wozniski wrote:
> 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.
I don't think so ... I think I got it (though not the first time :) ) -
though, like I said, I could have it wrong too...
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.
> 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
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
