Description: The standard KDE Makefile highlighter is mostly reflex based — it sees tokens and words, and colors them. My problem was its lack of understanding of nesting, and the resulting garbling of nested function calls.
This remake uses the state machine approach much more — it actually understands syntax (e.g. nesting), and will mark some of your syntax errors.
There was a KDE feature request for which I submitted this fix: https://bugs.kde.org/show_bug.cgi?id=144142 However, this is a fix for so much more, and it has yet to be commented after 5 months.
How to install: Replace the default makefile.xml in /usr/share/kde4/apps/katepart/syntax/ with mine.Last changelog:
2.2 This version is dedicated to zaufi. Massive thanks for sending me that crazy real-world testcase! I have implemented every bit of it to the best of my knowledge.
* Fix: In recipes, or as termination of recipes, permit leading spaces in front of keywords (like ifdef), comments, new rules and assignments. Leading spaces are sometimes used inside ifdefs. * Region markers for ifdef, define * Comment alerts * Green colored shell both in recipes and the $(shell function,call). Primitive highlighting of shell syntax (inclusion of bash.xml proved futile). * Orange rules, with purple special targets (.PHONY). * Cyan builtin variables for $(CC) $(LD) $(RM) etc. These barely stand out from the blue ordinary ones. * Cyan bold special variables like $< $^ $@ $(SHELL) $(MAKE). These are more screaming. * In-variable pattern substitution $(origin:%=prefix%suffix) * Differ between immediate and deferred assignment. * Random adjustments all over the place.
2.1 * Look for comments before looking for rule defs. (thanks, zaufi) * Use custom style for error marking. (thanks, zaufi) * Adjust extensions & priority so that makefile.inc and makefile.xml are recognised as makefile and XML respectively (instead of PHP and makefile). * Removed silent operator '@' from normal mode (probably a leftover from old design).
2.0
There are mainly 2 things I have refactored from the 1.12 version I started with, plus some random fixes.
Main thing 1: Expand the state machine to identify prerequisites and rule definitions. This allowed me to: * mark leading spaces as errors in rule definitions (Finally!) * don't recognise keywords in rule definitions * don't recognise keywords, singlequotes or doublequotes in prerequisites * color prerequisites (default color for data types (blue))
Main thing 2: Rework how variables and function calls are recognised. * don't distinguish callsites of functions (don't neglect functions in rhs of assignments) * distinguish function calls from variables in an intermediate "call" state (stop looking for function names in variables) * test what comes after the $ sign in an intermediate "dollar" state (simplified many other states) * recognise unparenthesized variables e.g. var$iable means var$(i)able * recognise computed variable names e.g. $(var$(i)able)
Random fixes: * mark illegal characters in variable names (whitespace, =, :, #) * add the "override" keyword * make the "filter-out" function work (the only with a dash in its name) * color assignment operators (=, +=, :=) like operators, not as strings * recognise singlequoted strings in function parameters * recognise doublequoted strings in commands * color commas in function calls * color the whole command if the silent operator @ is prepended to it
0) if comments (lines w/ '#' as first noncpace char) contains a ':' symbol they higlighted as targets (not as comments!)
1) I still can't see error highlighting when spaces mixed w/ tabs (particularly spaces before tabs in rule definition)
0) Will fix. Thanks, that was embarrasing ;)
1) Works for me.
Leading spaces in rule defs are marked with the default "Error" style (red underline, in my case).
How is your "Error" style? (Settings → Configure Editor → Fonts & Colors → Highlighting Text Styles)
It needs to be underlined to be visible on spaces. I could make a custom style.
Hi!
I've played w/ 2.1 version and still found few problems w/ it... Some of them are:
0) it is Ok to use a backslash to continue dependency list on a next line, but it displayed as error in that case:
some-target : dep1 dep2 ... depM \
<spaces-here> depN ... depZ
<-tab->@rules goes here
1) it is not required for target names to be the first symbol on a line
target-1-displayed-ok : blah
<spaces> target-2-not-higlighted : blah-blah
sometimes it is convinient to have indented target definitions due `if' conditions...
btw, even if target name is at position 0, the following snippet displayed incorrectly:
target: blah
<-tab-># empty rule... just target (deps) declaration...
<spaces> # just a comment w/ leading spaces...
2) static pattern rules are diplayed strange (see 4.12.1 of `info make`) -- I guess better to introduce a few types (attributes) for different kind of rule declarations
3) the following snippet has strange (incorrect) higlighting @ 2nd line:
foo:= a.c b.c c.c
bar:= $(foo:.c=.o)
4) the following snippet is valid, but displayed incorrectly:
all:;echo $(foo)
moreover if next line starts w/ leading spaces it will be displayed as error, which is obviously incorrect as well...
also here is a whishlist :)
* it would be neat to higlight special targets (like .PHONY, .DEFAULT, & etc)
* also it may helps to higlight predefined make variables (like MAKELEVEL, MAKEFILES, etc) to make 'em visually diferent than a usual one...
* "10.5.3 Automatic Variables" (like $@, $<, $(D), etc)
* maybe "10.3 Implicit Variables"
* it would be nice to reuse bash.xml somehow to higlight a rules...
btw, I have some legacy project w/ a sophisticated makefile(s) (in fact a whole build system like autotools was implemented on pure makefiles), so you may play w/ higligting on it...
just give me a mail where I can send some files for you...
Ratings & Comments
5 Comments
0) if comments (lines w/ '#' as first noncpace char) contains a ':' symbol they higlighted as targets (not as comments!) 1) I still can't see error highlighting when spaces mixed w/ tabs (particularly spaces before tabs in rule definition)
0) Will fix. Thanks, that was embarrasing ;) 1) Works for me. Leading spaces in rule defs are marked with the default "Error" style (red underline, in my case). How is your "Error" style? (Settings → Configure Editor → Fonts & Colors → Highlighting Text Styles) It needs to be underlined to be visible on spaces. I could make a custom style.
Hi! I've played w/ 2.1 version and still found few problems w/ it... Some of them are: 0) it is Ok to use a backslash to continue dependency list on a next line, but it displayed as error in that case: some-target : dep1 dep2 ... depM \ <spaces-here> depN ... depZ <-tab->@rules goes here 1) it is not required for target names to be the first symbol on a line target-1-displayed-ok : blah <spaces> target-2-not-higlighted : blah-blah sometimes it is convinient to have indented target definitions due `if' conditions... btw, even if target name is at position 0, the following snippet displayed incorrectly: target: blah <-tab-># empty rule... just target (deps) declaration... <spaces> # just a comment w/ leading spaces... 2) static pattern rules are diplayed strange (see 4.12.1 of `info make`) -- I guess better to introduce a few types (attributes) for different kind of rule declarations 3) the following snippet has strange (incorrect) higlighting @ 2nd line: foo:= a.c b.c c.c bar:= $(foo:.c=.o) 4) the following snippet is valid, but displayed incorrectly: all:;echo $(foo) moreover if next line starts w/ leading spaces it will be displayed as error, which is obviously incorrect as well... also here is a whishlist :) * it would be neat to higlight special targets (like .PHONY, .DEFAULT, & etc) * also it may helps to higlight predefined make variables (like MAKELEVEL, MAKEFILES, etc) to make 'em visually diferent than a usual one... * "10.5.3 Automatic Variables" (like $@, $<, $(D), etc) * maybe "10.3 Implicit Variables" * it would be nice to reuse bash.xml somehow to higlight a rules...
btw, I have some legacy project w/ a sophisticated makefile(s) (in fact a whole build system like autotools was implemented on pure makefiles), so you may play w/ higligting on it... just give me a mail where I can send some files for you...
You can find me in makefile.xml. You had lots of suggestions here, will look into it ;) If this takes off, I might put this in a git repo…