Indent lines that continue statements on previous lines #596

Open
totalgee opened this Issue Oct 10, 2012 · 7 comments

Comments

Projects
None yet
6 participants
Contributor

totalgee commented Oct 10, 2012

Sorry, I don't think the title does this one justice, but in SC OSX (3.5.5) the normal indent, when you were chaining a bunch of method calls on different lines, was something like this:

w = Window("Hello")
    .onClose_({
        "Window closed!".postln;
    })
    .setInnerExtent(450, 235)
    .front;

Now, in 3.6Alpha3 (on OS X 10.8.2), it gives this (whether using tabs or using Auto-indent from the Edit menu):

w = Window("Hello")
.onClose_({
    "Window closed!".postln;
})
.setInnerExtent(450, 235)
.front;

I find the older style, using an indent until we finish the entire statement, is much more readable.

Owner

jleben commented Oct 10, 2012

It would not be a trouble to implement this style of indentation per se, but the issue is that automatic indentation calculates indentation based on all the previous lines, which means any previous line not terminated in ';' would amount to larger indentation level.

Since it is most common in SC to evaluate individual statements, that are therefore not terminated with ';', this would have a very troublesome effect.

I propose to change automatic indentation to only take into account actual indentation level of a single previous line, and not all previous lines. That means that, if indentation of previous line was "wrong" (according to broader context) auto-indentation would also be "wrong" (according to same broader context). But I think this is the common way it is done in code editors, and is way more practical.

Contributor

totalgee commented Oct 10, 2012

What you propose sounds good, but right now it seems impossible to indent as you want, i.e. overriding what it does when you press tab. I've used plenty of editors that "suggest" where a new line should start, but then let you use 'tab' to change it. With the new IDE I can't seem to do that.

Glen.

On 10/10/2012, at 18:26, Jakob Leben notifications@github.com wrote:

It would not be a trouble to implement this style of indentation per se, but the issue is that automatic indentation calculates indentation based on all the previous lines, which means any previous line not terminated in ';' would amount to larger indentation level.

Since it is most common in SC to evaluate individual statements, that are therefore not terminated with ';', this would have a very troublesome effect.

I propose to change automatic indentation to only take into account actual indentation level of a single previous line, and not all previous lines. That means that, if indentation of previous line was "wrong" (according to broader context) auto-indentation would also be "wrong" (according to same broader context). But I think this is the common way it is done in code editors, and is way more practical.


Reply to this email directly or view it on GitHub.

Contributor

timblechmann commented Oct 11, 2012

you can shift-tab

Contributor

jamshark70 commented Oct 11, 2012

you can shift-tab

You can, but the next closing bracket of any shape will cause the editor to indent the line to the level it thinks is correct.

E.g., type:

Button(w, Rect(.....))

And here, I want to follow up with .states_(......), but I would like that to be indented one more level. So I shift-tab and start typing:

Button(w, Rect(.....))
    .states_([["GO"

... and I have just (re)confirmed, as soon as you type the closing bracket that's expected at this point, the manual shift-tab indentation is destroyed... so this is no solution at all.

The request is, correctly, for a change to the default indentation scheme.

Jakob:

It would not be a trouble to implement this style of indentation per se, but the issue is that automatic indentation calculates indentation based on all the previous lines, which means any previous line not terminated in ';' would amount to larger indentation level.

Hm, I guess the question is, what defines the completion of a statement? Is it only ";"?

It's only a continuation if the next thing is a method call:

SCButton(w, Rect(.....))
.states_([["GO"]])

1
+ 2

10
rrand: 20

But this would not be a continuation:

1 + 1
rrand(10, 20)  // neither .method or method:
Owner

jleben commented Oct 11, 2012

Note that we should auto-indent as soon as Return is pressed, not after starting to type the next line.
So, there's numerous valid cases of continuation, regarding what is the grammatical element before line break:

Rect
(...)

Rect.
new

Rect.new
()

Rect.new()
...

[1,2,3]
.scramble

{}
.play

1 +
2

1 rrand:
2

etc. etc. etc.

Well, there's just as many cases as there's different types of token :)

I think the only unambiguous way to determine completion of statement is ';'.

Otherwise, we should parse the code grammatically, and assume a new statement starts if including the previous line does not make a valid grammatical group. But even that I think is a risky assumption.

Owner

telephon commented Oct 11, 2012

I think the issue is also about how to deal with specific indentation that the user chose for a specific bit of code (for various reasons, readability, aesthetics, or whatever). If indentation shouldn't be a all or nothing feature, it should reckon with such choices. Perhaps suspend auto-indentation until the next syntactic unit has been closed?

On 11.10.2012, at 12:02, Jakob Leben notifications@github.com wrote:

Note that we should auto-indent as soon as Return is pressed, not after starting to type the next line.
So, there's numerous valid cases of continuation, regarding what is the grammatical element before line break:

Rect
(...)

Rect.
new

Rect.new
()

Rect.new()
...

[1,2,3]
.scramble

{}
.play

1 +
2

1 rrand:
2

etc. etc. etc.

Well, there's just as many cases as there's different types of token :)

I think the only unambiguous way to determine completion of statement is ';'.

Otherwise, we should parse the code grammatically, and assume a new statement starts if including the previous line does not make a valid grammatical group. But even that I think is a risky assumption.


Reply to this email directly or view it on GitHub.

Owner

jleben commented Apr 3, 2013

Changed title, removed "bug" label.

@scztt scztt modified the milestone: future Apr 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment