Home » Modeling » TMF (Xtext) » [Xtext] Enabling user customization for formatting
| [Xtext] Enabling user customization for formatting [message #665524] |
Thu, 14 April 2011 21:30  |
Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
Hi,
We currently have some built-in formatting in our Xtext based editor, but
are looking at providing user level customization for formatting. We are
creating a Formatter preference page where users can specify custom
formatting options such as maximum line width (line wrap), whether the
opening braces should be on the same line or next line, etc.
The question I have is -- what's the best way to apply end user
customizations? From what I can tell, the
configureFormatting(FormattingConfig) method in the
AbstractDeclarativeFormatter gets called initially to configure the
formatting options. When the formatting options change (in the preference
page), what is the best way to reconfigure the FormattingConfig with the new
options? I tried getting a handle to the FormattingConfig and setting the
new options, but that does not seem to work because the previous settings
governing the same objects/keywords have not been cleared (and setting the
new options does not override previous settings). I don't see any good way
of clearing previous setting and setting the new options (without
reconfiguring everything).
Any hint or comments will be appreciated.
Thanks!
Mary
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #665535 is a reply to message #665524] |
Fri, 15 April 2011 00:18  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The AbstractDeclarativeFormatter has this inside...
@Singleton
protected static class ConfigStore {
protected FormattingConfig config;
}
You could try to just set the config to null when it needs to be
recomputed, the code seems to handle that - but I have no idea if that
does what you want... try it in the debugger and see if it reloads nicely.
- henrik
On 4/14/11 11:30 PM, Mary K wrote:
> Hi,
>
> We currently have some built-in formatting in our Xtext based editor,
> but are looking at providing user level customization for formatting. We
> are creating a Formatter preference page where users can specify custom
> formatting options such as maximum line width (line wrap), whether the
> opening braces should be on the same line or next line, etc.
>
> The question I have is -- what's the best way to apply end user
> customizations? From what I can tell, the
> configureFormatting(FormattingConfig) method in the
> AbstractDeclarativeFormatter gets called initially to configure the
> formatting options. When the formatting options change (in the
> preference page), what is the best way to reconfigure the
> FormattingConfig with the new options? I tried getting a handle to the
> FormattingConfig and setting the new options, but that does not seem to
> work because the previous settings governing the same objects/keywords
> have not been cleared (and setting the new options does not override
> previous settings). I don't see any good way of clearing previous
> setting and setting the new options (without reconfiguring everything).
>
> Any hint or comments will be appreciated.
>
> Thanks!
>
> Mary
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #665547 is a reply to message #665535] |
Fri, 15 April 2011 04:27 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
I can't set the FormattingConfig in AbstractDeclarativeFormatter to null...
I would have to override the ConfigStore -- i.e have my own ConfigStore,
which will give me my own FormattingConfig, which I can then set to null. I
would also have to override getConfig() to make sure that my
FormattingConfig is being returned. That's quite a bit of hack though. It
would have been nice to just get the existing FormattingConfig and reset
some of the options.
Anyway, I did try this out and it *seems* to work... but not quite. After I
set the FormattingConfig to null, it seems that when I run the format
(FormattingConfig gets recreated with new options), previous settings are
remembered and applied. I tried a very simple sequence of
- FormattingConfig.setLineWrap(2).after(Keyword)
- run the format, observe that it does the line wrap with the specified
number of lines
- set FormattingConfig to null
- FormattingConfig.setLineWrap().after(Keyword)
- run the format. I expected the file to be reformatted to only have single
line wraps, but the format insisted on still inserting two line wraps.
I'm not sure where the previous option is being remembered. As far as I can
tell from the debugger, the locatorsSemantic list in the new
FormattingConfig only has one entry with the new setting.
Mary
"Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
news:io82em$pg4$1@news.eclipse.org...
> The AbstractDeclarativeFormatter has this inside...
> @Singleton
> protected static class ConfigStore {
> protected FormattingConfig config;
> }
>
> You could try to just set the config to null when it needs to be
> recomputed, the code seems to handle that - but I have no idea if that
> does what you want... try it in the debugger and see if it reloads nicely.
>
> - henrik
>
> On 4/14/11 11:30 PM, Mary K wrote:
>> Hi,
>>
>> We currently have some built-in formatting in our Xtext based editor,
>> but are looking at providing user level customization for formatting. We
>> are creating a Formatter preference page where users can specify custom
>> formatting options such as maximum line width (line wrap), whether the
>> opening braces should be on the same line or next line, etc.
>>
>> The question I have is -- what's the best way to apply end user
>> customizations? From what I can tell, the
>> configureFormatting(FormattingConfig) method in the
>> AbstractDeclarativeFormatter gets called initially to configure the
>> formatting options. When the formatting options change (in the
>> preference page), what is the best way to reconfigure the
>> FormattingConfig with the new options? I tried getting a handle to the
>> FormattingConfig and setting the new options, but that does not seem to
>> work because the previous settings governing the same objects/keywords
>> have not been cleared (and setting the new options does not override
>> previous settings). I don't see any good way of clearing previous
>> setting and setting the new options (without reconfiguring everything).
>>
>> Any hint or comments will be appreciated.
>>
>> Thanks!
>>
>> Mary
>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666279 is a reply to message #665547] |
Tue, 19 April 2011 17:30 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
Still struggling with this and would really like to have some guidance from
the Xtext team whether this is even possible. Is it possible to reset/change
the formatting after the initial configuration?
It seems to me that an AbstractElement has a MatcherState that keeps track
of all the patterns (e.g. linewraps, etc) that have been applied to the
element. So, if a noLineWrap has been previously applied/installed on the
element, then further linewrap patterns will not have any affect. Is my
understanding correct? Is it possible to "reset" previous states?
By the way, I'm using Xtext 1.02 and need to stay on this version for now.
Any suggestion or recommendation will be greatly appreciated.
Mary
"Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
news:io8h25$bvi$1@news.eclipse.org...
> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
> null... I would have to override the ConfigStore -- i.e have my own
> ConfigStore, which will give me my own FormattingConfig, which I can then
> set to null. I would also have to override getConfig() to make sure that
> my FormattingConfig is being returned. That's quite a bit of hack though.
> It would have been nice to just get the existing FormattingConfig and
> reset some of the options.
>
> Anyway, I did try this out and it *seems* to work... but not quite. After
> I set the FormattingConfig to null, it seems that when I run the format
> (FormattingConfig gets recreated with new options), previous settings are
> remembered and applied. I tried a very simple sequence of
> - FormattingConfig.setLineWrap(2).after(Keyword)
> - run the format, observe that it does the line wrap with the specified
> number of lines
> - set FormattingConfig to null
> - FormattingConfig.setLineWrap().after(Keyword)
> - run the format. I expected the file to be reformatted to only have
> single line wraps, but the format insisted on still inserting two line
> wraps.
>
> I'm not sure where the previous option is being remembered. As far as I
> can tell from the debugger, the locatorsSemantic list in the new
> FormattingConfig only has one entry with the new setting.
>
> Mary
>
> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
> news:io82em$pg4$1@news.eclipse.org...
>> The AbstractDeclarativeFormatter has this inside...
>> @Singleton
>> protected static class ConfigStore {
>> protected FormattingConfig config;
>> }
>>
>> You could try to just set the config to null when it needs to be
>> recomputed, the code seems to handle that - but I have no idea if that
>> does what you want... try it in the debugger and see if it reloads
>> nicely.
>>
>> - henrik
>>
>> On 4/14/11 11:30 PM, Mary K wrote:
>>> Hi,
>>>
>>> We currently have some built-in formatting in our Xtext based editor,
>>> but are looking at providing user level customization for formatting. We
>>> are creating a Formatter preference page where users can specify custom
>>> formatting options such as maximum line width (line wrap), whether the
>>> opening braces should be on the same line or next line, etc.
>>>
>>> The question I have is -- what's the best way to apply end user
>>> customizations? From what I can tell, the
>>> configureFormatting(FormattingConfig) method in the
>>> AbstractDeclarativeFormatter gets called initially to configure the
>>> formatting options. When the formatting options change (in the
>>> preference page), what is the best way to reconfigure the
>>> FormattingConfig with the new options? I tried getting a handle to the
>>> FormattingConfig and setting the new options, but that does not seem to
>>> work because the previous settings governing the same objects/keywords
>>> have not been cleared (and setting the new options does not override
>>> previous settings). I don't see any good way of clearing previous
>>> setting and setting the new options (without reconfiguring everything).
>>>
>>> Any hint or comments will be appreciated.
>>>
>>> Thanks!
>>>
>>> Mary
>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666315 is a reply to message #666279] |
Tue, 19 April 2011 20:43 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Mary,
sorry, your question somehow slipped through my unread message queue.
Setting the formatting config to null should work. That is, it is
perfectly ok to extend the ConfigStore and set this one back to null.
However, the AbstractElements hold an EMF Adapter that caches some
information. When you try to reset the formatting config, you'll have to
traverse the grammar (can be obtained from the IGrammarAccess) and
remove any adapter that fulfill the interface INFAState.
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 19.04.11 19:30, schrieb Mary K:
> Still struggling with this and would really like to have some guidance
> from the Xtext team whether this is even possible. Is it possible to
> reset/change the formatting after the initial configuration?
>
> It seems to me that an AbstractElement has a MatcherState that keeps
> track of all the patterns (e.g. linewraps, etc) that have been applied
> to the element. So, if a noLineWrap has been previously
> applied/installed on the element, then further linewrap patterns will
> not have any affect. Is my understanding correct? Is it possible to
> "reset" previous states?
>
> By the way, I'm using Xtext 1.02 and need to stay on this version for now.
>
> Any suggestion or recommendation will be greatly appreciated.
>
> Mary
>
> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
> news:io8h25$bvi$1@news.eclipse.org...
>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>> null... I would have to override the ConfigStore -- i.e have my own
>> ConfigStore, which will give me my own FormattingConfig, which I can
>> then set to null. I would also have to override getConfig() to make
>> sure that my FormattingConfig is being returned. That's quite a bit of
>> hack though. It would have been nice to just get the existing
>> FormattingConfig and reset some of the options.
>>
>> Anyway, I did try this out and it *seems* to work... but not quite.
>> After I set the FormattingConfig to null, it seems that when I run the
>> format (FormattingConfig gets recreated with new options), previous
>> settings are remembered and applied. I tried a very simple sequence of
>> - FormattingConfig.setLineWrap(2).after(Keyword)
>> - run the format, observe that it does the line wrap with the
>> specified number of lines
>> - set FormattingConfig to null
>> - FormattingConfig.setLineWrap().after(Keyword)
>> - run the format. I expected the file to be reformatted to only have
>> single line wraps, but the format insisted on still inserting two line
>> wraps.
>>
>> I'm not sure where the previous option is being remembered. As far as
>> I can tell from the debugger, the locatorsSemantic list in the new
>> FormattingConfig only has one entry with the new setting.
>>
>> Mary
>>
>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>> news:io82em$pg4$1@news.eclipse.org...
>>> The AbstractDeclarativeFormatter has this inside...
>>> @Singleton
>>> protected static class ConfigStore {
>>> protected FormattingConfig config;
>>> }
>>>
>>> You could try to just set the config to null when it needs to be
>>> recomputed, the code seems to handle that - but I have no idea if
>>> that does what you want... try it in the debugger and see if it
>>> reloads nicely.
>>>
>>> - henrik
>>>
>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>> Hi,
>>>>
>>>> We currently have some built-in formatting in our Xtext based editor,
>>>> but are looking at providing user level customization for
>>>> formatting. We
>>>> are creating a Formatter preference page where users can specify custom
>>>> formatting options such as maximum line width (line wrap), whether the
>>>> opening braces should be on the same line or next line, etc.
>>>>
>>>> The question I have is -- what's the best way to apply end user
>>>> customizations? From what I can tell, the
>>>> configureFormatting(FormattingConfig) method in the
>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>> formatting options. When the formatting options change (in the
>>>> preference page), what is the best way to reconfigure the
>>>> FormattingConfig with the new options? I tried getting a handle to the
>>>> FormattingConfig and setting the new options, but that does not seem to
>>>> work because the previous settings governing the same objects/keywords
>>>> have not been cleared (and setting the new options does not override
>>>> previous settings). I don't see any good way of clearing previous
>>>> setting and setting the new options (without reconfiguring everything).
>>>>
>>>> Any hint or comments will be appreciated.
>>>>
>>>> Thanks!
>>>>
>>>> Mary
>>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666329 is a reply to message #666315] |
Tue, 19 April 2011 22:27 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
Sebastian, thanks for your response.
I did try removing the adapter (MatcherState) for the AbstractElement, but
that is apparently not sufficient. Still does not work. There seems to be a
TransitionMatcher that seems to be holding on to some stale information...
still debugging into the bowels of Xtext... making very slow progress.
If you have any additional recommendation, it will definitely help! I'm
still painstakingly stepping through a lot of code trying to figure out why
this is not working...
Mary
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:iokri5$er9$1@news.eclipse.org...
> Hi Mary,
>
> sorry, your question somehow slipped through my unread message queue.
>
> Setting the formatting config to null should work. That is, it is
> perfectly ok to extend the ConfigStore and set this one back to null.
> However, the AbstractElements hold an EMF Adapter that caches some
> information. When you try to reset the formatting config, you'll have to
> traverse the grammar (can be obtained from the IGrammarAccess) and remove
> any adapter that fulfill the interface INFAState.
>
> Hope that helps,
> Sebastian
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
> Am 19.04.11 19:30, schrieb Mary K:
>> Still struggling with this and would really like to have some guidance
>> from the Xtext team whether this is even possible. Is it possible to
>> reset/change the formatting after the initial configuration?
>>
>> It seems to me that an AbstractElement has a MatcherState that keeps
>> track of all the patterns (e.g. linewraps, etc) that have been applied
>> to the element. So, if a noLineWrap has been previously
>> applied/installed on the element, then further linewrap patterns will
>> not have any affect. Is my understanding correct? Is it possible to
>> "reset" previous states?
>>
>> By the way, I'm using Xtext 1.02 and need to stay on this version for
>> now.
>>
>> Any suggestion or recommendation will be greatly appreciated.
>>
>> Mary
>>
>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>> news:io8h25$bvi$1@news.eclipse.org...
>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>> null... I would have to override the ConfigStore -- i.e have my own
>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>> then set to null. I would also have to override getConfig() to make
>>> sure that my FormattingConfig is being returned. That's quite a bit of
>>> hack though. It would have been nice to just get the existing
>>> FormattingConfig and reset some of the options.
>>>
>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>> After I set the FormattingConfig to null, it seems that when I run the
>>> format (FormattingConfig gets recreated with new options), previous
>>> settings are remembered and applied. I tried a very simple sequence of
>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>> - run the format, observe that it does the line wrap with the
>>> specified number of lines
>>> - set FormattingConfig to null
>>> - FormattingConfig.setLineWrap().after(Keyword)
>>> - run the format. I expected the file to be reformatted to only have
>>> single line wraps, but the format insisted on still inserting two line
>>> wraps.
>>>
>>> I'm not sure where the previous option is being remembered. As far as
>>> I can tell from the debugger, the locatorsSemantic list in the new
>>> FormattingConfig only has one entry with the new setting.
>>>
>>> Mary
>>>
>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>> news:io82em$pg4$1@news.eclipse.org...
>>>> The AbstractDeclarativeFormatter has this inside...
>>>> @Singleton
>>>> protected static class ConfigStore {
>>>> protected FormattingConfig config;
>>>> }
>>>>
>>>> You could try to just set the config to null when it needs to be
>>>> recomputed, the code seems to handle that - but I have no idea if
>>>> that does what you want... try it in the debugger and see if it
>>>> reloads nicely.
>>>>
>>>> - henrik
>>>>
>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>> Hi,
>>>>>
>>>>> We currently have some built-in formatting in our Xtext based editor,
>>>>> but are looking at providing user level customization for
>>>>> formatting. We
>>>>> are creating a Formatter preference page where users can specify
>>>>> custom
>>>>> formatting options such as maximum line width (line wrap), whether the
>>>>> opening braces should be on the same line or next line, etc.
>>>>>
>>>>> The question I have is -- what's the best way to apply end user
>>>>> customizations? From what I can tell, the
>>>>> configureFormatting(FormattingConfig) method in the
>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>> formatting options. When the formatting options change (in the
>>>>> preference page), what is the best way to reconfigure the
>>>>> FormattingConfig with the new options? I tried getting a handle to the
>>>>> FormattingConfig and setting the new options, but that does not seem
>>>>> to
>>>>> work because the previous settings governing the same objects/keywords
>>>>> have not been cleared (and setting the new options does not override
>>>>> previous settings). I don't see any good way of clearing previous
>>>>> setting and setting the new options (without reconfiguring
>>>>> everything).
>>>>>
>>>>> Any hint or comments will be appreciated.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Mary
>>>>
>
>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666359 is a reply to message #666329] |
Wed, 20 April 2011 05:51 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
In my previous post, I said TransitionMatcher in error. It should be
MatcherTransition. (And yes, they are both valid class names in the
org.eclipse.xtext.formatting.impl package! :-} )
Mary
"Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
news:iol1r0$nof$1@news.eclipse.org...
> Sebastian, thanks for your response.
>
> I did try removing the adapter (MatcherState) for the AbstractElement, but
> that is apparently not sufficient. Still does not work. There seems to be
> a TransitionMatcher that seems to be holding on to some stale
> information... still debugging into the bowels of Xtext... making very
> slow progress.
>
> If you have any additional recommendation, it will definitely help! I'm
> still painstakingly stepping through a lot of code trying to figure out
> why this is not working...
>
> Mary
>
> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
> news:iokri5$er9$1@news.eclipse.org...
>> Hi Mary,
>>
>> sorry, your question somehow slipped through my unread message queue.
>>
>> Setting the formatting config to null should work. That is, it is
>> perfectly ok to extend the ConfigStore and set this one back to null.
>> However, the AbstractElements hold an EMF Adapter that caches some
>> information. When you try to reset the formatting config, you'll have to
>> traverse the grammar (can be obtained from the IGrammarAccess) and remove
>> any adapter that fulfill the interface INFAState.
>>
>> Hope that helps,
>> Sebastian
>> --
>> Need professional support for Eclipse Modeling?
>> Go visit: http://xtext.itemis.com
>>
>> Am 19.04.11 19:30, schrieb Mary K:
>>> Still struggling with this and would really like to have some guidance
>>> from the Xtext team whether this is even possible. Is it possible to
>>> reset/change the formatting after the initial configuration?
>>>
>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>> track of all the patterns (e.g. linewraps, etc) that have been applied
>>> to the element. So, if a noLineWrap has been previously
>>> applied/installed on the element, then further linewrap patterns will
>>> not have any affect. Is my understanding correct? Is it possible to
>>> "reset" previous states?
>>>
>>> By the way, I'm using Xtext 1.02 and need to stay on this version for
>>> now.
>>>
>>> Any suggestion or recommendation will be greatly appreciated.
>>>
>>> Mary
>>>
>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>> news:io8h25$bvi$1@news.eclipse.org...
>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>> then set to null. I would also have to override getConfig() to make
>>>> sure that my FormattingConfig is being returned. That's quite a bit of
>>>> hack though. It would have been nice to just get the existing
>>>> FormattingConfig and reset some of the options.
>>>>
>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>> After I set the FormattingConfig to null, it seems that when I run the
>>>> format (FormattingConfig gets recreated with new options), previous
>>>> settings are remembered and applied. I tried a very simple sequence of
>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>> - run the format, observe that it does the line wrap with the
>>>> specified number of lines
>>>> - set FormattingConfig to null
>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>> - run the format. I expected the file to be reformatted to only have
>>>> single line wraps, but the format insisted on still inserting two line
>>>> wraps.
>>>>
>>>> I'm not sure where the previous option is being remembered. As far as
>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>> FormattingConfig only has one entry with the new setting.
>>>>
>>>> Mary
>>>>
>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>> @Singleton
>>>>> protected static class ConfigStore {
>>>>> protected FormattingConfig config;
>>>>> }
>>>>>
>>>>> You could try to just set the config to null when it needs to be
>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>> that does what you want... try it in the debugger and see if it
>>>>> reloads nicely.
>>>>>
>>>>> - henrik
>>>>>
>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We currently have some built-in formatting in our Xtext based editor,
>>>>>> but are looking at providing user level customization for
>>>>>> formatting. We
>>>>>> are creating a Formatter preference page where users can specify
>>>>>> custom
>>>>>> formatting options such as maximum line width (line wrap), whether
>>>>>> the
>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>
>>>>>> The question I have is -- what's the best way to apply end user
>>>>>> customizations? From what I can tell, the
>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>>> formatting options. When the formatting options change (in the
>>>>>> preference page), what is the best way to reconfigure the
>>>>>> FormattingConfig with the new options? I tried getting a handle to
>>>>>> the
>>>>>> FormattingConfig and setting the new options, but that does not seem
>>>>>> to
>>>>>> work because the previous settings governing the same
>>>>>> objects/keywords
>>>>>> have not been cleared (and setting the new options does not override
>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>> setting and setting the new options (without reconfiguring
>>>>>> everything).
>>>>>>
>>>>>> Any hint or comments will be appreciated.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Mary
>>>>>
>>
>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666360 is a reply to message #666359] |
Wed, 20 April 2011 06:52 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Mary,
I'm sorry for the inconvenience. The APIs were clearly not designed to
do what you try to achieve.
The resource that contains the AbstractElements may contain other
adapters, e.g. these lines in AbstractNFAState add an
IsInitializedAdapter to the resource. I bet you'll have to remove this
one, too:
for (Adapter a : element.eResource().eAdapters())
if (a instanceof IsInitializedMarker && ((IsInitializedMarker)
a).builder == builder)
return getIncoming();
element.eResource().eAdapters().add(new IsInitializedMarker(builder));
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 20.04.11 07:51, schrieb Mary K:
> In my previous post, I said TransitionMatcher in error. It should be
> MatcherTransition. (And yes, they are both valid class names in the
> org.eclipse.xtext.formatting.impl package! :-} )
>
> Mary
>
> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
> news:iol1r0$nof$1@news.eclipse.org...
>> Sebastian, thanks for your response.
>>
>> I did try removing the adapter (MatcherState) for the AbstractElement,
>> but that is apparently not sufficient. Still does not work. There
>> seems to be a TransitionMatcher that seems to be holding on to some
>> stale information... still debugging into the bowels of Xtext...
>> making very slow progress.
>>
>> If you have any additional recommendation, it will definitely help!
>> I'm still painstakingly stepping through a lot of code trying to
>> figure out why this is not working...
>>
>> Mary
>>
>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>> news:iokri5$er9$1@news.eclipse.org...
>>> Hi Mary,
>>>
>>> sorry, your question somehow slipped through my unread message queue.
>>>
>>> Setting the formatting config to null should work. That is, it is
>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>> However, the AbstractElements hold an EMF Adapter that caches some
>>> information. When you try to reset the formatting config, you'll have
>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>> remove any adapter that fulfill the interface INFAState.
>>>
>>> Hope that helps,
>>> Sebastian
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>>
>>> Am 19.04.11 19:30, schrieb Mary K:
>>>> Still struggling with this and would really like to have some guidance
>>>> from the Xtext team whether this is even possible. Is it possible to
>>>> reset/change the formatting after the initial configuration?
>>>>
>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>> track of all the patterns (e.g. linewraps, etc) that have been applied
>>>> to the element. So, if a noLineWrap has been previously
>>>> applied/installed on the element, then further linewrap patterns will
>>>> not have any affect. Is my understanding correct? Is it possible to
>>>> "reset" previous states?
>>>>
>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>> for now.
>>>>
>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>
>>>> Mary
>>>>
>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>>> then set to null. I would also have to override getConfig() to make
>>>>> sure that my FormattingConfig is being returned. That's quite a bit of
>>>>> hack though. It would have been nice to just get the existing
>>>>> FormattingConfig and reset some of the options.
>>>>>
>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>> After I set the FormattingConfig to null, it seems that when I run the
>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>> settings are remembered and applied. I tried a very simple sequence of
>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>> - run the format, observe that it does the line wrap with the
>>>>> specified number of lines
>>>>> - set FormattingConfig to null
>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>> - run the format. I expected the file to be reformatted to only have
>>>>> single line wraps, but the format insisted on still inserting two line
>>>>> wraps.
>>>>>
>>>>> I'm not sure where the previous option is being remembered. As far as
>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>> FormattingConfig only has one entry with the new setting.
>>>>>
>>>>> Mary
>>>>>
>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>> @Singleton
>>>>>> protected static class ConfigStore {
>>>>>> protected FormattingConfig config;
>>>>>> }
>>>>>>
>>>>>> You could try to just set the config to null when it needs to be
>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>> that does what you want... try it in the debugger and see if it
>>>>>> reloads nicely.
>>>>>>
>>>>>> - henrik
>>>>>>
>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>> editor,
>>>>>>> but are looking at providing user level customization for
>>>>>>> formatting. We
>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>> custom
>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>> whether the
>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>
>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>> customizations? From what I can tell, the
>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>>>> formatting options. When the formatting options change (in the
>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>> to the
>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>> seem to
>>>>>>> work because the previous settings governing the same
>>>>>>> objects/keywords
>>>>>>> have not been cleared (and setting the new options does not override
>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>> everything).
>>>>>>>
>>>>>>> Any hint or comments will be appreciated.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Mary
>>>>>>
>>>
>>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666363 is a reply to message #666359] |
Wed, 20 April 2011 07:12 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Mary,
it would help if you could describe your use case and the obstacles that
you stumbled across in a bugzilla ticket.
Thanks,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 20.04.11 07:51, schrieb Mary K:
> In my previous post, I said TransitionMatcher in error. It should be
> MatcherTransition. (And yes, they are both valid class names in the
> org.eclipse.xtext.formatting.impl package! :-} )
>
> Mary
>
> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
> news:iol1r0$nof$1@news.eclipse.org...
>> Sebastian, thanks for your response.
>>
>> I did try removing the adapter (MatcherState) for the AbstractElement,
>> but that is apparently not sufficient. Still does not work. There
>> seems to be a TransitionMatcher that seems to be holding on to some
>> stale information... still debugging into the bowels of Xtext...
>> making very slow progress.
>>
>> If you have any additional recommendation, it will definitely help!
>> I'm still painstakingly stepping through a lot of code trying to
>> figure out why this is not working...
>>
>> Mary
>>
>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>> news:iokri5$er9$1@news.eclipse.org...
>>> Hi Mary,
>>>
>>> sorry, your question somehow slipped through my unread message queue.
>>>
>>> Setting the formatting config to null should work. That is, it is
>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>> However, the AbstractElements hold an EMF Adapter that caches some
>>> information. When you try to reset the formatting config, you'll have
>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>> remove any adapter that fulfill the interface INFAState.
>>>
>>> Hope that helps,
>>> Sebastian
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>>
>>> Am 19.04.11 19:30, schrieb Mary K:
>>>> Still struggling with this and would really like to have some guidance
>>>> from the Xtext team whether this is even possible. Is it possible to
>>>> reset/change the formatting after the initial configuration?
>>>>
>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>> track of all the patterns (e.g. linewraps, etc) that have been applied
>>>> to the element. So, if a noLineWrap has been previously
>>>> applied/installed on the element, then further linewrap patterns will
>>>> not have any affect. Is my understanding correct? Is it possible to
>>>> "reset" previous states?
>>>>
>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>> for now.
>>>>
>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>
>>>> Mary
>>>>
>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>>> then set to null. I would also have to override getConfig() to make
>>>>> sure that my FormattingConfig is being returned. That's quite a bit of
>>>>> hack though. It would have been nice to just get the existing
>>>>> FormattingConfig and reset some of the options.
>>>>>
>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>> After I set the FormattingConfig to null, it seems that when I run the
>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>> settings are remembered and applied. I tried a very simple sequence of
>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>> - run the format, observe that it does the line wrap with the
>>>>> specified number of lines
>>>>> - set FormattingConfig to null
>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>> - run the format. I expected the file to be reformatted to only have
>>>>> single line wraps, but the format insisted on still inserting two line
>>>>> wraps.
>>>>>
>>>>> I'm not sure where the previous option is being remembered. As far as
>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>> FormattingConfig only has one entry with the new setting.
>>>>>
>>>>> Mary
>>>>>
>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>> @Singleton
>>>>>> protected static class ConfigStore {
>>>>>> protected FormattingConfig config;
>>>>>> }
>>>>>>
>>>>>> You could try to just set the config to null when it needs to be
>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>> that does what you want... try it in the debugger and see if it
>>>>>> reloads nicely.
>>>>>>
>>>>>> - henrik
>>>>>>
>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>> editor,
>>>>>>> but are looking at providing user level customization for
>>>>>>> formatting. We
>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>> custom
>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>> whether the
>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>
>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>> customizations? From what I can tell, the
>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>>>> formatting options. When the formatting options change (in the
>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>> to the
>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>> seem to
>>>>>>> work because the previous settings governing the same
>>>>>>> objects/keywords
>>>>>>> have not been cleared (and setting the new options does not override
>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>> everything).
>>>>>>>
>>>>>>> Any hint or comments will be appreciated.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Mary
>>>>>>
>>>
>>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666714 is a reply to message #666360] |
Thu, 21 April 2011 18:51 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
It took me a while, but I *think* I finally have it working now.
At first when I removed the MatcherState adapter, I was only removing it for
the AbstractElement (e.g. the '{' element) that I had set the formatting
options for. As I stated in my previous post, that did not work. I also said
that it had something to do with MatcherTransition. It took many more hours
of debugging to understand that when when you set a formatting option (e.g.
setLineBreak) on an element, the sibling element also keeps track of those
options and there are these MatcherTransition objects that keep track of
which element (source) is transitioning to another (target) and what
formatting option (pattern) needs to be applied. So, it turns out that in
addition to removing the MatcherState adapter for the element, I also have
to remove MatcherState adapter for the sibling element!
I then took the sledge hammer approach to this and cleared the MatcherState
adapter for EVERY AbstractElement whenever I needed to reset the
FormattingConfig.
The sledge hammer solution *still* didn't quite work... and I had to hire an
elephant to finish the job! As Sebastian pointed out, the resource that
contains the AbstractElement also contains other adapters and yes... they
needed to be cleared too. The main suspect in this case is the
IsInitializedMarker. However, IsInitializedMarker is a protected static
class within AbstractNFAState, so I can't even check for instanceof it when
I get all the adapters from the resource. So, that's where the elephant was
sent in to do the job. I now clear ALL the adapters on the resource when I
reset the FormattingConfig.
Yes, my eyebrows hit the ceiling too! I'm sure there are alarms going on
everywhere... BUT at least the re-formatting is working for now. I will tune
out the blaring alarm and enjoy this brief moment of victory... before I
have to go and figure out what else I would have broken from clearing out
all the adapters on the resource.
Am I totally off track?! Is this the only way to get re-formatting to work?
Do I really need to implement the sledge hammer and hire an elephant? I
would really really appreciate some sort of acknowledgement from the experts
on this.
Mary
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:iolv95$tmj$1@news.eclipse.org...
> Hi Mary,
>
> I'm sorry for the inconvenience. The APIs were clearly not designed to do
> what you try to achieve.
>
> The resource that contains the AbstractElements may contain other
> adapters, e.g. these lines in AbstractNFAState add an IsInitializedAdapter
> to the resource. I bet you'll have to remove this one, too:
>
> for (Adapter a : element.eResource().eAdapters())
> if (a instanceof IsInitializedMarker && ((IsInitializedMarker) a).builder
> == builder)
> return getIncoming();
> element.eResource().eAdapters().add(new IsInitializedMarker(builder));
>
>
> Regards,
> Sebastian
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
> Am 20.04.11 07:51, schrieb Mary K:
>> In my previous post, I said TransitionMatcher in error. It should be
>> MatcherTransition. (And yes, they are both valid class names in the
>> org.eclipse.xtext.formatting.impl package! :-} )
>>
>> Mary
>>
>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>> news:iol1r0$nof$1@news.eclipse.org...
>>> Sebastian, thanks for your response.
>>>
>>> I did try removing the adapter (MatcherState) for the AbstractElement,
>>> but that is apparently not sufficient. Still does not work. There
>>> seems to be a TransitionMatcher that seems to be holding on to some
>>> stale information... still debugging into the bowels of Xtext...
>>> making very slow progress.
>>>
>>> If you have any additional recommendation, it will definitely help!
>>> I'm still painstakingly stepping through a lot of code trying to
>>> figure out why this is not working...
>>>
>>> Mary
>>>
>>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>>> news:iokri5$er9$1@news.eclipse.org...
>>>> Hi Mary,
>>>>
>>>> sorry, your question somehow slipped through my unread message queue.
>>>>
>>>> Setting the formatting config to null should work. That is, it is
>>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>>> However, the AbstractElements hold an EMF Adapter that caches some
>>>> information. When you try to reset the formatting config, you'll have
>>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>>> remove any adapter that fulfill the interface INFAState.
>>>>
>>>> Hope that helps,
>>>> Sebastian
>>>> --
>>>> Need professional support for Eclipse Modeling?
>>>> Go visit: http://xtext.itemis.com
>>>>
>>>> Am 19.04.11 19:30, schrieb Mary K:
>>>>> Still struggling with this and would really like to have some guidance
>>>>> from the Xtext team whether this is even possible. Is it possible to
>>>>> reset/change the formatting after the initial configuration?
>>>>>
>>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>>> track of all the patterns (e.g. linewraps, etc) that have been applied
>>>>> to the element. So, if a noLineWrap has been previously
>>>>> applied/installed on the element, then further linewrap patterns will
>>>>> not have any affect. Is my understanding correct? Is it possible to
>>>>> "reset" previous states?
>>>>>
>>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>>> for now.
>>>>>
>>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>>
>>>>> Mary
>>>>>
>>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>>>> then set to null. I would also have to override getConfig() to make
>>>>>> sure that my FormattingConfig is being returned. That's quite a bit
>>>>>> of
>>>>>> hack though. It would have been nice to just get the existing
>>>>>> FormattingConfig and reset some of the options.
>>>>>>
>>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>>> After I set the FormattingConfig to null, it seems that when I run
>>>>>> the
>>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>>> settings are remembered and applied. I tried a very simple sequence
>>>>>> of
>>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>>> - run the format, observe that it does the line wrap with the
>>>>>> specified number of lines
>>>>>> - set FormattingConfig to null
>>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>>> - run the format. I expected the file to be reformatted to only have
>>>>>> single line wraps, but the format insisted on still inserting two
>>>>>> line
>>>>>> wraps.
>>>>>>
>>>>>> I'm not sure where the previous option is being remembered. As far as
>>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>>> FormattingConfig only has one entry with the new setting.
>>>>>>
>>>>>> Mary
>>>>>>
>>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>>> @Singleton
>>>>>>> protected static class ConfigStore {
>>>>>>> protected FormattingConfig config;
>>>>>>> }
>>>>>>>
>>>>>>> You could try to just set the config to null when it needs to be
>>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>>> that does what you want... try it in the debugger and see if it
>>>>>>> reloads nicely.
>>>>>>>
>>>>>>> - henrik
>>>>>>>
>>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>>> editor,
>>>>>>>> but are looking at providing user level customization for
>>>>>>>> formatting. We
>>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>>> custom
>>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>>> whether the
>>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>>
>>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>>> customizations? From what I can tell, the
>>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>>>>> formatting options. When the formatting options change (in the
>>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>>> to the
>>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>>> seem to
>>>>>>>> work because the previous settings governing the same
>>>>>>>> objects/keywords
>>>>>>>> have not been cleared (and setting the new options does not
>>>>>>>> override
>>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>>> everything).
>>>>>>>>
>>>>>>>> Any hint or comments will be appreciated.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Mary
>>>>>>>
>>>>
>>>>
>
>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #666750 is a reply to message #666714] |
Fri, 22 April 2011 07:47 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Mary,
the sledge hammer is definitly the right tool for your job. However, the
elephant should check the resource's adapter for .getClass().getName()
or something to only clear the IsInitializedAdapter.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 21.04.11 20:51, schrieb Mary K:
> It took me a while, but I *think* I finally have it working now.
>
> At first when I removed the MatcherState adapter, I was only removing it
> for the AbstractElement (e.g. the '{' element) that I had set the
> formatting options for. As I stated in my previous post, that did not
> work. I also said that it had something to do with MatcherTransition. It
> took many more hours of debugging to understand that when when you set a
> formatting option (e.g. setLineBreak) on an element, the sibling element
> also keeps track of those options and there are these MatcherTransition
> objects that keep track of which element (source) is transitioning to
> another (target) and what formatting option (pattern) needs to be
> applied. So, it turns out that in addition to removing the MatcherState
> adapter for the element, I also have to remove MatcherState adapter for
> the sibling element!
>
> I then took the sledge hammer approach to this and cleared the
> MatcherState adapter for EVERY AbstractElement whenever I needed to
> reset the FormattingConfig.
>
> The sledge hammer solution *still* didn't quite work... and I had to
> hire an elephant to finish the job! As Sebastian pointed out, the
> resource that contains the AbstractElement also contains other adapters
> and yes... they needed to be cleared too. The main suspect in this case
> is the IsInitializedMarker. However, IsInitializedMarker is a protected
> static class within AbstractNFAState, so I can't even check for
> instanceof it when I get all the adapters from the resource. So, that's
> where the elephant was sent in to do the job. I now clear ALL the
> adapters on the resource when I reset the FormattingConfig.
>
> Yes, my eyebrows hit the ceiling too! I'm sure there are alarms going on
> everywhere... BUT at least the re-formatting is working for now. I will
> tune out the blaring alarm and enjoy this brief moment of victory...
> before I have to go and figure out what else I would have broken from
> clearing out all the adapters on the resource.
>
> Am I totally off track?! Is this the only way to get re-formatting to
> work? Do I really need to implement the sledge hammer and hire an
> elephant? I would really really appreciate some sort of acknowledgement
> from the experts on this.
>
> Mary
>
> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
> news:iolv95$tmj$1@news.eclipse.org...
>> Hi Mary,
>>
>> I'm sorry for the inconvenience. The APIs were clearly not designed to
>> do what you try to achieve.
>>
>> The resource that contains the AbstractElements may contain other
>> adapters, e.g. these lines in AbstractNFAState add an
>> IsInitializedAdapter to the resource. I bet you'll have to remove this
>> one, too:
>>
>> for (Adapter a : element.eResource().eAdapters())
>> if (a instanceof IsInitializedMarker && ((IsInitializedMarker)
>> a).builder == builder)
>> return getIncoming();
>> element.eResource().eAdapters().add(new IsInitializedMarker(builder));
>>
>>
>> Regards,
>> Sebastian
>> --
>> Need professional support for Eclipse Modeling?
>> Go visit: http://xtext.itemis.com
>>
>> Am 20.04.11 07:51, schrieb Mary K:
>>> In my previous post, I said TransitionMatcher in error. It should be
>>> MatcherTransition. (And yes, they are both valid class names in the
>>> org.eclipse.xtext.formatting.impl package! :-} )
>>>
>>> Mary
>>>
>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>> news:iol1r0$nof$1@news.eclipse.org...
>>>> Sebastian, thanks for your response.
>>>>
>>>> I did try removing the adapter (MatcherState) for the AbstractElement,
>>>> but that is apparently not sufficient. Still does not work. There
>>>> seems to be a TransitionMatcher that seems to be holding on to some
>>>> stale information... still debugging into the bowels of Xtext...
>>>> making very slow progress.
>>>>
>>>> If you have any additional recommendation, it will definitely help!
>>>> I'm still painstakingly stepping through a lot of code trying to
>>>> figure out why this is not working...
>>>>
>>>> Mary
>>>>
>>>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>>>> news:iokri5$er9$1@news.eclipse.org...
>>>>> Hi Mary,
>>>>>
>>>>> sorry, your question somehow slipped through my unread message queue.
>>>>>
>>>>> Setting the formatting config to null should work. That is, it is
>>>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>>>> However, the AbstractElements hold an EMF Adapter that caches some
>>>>> information. When you try to reset the formatting config, you'll have
>>>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>>>> remove any adapter that fulfill the interface INFAState.
>>>>>
>>>>> Hope that helps,
>>>>> Sebastian
>>>>> --
>>>>> Need professional support for Eclipse Modeling?
>>>>> Go visit: http://xtext.itemis.com
>>>>>
>>>>> Am 19.04.11 19:30, schrieb Mary K:
>>>>>> Still struggling with this and would really like to have some
>>>>>> guidance
>>>>>> from the Xtext team whether this is even possible. Is it possible to
>>>>>> reset/change the formatting after the initial configuration?
>>>>>>
>>>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>>>> track of all the patterns (e.g. linewraps, etc) that have been
>>>>>> applied
>>>>>> to the element. So, if a noLineWrap has been previously
>>>>>> applied/installed on the element, then further linewrap patterns will
>>>>>> not have any affect. Is my understanding correct? Is it possible to
>>>>>> "reset" previous states?
>>>>>>
>>>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>>>> for now.
>>>>>>
>>>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>>>
>>>>>> Mary
>>>>>>
>>>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>>>>> then set to null. I would also have to override getConfig() to make
>>>>>>> sure that my FormattingConfig is being returned. That's quite a
>>>>>>> bit of
>>>>>>> hack though. It would have been nice to just get the existing
>>>>>>> FormattingConfig and reset some of the options.
>>>>>>>
>>>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>>>> After I set the FormattingConfig to null, it seems that when I
>>>>>>> run the
>>>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>>>> settings are remembered and applied. I tried a very simple
>>>>>>> sequence of
>>>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>>>> - run the format, observe that it does the line wrap with the
>>>>>>> specified number of lines
>>>>>>> - set FormattingConfig to null
>>>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>>>> - run the format. I expected the file to be reformatted to only have
>>>>>>> single line wraps, but the format insisted on still inserting two
>>>>>>> line
>>>>>>> wraps.
>>>>>>>
>>>>>>> I'm not sure where the previous option is being remembered. As
>>>>>>> far as
>>>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>>>> FormattingConfig only has one entry with the new setting.
>>>>>>>
>>>>>>> Mary
>>>>>>>
>>>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>>>> @Singleton
>>>>>>>> protected static class ConfigStore {
>>>>>>>> protected FormattingConfig config;
>>>>>>>> }
>>>>>>>>
>>>>>>>> You could try to just set the config to null when it needs to be
>>>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>>>> that does what you want... try it in the debugger and see if it
>>>>>>>> reloads nicely.
>>>>>>>>
>>>>>>>> - henrik
>>>>>>>>
>>>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>>>> editor,
>>>>>>>>> but are looking at providing user level customization for
>>>>>>>>> formatting. We
>>>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>>>> custom
>>>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>>>> whether the
>>>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>>>
>>>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>>>> customizations? From what I can tell, the
>>>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>>>> AbstractDeclarativeFormatter gets called initially to configure
>>>>>>>>> the
>>>>>>>>> formatting options. When the formatting options change (in the
>>>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>>>> to the
>>>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>>>> seem to
>>>>>>>>> work because the previous settings governing the same
>>>>>>>>> objects/keywords
>>>>>>>>> have not been cleared (and setting the new options does not
>>>>>>>>> override
>>>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>>>> everything).
>>>>>>>>>
>>>>>>>>> Any hint or comments will be appreciated.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Mary
>>>>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #667124 is a reply to message #666750] |
Tue, 26 April 2011 21:41 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
Hi Sebastian,
Thanks for your response. The sledge hammer is in place and I've exchanged
the (wild) elephant for a more domesticated baby elephant that clears only
the IsInitializedAdapter -- by using .getClass.getSimpleName().
I've also been trying to customize the formatter to indent wrapped lines...
and that has been quite a challenge in itself. I have to override/change
FormattingConfigBasedStream.Line.flushLine(), but there is no quick and easy
way to do it. I started by trying to extend/override, but it soon got to a
point where I was literally making a copy of FormattingConfigBasedStream
(and the two inner classes Line and LineEntry). I can't see any other way of
doing it... again, any guidance will be greatly appreciated.
By the way, I've added some comments and added a link to this discussion to
Bug 333987 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=333987)
Mary
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:iorb86$l5s$1@news.eclipse.org...
> Hi Mary,
>
> the sledge hammer is definitly the right tool for your job. However, the
> elephant should check the resource's adapter for .getClass().getName() or
> something to only clear the IsInitializedAdapter.
>
> Regards,
> Sebastian
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
> Am 21.04.11 20:51, schrieb Mary K:
>> It took me a while, but I *think* I finally have it working now.
>>
>> At first when I removed the MatcherState adapter, I was only removing it
>> for the AbstractElement (e.g. the '{' element) that I had set the
>> formatting options for. As I stated in my previous post, that did not
>> work. I also said that it had something to do with MatcherTransition. It
>> took many more hours of debugging to understand that when when you set a
>> formatting option (e.g. setLineBreak) on an element, the sibling element
>> also keeps track of those options and there are these MatcherTransition
>> objects that keep track of which element (source) is transitioning to
>> another (target) and what formatting option (pattern) needs to be
>> applied. So, it turns out that in addition to removing the MatcherState
>> adapter for the element, I also have to remove MatcherState adapter for
>> the sibling element!
>>
>> I then took the sledge hammer approach to this and cleared the
>> MatcherState adapter for EVERY AbstractElement whenever I needed to
>> reset the FormattingConfig.
>>
>> The sledge hammer solution *still* didn't quite work... and I had to
>> hire an elephant to finish the job! As Sebastian pointed out, the
>> resource that contains the AbstractElement also contains other adapters
>> and yes... they needed to be cleared too. The main suspect in this case
>> is the IsInitializedMarker. However, IsInitializedMarker is a protected
>> static class within AbstractNFAState, so I can't even check for
>> instanceof it when I get all the adapters from the resource. So, that's
>> where the elephant was sent in to do the job. I now clear ALL the
>> adapters on the resource when I reset the FormattingConfig.
>>
>> Yes, my eyebrows hit the ceiling too! I'm sure there are alarms going on
>> everywhere... BUT at least the re-formatting is working for now. I will
>> tune out the blaring alarm and enjoy this brief moment of victory...
>> before I have to go and figure out what else I would have broken from
>> clearing out all the adapters on the resource.
>>
>> Am I totally off track?! Is this the only way to get re-formatting to
>> work? Do I really need to implement the sledge hammer and hire an
>> elephant? I would really really appreciate some sort of acknowledgement
>> from the experts on this.
>>
>> Mary
>>
>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>> news:iolv95$tmj$1@news.eclipse.org...
>>> Hi Mary,
>>>
>>> I'm sorry for the inconvenience. The APIs were clearly not designed to
>>> do what you try to achieve.
>>>
>>> The resource that contains the AbstractElements may contain other
>>> adapters, e.g. these lines in AbstractNFAState add an
>>> IsInitializedAdapter to the resource. I bet you'll have to remove this
>>> one, too:
>>>
>>> for (Adapter a : element.eResource().eAdapters())
>>> if (a instanceof IsInitializedMarker && ((IsInitializedMarker)
>>> a).builder == builder)
>>> return getIncoming();
>>> element.eResource().eAdapters().add(new IsInitializedMarker(builder));
>>>
>>>
>>> Regards,
>>> Sebastian
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>>
>>> Am 20.04.11 07:51, schrieb Mary K:
>>>> In my previous post, I said TransitionMatcher in error. It should be
>>>> MatcherTransition. (And yes, they are both valid class names in the
>>>> org.eclipse.xtext.formatting.impl package! :-} )
>>>>
>>>> Mary
>>>>
>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>> news:iol1r0$nof$1@news.eclipse.org...
>>>>> Sebastian, thanks for your response.
>>>>>
>>>>> I did try removing the adapter (MatcherState) for the AbstractElement,
>>>>> but that is apparently not sufficient. Still does not work. There
>>>>> seems to be a TransitionMatcher that seems to be holding on to some
>>>>> stale information... still debugging into the bowels of Xtext...
>>>>> making very slow progress.
>>>>>
>>>>> If you have any additional recommendation, it will definitely help!
>>>>> I'm still painstakingly stepping through a lot of code trying to
>>>>> figure out why this is not working...
>>>>>
>>>>> Mary
>>>>>
>>>>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>>>>> news:iokri5$er9$1@news.eclipse.org...
>>>>>> Hi Mary,
>>>>>>
>>>>>> sorry, your question somehow slipped through my unread message queue.
>>>>>>
>>>>>> Setting the formatting config to null should work. That is, it is
>>>>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>>>>> However, the AbstractElements hold an EMF Adapter that caches some
>>>>>> information. When you try to reset the formatting config, you'll have
>>>>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>>>>> remove any adapter that fulfill the interface INFAState.
>>>>>>
>>>>>> Hope that helps,
>>>>>> Sebastian
>>>>>> --
>>>>>> Need professional support for Eclipse Modeling?
>>>>>> Go visit: http://xtext.itemis.com
>>>>>>
>>>>>> Am 19.04.11 19:30, schrieb Mary K:
>>>>>>> Still struggling with this and would really like to have some
>>>>>>> guidance
>>>>>>> from the Xtext team whether this is even possible. Is it possible to
>>>>>>> reset/change the formatting after the initial configuration?
>>>>>>>
>>>>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>>>>> track of all the patterns (e.g. linewraps, etc) that have been
>>>>>>> applied
>>>>>>> to the element. So, if a noLineWrap has been previously
>>>>>>> applied/installed on the element, then further linewrap patterns
>>>>>>> will
>>>>>>> not have any affect. Is my understanding correct? Is it possible to
>>>>>>> "reset" previous states?
>>>>>>>
>>>>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>>>>> for now.
>>>>>>>
>>>>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>>>>
>>>>>>> Mary
>>>>>>>
>>>>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>>>>> ConfigStore, which will give me my own FormattingConfig, which I
>>>>>>>> can
>>>>>>>> then set to null. I would also have to override getConfig() to make
>>>>>>>> sure that my FormattingConfig is being returned. That's quite a
>>>>>>>> bit of
>>>>>>>> hack though. It would have been nice to just get the existing
>>>>>>>> FormattingConfig and reset some of the options.
>>>>>>>>
>>>>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>>>>> After I set the FormattingConfig to null, it seems that when I
>>>>>>>> run the
>>>>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>>>>> settings are remembered and applied. I tried a very simple
>>>>>>>> sequence of
>>>>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>>>>> - run the format, observe that it does the line wrap with the
>>>>>>>> specified number of lines
>>>>>>>> - set FormattingConfig to null
>>>>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>>>>> - run the format. I expected the file to be reformatted to only
>>>>>>>> have
>>>>>>>> single line wraps, but the format insisted on still inserting two
>>>>>>>> line
>>>>>>>> wraps.
>>>>>>>>
>>>>>>>> I'm not sure where the previous option is being remembered. As
>>>>>>>> far as
>>>>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>>>>> FormattingConfig only has one entry with the new setting.
>>>>>>>>
>>>>>>>> Mary
>>>>>>>>
>>>>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>>>>> @Singleton
>>>>>>>>> protected static class ConfigStore {
>>>>>>>>> protected FormattingConfig config;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> You could try to just set the config to null when it needs to be
>>>>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>>>>> that does what you want... try it in the debugger and see if it
>>>>>>>>> reloads nicely.
>>>>>>>>>
>>>>>>>>> - henrik
>>>>>>>>>
>>>>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>>>>> editor,
>>>>>>>>>> but are looking at providing user level customization for
>>>>>>>>>> formatting. We
>>>>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>>>>> custom
>>>>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>>>>> whether the
>>>>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>>>>
>>>>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>>>>> customizations? From what I can tell, the
>>>>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>>>>> AbstractDeclarativeFormatter gets called initially to configure
>>>>>>>>>> the
>>>>>>>>>> formatting options. When the formatting options change (in the
>>>>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>>>>> to the
>>>>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>>>>> seem to
>>>>>>>>>> work because the previous settings governing the same
>>>>>>>>>> objects/keywords
>>>>>>>>>> have not been cleared (and setting the new options does not
>>>>>>>>>> override
>>>>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>>>>> everything).
>>>>>>>>>>
>>>>>>>>>> Any hint or comments will be appreciated.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Mary
>>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>
|
|
|
| Re: [Xtext] Enabling user customization for formatting [message #667125 is a reply to message #666363] |
Tue, 26 April 2011 21:43 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bugzilla.post.gmail.com
Sebastian,
There seems to be an existing bugzilla defect:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=333987
I've added a comment and provided a link to this discussion in that bug.
Mary
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:iom0eu$vdo$1@news.eclipse.org...
> Mary,
>
> it would help if you could describe your use case and the obstacles that
> you stumbled across in a bugzilla ticket.
>
> Thanks,
> Sebastian
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
> Am 20.04.11 07:51, schrieb Mary K:
>> In my previous post, I said TransitionMatcher in error. It should be
>> MatcherTransition. (And yes, they are both valid class names in the
>> org.eclipse.xtext.formatting.impl package! :-} )
>>
>> Mary
>>
>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>> news:iol1r0$nof$1@news.eclipse.org...
>>> Sebastian, thanks for your response.
>>>
>>> I did try removing the adapter (MatcherState) for the AbstractElement,
>>> but that is apparently not sufficient. Still does not work. There
>>> seems to be a TransitionMatcher that seems to be holding on to some
>>> stale information... still debugging into the bowels of Xtext...
>>> making very slow progress.
>>>
>>> If you have any additional recommendation, it will definitely help!
>>> I'm still painstakingly stepping through a lot of code trying to
>>> figure out why this is not working...
>>>
>>> Mary
>>>
>>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>>> news:iokri5$er9$1@news.eclipse.org...
>>>> Hi Mary,
>>>>
>>>> sorry, your question somehow slipped through my unread message queue.
>>>>
>>>> Setting the formatting config to null should work. That is, it is
>>>> perfectly ok to extend the ConfigStore and set this one back to null.
>>>> However, the AbstractElements hold an EMF Adapter that caches some
>>>> information. When you try to reset the formatting config, you'll have
>>>> to traverse the grammar (can be obtained from the IGrammarAccess) and
>>>> remove any adapter that fulfill the interface INFAState.
>>>>
>>>> Hope that helps,
>>>> Sebastian
>>>> --
>>>> Need professional support for Eclipse Modeling?
>>>> Go visit: http://xtext.itemis.com
>>>>
>>>> Am 19.04.11 19:30, schrieb Mary K:
>>>>> Still struggling with this and would really like to have some guidance
>>>>> from the Xtext team whether this is even possible. Is it possible to
>>>>> reset/change the formatting after the initial configuration?
>>>>>
>>>>> It seems to me that an AbstractElement has a MatcherState that keeps
>>>>> track of all the patterns (e.g. linewraps, etc) that have been applied
>>>>> to the element. So, if a noLineWrap has been previously
>>>>> applied/installed on the element, then further linewrap patterns will
>>>>> not have any affect. Is my understanding correct? Is it possible to
>>>>> "reset" previous states?
>>>>>
>>>>> By the way, I'm using Xtext 1.02 and need to stay on this version
>>>>> for now.
>>>>>
>>>>> Any suggestion or recommendation will be greatly appreciated.
>>>>>
>>>>> Mary
>>>>>
>>>>> "Mary K" <eclipse.bugzilla.post@gmail.com> wrote in message
>>>>> news:io8h25$bvi$1@news.eclipse.org...
>>>>>> I can't set the FormattingConfig in AbstractDeclarativeFormatter to
>>>>>> null... I would have to override the ConfigStore -- i.e have my own
>>>>>> ConfigStore, which will give me my own FormattingConfig, which I can
>>>>>> then set to null. I would also have to override getConfig() to make
>>>>>> sure that my FormattingConfig is being returned. That's quite a bit
>>>>>> of
>>>>>> hack though. It would have been nice to just get the existing
>>>>>> FormattingConfig and reset some of the options.
>>>>>>
>>>>>> Anyway, I did try this out and it *seems* to work... but not quite.
>>>>>> After I set the FormattingConfig to null, it seems that when I run
>>>>>> the
>>>>>> format (FormattingConfig gets recreated with new options), previous
>>>>>> settings are remembered and applied. I tried a very simple sequence
>>>>>> of
>>>>>> - FormattingConfig.setLineWrap(2).after(Keyword)
>>>>>> - run the format, observe that it does the line wrap with the
>>>>>> specified number of lines
>>>>>> - set FormattingConfig to null
>>>>>> - FormattingConfig.setLineWrap().after(Keyword)
>>>>>> - run the format. I expected the file to be reformatted to only have
>>>>>> single line wraps, but the format insisted on still inserting two
>>>>>> line
>>>>>> wraps.
>>>>>>
>>>>>> I'm not sure where the previous option is being remembered. As far as
>>>>>> I can tell from the debugger, the locatorsSemantic list in the new
>>>>>> FormattingConfig only has one entry with the new setting.
>>>>>>
>>>>>> Mary
>>>>>>
>>>>>> "Henrik Lindberg" <henrik.lindberg@cloudsmith.com> wrote in message
>>>>>> news:io82em$pg4$1@news.eclipse.org...
>>>>>>> The AbstractDeclarativeFormatter has this inside...
>>>>>>> @Singleton
>>>>>>> protected static class ConfigStore {
>>>>>>> protected FormattingConfig config;
>>>>>>> }
>>>>>>>
>>>>>>> You could try to just set the config to null when it needs to be
>>>>>>> recomputed, the code seems to handle that - but I have no idea if
>>>>>>> that does what you want... try it in the debugger and see if it
>>>>>>> reloads nicely.
>>>>>>>
>>>>>>> - henrik
>>>>>>>
>>>>>>> On 4/14/11 11:30 PM, Mary K wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We currently have some built-in formatting in our Xtext based
>>>>>>>> editor,
>>>>>>>> but are looking at providing user level customization for
>>>>>>>> formatting. We
>>>>>>>> are creating a Formatter preference page where users can specify
>>>>>>>> custom
>>>>>>>> formatting options such as maximum line width (line wrap),
>>>>>>>> whether the
>>>>>>>> opening braces should be on the same line or next line, etc.
>>>>>>>>
>>>>>>>> The question I have is -- what's the best way to apply end user
>>>>>>>> customizations? From what I can tell, the
>>>>>>>> configureFormatting(FormattingConfig) method in the
>>>>>>>> AbstractDeclarativeFormatter gets called initially to configure the
>>>>>>>> formatting options. When the formatting options change (in the
>>>>>>>> preference page), what is the best way to reconfigure the
>>>>>>>> FormattingConfig with the new options? I tried getting a handle
>>>>>>>> to the
>>>>>>>> FormattingConfig and setting the new options, but that does not
>>>>>>>> seem to
>>>>>>>> work because the previous settings governing the same
>>>>>>>> objects/keywords
>>>>>>>> have not been cleared (and setting the new options does not
>>>>>>>> override
>>>>>>>> previous settings). I don't see any good way of clearing previous
>>>>>>>> setting and setting the new options (without reconfiguring
>>>>>>>> everything).
>>>>>>>>
>>>>>>>> Any hint or comments will be appreciated.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Mary
>>>>>>>
>>>>
>>>>
>
>
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 05:44:05 GMT 2024
Powered by FUDForum. Page generated in 0.02879 seconds |
] 
Search
Help
Register
Login
Home
