Nick Sabalausky wrote:
> So I've changed my style to this:
>
> if(blah)
> {
> ->  foo(
> ->  ->  bigLongArg1,
> ->  ->  bigLongArg2,
> ->  ->  bigLongArg3
> ->  );
> }

That's something I've started doing too. It's not just a matter of alignment either - I think the first argument on the same line as the function name is easy to miss. It all blends in together.

Nick Sabalausky Wrote:

> So I've changed my style to this:
> 
> if(blah)
> {
> ->  foo(
> ->  ->  bigLongArg1,
> ->  ->  bigLongArg2,
> ->  ->  bigLongArg3
> ->  );
> }
> 
> Much better. Of course, it would be even better still if Scintilla would be willing to add elastic tabstops (I'm getting increasingly annoyed that it doesn't, and that it doesn't even seem receptive to the idea, for technical reasons), because then I *could* do exactly what I used to with absolutely no problem:

Scintilla has 3 word wrapping modes, so long lines should not be a problem.

On 04/12/2011 10:08 PM, Nick Sabalausky wrote:
> ""Jérôme M. Berger""<jeberger@free.fr>  wrote in message
> news:io2396$1nuo$1@digitalmars.com...
>> spir wrote:
>>>
>>> A drawback is one cannot directly have different indent levels, for
>>> instance to indent collection contents more, or less, than blocks of
>>> code. This can also be considered an advantage; and is simply solved by
>>> using... spaces ;-)
>>>
>>> void f () {
>>>   ->  while (true) {
>>>   ->   ->  table = [
>>>   ->   ->  .."aaa" : 1,
>>>   ->   ->  .."bbb" : 2,
>>>   ->   ->  .."ccc" : 3,
>>>   ->   ->  ];
>>>   ->   ->  auto a = this(table);
>>>   ->   ->  if (! a) break;
>>>   ->  }
>>> }
>>>
>>> (yes, the example is stupid)
>>>
>> Unfortunately, most editors are completely unable to handle this
>> example properly: sure they will *display* it fine, but they will
>> not allow you to *enter* it right (especially if you need more
>> spaces for alignment than the tab size).
>>
>
> That's unfortunately true.

Strange... did not know that, but I have only used geany for a while already.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

> On 2011-04-12 05:19, Jonathan M Davis wrote:
> >> On 04/11/2011 08:13 AM, Jonathan M Davis wrote:
> >>> They mix tabs and spaces. On some lines, they use spaces and on others they use tabs.
> >> 
> >> Never seen this, not even once. Messing can only happen when one copy-pastes from modules using spaces.
> > 
> > As Steve pointed out, it frequently happens when you have multiple developers working on the same code. It may work with one developer who likes using tabs, but as soon as you get a mix of developers, you invariably get a mix of spaces and tabs unless _everyone_ involved is really careful, and that rarely happens. It's just too easy to use spaces without realizing that someone else used tabs or even that you yourself are using spaces, depending on your editor's settings.
> 
> How can it not be as easy to use tabs without realizing that someone else used spaces?

Oh, it can be. But what generally happens in environments where spaces are required is that everyone sets up their editors to insert spaces when you hit the tab key instead of a tab (if everyone is using a common IDE, it's probably even required), so it becomes pretty much impossible to enter tabs by accident, whereas in an environment where tabs are used, you're not going to disable the spacebar, so spaces can still be inserted. So, generally, in a spaces-only environment, you don't run into problems with tabs.

- Jonathan M Davis

On 11/04/2011 20:54, Steven Schveighoffer wrote:
> In most of the editors I use, the default is to use spaces for
> indentation.  So what happens is someone opens a file that uses tabs for
> indentation, then adds some lines.  However, their editor only uses
> spaces *for those lines they added*, which results in a hybrid.
> However, the person editing doesn't notice because it all lines up on
> their screen.

Just FYI, in Eclipse, the auto-indentation that happen when you press Enter will use the indentation from the previous line (whether it's spaces, tabs, or even mixed).
However, other editing operations that generate lines of code (like code templates, auto-generated code, refactorings like extracting a method, etc.) are not so smart and will indent with according to the default indentation you specify in the settings, they won't look at how the file is already indented.


-- 
Bruno Medeiros - Software Engineer

On 11/04/2011 22:03, David Gileadi wrote:
> On 4/11/11 1:51 PM, "Jérôme M. Berger" wrote:
>> Nick Sabalausky wrote:
>>> "Andrej Mitrovic"<andrej.mitrovich@gmail.com> wrote in message
>>> news:mailman.3396.1302548836.4748.digitalmars-d@puremagic.com...
>>>> Smart editors also allow you to unindent with a single backspace
>>>> regardless if you're using tabs or spaces.
>>>
>>> In other words, *some* editors handle space-indentation intelligently
>>> (and
>>> do so by reinventing *tabs*), while *all* editors handle tab-indentation
>>> intelligently.
>>>
>> I have seen editors that would convert a tab to spaces and only
>> delete one space when hitting backspace ;)
>>
>> Jerome
>
> Eclipse, I'm looking at you!

In Eclipse you can press Shift-Tab to reduce the indentation by one level, regardless of whether it's using spaces or tabs. This also works if you have multiple lines of code selected in the editor. (so if you have 4 spaces of indentation and you press Shift-Tab anywhere on the line it will delete those 4 spaces, assuming you configured a level of indentation to be 4 spaces (that's usually the default though))

-- 
Bruno Medeiros - Software Engineer

