[ Originally filed by 'timnik' as http://www.reinteract.org/trac/ticket/19 ]

To repeat this bug open reinteract and type the following, then press ctrl+enter:

a_list = [

    1, 2, 3

]

a_dict = {

    'a': 1, 'b': 2, 'c': 3

}

a_tuple = (

    1, 2, 3

)

12/11/07 18:25:05 changed by timnik
===================================

    summary changed from "invalid syntax" on muliline tuple, dict or list syntax to "invalid syntax" on multiline tuple, dict or list syntax.

12/11/07 18:27:35 changed by timnik
===================================

I put a new line after each comma in the above example, but trac removed it for some reason. Either way, the bug is still reproducible even with the syntax as trac displays it.

12/11/07 19:14:41 changed by otaylor
====================================

This is basically "working as planned". Reinteract breaks the text into statements based on indentation, then parses each statement individually,

So, if you write

a_type = (
       1,
       2
   )

[ let's see if Trac likes this better with triple-curlies to indicate literal text ] Then it will be happy, but if the ) is in the first column, it will be a new statement.

My concern about changing this (other than in the simply way I described in ticket 18), is not that something matching Python's rules better is hard to implement. The token matching code is already there and used for autoindentation. The problem is that it's unstable: Whenever you typed open punctuation, the current statement would swallow up all the following text, then when you closed it, the statement breaking would fix itself again. Some attention to where the cursor is, history, etc, would help, but makes this a lot more complex and harder to test.

12/12/07 09:19:35 changed by otaylor
====================================

A further thought here ...what we could do is leave the statements broken as they are now when editing, but merge in following statements as necessary before compiling -- take advantage of the fact that the user has to explicitly trigger compilation.

This would work pretty well for paired-punctuation cases:

    Syntax highlighting doesn't depend on the line structure (though paren matching will break, without additional logic, which would be disturbing.)
    We can scan for the end based on the tokenized representation of subsequent lines
    The chances of a false positive is small 

However it works less well for strings

    Syntax highlighting will be wrong
    We'd have to write custom scanning code to find the end (not a big deal)
    There's a good chance of false-positives 

What I mean by the last, is that when you hit compile on:

string1 = """
Some Text
""

# Blah blah
# ... lots more code 
# Blah blah

string2 = """
another string
"""

You'd get a very long multiline string ending in 'string2 =' and then a syntax error on the subsequent part.

Doing this for paired punctuation and not for strings is of course possible - though the need to add the indents bothers me a little more for multiline strings.

09/07/08 19:53:52 changed by otaylor
====================================

Idea I had on multiline strings... what if the opening """ was made electric? So as soon as you typed """ it would insert another """ after the cursor (on the same line? on the next line?) While you could still trigger highlighting everything to the end of the buffer, you'd have to try harder to do so.