Can LU parser parse with syntax error file?

[zhixzhan]

Is your feature request related to a problem? Please describe.

In inline lu editor, final content is make up from luParser function looks like,

luFile.updateSection(content)

but when content have some syntax error, it would failed.

more precisely:

1. when content have syntax error, this function call won't success.
2. when luFile have syntax error, both parse/update would failed.

Describe the solution you'd like

So can LU parser handle those better? for example,

1. Can parse file if it's not a fatal syntax error.
2. Can updateSection(invalidContent), and wrap/encode invalidContent to be valid.
   3, Ensure update function's return always can be parse.

Describe alternatives you've considered

Currently lg parser looks like can handle most syntax error.

Additional context

[zhixzhan]

@feich-ms please take a look here

[hibrenda]

#2242
#2141

[feich-ms]

Fixed in bf-lu package side. Zhixiang can take action on composer side once the nightly package is built.

[zhixzhan]

Hi Fei, I tried last day build, it fixed a lot. here I get some additional updates.

Image a common usage flow looks like:

parse ->
update(syntax error) -> lu file now with error
update(syntax good) -> lu file should be fix
parse

Compares first parse to last parse, the suppose parse result to be :

1. Sections's count is same
2. Error's increment is restrict on updated section

I follow this rules made test below:

Test case 1: missing - in body

parse:

#CheckEmail
- check my email
- show my emails

update with body:

check my email
- show my emails

get:

#CheckEmail
check my email
- show my emails

update with body:

- check my email
- show my emails

get:

#CheckEmail
- check my email
- show my emails

Cheers! All operation are reversible.

Test case 2: end with empty entity @ in body

parse:

#CheckEmail
- check my email
- show my emails

update with body:

- check my email
- show my emails
@

get:

#CheckEmail
check my email
- show my emails
@

continue update with body:

- check my email
- show my emails

get:

#CheckEmail
- check my email
- show my emails
@

Sad, the last @ is not treated to be part of updated section, when do another update, nothing can will be fix.
I prefer treat all text before next #SectionName is current section's body

Test case 3: include # IntentName in body

parse:

#CheckEmail
- check my email
- show my emails

update with body:

- check my email
- show my emails

#UnexpectedIntentDefination. // should not be allowed
- unexpected intent body

get:

#CheckEmail
check my email
- show my emails

#UnexpectedIntentDefination
- unexpected intent body

Here we suppose to update #CheckEmail, but the result turn out to be add another section.
Suggestion:

1. throw error
2. encode input tobe a valid body e.g

## UnexpectedIntentDefination
- unexpected intent body

[zhixzhan]

Another issue I want bring up here is does the position of entity decide which section it belongs ?

When parse a lu document, it contains comments and entity, they can appears in the top of file, buttom of file, or inside a intent.

@ list orders         // it is global ? [Fei: yes]

> Sample for nested section
# CheckTodo
## CheckUnreadTodo
- check my unread todo
- show my unread todos

> if I comments here.    // is it include by body ? [Fei: Yes, comments are only kept in Body and skipped if it is between any intents or global entities]
@ simple todoTitle.       // is it include by body ? [Fei: Yes, it's content belongs to this simple intent section CheckUnreadTodo, but it can be referred in any intents]

## CheckDeletedTodo
- check my deleted todo
- show my deleted todos

@ simple todoSubject

> Help intent and related utterances.
# Help
- What can I say? 
- Who are you?

[feich-ms]

For test case 2, I will try to find a solution. For test case 3, I will throw a error for such case.