On 12/04/2011 21:08, Nick Sabalausky wrote:
> ""Jérôme M. Berger""<jeberger@free.fr>  wrote in message
> news:io2396$1nuo$1@digitalmars.com...
>> spir wrote:
>>>
>>> A drawback is one cannot directly have different indent levels, for
>>> instance to indent collection contents more, or less, than blocks of
>>> code. This can also be considered an advantage; and is simply solved by
>>> using... spaces ;-)
>>>
>>> void f () {
>>>   ->  while (true) {
>>>   ->   ->  table = [
>>>   ->   ->  .."aaa" : 1,
>>>   ->   ->  .."bbb" : 2,
>>>   ->   ->  .."ccc" : 3,
>>>   ->   ->  ];
>>>   ->   ->  auto a = this(table);
>>>   ->   ->  if (! a) break;
>>>   ->  }
>>> }
>>>
>>> (yes, the example is stupid)
>>>
>> Unfortunately, most editors are completely unable to handle this
>> example properly: sure they will *display* it fine, but they will
>> not allow you to *enter* it right (especially if you need more
>> spaces for alignment than the tab size).
>>
>

Why would editors not allow you to enter that right? I don't see what the problem would be, unless you configured your editor to replaces N spaces into a tab for indentation.


> That's unfortunately true. I used to try to do that in cases like this:
>
> if(blah)
> {
> ->   foo(.bigLongArg1,
> ->   .....bigLongArg2,
> ->   .....bigLongArg3
> ->   );
> }
>
> But editors just choke on that like crazy. It's a pain to type it in that
> way, and then when you go back to edit (add another arg on another line, for
> instance), it just screws it all up again, likely without me even noticing
> right away. (And I even have most auto-formatting turned off.) I decided it
> was far more trouble than it was worth.
>

Works fine in Eclipse, again because when it auto-indents on Enter, it uses the indentation of the previous line. :)

-- 
Bruno Medeiros - Software Engineer

Nick Sabalausky wrote:
> ""J�r�me M. Berger"" <jeberger@free.fr> wrote in message news:io230l$1ldc$3@digitalmars.com...
>> Well, I have worked in both environments, and I have seen a lot more mess ups with tabs than with spaces... Other than that (and the fact that almost *no* editors are able to do it properly), I would really prefer "tabs for indent, spaces for align".
> 
> I prefer "tabs for indent, tabs for align, spaces for separation", but that requires elastic tabstops. And at least one of the biggest code-edit controls out there (the one I use), Scintilla, doesn't support them :(
> 
> 
	That depends what you mean by "align". I agree that for the
following, elastic tab stops would be best:

int      a;
SomeType b;

	However, for this, I think that spaces are better:

doSomething (someLongParameterThatJustifiesBreakingTheLine,
             someOtherLongParameterJustInCase);

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

""Jérôme M. Berger"" <jeberger@free.fr> wrote in message news:io4sng$1p9b$1@digitalmars.com...
>Nick Sabalausky wrote:
>> ""J?r?me M. Berger"" <jeberger@free.fr> wrote in message news:io230l$1ldc$3@digitalmars.com...
>>> Well, I have worked in both environments, and I have seen a lot more mess ups with tabs than with spaces... Other than that (and the fact that almost *no* editors are able to do it properly), I would really prefer "tabs for indent, spaces for align".
>>
>> I prefer "tabs for indent, tabs for align, spaces for separation", but
>> that
>> requires elastic tabstops. And at least one of the biggest code-edit
>> controls out there (the one I use), Scintilla, doesn't support them :(
>>
>>
> That depends what you mean by "align". I agree that for the
>following, elastic tab stops would be best:
>
>int      a;
>SomeType b;
>
> However, for this, I think that spaces are better:
>
>doSomething (someLongParameterThatJustifiesBreakingTheLine,
>             someOtherLongParameterJustInCase);

I guess we disagree on that. Like I said in another branch, I used to do that, but then I found that mixing tabs/spaces before the first non-whitespace on a line is just asking for trouble.

I'd rather do it like this (assuming elastic tabstops):

doSomething(->someLongParameterThatJustifiesBreakingTheLine, ->            someOtherLongParameterJustInCase);

Of course, that does demonstrate that I've never liked putting any whitespace between a function name (or if/while/etc.) and the opening paren. YMMV.

Nick Sabalausky wrote:
> ""J�r�me M. Berger"" <jeberger@free.fr> wrote in message news:io4sng$1p9b$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> ""J?r?me M. Berger"" <jeberger@free.fr> wrote in message news:io230l$1ldc$3@digitalmars.com...
>>>> Well, I have worked in both environments, and I have seen a lot more mess ups with tabs than with spaces... Other than that (and the fact that almost *no* editors are able to do it properly), I would really prefer "tabs for indent, spaces for align".
>>> I prefer "tabs for indent, tabs for align, spaces for separation", but
>>> that
>>> requires elastic tabstops. And at least one of the biggest code-edit
>>> controls out there (the one I use), Scintilla, doesn't support them :(
>>>
>>>
>> That depends what you mean by "align". I agree that for the following, elastic tab stops would be best:
>>
>> int      a;
>> SomeType b;
>>
>> However, for this, I think that spaces are better:
>>
>> doSomething (someLongParameterThatJustifiesBreakingTheLine,
>>             someOtherLongParameterJustInCase);
> 
> I guess we disagree on that. Like I said in another branch, I used to do that, but then I found that mixing tabs/spaces before the first non-whitespace on a line is just asking for trouble.
> 
	Yes, that is the main reason why I use spaces for indenting...

> I'd rather do it like this (assuming elastic tabstops):
> 
> doSomething(->someLongParameterThatJustifiesBreakingTheLine, ->            someOtherLongParameterJustInCase);
> 
> Of course, that does demonstrate that I've never liked putting any whitespace between a function name (or if/while/etc.) and the opening paren. YMMV.
> 
	Well, standard (printed) typographic practices put spaces outside
the parenthesis and none inside. And as opposed to a lot of
typographic rules, that one is a constant across languages and variants.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr