I am using Sublime Text 3 as a PHP editor, I've been customizing the PHP.tmLanguage file to include more syntax scopes, right now I cannot figure out how to capture class method invocations.
$html = new HTML("hr");
$html->output_ml("moo");
output_ml is currently declared as scope variable.other.property.php
I would like to add a scope to pertain to specifically to class method calls, but I am having trouble defining the regex in the tmLanguage file.
I've tried
<dict>
<key>match</key>
<string>(?i)\$[a-z_][a-z0-9_]*->([a-z_][a-z_0-9]*)\s*\(</string>
<key>name</key>
<string>meta.method-call.php</string>
</dict>
You were pretty close, I just tweaked a few things:
(?i:(?!\$[a-z_][a-z0-9_]*->)([a-z_][a-z_0-9]*)\s*\()
First thing I did was wrap the entire expression in the "case-insensitive" modifier, just so nothing got missed. Probably not necessary, but whatever. Second, and more importantly, I took your first group that was outside of parentheses, and made them a negative lookahead. This way, they match the class name and the arrow, but don't report it - basically saying "match whatever is ahead of us as long as we exist in front of it, but don't match us."
Now, you'll have a scope that matches just the method's name.
Demo
Now, here's what I don't get - why you should have to do this. I maintain both a language syntax and a color scheme, so I have a lot of experience with scoping in Sublime Text and TextMate. And to my knowledge, the PHP .tmLanguage already includes scopes for function calls. I'm not a PHP expert by any means, but I know the basics, so I made three examples of different PHP function calls:
Green highlights a large variety of function calls in different languages. In the top example, baz_quux is scoped as meta.function-call.object.php, in the middle example it's meta.function-call.static.php, and in the bottom it's just meta.function-call.php. I don't understand where you're getting variable.other.property.php from.
However, if I take away the parentheses after the function calls above:
I get the following scopes, from top down: variable.other.property.php (aha!), constant.other.class.php, and constant.other.php. If I put the parens back, and add a space or three after the end of the function name, they are still highlighted as functions, in green.
So, while we had some fun with regexes today, ultimately your work has already been done for you. If you're going to be doing more scope-hunting, I highly recommend the ScopeAlways plugin, which, like its name implies, always lists the full scope of the current cursor position in the bottom bar (you can turn it off via the Command Palette if you want). If I get a request to expand my color scheme's highlighting to a new language, I just open up as much code as I can find and poke around with my mouse, looking at the different scopes, then editing my theme to correct colors as needed, or add new ones for brand-new scopes. I then scan through the .tmLanguage file (after converting it to YAML) and see if I missed anything.
Good luck with your work!
Related
We are looking for a PHP linter, and we are chasing a particular problem that's causing E_NOTICE's, a lot of them:
if($undef_variable)...
if($assoc['undef_key'])...
$undef_variable?...:...
$assoc['undef_key']?...:...
Functionally, the code works perfectly so if the tools was also able to replace on-the-fly such occurences with i.e.
if($undef_variable??null)
That would be a huge help.
Some of the code is in templates that are in included with some pre-set variables (always the same). So ideally the tool would also allow configuring some available global-namespace variables.
The tool should absolutely understand PHP7 syntax, especially anonymous functions.
At a minimum, we need to generate a list of every occurence where a variable is used as a boolean condition and is not defined in the same scope, and every occurence where an array key is used as a boolean condition.
Phpcs- PhpCodeSniffer can be used for that. You need to configure a rule for that. Find it here - Phpcs
Check this rule -
https://github.com/sirbrillig/phpcs-variable-analysis
If you use PhpStorm, it has an option in Inspections. https://www.jetbrains.com/help/phpstorm/php-undefined-variable.html
I am editing a Vim color scheme for PHP. Why are variables such as $_POST and $_SESSION categorized as statements? They use the same color as if statements, for example. Other variables will have a different coloring. Also, the dollar sign is categorized as statement.
How do I change the coloring of these separately?
You need to find out which syntax group causes the highlighting. :syn list shows all active groups, but it's easier when you install the SyntaxAttr.vim - Show syntax highlighting attributes of character under cursor plugin.
For me, this results to the following mappings (Vim 8.0.55):
"if": phpConditional -> Conditional links to Statement
"$": phpVarSelector -> Operator links to Statement
"POST": phpIntVar -> Identifier
In general, colorschemes define a basic set of styles, for example Constant, Identifier, Statement. Then, (still generic) variants are defined: String is-a kind of Constant. Syntax plugins then link to one of those. Your can see that for PHP in $VIMRUNTIME/syntax/php.vim, in the :hi def link commands in the bottom of the script.
That gives the user several ways to configure the highlighting: If you don't see String as a kind of Constant, you can redefine that link, or override with a new custom style, and it will apply to all sorts of syntaxes. If you just want to tweak a certain language element (like phpIntVar), you can change that link, and it will be only for PHP and that element. And all of that can be done in your ~/.vimrc!
I'm trying to store some meta data about CSS styles, which our app can use to build menus that allow the user to select those styles (amongst other things).
I thought the JavaDoc style comment was the best approach, and use an attribute like config or similar. Then store a JSON style definition as the value of that property.
I've been trying to write some RegEx (PHP) to do the following:
Find all JavaDoc comments with #config attribute.
Extract the value of #config as the JSON object
Then match the following css TAG and CLASS names if they are defined under it.
So this comment and class definition could be extracted into 3 matches.
/**
* #config {name:'Orange Title', order:1}
*/
h1.title_orange {
}
Match 1 : {name:'Orange Title', order:1}
Match 2 : h1
Match 3 : title_orange
What makes it more complex is the JSON part could be multiline, and the multilines may or may not contain the *.
The biggest task is on the assumptions you make (which things to test):
(?:^\/\*\*[\s\n\r]+\*\s#config\s(.*)$|^\s+\*\/[\s\n\r]+[\#\.]?([\w-]+)\s*(?:[\#\.]*([\w-]+)\s*)*{$)
You can test it in this Rubular.
I assumed that you have config in the first comment line of the javaDoc, I also assumed that you may have multiple spaces randomly between these, that your words/classes/ids may have -.
What more do you need?
EDIT
This works great in Rubular. Although regex should be the same across languages, this doesn't seem to work in PHP Live Regex – Alexander 4 mins ago
You're right, so I compacted it into one match group and this one seems to be working (you have to click preg_match_all tab):
\/[*]{2}[\s\n\r]+\*\s#config\s(.*)[\s\n\r]+.*[\s\n\r]+\*\/[\s\n\r]+[\#\.]?([\w-]+)\s*(?:[\#\.]*([\w-]+)\s*)*{
Which means, I am considering the javaDoc and the CSS together (javaDoc with several lines). Still, there may be adjustments that need to be made.
EDIT2
Thats amazing, thanks so much! What if the #config wasn't always the first entry in the comment? Is that still possible ? – Matt Bryson 7 mins ago
It is:
\/[*]{2}(?:[\s\n\r]+.*)*[\s\n\r]+\*\s#config\s(.*)[\s\n\r]+.*[\s\n\r]+\*\/[\s\n\r]+[\#\.]?([\w-]+)\s*(?:[\#\.]*([\w-]+)\s*)*{
You can try this one PHP Live Regex in preg_match_all tab.
EDIT3
Matt evolved his own regex to something simpler. The problem seems that the capture groups cannot be repeated indefinitely with this (to get all CSS classes/ids):
(?:[\#\.\,]([\w-]+)\s*)*
https://regex101.com/r/jM0yH0/6
Therefore, this still needs to be solved...
I wanted ST3 to include the "$" when selecting PHP files so I edited word_separators by removing $ as such :
"word_separators": "./\\()\"':,.;<>~!##%^&*|+=[]{}`~?"
And now it highlight the whole varibale including the "$" when double clicking a variable. However, now Sublime is not matching/outlining those variables using the default match_selection functionality.
Any thoughts on this? Is there a setting I am missing. Much appreciated.
Please see my answer to this question for an in-depth look at the effect of changing word_separators and various find and select options. Long story short, altering word_separators changes the behavior of double-clicking, as you noted, but other operations, including match_selection, rely on an internal word separators list that apparently can't be altered by the user. So, when you double-click to select a PHP variable, you'll get the $ selected, but other instances of the variable won't be highlighted. They will be selected when using CtrlD to make multiple selections, however:
Additionally, when using the Find dialog, other instances will be highlighted:
So, to address your original problem, if you need to see all the instances of the currently-selected variable, set "find_selected_text": true in your user preferences, double-click to select your variable of interest, then hit CtrlF (⌘F on OS X) to view all occurrences. Just make sure you don't have the regex search button selected, as $ has a special meaning in regexes.
I want to embed in a page a detailed structure report of my model objects, like print_r() or var_export() produce (now I’m doing this with running var_export() on get_object_vars()). But what I actually want to see is only some properties (in most cases), but at this moment I have to use Ctrl+F and seek the variable I want, instead of just staring at it right after the page completes loading. So I’m embedding buttons to show/hide large arrays etc. but thought: ‘What if there already is the thing I do right now?’ So is there?
Update:
What would your ideal interface look like?
First of all, dumped models fit in the first screen. All the properties can be seen at the first look at the screen (there are not many of them, around 10 per each, three models total, so it is possible). Small arrays can be shown unrolled too. Let the size of the array to count it as ‘small’ be definable. Ideally, the user can see values of the properties without doing any click, scrolling the screen or typing something.
There must be some improvements to representing the values, say, if an array is empty, show
array ‘My_big_array’ is empty
and if a boolean variable starting with is_, has_, had_ has a false as the value, make the variable (let us take is_available for example) shown as
is_NOT_available
in red, and if it has true as the value, show
is_available
in green. Without any value shown. The same goes for defined constants.
That would be ideal.
I want to make focus on this kind of switches.
Krumo seems useful, but since it always closes up the variable without making difference of how large it is, I cannot use it as is, but there might appear something similar on github soon :)
Second update starts here:
Any programmer who sees is_available = false will know what it means, no need to do more
Bringing in color indication I forgot about one thing: the ‘switches’ let’s call them so, may me important or not. So I have right now some of them that will show in green or red, this is for something global, like caching, which is shown as
Caching is… ON
with ‘ON’ written in green, (and ‘OFF’ in red when disabled) while the words about what it is, i.e. ‘Caching is… ’ are written in black.
And some which are not so important, for example I haven’t defined
REVEAL_TIES is… not set
with ‘not set’ written in gray, while the words describing what it is stay in black. And if it would be set the whole phrase would be in black since there is nothing important: if this small utility for showing some undercover things is working, I will see some messages after it, if it isn’t — site will be working independently of its state.
Dividing switches into important ones and not with corresponding color match should improve readability, especially for those users who are not programmers and just enabled debug mode because some guy from bugzilla said do that — for them it would help to understand what is important and what is not.
A big thanks to all who replied.