Editor Bug

[Max]

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

[thomas]

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

[Max]

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!!   

Bye

Massimo

[mandrav]

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?

[thomas]

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.  :?

[takeshimiya]

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.

[thomas]

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.

[tiwag]

i vote for

Code

$(VAR)

 

[takeshimiya]

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:

[sethjackson]

I vote for $(VAR) too......

[thomas]

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.

[takeshimiya]

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:

[thomas]

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.

[takeshimiya]

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.

[thomas]

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.