Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: Max on October 18, 2006, 03:06:11 pm
-
Try this: (Windows XP SP2 and latest nightly 3099)
a) define an abbreviation (Settings->Editor->Abbreviations). For example
/*
$a:$
$b:$
$c:$
*/
call it 'test' (or whatever you want)
b) In any opened file type test then Ctrl-J
c) The inserted text will be
/*
:$
$b:$
$c:$
*/
You can try several abbreviation name or contents. The result is always the same:
The first string after the first '$' , including it, will disapper.
I am used to insert RCS header in any file like
/*
$Author: $
$Date: $
$Revision: $
$Log: $
*/
This bug does not permit any abbreviation of this kind.
The bug appears recently, during the last week. Older nightly worked correctly.
May you confirm?
Bye
Massimo
-
This one is not a real bug, but a feature. Abbrevations support variable expansion since one or two weeks, to comply with the requests to be able to insert a datestamp or similar.
One consequence of this feature is that things that look like variables are treated as variables, too.
The substring $a will be interpreted as variable (delimited by ':'), and the $ followed by \n will be interpreted as verbatim $ (since there is no variable name following). Since $a is undefined, $a:$ expands to $:$.
There are two possible solutions:
1. Find a way to escape the dollar sign, this has already been tried in another context. It is hard to achieve that without rewriting the whole macros manager.
2. Write $ a: $ instead of $a:$ as this will be interpreted as "dollar-sign a" rather than "variable-a".
-
There are two possible solutions:
1. Find a way to escape the dollar sign, this has already been tried in another context. It is hard to achieve that without rewriting the whole macros manager.
2. Write $ a: $ instead of $a:$ as this will be interpreted as "dollar-sign a" rather than "variable-a".
Unfortunately both seem not applicable. The revison control application is waiting for $Author, $<space>Author means
nothing for it.
Anyway there is a workaround. If I insert the RCS header in the "Defalt Code" editor option I am able to insert the whole header in the C/C++ files. It seems that the "default code" is not parsed for macro. Unfortunately creating an header file
the defalt code is ignored (a quite old bug).
Do the developers plan to introduce the macro parsing in the "default code" as well? In that case the only solution is to
write the whole header manually or, better, using a snippet.
Hopefully the snippet will be not parsed for macro in the future!! :D
Bye
Massimo
-
I 've been in a similar situation myself.
The easiest thing I can think of to fix this, is to remove $VAR syntax from being a variable. Currently, all the below forms are treated equivalently:
$VAR
$(VAR)
${VAR}
%VAR%
The problem is that although I never use the $VAR form myself, there may be others that do. So while that would solve your problem, it might make things uncomfortable for others.
Another fix that crossed my mind while I was writing this, is to alter the MacrosManager to not substitute unknown macros. So if there is no macro $VAR defined, then no substitution takes place. Any thoughts from other developers on this?
-
Solution 1 would mean that I would need to edit *every* project of mine.
Solution 2 is problematic, since you also want environment variables to be substituted, this won't work any more.
When this issue first came up, my strategy was to esacape '$' with some sequence (for example "$$") and to replace '$$' with some other token that does not occur normally ('\b') as the first thing. After variable expansion, replace the substitute back to '$'.
Actually a trivial thing to do, but it does not work because the macros manager is called multiple times with the same string. :?
-
I 've been in a similar situation myself.
The easiest thing I can think of to fix this, is to remove $VAR syntax from being a variable. Currently, all the below forms are treated equivalently:
$VAR
$(VAR)
${VAR}
%VAR%
The problem is that although I never use the $VAR form myself, there may be others that do. So while that would solve your problem, it might make things uncomfortable for others.
Four variations of the syntax to declare a variable is a plus on flexibility but a loss on consistency and more important, unexpected behaviors, for example I didn't knew the %VAR% syntax and it will be replaced.
For me, the best thing would be to use only one syntax, either $(VAR) or ${VAR}.
Another fix that crossed my mind while I was writing this, is to alter the MacrosManager to not substitute unknown macros. So if there is no macro $VAR defined, then no substitution takes place. Any thoughts from other developers on this?
I can think both scenarios where one might want one behavior or another, but this doesn't means anything.
-
Takeshi is right, we should only use one syntax for consistency, and render 75% of the exising projects useless. Sounds like a good plan to me.
I vote for ${VAR} on western European keybords because $(VAR) is far too easy to type, we don't want it to happen accidentially! For US layouts, we'll have to think of something more complicated.
-
i vote for
:P
-
Takeshi is right, we should only use one syntax for consistency, and render 75% of the exising projects useless.
NO!
Only for projects minor > "5" version. Else it will render 45% of the exising projects useless.
I vote for $(VAR)
too :twisted:
-
I vote for $(VAR) too......
-
While we are at it: Considering that '#' is a perfectly legal character in an URL and Code::Blocks can operate on URLs, we should use a different symbol for gcvs too. Maybe '!' or 'ß'.
That way, we can render a lot more projects useless than by removing 3/4 of the variable syntax. :)
-
While trying to ignore plain non-sense:
As first-post says, it's very common to use $Variable: $ in RCS headers, I use them always with SVN, good that I didn't use C::B abbreviations.
And again: only for projects minor > "5" version.
It seems I was wrong with the 45% figure, it's 20% :mrgreen:
-
While trying to ignore plain non-sense
Yes, most of us try to do that most of the time, Takeshi.
Instead of leaving out something that people are used to and have indeed been using in projects, the correct solution would be to make it work, in other words find out why and when the same string is expanded multiple times. It is not only the reason why escaping doesn't work, it is also needlessly inefficient.
It is perfectly acceptable to type $$Author$, or more consistently $$Author$$ to get the desired output, as having plain $s is the exception, not the rule, both in compiler options and in abbrevations.
-
Instead of leaving out something that people are used to and have indeed been using in projects, the correct solution would be to make it work,
Yes, it can be made it to work, and that could solve the problem you're referring.
But I'm talking about another different problem: I don't have anything against the syntax $(var), and ${var} because they are strict enough for not having false positives, however the %sometext% syntax is not strict enough but not really a problem; the problem comes with the $Var syntax, because it's very non-strict, it doesn't have a terminator token and it's very easy to have false positives.
Perhaps yes, this is something that should have been discussed when the other syntax got introduced; but Code::Blocks projects are serializable. =P
It is perfectly acceptable to type $$Author$, or more consistently $$Author$$
Well that is what I'm talking about when I say that syntax is very non-strict.
-
however the %sometext% syntax is not strict enough [...]
Perhaps yes, this is something that should have been discussed when the other syntax got introduced
As usual, you are discussing about vain things.
First, there is a good reason why the %VAR% syntax exists. It is the Windows/DOS syntax for environment variables, and as such it is what many Windows devs are probably using (as it is the natural thing to do for them).
Second, this syntax existed well before the macros manager was redesigned and well before anything else, for that matter (revision 521).
People are used to this syntax and without any doubt, many people have been using it for literally years. Taking away something that a user has become used to for such a long time is problematic at best.
-
First, there is a good reason why the %VAR% syntax exists. It is the Windows/DOS syntax for environment variables, and as such it is what many Windows devs are probably using (as it is the natural thing to do for them).
So with that in mind, you can't have abbreviations for batch files right now...
Second, this syntax existed well before the macros manager was redesigned and well before anything else, for that matter (revision 521).
And I really doubt anyone is using it nowadays.
Look, the problem is that different syntax for declaring variables is a half-attempt.
There are two ways that can solve most/all problems:
1) The fixed approach
Have only the $(VAR) syntax for new projects. All previous versions will be either supported, or translated to the $(VAR) syntax.
Code::Blocks projects are serializable.
2) The flexible approach
Let the user define multiple syntax for variables, with tokens or regexs.
Defaulting to:
$(VAR)
${VAR}
$VAR
%VAR%
I personally prefer the 1) approach, but I don't mind as both solves the aforementioned problems.
-
So, no changes as this would possibly break existing projects.
@Takeshi: the reason all these different forms are supported is to let the user choose what he 's more accustomed to. Windows devs probably are used to %VAR% while non-windows devs are used to one of the other three forms.
And I never heard anyone complain about this fact ;).
-
And I never heard anyone complain about this fact ;).
Because it's a minor issue :wink:
-
And I never heard anyone complain about this fact ;).
Because it's a minor issue :wink:
What is an issue? The fact that we support all forms of variables for all platforms? :?:
-
What is an issue? The fact that we support all forms of variables for all platforms? :?:
Well, you know that is common that developers sees something as a feature while others sees it as a bug.
Perhaps this is because in some case scenarios it behaves as a feature while in others it behaves as an issue.
In short, in this case, it's "more than one syntax to do the same" vs. "consistency" and here can be clearly seen that some prefer "consistency" (refer to the "I vote..." posts).
But, anyways, this is a minor "feature/issue" so let's move on to things with more priority. :arrow: