User forums > General (but related to Code::Blocks)
Problem with '%' in editor abbreviations
Game_Ender:
Umm... you can't escape Macros the MacroManager was never built to handle that (!).
I'm sorry but if there was some semblance of unit testing for non-gui stuff in Code::Blocks (and Macros can very easily be unit tested) things like this would be a lot less likely to crop up. I will look at the code and see if I can whip some up. Where is the standard place for test code in Code::Blocks?
Pecan:
--- Quote from: rjmyst3 on November 14, 2006, 01:21:28 pm ---
--- Quote ---This is probably a silly question but I am trying to configure my linker options to add "@test.r$p" to the command line. However the program interprets the "$p" as a macro and all that gets placed is "@test.r"
--- End quote ---
I've used backticks as a workaround successfully.
Try
--- Code: ---@test.r$``p
--- End code ---
The backticks resolve to empty, and the $ lives (only tested on linux - but could work on windows)
--- End quote ---
I'm unsuccessful getting backticks to work on abbreviations in windows XP
Anyway to allow %% (as in DOS) to escape substitution?
rjmyst3:
The backticks worked for me in linker/compiler options, because the backticks actually go to command line in linux, and the shell interprets them. So, unfortunately, I wouldn't expect that particular hack to work on abbreviations.
thomas:
--- Quote from: Game_Ender on November 14, 2006, 02:34:58 am ---I'm sorry but if there was some semblance of unit testing for non-gui stuff in Code::Blocks (and Macros can very easily be unit tested) things like this would be a lot less likely to crop up.
--- End quote ---
Have to object here. It's not a matter of testing, or of any actual bug.
We have three issues:
1. the same string gets passed to MacrosManger several times during build (not during abbrevations, though). This could be considered a bug (at the very least, it is unnecessary), but it does not matter, because of (2).
2. in addition to that, MacrosManager will keep replacing any variables it can find in a semi-recursive way (there is no "real" recursion as in function calls, but it works in a recursive manner)
3. although I did (2) by accident in the first place, it happens to be the correct way, just like it has to be. Otherwise nested macros like $($(TARGET_NAME)_OUTPUT_FILE) will not work.
To be able to address the problems, we don't need to test or find a bug. What we need to do is decide whether or not we want to support nested variables like $($(a)b).
If we can drop that feature (personally, I'll be happy with that), then implementing escaping properly should not be a big issue. However, I don't have any figures on how many people use it, and how important it is.
If you think that unit tests should be done, feel free to start a "test" application.
However, it is my belief that unit tests generally don't make anything better. wxWidgets is the best example for that, they have plenty of unit tests, and plenty of dumb errors that nobody seems to see, nevertheless.
dmoore:
--- Quote from: thomas on November 14, 2006, 05:59:44 pm ---To be able to address the problems, we don't need to test or find a bug. What we need to do is decide whether or not we want to support nested variables like $($(a)b).
If we can drop that feature (personally, I'll be happy with that), then implementing escaping properly should not be a big issue. However, I don't have any figures on how many people use it, and how important it is.
--- End quote ---
I've looked at the MacroManager code:
1. I cannot see how implementing escaping is a big issue with or without "recursion". It just might be a little sloppy/slow to convert escaped chars to something safe before the replace then convert them back afterwards.
2. someone could also change the code allow different plugins to choose their own optional escape character as an argument to the replace function. If no character is chosen, you get the default implementation without escapes.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version