Author Topic: Problem with '%' in editor abbreviations  (Read 8344 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2178
Problem with '%' in editor abbreviations
« on: November 13, 2006, 01:17:44 pm »
I cannot seem to get an editor abbreviation to print a '%s" etc.
It wants to do a substitution.

How can I get an abbreviation to print, say: printf(wxT("%s %d"));
Right now, it substitutes as: printf(wxT(""));

thanks
pecan

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problem with '%' in editor abbreviations
« Reply #1 on: November 13, 2006, 01:39:53 pm »
Currently, and in the near, predictable future, you can't.

A working hack to work around the substitution problem (not only relating to % but also $) at least in the autocomplete box would be to add a checkbox "substitute variables" to enable substitution.

There is unluckily no way to make it really work.

I was previously under the assumption that escaping the control chars % and $ did not work because the replacement process runs recursively due to an error of mine.
However, the truth is that although this originally indeed was an error, it is also a feature, since because of that "error", it accidentially behaves the way people want it to, which it otherwise wouldn't...
Therefore, there is not only no easy way to fix it (as I claimed earlier), there is no way at all.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Problem with '%' in editor abbreviations
« Reply #2 on: November 13, 2006, 02:08:24 pm »
Therefore, there is not only no easy way to fix it (as I claimed earlier), there is no way at all.

Actually, Thomas, why does it make the substitution if no such macro is found? If it just left it untouched in this case, then this problem would be mostly fixed, no?
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problem with '%' in editor abbreviations
« Reply #3 on: November 13, 2006, 05:03:40 pm »
Apparently, the regex matches %s %d, taking ' ' and '"' as delimiters (though I don't see why, it shouldn't). We could try a regex that is a lot more complicated (with, what's it called, lookback?).

That would solve the problem in the particular example by Pecan, but not in general. The general problem persists, and cannot be solved, as people expect stuff like $($(TARGET_NAME)_OUTPUT_FILE) to work. This only works because macro replacement (errornously) runs recursively. As long as this is true, we cannot escape the control chars :(
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Problem with '%' in editor abbreviations
« Reply #4 on: November 13, 2006, 05:47:47 pm »
You probably misunderstood me.
What I 'm saying is what if instead of replacing the macro (whatever that is) with an empty string (in case it's not defined), just let it untouched.
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problem with '%' in editor abbreviations
« Reply #5 on: November 13, 2006, 06:28:10 pm »
Ah, but we had that already... this will not work for environment variables.
I could do without environment variables, but I bet a good number of people will object if we break them :)


EDIT:
To clarify, we have wxGetEnv() and wxSetEnv() at our hands. So, if a variable is not known to Code::Blocks as "builtin", we can either replace it with whatever wxGetEnv() returns (empty string if not defined) or we can say "pfft... screw environment".
In reality, "empty" and "does not exist" are two different things, but we have no way of telling.
« Last Edit: November 13, 2006, 06:33:45 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Problem with '%' in editor abbreviations
« Reply #6 on: November 13, 2006, 11:02:29 pm »
But they are almost always the same thing aren't they?  When is an environment variable set '' ever meaningful.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problem with '%' in editor abbreviations
« Reply #7 on: November 13, 2006, 11:20:45 pm »
Lumme if I knows! Someone might set a variable to empty when it's not needed so it never triggers an error. Just like you #define assert empty in release builds...
In any case I'm not sure if you can be so bold as to assume that empty string and unset are the same.

What if I define EXTRA_CC_OPTIONS as either "" or "-O3 -fexpensive-optimisations"? Bad example because that's done easier using project options. But let's assume those are options which aren't in the stock options.

So... I don't want to use those extra options for a certain project for some reason, and I set that variable to empty.
What happens? Code::Blocks decides that because it doesn't know that variable, it'll leave it as it is.

Result: The compiler will complain "unknown commandline option $EXTRA_CC_OPTIONS".
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Problem with '%' in editor abbreviations
« Reply #8 on: November 13, 2006, 11:21:18 pm »
But they are almost always the same thing aren't they?  When is an environment variable set '' ever meaningful.
Well in fact it can easily happen, for example in the case of a wxWidgets configuration/version -> wxmsw$(WX_VER)wxmsx$(WX_CFG). Both of them could be empty and it makes sense if you think of using this construct on different platforms and *want* to use env. vars for that purpose - which happens surely.
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Problem with '%' in editor abbreviations
« Reply #9 on: November 13, 2006, 11:50:05 pm »
That would solve the problem in the particular example by Pecan, but not in general. The general problem persists, and cannot be solved, as people expect stuff like $($(TARGET_NAME)_OUTPUT_FILE) to work. This only works because macro replacement (errornously) runs recursively. As long as this is true, we cannot escape the control chars :(

this is only a problem if you recurse on your escape character, which you shouldn't. why not allow a user-definable escape character (some punctuation character that is not in the set of chars that get recursed and, ideally, not in the c/c++ language). you could then convert all of your escapes to something safe for the recursed regex and then convert them to flat text afterwards

BTW, according to the wxWidgets docs:

Quote
wxGetEnv

bool wxGetEnv(const wxString& var, wxString *value)

Returns the current value of the environment variable var in value. value may be NULL if you just want to know if the variable exists and are not interested in its value.

Returns true if the variable exists, false otherwise.

is this broken?

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Problem with '%' in editor abbreviations
« Reply #10 on: November 14, 2006, 02:34:58 am »
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?

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2178
Re: Problem with '%' in editor abbreviations
« Reply #11 on: November 14, 2006, 03:11:22 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"

I've used backticks as a workaround successfully.

Try
Code: [Select]
@test.r$``p
The backticks resolve to empty, and the $ lives (only tested on linux - but could work on windows)

I'm unsuccessful getting backticks to work on abbreviations in windows XP

Anyway to allow %% (as in DOS) to escape substitution?

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: Problem with '%' in editor abbreviations
« Reply #12 on: November 14, 2006, 04:06:59 pm »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problem with '%' in editor abbreviations
« Reply #13 on: November 14, 2006, 05:59:44 pm »
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.
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Problem with '%' in editor abbreviations
« Reply #14 on: November 14, 2006, 06:08:04 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.

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.
« Last Edit: November 14, 2006, 06:20:57 pm by dmoore »