Problem with '%' in editor abbreviations

[Pecan]

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

[thomas]

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.

[mandrav]

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?

[thomas]

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

[mandrav]

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.

[thomas]

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.

[Game_Ender]

But they are almost always the same thing aren't they?  When is an environment variable set '' ever meaningful.

[thomas]

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".

[MortenMacFly]

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.

[dmoore]

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:

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?

[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]

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

@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?

[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]

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.

[dmoore]

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.

[thomas]

Well, I implemented it a few weeks ago... replaced '$$' with '\b' before doing variable expansion, and replaced '\b' with '$' after variable expansion.
It did not work, and that was because the same string was being expanded again.
One could leave the "special char" as it is, or one could substitute back to the escape sequence. That would work, but then client code would have to manually strip each string as the last thing, which is not good (error-prone).

[mandrav]

Well, I implemented it a few weeks ago... replaced '$$' with '\b' before doing variable expansion, and replaced '\b' with '$' after variable expansion.
It did not work, and that was because the same string was being expanded again.
One could leave the "special char" as it is, or one could substitute back to the escape sequence. That would work, but then client code would have to manually strip each string as the last thing, which is not good (error-prone).

What 's wrong with the standard escape char '\' ?
The easiest thing to do is to add this escape char in the regular expressions: just put something like [^\\]* at the start of each regex and there you go. Am I missing something?

[thomas]

It doesn't matter what you use. If you add '\' as escape char, you will have to remove it in the end, as you don't want it to appear in the final output.

[mandrav]

It doesn't matter what you use. If you add '\' as escape char, you will have to remove it in the end, as you don't want it to appear in the final output.

Right, but *in the end*. Right before the result is returned, a replace runs and changes \$ to $ (and \% to %). What's so complicated about that?

[dmoore]

What 's wrong with the standard escape char '\' ?
The easiest thing to do is to add this escape char in the regular expressions: just put something like [^\\]* at the start of each regex and there you go. Am I missing something?

The problem with \ as an escape char is that if it is used for windows paths and c/c++ string literals. e.g. "This is the path to a source file in the root folder \\\\$PROJECT_FILE"

Backslash could be offered as a standard escape character (with a corresponding pre-compiled regex if speed is a concern), but there should be a way to specify an alternative escape string for some purposes.

What's so complicated about that?

i think the complication is this:

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),

until this is fixed, one could make not handling escapes the default behavior of the macro manager variable replace function (by adding optional argument for an escape string whose default value is an empty string)

[Pecan]

Resolved: thomas fixed this in SVN 3222

thanks thomas