[ jEdit-devel ] Fixing #define in C mode?

[Marcelo V. <va...@us...>]

Hi there! Cope with me, this is a long e-mail. :-)

I found out I was doing something wrong with the HASH_CHAR(S) thingy
and just fixing the tab character fixed one of the bugs in the C mode.
So disregard the patch I sent yesterday. :-)

My next pet peeve if fixing #define highlighting in C mode (bug
1658252). Take this as an example:

#define	LONG_DEFINE(a,b)	{	\
	int i;				                \
	for (i = 1; i < 2; i++) {	           \
		break;			             \
	}				               \
}

#  define    X   Y

#include <net/if.h>

int main(void) {
	bool include;
	return 1;
}


The current mode uses a EOL_SPAN_REGEXP, which highlight the whole
first line as KEYWORD2 and breaks bracket matching. This is wrong,
since after the #define we basically have C code.

Now I found two ways to fix it, but both have caveats.

The first one is very simple. Just use "MARK_FOLLOWING". This changes
the way the # char is highlighted (currently it's different than the
directive; "MARK_FOLLOWING" just makes the # and the directive the
same color). This has one caveat: "# define" is not highlighted.

The second one is to just highlight "#" and treat the rest in the top
level mode. This has a couple of caveats.

First one is #include. The problem is the current hack that makes the
"if" in "#include <net/if.h>" not be highlighted as a keyword. To
support that, I found three solutions:

- not do the hack and live with <net/if.h> being highlighted weirdly. (1)
- highlight "#include" differently than other pre-processor
directives, using an EOL_SPAN_REGEXP. (2)
- try to highlight "#include" correctly, but break other places where
the word "include" is used.

The second caveat is that the available directive are now keywords in
the top-level mode, not just under CPP. That makes them highlighted
even when they should not be. The ideal case would be delegate to CPP,
but that doesn't seem to work as expected since the token marker never
seems to get out of the CPP mode in that case (because "SEQ" has no
end?).

I'm attaching a patch to c.xml that shows these options (see the
comments). (1) is the patch as is, the other two are commented out.

Does anybody know if there are other options to the above? It seems
adding features to the parser rules would help, like:

- have a special value for DEFAULT that triggers the end of a
delegate. This would fix the marker never returning from the CPP rule
set when delegating from a SEQ.

- have MARK_FOLLOWING allow marking the match and the following token
with different styles.

- an option for MARK_FOLLOWING to mark the next non-whitespace token.

What do you guys think?

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."