WIP: giving suggestions when unexpected indent happens #12
Conversation
when it can parse the beginning of a list item or map item after a map but with too much indentation, it will panic. on the way "out" it will register all possible indents it's backtracked over, so that we can give a list of suggestions for nested things this may also want to differentiate between indents registered for maps and for lists, so that it doesn't suggest to indent a list entry with the same amount as a map key, because that'd still be wrong.
Leont
changed the title
|
This sort of thing is very necessary. I wish it was prettier to implement though. I'm currently trying to reduce the amount of contextual variables, as it tends to lead to action-at-a-distance, I think this can be rewritten in such a way too. |
|
the problem i see is that we sometimes have to remember stuff from the last leaf of the tree so far, and having state in the grammar's class is not so easy because of backtracking; our code blocks inside the regexes could be run any number of times, and the parser can back off over them without telling us. that's why i came up with the thing that'll remember the latest position of a newline + indent we've seen and clears the list of suggestions when we have advanced somehow. of course there's the problem i mentioned in the commit that we don't get to see "shorter" suggested indents, because we don't go back up far enough in the parse tree before exploding. perhaps the way to make this work is to only actually call the panic method when we're currently in a regex belonging to a 0-spaces-indent match? how do you suggest we partition this task among us? |
|
FWIW, i can tear out the whole suggestion mechanism and it'll still give a much better error message as before, i.e. it'll tell you that an indent was wrong, and it'll tell you what line it was at. would that be fine for merging immediately? |
I guess. Possibly my problem is that I don't fully understand your code; tests may be helpful here. |
when it can parse the beginning of a list item or map item after
a map but with too much indentation, it will panic. on the way "out"
it will register all possible indents it's backtracked over, so that
we can give a list of suggestions for nested things
this may also want to differentiate between indents registered for
maps and for lists, so that it doesn't suggest to indent a list entry
with the same amount as a map key, because that'd still be wrong.
i'm not actually suggesting this to be pulled right away, i'd like to have a discussion first :)