Thread: [cedet-semantic] semantic-toggle-decoration-style error
Brought to you by:
zappo
From: Pete B. <elb...@ms...> - 2013-05-02 17:33:03
|
hello, using: (semantic-load-enable-excessive-code-helpers) (semantic-toggle-decoration-style "semantic-decoration-on-include" t) in my .emacs i get: eval: Wrong type argument: consp, nil caused by defun semantic-toggle-decoration-style ;; Store the new flag. (setcdr style flag) when style is set (via let) as nil fix attached, cheers Pete |
From: Eric M. L. <er...@si...> - 2013-05-07 01:01:39
|
Hi Pete, While I think your patch certainly prevents the error, I doubt it is doing what you might hope. You are effectively turning your call to enable decorations on include into a no-op. I think a better fix is to throw a useful error, such as 'no such decoration mode' or something like that. Of course, the line you added isn't necessary, since that happens by default when you enable decoration mode. Was there something you were trying to accomplish with the below code snippet? Eric On 05/02/2013 01:32 PM, Pete Beardmore wrote: > > hello, > > using: > > (semantic-load-enable-excessive-code-helpers) > (semantic-toggle-decoration-style "semantic-decoration-on-include" t) > > in my .emacs i get: > > eval: Wrong type argument: consp, nil > > caused by defun semantic-toggle-decoration-style > > ;; Store the new flag. > (setcdr style flag) > > when style is set (via let) as nil > > fix attached, cheers > Pete > > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with<2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > > > > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic |
From: Pete B. <elb...@ms...> - 2013-05-09 09:54:56
|
Quoting "Eric M. Ludlam" <er...@si...>: > > Hi Pete, > > While I think your patch certainly prevents the error, I doubt it is > doing what you might hope. You are effectively turning your call > to enable decorations on include into a no-op. > > I think a better fix is to throw a useful error, such as 'no such > decoration mode' or something like that. > > Of course, the line you added isn't necessary, since that happens by > default when you enable decoration mode. Was there something you > were trying to accomplish with the below code snippet? > > Eric > hi, thanks for coming back to me on this, you are of course correct, and i should have been more thorough. after my 'fix' i could actually have sent any garbage string to the toggle function and have recorded the desired positive result - namely 'semantic-decoration-styles' containing the missing 'semantic-decoration-on-include' style following a successful loading of my config file. i recorded a false positive :( it is still an issue though, and i'm not one for avoiding a bug if i know it's there. toggling the includes decoration doesn't work unless 'some mode' (and it's not 'global-semantic-decoration-mode' that does this!) has loaded the 'semantic/decorate/include.el' file which is where the includes style gets added to the styles list. you hit the bug i refer to, as the valid name 'semantic-decoration-on-includes' is not in the list. so for example (require cedet-devel-load) (global-semantic-decoration-mode t) (semantic-toggle-decoration-style "semantic-decoration-on-include" t) doesn't work, and i think it should adding (require semantic/decorate/include) to semantic/decorate/mode would fix this hole, but that leads to a recursive load issue, so i've moved the style's definition (the macro call to add it to the list) into the mode.el file instead, with the logic: -in spite of its file location (under /decorate), includes.el is feature-wise standalone enough not to be required by mode.el (hence don't entertain making it a requisite) -to implement a style, mode.el must know about the new style in advance moving this definition out of include.el made (require 'semantic/decorate/mode) in include.el redundant, so i removed that too. this way, with a now guaranteed complete list of possible styles, the toggle function's name check doesn't have to discern 'invalid - not loaded yet' from 'invalid - no such style'. but maybe there's a better way? i've also modified the 'semantic-load-enable-gaudy-code-helpers-1' to explicitly enable the style, in the same way 'semantic-load-enable-excessive-code-helpers-1' does with other styles fyi. how did i find this? well for some (still unknown) reason, all of a sudden my includes weren't clickable. i checked out what my canned config actually loaded, and landed at: (defun semantic-load-enable-excessive-code-helpers-1 () (semantic-toggle-decoration-style "semantic-decoration-on-private-members" t) (semantic-toggle-decoration-style "semantic-decoration-on-protected-members" t)) from there i found the 'semantic-decoration-styles' list in 'semantic-toggle-decoration-style', and noted it contained ONLY those two members above. thus i thought i should just add.. (semantic-toggle-decoration-style "semantic-decoration-on-include" t) ..to my config as a solution. cue this issue. the gremlins ate some of my 'semantic-decoration-styles' list on that occasion is my only call on how that broken state came about in the first place cheers, Pete |
From: Eric M. L. <er...@si...> - 2013-05-12 18:19:51
|
On 05/09/2013 05:54 AM, Pete Beardmore wrote: > > Quoting "Eric M. Ludlam" <er...@si...>: >> >> Hi Pete, >> >> While I think your patch certainly prevents the error, I doubt it is >> doing what you might hope. You are effectively turning your call to >> enable decorations on include into a no-op. >> >> I think a better fix is to throw a useful error, such as 'no such >> decoration mode' or something like that. >> >> Of course, the line you added isn't necessary, since that happens by >> default when you enable decoration mode. Was there something you were >> trying to accomplish with the below code snippet? >> >> Eric >> > > hi, > > thanks for coming back to me on this, you are of course correct, and i > should have been more thorough. after my 'fix' i could actually have > sent any garbage string to the toggle function and have recorded the > desired positive result - namely 'semantic-decoration-styles' containing > the missing 'semantic-decoration-on-include' style following a > successful loading of my config file. i recorded a false positive :( > > it is still an issue though, and i'm not one for avoiding a bug if i > know it's there. toggling the includes decoration doesn't work unless > 'some mode' (and it's not 'global-semantic-decoration-mode' that does > this!) has loaded the 'semantic/decorate/include.el' file which is where > the includes style gets added to the styles list. you hit the bug i > refer to, as the valid name 'semantic-decoration-on-includes' is not in > the list. so for example > > (require cedet-devel-load) > (global-semantic-decoration-mode t) > (semantic-toggle-decoration-style "semantic-decoration-on-include" t) > > doesn't work, and i think it should > Hi again Pete, I think you are right. I looked at your solution, and I think we can tidy this up nicely. I've checked in a change that allows a new decoration mode to be specified with a load feature. When that is done, it uses autoload tokens to create the mode (so you can toggle it) and when it is first used, will load in the necessary code to operate the mode. My brief experiments shows this works well after adding a declaration for the decorate-on-includes in the mode.el file. I think this will be helpful since it doesn't require changes to the canned configurations, which means it will work with stock Emacs also, which does not have those. Hopefully this works well for you also. Thanks Eric |
From: Pete B. <elb...@ms...> - 2013-05-14 08:09:33
|
Quoting "Eric M. Ludlam" <er...@si...>: > > Hi again Pete, > > I think you are right. I looked at your solution, and I think we > can tidy this up nicely. I've checked in a change that allows a new > decoration mode to be specified with a load feature. When that is > done, it uses autoload tokens to create the mode (so you can toggle > it) and when it is first used, will load in the necessary code to > operate the mode. > > My brief experiments shows this works well after adding a > declaration for the decorate-on-includes in the mode.el file. I > think this will be helpful since it doesn't require changes to the > canned configurations, which means it will work with stock Emacs > also, which does not have those. > > Hopefully this works well for you also. > Thanks > Eric works a treat. thank you for doing that |