An identifier inside a string should be colored as identifier, not as string.
Probably it's related to the execution order applying the colors. Now the string scheme has more importance than identifier, and it should be the opposite. An example:
`"Here is a $variable is inside a string"`
The ideal in this case I believe is firstly applying the string color, and then, applying the identifier color which would let the identifier with a different color even it is inside the string, the point is to call the attention to it. In my editor, it is using the string color, ignoring the identifier color. Outside a string the identifier color is OK, but when inside a string, the priority color used is the string color, not identifier's color.
That's not how things work here, the identifier id either recognized as such anf given a separate style (which we might or might not draw the same as a string), or it's not recognized and thus is considered a string.
Which language do you have issue with?
Bash and PHP are mentioned.
AFAICT bash needs property `lexer.bash.styling.inside.string` set but the default is unset.
Php styles `$word` inside strings as `SCE_HPHP_HSTRING_VARIABLE` so it depends on what it maps to and what the theme set it to.
I use vim and it always color the identifier with a different color. It does not matter if is shell script or php. If geany draws identifier_1 nicely out of the string and do not when the dollar variable is interpolated in a string it is geany weakness and I could myself show how to fix it
Em dom, 28 de abr de 2024 04:47, Colomban Wendling ***@***.***> escreveu:
That's not how things work here, the identifier id either recognized as such anf given a separate style (which we might or might not draw the same as a string), or it's not recognized and thus is considered a string.
Which language do you have issue with?
— Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/3860#issuecomment-2081376204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFZGK2TWL56BEYCLB3STODY7SSPNAVCNFSM6AAAAABG4NXGICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGM3TMMRQGQ . You are receiving this because you authored the thread.Message ID: ***@***.***>
I thank the lexer.bash.styling.inside.string information. How to set it ? If Geany color application followed a simple rule, it would NOT depend on language neither of this config. The algorithm now paits string after the identifier_1 color with is for dollar variables. If just the identifier_1 color were applyed ALWAYS to all dollar variables wherever they are, and AFTER strings where colored, the result would be correct, becase identifier_1 (dollar variables) are more important to have a different color than a string.
In php vim does equal geany, treating all as **keyword** color, **not** uses identifier_1 config. But in shell, it is different.
The problem in shell is that before a variable is "dollared" (identifier_1) it was a simple identifier, without dollar. And identifier color is default, but you can set identifier_1 to be magenta in a green string as I do.
# Shell, bash, sh syntax:
variable="value" #here has no dollar, geany reads variable as a simple **identifier** NOT **identifier_1** echo $variable #after the value, it is **identifier_1**, magenta in my case.
echo "a string with $variable" # Geany do not priorize **identifier_1** that was correct in the 2nd line above, painting green (string):
 
See the sh correct syntax (identifier_1 priority) done by vim: 
An important observation:
For single quoted string 'Single quoted string kills $dollar $vars' it is OK as they kill dollar variables. In this case, the string color is used.
But double quotes "Double quotation keeps the $dollar $variables" they should be colored as identifier_1 as geany does outside the string.
PHP uses "preprocessor" color for the dollar variables, not identifier_1 ( that sh/bash uses )
**The question is:** Why geany can draw php dollar variables interpolated in string correctly, but not for shellscript ?
Try adding this in *filetypes.sh* (you can open it from *Tools → Configuration files → Filetypes configuration files → Scripting languages*): ```ini [lexer_properties] lexer.bash.styling.inside.string=1 lexer.bash.styling.inside.backticks=1 lexer.bash.styling.inside.parameter=1 lexer.bash.styling.inside.heredoc=1 ```
We probably should use all or some by default, we'd just need to check what defaults make more sense, and what the limitations might be.
The bad news is that it doesn't work too. I have added it, closed geany, reopen and all is the same.
One question: what is the correct: altering via Geany Tools, ... or editing directly in the file /usr/share/geany/file... Because opening in Tools, **all lines appear commented** and is is different from the same file in /usr/share/geany/file... What is actually used ?
The bad news is that it doesn't work too. I have added it, closed geany, reopen and all is the same.
<details> <summary>WFM, looks like that:</summary>
Default: 
Adding `lexer.bash.styling.inside.string=1` 
Adding `lexer.bash.styling.inside.backticks=1` 
Adding `lexer.bash.styling.inside.heredoc=1`  </details>
One question: what is the correct: altering via Geany Tools, ... or editing directly in the file /usr/share/geany/file...
Because opening in Tools, all lines appear commented and is is different from the same file in /usr/share/geany/file... What is actually used ?
Both are used together. If something is not defined in the user's configuration, the value is looked up in the /usr/share one (or whatever the Geany installation path is).
All you need to do is go through Tools… and replace the whole content with literally what I mentioned above. Or add it (uncommented) somewhere.
Have done that, opened via Tools, replaced all the file content with the configs you suggested and still not working. I closed geany, reopened, and even think that **bash** is taken by geany as **sh** too ?
if the software prints the **string colors** AFTER **scalar and identifier_1** color, these colors are ovewritten by string color, and that seems to be the deep problem.
WFM.
if the software draws the string colors AFTER scalar and identifier_1 color, these colors are ovewritten by string color, and that seems to be the deep problem.
No it doesn't work like that. What version of Geany are you using?
github-comments@lists.geany.org