Alright, that makes sense, thanks. But I still have one extra issue… let me get another example.
Here I am on another sheet that is not the Root.
Ok, got it.
This dot in front does all the magic.
If I use * directly I am using wildcard instead of regexp, and this is messing up with my pattern.
thanks @craftyjon all good now!
2 Likes
Just to clarify for other users.
The field supports both Wildcard AND Regexp.
This is a powerful feature since it allows you to pick the pattern you want.
However, this time, since the Wildcard * was giving results, it messed up with my understanding of the regex. The way to “make the field” interpret regexp is starting the pattern with a regexp which instead would be .* and not just *
I believe this confusion would have not happened if the * resulted in zero matches. But yeah, this is definitely my mistake.
1 Like
And to clarify further: it’s not possible to mix regexp and wildcards in one pattern. Both are tested, but only one type at a time for the whole pattern. The whole pattern is tested as a regexp. The whole pattern is tested as a wildcard pattern. But not so that one part of the pattern could be wildcard and the other part regexp.
1 Like
True, but to clarify, this is something that I did understand before!
Now, what I did not see at that time is that a “broken” regexp was returning matches. So I did not see it as a broken regexp but a working regexp.
It is a powerful thing. But it was confusing, to say the least.
You may think you were using wildcard, but when KiCad is doing regexp test it sees * as * in any regexp, whatever it means in that particular regexp syntax dialect. When it’s doing wildcard test it handles * as the wildcard but the last characters in your pattern are literal in wildcard syntax, so it doesn’t match any of the net names.
To be more specific: *USB_conn_D[+-] (without the period in front) is an invalid regex, because the * character acts on the previous character (so having it at the start, with no previous character, is invalid). So, KiCad will try it as a regex, note that it is invalid and can’t be evaluated as a regex, and so only use it as a wildcard expression.
https://www.regexpal.com/ is a handy tool for debugging / composing / testing regexes.
2 Likes
Not only that.
It is an invalid Kicad Wildcard-Regexp mixed thing (which is actually a horrible thing behavior, it should use only regexp). Because it starts with an invalid regexp which is actually a wildcard and ends with a regexp-like syntax but it is late since the field was already evaluated as a wildcard and this may not result in what the user is looking for.
This is somewhere in between a broken regexp and an expression with wildcards. Horrible, to say the least. Because we (I) don’t expect a broken regexp resulting matches.
Also, this doesnt help… because I know how to use regexp. But I do make mistakes of course. And when I make mistakes I see issues or no output then I iterate. But when I did a mistake using this mixed Wildcard-Regexp syntax I could not see any mistake.
Based on this and your post in another thread I feel I must say this again: it’s not mixed syntax. It’s either or. KiCad tries both styles, but it doesn’t switch the style in the middle of the pattern string. It switches the style only after going through the whole string in one style and deciding if it matches or not. Then it reuses the same string for the other style.
You can try to mix styles or think that styles are mixed, and a human being can see they are mixed, but KiCad sees only one syntax for one pattern at a time.
It would be correct to say that you can mix syntaxes in the whole bunch of several pattern strings (seen as lines in the dialog), but only change syntax between patterns, between lines in the dialog.
I think it’s important to make this as clear as possible because it’s not clear what you really mean from what you say, and future readers who don’t know how this works may be led astray.
2 Likes
Yes, this is the code point of view. Not the user’s point of view. Because an issue with a bad Rexgexp is not rendering a bad regexp result, but selecting the other format. In other words, it is a hidden selection triggered by the content. I get that, I am fine with that, since now I understood that. But accepting both is poor. The field should accept regexp only since it is more powerful, to get rid of confusion. But anyways, I will deal with it, it is fine.
Regex is more powerful but is also much more error prone and usually a simple wildcard is enough.
Instead of eliminating choice I would prefer having it be made an explicit choice with a toggle button that turns on regex but is otherwise wildcard only.
1 Like
Yeah, that would be a much more reliable and easy to understand solution for the user point of view.
The current solution is really smart, but it is confusing because we don’t know (easily), when we make mistakes, that it is matching an expression with regexp or a wilcards.
Also, the hirerarchical design did play a bit of noise when I was experimenting with this due to the inicial character of the sheet regarding if it is a local search or a global search. It is using something like Unix paths, which is awesome. I just didn’t know.
Also, another issue is that, sometimes the matching expression returned labels, but none were being market with the net class I was selecting, because maybe they were local and the wire/label were being renamed assigned with the global name. and then the setup was not doing what I wanted.
Or perhaps an indicator which kind of match it will be, thus serving as a check.
1 Like
I don’t think that’s feasible. A string can be valid regexp and valid wildcard expression. KiCad can’t make the decision. For each matching net name there could be an indicator telling which kind of expression matched (first), but how helpful would it be?
Show the one that will take precedence. I think writing an expression that can be both is bad practice. If it’s a valid regex the code should not try wildcard after that.
Why not develop some examples? Sorry, I have to go get dinner. 
Let’s take for example
a*c
It’s a valid wildcard expression which matches “aac”. It’s also a valid regexp which matches “aac”. Which one is it? At the moment it doesn’t matter. There’s no precedence or choice.
Are you saying that if the pattern is a valid regexp, the meaning of it should be fixed for all future uses? So that the same pattern could be used only as a regexp for all comparisons? That would make wildcards almost impossible to use because * and ? are almost always valid in regexp (the beginning of the expression is an exception for both).
I’ll leave you and others to work it a suitable proposal to remedy the shortcomings. Maybe you should start a new thread in Feature Chat. I’ll have to go practice pugilism on my belongings. And Christmas isn’t close either. No gerbers for me in the near future, but maybe some burgers. 
I can summarize some ideas:
- indicate which method is being matched, somehow, with colors or a label.
- an explicit way to specify the intended syntax so the user will be asking for a particular way to interpret. maybe a checkbox for the regexp while the default is interpreting wildcards.
- I personally would make a field that accepts regexp only
- A link/button with a popup describing the syntax with some examples as we have on DRC rules, would be and alternative too so it could include one or 2 examples of the mistakes that may result positive matches even if a broken regexp is being interpreted as a wildcard expression.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.