bug#19882: 25.0.50; Backwards font-lock regex in m4-mode

[Marcin Borkowski]

On 2015-02-16, at 11:32, Rupert Swarbrick <ruperts@broadcom.com> wrote:

> In m4-mode.el, the last two sexps in m4-font-lock-keywords are the wrong
> way around. As a result, if you are writing M4 code to be expanded in
> "-P mode", so have things like
>
>   m4_define
>
> in the file, then the "define" part gets matched by the penultimate
> regex, so m4_ doesn't get highlighted as part of a keyword.
>
> I think the fix for this is to just swap the two regexes around. That
> said, the commented stuff at the bottom of the file is rather
> ugly. Maybe it would be better to have a single regex, made with
> something like:
>
>    (regexp-opt (append (mapcar (lambda (kw)
>                                  (concat "m4_" kw))
>                                prefixed)
>                        prefixed
>                        unprefixed))
>
> with prefixed containing:
>
> '("builtin" "changecom" "changequote" "changeword" "debugfile"
>   "debugmode" "decr" "define" "defn" "divert" "divnum" "dnl"
>   "dumpdef" "errprint" "esyscmd" "eval" "file" "format"
>   "ifdef" "ifelse" "include" "incr" "index" "indir" "len" "line"
>   "m4exit" "m4wrap" "maketemp" "patsubst" "popdef" "pushdef" "regexp"
>   "shift" "sinclude" "substr" "syscmd" "sysval" "traceoff" "traceon"
>   "translit" "undefine" "undivert" "unix"))
>
>
> and unprefixed containing:
>
> '("gnu")
>
>
> Or maybe the absence of m4_gnu is a typo, in which case the logic could
> be slightly simpler. I'm assuming that "m4_m4_undefine" at the bottom of
> the file is a mistake.
>
> Sorry there's no patch: I've requested assignment papers, but they
> haven't come through yet. Since I think I've hit my minimal change
> limit, someone else gets to type the code...

Hi,

in case the problem is still there (I don't use m4, so it's difficult
for me to verify it), would you be able to provide a patch now?

> Rupert

Best,

-- 
Marcin