you could try to fix content assist but this might be even more work than introducing the additional rules as i suggested before.
Update: i dont know if there is a nice place to hook into content assist maybe
could serve as starting point.
Edwin Tuzar Messages: 33 Registered: April 2013 Location: Kaiserslautern
in the additional rules is a flaw imagine that you have the following use case: b i <<here>> /i /b or i b <<here>> /b /i
at <<here>> i can add again b (or i) and /b (or /i) that I don't want. This assuming what you proposed plus:
Sorry i dont know any out of the box solutions for this usecase.
and you are right the rules might explode.
unfortunately ParserBasedContentAssistContextFactory does not seem to have nice hooks for filtering.
and i dont know how easy skipping elements works on later states. (org.eclipse.xtext.ui.editor.contentassist.AbstractContentProposalProvider.createProposals(ContentAssistContext, ICompletionProposalAcceptor))
or even later.
You could write a separate rule for elements that can appear inside a
'Bold'. I would not recommend this, as the user would get an error from
the parser (unexpected token) instead of a helpful message (e.g. 'bold
not allowed within bold'). So rather be generous in the grammar and
cover these constraints with validation rules.
Am 20.06.13 16:47, schrieb Edwin Tuzar:
> So I have the following rules:
> BinaryElements | Image | Link | Text
> Bold | Italic | Underline | Paragraph
> now I want for Bold to do the following:
> 'b' (htmlaccelement+=HtmlAcceptedElement)+ '/b'
> but I want to don't allow Bold rule to be inside this:
> (htmlaccelement+=HtmlAcceptedElement)+ is this possible? to say somehow
> HtmlAcceptedElement except Bold ?
> Thanks in advance!
> Best regards,