Java Function Lists not displaying

DanKirkd · Aug 02, 2006#12006-08-02T03:39+00:00

For some reason my Java code no longer displays functions. This is something I don't use much, so I've only just noticed it. I'm using the version 12.10a of UltraEdit.

Here is the wordfile definition:

Code: Select all

/L4"Java 1.4" Line Comment = // Block Comment On = /* Block Comment Off = */ Escape Char = \ File Extensions = JAV JAVA
/Delimiters = ~!@%^&*()-+=|\/{}[]:;"'<> ,	.?
/Function String = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+[a-z0-9]+[ ^t]+^(*(*[^p]++[~)]++)^)[~;]++$"
/Function String 1 = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+^(*(*[^p]++[~)]++)^)[~;]++$"
/Function String 2 = "%[ ^t]++[ps][a-z]+[ ^t]+^([a-z0-9]+[ ^t]++(*[^p]++[~)]++)^)[~;]++$"
/Indent Strings = "{"
/Unindent Strings = "}"

I've tried shifting code to eliminate leading whitespace, or moving curly braces to the same line as the function/method name, and that doesn't work.

I'm pretty sure this used to work.

Any ideas?

Dan

Mofi · Aug 02, 2006#22006-08-02T10:22+00:00

Some function name examples would be helpful, but I think, I have found the problem.

[~;]++$ is an invalid regex. [~;]++ means find 0 or more occurences of ALL characters except a semicolon. This expression includes also CRLF and so it collects a multiline block until a ; is found and the $ is useless here.

So better use [~;^p]++$ instead of [~;]++$. Now the last search part for function name is restricted to a single line.

DanKirkd · Aug 02, 2006#32006-08-02T10:31+00:00

Mofi, I'll give your suggestion a try, but I'm not sure that's the issue. When I use an older version of UE (v10.20) the function strings I listed above work fine. But against the same code in v12.10 they don't.

I'll report back on your suggestion using v12.10 tomorrow.

Thanks,

Dan

Aug 02, 2006#42006-08-02T10:36+00:00

Further to your reply, this Java method displays fine with the original function strings in v10.20:

Code: Select all

    public static void getCarrierData(HttpServletRequest req, HttpServletResponse resp, 
                                      Message message, DataConnection connection, 
                                      String tableName, String appTimestamp) {
         doSomething();
    }

And the entire method signature is picked up for display when you mouse over the function list entry for it.

Dan

Mofi · Aug 02, 2006#52006-08-02T11:03+00:00

Well, with your example I could test it and have seen an other invalid regex *[^p]++. It's not possible to include a line termination into a normal range of character specification and ^p++ also does not work. From help about UltraEdit style regular expressions:

++ Matches the preceding character/expression zero or more times. Does not match repeated newlines.

If these expressions work with v10.20 then it is caused by a regex bug. I have written several bug reports containing problems with regex and line terminations and the IDM developers has fixed most of them. That could be the reason why your expressions did not work anymore in v12.10a.

Use the following expressions which I have tested with v11.20b and v12.10a on your example:

/Function String = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+[a-z0-9]+[ ^t]+^(*([~)]++)^)[~;^p]++$"
/Function String 1 = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+^(*([~)]++)^)[~;^p]++$"
/Function String 2 = "%[ ^t]++[ps][a-z]+[ ^t]+^([a-z0-9]+[ ^t]++([~)]++)^)[~;^p]++$"

DanKirkd · Aug 02, 2006#62006-08-02T21:24+00:00

Mofi - that did the trick!

Thanks!

Dan

StaticGhost · May 30, 2009#72009-05-30T10:57+00:00

Hi All,

Mofi's function strings here solved this problem for me too. However, in UltraEdit 15.00, it isn't picking up

Code: Select all

	/**
	 * {@inheritDoc}
	 * @see javax.servlet.jsp.tagext.TagSupport#doAfterBody()
	 */
	@Override
	public int doAfterBody() throws JspException {
		return EVAL_BODY_AGAIN;
	}

Any ideas on how the function strings need to be altered for this?

Thanks for any assistance!

Rob

Mofi · Jun 01, 2009#82009-06-01T11:22+00:00

More than 2 years ago (Jan. 2007) I reported to IDM that ^r and ^n are not correct interpreted when using them in a regular expression for function strings in the wordfile while they are correct interpreted when running a manual regular expression find. ^r in a regex string in the wordfile is interpreted as character r and ^n as character n instead of CR and LF. IDM has not fixed that issue till now.

The workaround is to use ^p instead of ^r^n which seems to be interpreted in a function string regular expression string as general line ending character because it works for DOS files as well as UNIX and MAC files opened with or without temporary conversion to DOS. That is maybe the reason why IDM has never corrected it. There is no need for using ^r and ^n in the regular expression function strings in a wordfile when ^p matches all type of line endings.

I have corrected all posts above where ^r^n was used instead of ^p.

DanKirkd · Jun 02, 2009#92009-06-02T02:16+00:00

Hmmm...

My function strings already use ^p:

Code: Select all

/Function String = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+[a-z0-9]+[ ^t]+^(*(*[^p]++[~)]++)^)[~;]++$"
/Function String 1 = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9]+[ ^t]+^(*(*[^p]++[~)]++)^)[~;]++$"
/Function String 2 = "%[ ^t]++[ps][a-z]+[ ^t]+^([a-z0-9]+[ ^t]++(*[^p]++[~)]++)^)[~;]++$"

I can't get it to find any functions in my Java source with v15.00.0.1046

Dan

StaticGhost · Jun 02, 2009#102009-06-02T21:21+00:00

Hi All,

Well, it works for me now after I replaced ^r^n with ^p - even though I could see multi-line functions ok, it was several single line functions that were not displaying!

I made a further correction to the function strings so that they pick up Generics (Java 5+).

Code: Select all

/Function String = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9<,>]+[ ^t]+[a-z0-9<,>]+[ ^t]+^(*([~)]++)^)[~;^p]++$"
/Function String 1 = "%[ ^t]++[ps][a-z]+[ ^t]+[a-z0-9<,>]+[ ^t]+^(*([~)]++)^)[~;^p]++$"
/Function String 2 = "%[ ^t]++[ps][a-z]+[ ^t]+^([a-z0-9<,>]+[ ^t]++([~)]++)^)[~;^p]++$"

Rob

DanKirkd · Jun 02, 2009#112009-06-02T22:13+00:00

That seems to work. Thanks.