Hello,
I would like to define a function statement to this case:
I'm trying to edit my .uew file and add this:
What I'm looking for is UltraEdit recognize the UPPERCASE words and add them as Keywords.
So, the question is: How do I say to UE to only recognize the UPPERCASE? I mean not to use [A-Z] as [a-zA-z]

Thanks!

What you want is not possible when using the default UltraEdit regular expression engine. But with using the Perl regular expression engine the function strings you need are no problems. Here are the function strings with a short explanation:

/TGFindStr = "(?-i)^(EDIT|END|GRID|OPTIMIZE|PROPS|REGIONS|RUNSPEC|SCHEDULE|SOLUTION|SUMMARY)\>"

(?-i) makes the search case sensitive.
^ means start of line.
(...) tag the string found by the expression inside the round brackets to display only that part of the line in the function list.
EDIT|END|GRID|OPTIMIZE|PROPS|REGIONS|RUNSPEC|SCHEDULE|SOLUTION|SUMMARY the words which must be at start of the line combined with a logical OR.
\> means end of a word.


/TGFindStr = "^(\u+)\>(?<!EDIT|END|GRID|OPTIMIZE|PROPS|REGIONS|RUNSPEC|SCHEDULE|SOLUTION|SUMMARY)"

^ means start of line.
(...) tag the string found by the expression inside the round brackets to display only that part of the line in the function list.
\u+ means find one or more uppercase characters.
\> means end of a word.
(?<!EDIT|END|GRID|OPTIMIZE|PROPS|REGIONS|RUNSPEC|SCHEDULE|SOLUTION|SUMMARY) means the preceding found string is NOT one of these strings. We don't want find the same strings twice.

Thanks, thanks!

But there is an error here:
It includes inside the "Keywords" the words "END", "GRID"... Only excluding is "EDIT". The first one.

Better working is:
Any better way to do it?

A quick test of

/TGFindStr = "^(\u+)\>(?<!(EDIT|END|GRID|OPTIMIZE|PROPS|REGIONS|RUNSPEC|SCHEDULE|SOLUTION|SUMMARY))"

showed me that this is no help. I'm not a Perl expect and therefore don't know why. However, it looks like

/TGFindStr = "^(\u+)\>(?<!EDIT)(?<!END)(?<!GRID)(?<!OPTIMIZE)(?<!PROPS)(?<!REGIONS)(?<!RUNSPEC)(?<!SCHEDULE)(?<!SOLUTION)(?<!SUMMARY)"

works quite well and therefore there is no real nead to search for a better one.

I'll leave it like this: But, I was thinking that it will be nice to add at a space, tab or enter at the beginning of the line.

I've tried to add: at the beginning of the statement... but doesn't work.

Something like: I need to have the [ \t\r\n] or nothing at the beginning of the line in my .DATA files.

Any ideas?

By the way: bulgrien and Mofi, thanks.

Thanks bulgrien for your explanation for the insight why my expression did not really work. Good to know for the future. pepemosca, you could use:
[ \t]* means that 0 or more spaces or tabs can occur between start of line and the first word in uppercase letters.

\r\n should not be inside the square brackets because ^ means start of a line. And where is the start of a line? The start of a line is the first character AFTER \r (MAC), \n (UNIX) or \r\n (DOS). So it is impossible that \r or \n are at start of a line, they define always the end of a line.

\> is very important because it defines where to end the search. Without \> something like ENDBOX would be matched by the section regular expression and on the other hand END would be returned as a valid result from the keyword regular expression.

Additionally as I created some test examples I found out that for the keyword regular expression it is necessary to insert \< before every word in the lookbehind expressions. Otherwise the expression would not find something like FEND because this word ends with the lookbehind word END. The lookbehind expression is evaluated from right to left on the string found by the preceding expression. Therefore just \< is required, but not \>, to avoid wrong exclusions.

Mofi, OK I understand everything except...

In Keyword, why not to add \> to the end of the words that I want to exclude?
Like:

pepemosca wrote:In Keyword, why not to add \> to the end of the words that I want to exclude?

You can do that, but it is not necessary. It does not make a difference if \> is used or not. The only difference would be that the search string is longer and therefore the search would be a little bit slower.

I don't have a deep insight to the Perl engine, but I think lookbehinds are applied from right the left. Let us simplify the expression to

/TGFindStr = "^[ \t]*(\u+)\>(?<!\<END\>)"

and think first how it works on the word ENDBOX. Most right character of found string is X. This character is compared with the negative lookbehind expression string which is simply the string END. X from ENDBOX is not equal D from END. So found string is surely okay. No further test necessary.

Now let us think about found string FEND with most right character is D. Most right character of negative lookbehind string is also D. So there is a match and therefore the next character to left must be analyzed. This is in both strings N, again a match, continue with next character to left, once again a match for E. Now when the lookbehind expression would be just (?<!END)" the negative lookbehind would return here true and FEND would be ignored. But the negative lookbehind expression is (?<!\<END). Therefore the Perl regex engine has to check now, if the E is the first character of the found string which is not the case or the character to the left is a non word character which is also not the case because F is a word character. Therefore the negative lookbehind is false for found string FEND and FEND is not excluded.

The search expression (\u+)\> finds only entire words and the negative lookbehinds are applied always from right to left on the found strings - from end of the words. The first character of the found string not matching the character at same position of the negative lookbehind string breaks further evaluation. Therefore \> is not necessary on the lookbehind strings. This expression returns always true for all found strings here.