nXhtml

Problem trying to use c-mode with mako submodes

Bug #718851 reported by lborgman on 2011-02-14

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	nXhtml	In Progress	Medium	Unassigned

Bug Description

I'm trying to edit mako templates which generate c sourcecode, which works much better with mumamo than with mmm-mako.el so far.

I use the following experimental mode (derived from the mako-html modes):

(define-mumamo-multi-major-mode mako-c-mumamo-mode
                        ("Mako C Family" c-mode
                         (
                          mumamo-chunk-mako-one-line-comment
                          mumamo-chunk-mako-<%doc
                          mumamo-chunk-mako-<%include
                          mumamo-chunk-mako-<%inherit
                          mumamo-chunk-mako-<%namespace
                          mumamo-chunk-mako-<%page

                          ;;mumamo-chunk-mako-<%def
                          ;;mumamo-chunk-mako-<%call
                          ;;mumamo-chunk-mako-<%text

                          mumamo-chunk-mako-<%
                          mumamo-chunk-mako-%
                          mumamo-chunk-mako$

                          mumamo-chunk-xml-pi
                          mumamo-chunk-inlined-style
                          mumamo-chunk-inlined-script
                          mumamo-chunk-style=
                          mumamo-chunk-onjs=
                          )))

But when I use a ${ ... } block inside a c-string, the font-locking stays in c-string mode afterwards.

Example (from https://github.com/TauPan/bdec/blob/master/bdec/templates/c/main.c#L25):

#include "${protocol.name |filename}.h"

static void usage(char* program)
{

the function protocol for main is rendered in string mode.

I admit I don't really know what I'm doing, as I simply changed nxhtml-mode in the define to c-mode, and it "just (almost) worked"[TM], and read some code in mumamo-fun.el, to figure out why it (almost) didn't, so I hope you can hit me a little with the cluebat here.

Revision history for this message

lborgman (lennart-borgman) wrote on 2011-02-14:

Thanks Friedrich, it is good you are extending it on your own. But please remember that nXhtml is far from perfect. It is trying to give reasonable abilities. (Some low level changes to Emacs might be required to make it work better in some cases.)

There is also some still open bugs for the mako support.

However I can not reproduce the problem you have here. After adding a doc string to mako-c-mumamo-mode so I can compile it I do not see the problem.

Can you please give more details? Have you tried the latest beta 2.09 of nXhtml?

Changed in nxhtml:
status:	New → In Progress
importance:	Undecided → Medium

Revision history for this message

Friedrich Delgado (taupan) wrote on 2011-02-16:

I still see "main" in string font-locking with nxhtml-2.09beta-110129-17_38_56.zip, when I open main.c from the github link.

nXhtml mode version 2.09beta

GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2010-12-11 on brahms, modified by Debian

I tried with emacs -Q and loading nothing else but nxhtml/autostart.el, nxhtml-mumamo and my mako-c-mumamo-mode definition.

Could you tell me what other details would help you track down or reproduce the problem?

Revision history for this message

Friedrich Delgado (taupan) wrote on 2011-02-16:

sorry, that main.c.html attachment doesn't have the font-locking that I see on screen, looks like I need to attach a graphical screen shot. Could you please delete the attachment?

Revision history for this message

Friedrich Delgado (taupan) wrote on 2011-02-16:

screenshot of font-locking in mako/c mode Edit (104.8 KiB, image/png)

Revision history for this message

Friedrich Delgado (taupan) wrote on 2011-02-17:

I figured out how to delete the wrong attachment. The png screenshot shows the wrong font-locking.

Revision history for this message

lborgman (lennart-borgman) wrote on 2011-03-11:

Hi Friedrich, I am afraid this might be a complicated problem you have bumped into. Some low level changes to Emacs might be needed to fix this.

Revision history for this message

Friedrich Delgado (taupan) wrote on 2011-03-14:

Finding complicated bugs by applying fringe use-cases seems to be my thing... :-}

When you find the time, could you elaborate on the problems or provide some links to discussions/bugs, etc. elsewhere?

Revision history for this message

lborgman (lennart-borgman) wrote on 2011-03-14:

Yes, Freidrich, I am starting to think that is a good idea. I am not sure I can move nXhtml forward alone anymore, it is too complicated, so I need to explain the status and problems.

I think I will start a mailing list later.