[Launch] Strange 'launch.xml' caching

Report Bugs Here

[Launch] Strange 'launch.xml' caching

Postby immortalnights » Tue Dec 21, 2010 5:24 pm

I previously created a number of rules within the launch.xml file and a little later decided I no longer wanted those rules and removed and changed some.

It seems however that somewhere Editra/Launch has cached them. I decided to post here rather then create an official Issue, because I'm hoping that it's just me being unable to find the cached file.

The attached screen shot shows what Launch is displaying and what is contained in the launch file I originally edited to display the launch options it displays. As is evident from the screen shot, the launch.xml file does not match what is being used.

I have restarted Editra a number of times. Deleted and replaced the launch.xml file entirely and no matter what I do, I always see my old launch rules. Despite the fact that, if I remove the launch.xml file I get no launch options with CPP files, as is expected.

It's worth mentioning that if I edit the name of the handler it works as I expect.
Attachments
editra-launch-cache.JPG
editra-launch-cache.JPG (77.07 KiB) Viewed 3986 times
immortalnights
User
 
Posts: 39
Joined: Tue Dec 21, 2010 2:02 pm

Re: [Launch] Strange 'launch.xml' caching

Postby cody » Tue Dec 21, 2010 6:25 pm

Hello,

The commands get saved to you user configuration after their initial load. This is in case you modified them through the user interface or if in the case of a plugin or something the user or client code modified them.

If you want to remove them use the Launch configuration dialog and delete them from the list.


Cody
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States

Re: [Launch] Strange 'launch.xml' caching

Postby immortalnights » Tue Dec 21, 2010 6:40 pm

Okay, I see how it works.

It doesn't make much sense to me though - as in as soon as the use has created a definition in the 'launch.xml' file they have to then use the Launch configuration to remove/edit them? It's like intentional out-of-sync behavior. As soon as a name is used in the xml file it's forever associated with not only the commands but the language. Even if the user then removes in out of the xml and four weeks late creates a "new" record with a the same name but different id and commands.

Is there any intention to allow the Launch configuration to manipulate the 'launch.xml' directly, if so then the out-of-sync behavior would, I assume, be corrected somewhat then?
immortalnights
User
 
Posts: 39
Joined: Tue Dec 21, 2010 2:02 pm

Re: [Launch] Strange 'launch.xml' caching

Postby cody » Tue Dec 21, 2010 6:50 pm

Hi,

The Launch XML interface is fairly new and not all parts have been completed. The final intention is yes the configuration in the UI will allow manipulating and modifying the xml, the user configuration for commands and filetypes will also likely all be serialized to the xml configuration file as well. Currently just the low level workings of this feature are in place for those that want to tinker around with things.

Cody
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States

Re: [Launch] Strange 'launch.xml' caching

Postby immortalnights » Wed Dec 22, 2010 3:08 pm

If I understand the way you've described the "caching" to work, the launch.xml file really only needs to be used to define new handlers. Though those handlers have to be against known IDs.

If that is the case, extending the interface to fulfill the purpose of the launch.xml wouldn't be a great change since it could simple allow items to be added to it's "File Type" list and then saved in the profile.

I don't fully understand the reason why, in the code you've hard coded a number of handlers in fuill Python classes. In there any case where the handler actually does something out of the scope of the current handler/command implementation available to the user within the xml? If that's not the case, would it not make sense to move them hard-coded definitions out into the xml and permit the "File Type" list to select from all file type IDs. Whereby if the user selected one that there was not a default handler defined, one would be created in the XML?

Obviously that might be a little extream, the simplest solution would be to fully populate the file type list, and then as above, create the handler XML tag and content when required?

Am I making sense?

(Can that list of IDs be added to, as in creating a new set of file associations and lexer?)
immortalnights
User
 
Posts: 39
Joined: Tue Dec 21, 2010 2:02 pm

Re: [Launch] Strange 'launch.xml' caching

Postby cody » Wed Dec 22, 2010 3:31 pm

immortalnights wrote:If I understand the way you've described the "caching" to work, the launch.xml file really only needs to be used to define new handlers. Though those handlers have to be against known IDs.

If that is the case, extending the interface to fulfill the purpose of the launch.xml wouldn't be a great change since it could simple allow items to be added to it's "File Type" list and then saved in the profile.


Well yes, that is why this is a planned feature. I has not been high on my priorities though as this kind of 'power user' configuration is not something that the main 80% of users need.

immortalnights wrote:I don't fully understand the reason why, in the code you've hard coded a number of handlers in fuill Python classes. In there any case where the handler actually does something out of the scope of the current handler/command implementation available to the user within the xml? If that's not the case, would it not make sense to move them hard-coded definitions out into the xml and permit the "File Type" list to select from all file type IDs. Whereby if the user selected one that there was not a default handler defined, one would be created in the XML?


If you read my previous post you will see that it say that the XML interface is relatively new. The Launch plugin is not new but the xml it uses is. The 'hard coded' handlers provide a class interface that is another way for plugins and other components to install handlers by deriving from the base handler class. It also allows for more custom handling of the output text if a certain file type requires do do any sort of filtering or other processing.

The builtin handlers cover the needs of most users and are easily extended upon without the need of an external file or the risks associated with it becoming corrupted or deleted by an unknowing user. The XML interface allows for overriding the builtin handlers as well so I see no conflict.

immortalnights wrote:Obviously that might be a little extream, the simplest solution would be to fully populate the file type list, and then as above, create the handler XML tag and content when required?


I am not sure what you mean by this? Do you mean generate a full list for all supported file types?


immortalnights wrote:Am I making sense?

(Can that list of IDs be added to, as in creating a new set of file associations and lexer?)


Maybe? Though I don't think I fully understand what your asking in the parens here.
User avatar
cody
Site Admin
 
Posts: 1315
Joined: Mon Oct 09, 2006 2:49 am
Location: United States


Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron