View mode: basic / threaded / horizontal-split · Log in · Help
April 12, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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.
April 12, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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.
April 12, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
> 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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
""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.
April 13, 2011
Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))
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
7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home