Trouble fontifying /** ... */

Trouble fontifying /** ... */

[Davin Pearson]

I sent the following email to gnu.emacs.help but received no helpful
reply.

I have invented a new (free GPL) programming language called SJS,
short for Simplified Java Syntax which provides a stepping stone for
learning Java, which makes it easier to learn Java than by learning
Java from scratch.  While writing the major mode sjs-mode, I ran into
a problem highlighting /** ... */ in font-lock-doc-face.

Click below for my Elisp code:

http://h1.ripway.com/davin/sjs.el

To get the desired fontification online, I considered inheriting sjs-
mode from java-mode, but when you uncomment the line that says (java-
mode) it does fontify /** ... */ in font-lock-doc-face but it also
erroneously fontifies the "end" keyword in font-lock-type-face.  This
behaviour is erroneous and I don't want for this to happen.  I read
the documentation for font-lock-add-keywords but nothing I tried
eliminated the fontification of "end".

-- 
Sincerely and kindest regards, Davin.
Davin Pearson    http://www.davinpearson.com

Re: Trouble fontifying /** ... */

[Alan Mackenzie]

Hi, Davin,

On Mon, Jan 26, 2009 at 06:00:57PM +1300, Davin Pearson wrote:
> I sent the following email to gnu.emacs.help but received no helpful
> reply.

If it's derived from Java Mode, then this is really one of mine.  ;-)

> I have invented a new (free GPL) programming language called SJS,
> short for Simplified Java Syntax which provides a stepping stone for
> learning Java, which makes it easier to learn Java than by learning
> Java from scratch.  While writing the major mode sjs-mode, I ran into
> a problem highlighting /** ... */ in font-lock-doc-face.

It might be worth checking any regexps you've got, making sure the '*'s
are quoted right.  They can be horribly tricky.  ;-(  A regexp to match
"/*****..... " (minimum 2 stars) might look a bit like:
"/\\*\\*+"

> Click below for my Elisp code:

> http://h1.ripway.com/davin/sjs.el

OK, I've picked up the code.

> To get the desired fontification online, I considered inheriting sjs-
> mode from java-mode, but when you uncomment the line that says (java-
> mode) it does fontify /** ... */ in font-lock-doc-face but it also
> erroneously fontifies the "end" keyword in font-lock-type-face.  This
> behaviour is erroneous and I don't want for this to happen.  I read
> the documentation for font-lock-add-keywords but nothing I tried
> eliminated the fontification of "end".

Any chance you could give me something to chew on?  A bit of SJS source
(preferably quite concise) where the problem is apparent, together with a
recipe for making it happen?

Thanks!

> -- 
> Sincerely and kindest regards, Davin.
> Davin Pearson    http://www.davinpearson.com

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Trouble fontifying /** ... */

[Davin Pearson]

2009/1/27 Alan Mackenzie <acm@muc.de>:
> "/*****..... " (minimum 2 stars) might look a bit like:
> "/\\*\\*+"
>

The following Elisp code only matches a single line comment

     ("/\\*\\*+.*\\*/" 0 'font-lock-doc-face t)

and erroneously fontifies

       a = "/** foo */";

in font-lock-doc-face when it should be font-lock-string-face.

-------------------------------------------------------------------

Click below for my Elisp code: (please note that I have updated the code)

http://h1.ripway.com/davin/sjs.el

Click below for a program fragment:

http://h1.ripway.com/davin/a.sjs


-- 
Sincerely and kindest regards, Davin.
Davin Pearson    http://www.davinpearson.com

Re: Trouble fontifying /** ... */

[Alan Mackenzie]

'Evening, Davin!

On Tue, Jan 27, 2009 at 03:04:58PM +1300, Davin Pearson wrote:
> 2009/1/27 Alan Mackenzie <acm@muc.de>:
> > "/*****..... " (minimum 2 stars) might look a bit like:
> > "/\\*\\*+"
> >

> The following Elisp code only matches a single line comment
> 
>      ("/\\*\\*+.*\\*/" 0 'font-lock-doc-face t)
                                               ^
                                               |

> and erroneously fontifies

>        a = "/** foo */";

> in font-lock-doc-face when it should be font-lock-string-face.

Ah!  I see it now.  The last element of that list, t, is the OVERRIDE
parameter which means "apply this fontification even if this piece of
buffer has already been fontified" (See page "Search-based
Fontification" in the Elisp manual).  Of course, the string had already
been fontified with font-lock-string-face before that got overridden.

So, you asked for it, you got it!

If that t kind of sneaked in by accident while you weren't watching,
just take it out.  If it was put there for a reason, well, you'll have
to jiggle things around, somehow - change the order of the elements in
font-lock-keywords, something like that.  There'll be some way of making
it work, just like there's always a way of pressing the wallpaper flat
without the bubble of paste oozing up somewhere else.  ;-)

> -------------------------------------------------------------------

> Click below for my Elisp code: (please note that I have updated the code)

> http://h1.ripway.com/davin/sjs.el

> Click below for a program fragment:

> http://h1.ripway.com/davin/a.sjs

Just as an aside, it's very helpful, really enourmously helpful, for
there to be a code fragment (as concise as possible, like the one above)
and relevant bits of Elisp (again concise, like the one above) actually
in the post in the mailing list.  It encourages people to answer your
post rather than getting another cup of coffee.  Downloading these from
a URL is more of a drag than you'd believe.  ;-)

> Sincerely and kindest regards, Davin.
> Davin Pearson    http://www.davinpearson.com

And all the best to yourself, too!  Hope you get it sorted out.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Trouble fontifying /** ... */

[Davin Pearson]

2009/1/27 Alan Mackenzie <acm@muc.de>:
> 'Evening, Davin!
>
> On Tue, Jan 27, 2009 at 03:04:58PM +1300, Davin Pearson wrote:
>> 2009/1/27 Alan Mackenzie <acm@muc.de>:
>> > "/*****..... " (minimum 2 stars) might look a bit like:
>> > "/\\*\\*+"
>> >
>
>> The following Elisp code only matches a single line comment
>>
>>      ("/\\*\\*+.*\\*/" 0 'font-lock-doc-face t)
>                                               ^
>                                               |
>
>> and erroneously fontifies
>
>>        a = "/** foo */";
>
>> in font-lock-doc-face when it should be font-lock-string-face.
>
> Ah!  I see it now.  The last element of that list, t, is the OVERRIDE
> parameter which means "apply this fontification even if this piece of
> buffer has already been fontified" (See page "Search-based
> Fontification" in the Elisp manual).  Of course, the string had already
> been fontified with font-lock-string-face before that got overridden.
>
> So, you asked for it, you got it!

Yes I already know about the override feature.  The problem is that
without the override feature it doesn't work at all.

> If that t kind of sneaked in by accident while you weren't watching,
> just take it out.  If it was put there for a reason, well, you'll have
> to jiggle things around, somehow - change the order of the elements in
> font-lock-keywords, something like that.  There'll be some way of making
> it work, just like there's always a way of pressing the wallpaper flat
> without the bubble of paste oozing up somewhere else.  ;-)

Help me! I am stuck!

>> Click below for my Elisp code: (please note that I have updated the code)
>
>> http://h1.ripway.com/davin/sjs.el
>
>> Click below for a program fragment:
>
>> http://h1.ripway.com/davin/a.sjs
>
> Just as an aside, it's very helpful, really enourmously helpful, for
> there to be a code fragment (as concise as possible, like the one above)
> and relevant bits of Elisp (again concise, like the one above) actually
> in the post in the mailing list.  It encourages people to answer your
> post rather than getting another cup of coffee.  Downloading these from
> a URL is more of a drag than you'd believe.  ;-)

What is so much of an effort clicking on a URL? It only takes a few seconds.

-- 
Sincerely and kindest regards, Davin.
Davin Pearson    http://www.davinpearson.com

Re: Trouble fontifying /** ... */

[Alan Mackenzie]

Hi, Davin!

On Thu, Jan 29, 2009 at 06:02:36PM +1300, Davin Pearson wrote:
> 2009/1/27 Alan Mackenzie <acm@muc.de>:
> > 'Evening, Davin!

> > On Tue, Jan 27, 2009 at 03:04:58PM +1300, Davin Pearson wrote:
> >> 2009/1/27 Alan Mackenzie <acm@muc.de>:
> >> > "/*****..... " (minimum 2 stars) might look a bit like:
> >> > "/\\*\\*+"


> >> The following Elisp code only matches a single line comment

> >>      ("/\\*\\*+.*\\*/" 0 'font-lock-doc-face t)
> >                                               ^
> >                                               |

> >> and erroneously fontifies

> >>        a = "/** foo */";

> >> in font-lock-doc-face when it should be font-lock-string-face.

> > Ah!  I see it now.  The last element of that list, t, is the OVERRIDE
> > parameter which means "apply this fontification even if this piece of
> > buffer has already been fontified" (See page "Search-based
> > Fontification" in the Elisp manual).  Of course, the string had already
> > been fontified with font-lock-string-face before that got overridden.

> > So, you asked for it, you got it!

> Yes I already know about the override feature.  The problem is that
> without the override feature it doesn't work at all.

> > If that t kind of sneaked in by accident while you weren't watching,
> > just take it out.  If it was put there for a reason, well, you'll have
> > to jiggle things around, somehow - change the order of the elements in
> > font-lock-keywords, something like that.  There'll be some way of making
> > it work, just like there's always a way of pressing the wallpaper flat
> > without the bubble of paste oozing up somewhere else.  ;-)

> Help me! I am stuck!

OK.  But first, please describe the glue you used.  :-)  Say why you are
using the OVERRIDE flag in the font-lock pattern, what would(n't) happen
if you didn't use it, and so on.

> >> Click below for my Elisp code: (please note that I have updated the code)

> >> http://h1.ripway.com/davin/sjs.el

> >> Click below for a program fragment:

> >> http://h1.ripway.com/davin/a.sjs

> > Just as an aside, it's very helpful, really enourmously helpful, for
> > there to be a code fragment (as concise as possible, like the one
> > above) and relevant bits of Elisp (again concise, like the one above)
> > actually in the post in the mailing list.  It encourages people to
> > answer your post rather than getting another cup of coffee.
> > Downloading these from a URL is more of a drag than you'd believe.
> > ;-)

> What is so much of an effort clicking on a URL? It only takes a few
> seconds.

Fair question.  It actually takes a few seconds multiplied by the number
of people you do it for.  It means doing drudge work, over and over
again.  It is a task which can't be automated.

And "clicking" on a URL might easily mean copying the URL with the mouse,
pasting it into a browser, after having had to start X-Windows and fire
up the browser.  Having done this, one has somehow to transfer the file
to Emacs to look at it.  Not everybody is online all the time.  Richard
Stallman is well known for this.  There are still some people who use a
modem and need to pay telephone charges by the minute.  I often read mail
over an SSH link from a Linux text terminal.

Now it is true, one can streamline ones setup so that all this movement
of text data runs more smoothly, but doing this is hassle and the gain in
efficiency is paid for in lost flexibility.

It means having to download a "large" file (where large means more than
5 or 6 lines) and having to STUDY this file to find the relevant part.
As an example, your sjs.el is 245 lines long.  You didn't even suggest a
line number to start looking at.  ;-)

It means the bug report or help request is fragmented - rather than
everything being in one place, part of the request is in the posting,
part of it _somewhere_ inside a 245 line elisp file, and part _somewhere_
in a data file (of unknown length) which will require further study.
Exercise for the reader: who can more easily organise and summarise a
problem: the hacker who's written the bit of troublesome Elisp or the
hacker who's trying to help?

Remember, Emacs users are _lazy_; one of the greatest things about Emacs
is that it allows people to be lazy whilst still getting a lot done.

Also, when the person posting has taken trouble to arrange and organise
his request, it's a strong indication that he's got a problem worth
answering, rather than his not being bothered to read a (well written)
manual.

So, let's get on and get your font-locking problem solved!

> -- 
> Sincerely and kindest regards, Davin.
> Davin Pearson    http://www.davinpearson.com

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Trouble fontifying /** ... */

[Alan Mackenzie]

Hi, Davin!

On Sun, Feb 01, 2009 at 05:17:54PM +1300, Davin Pearson wrote:
> 2009/1/30 Alan Mackenzie <acm@muc.de>:
> > Fair question.  It actually takes a few seconds multiplied by the
> > number of people you do it for.  It means doing drudge work, over and
> > over again.  It is a task which can't be automated.

> > And "clicking" on a URL might easily mean copying the URL with the
> > mouse, pasting it into a browser, after having had to start X-Windows
> > and fire up the browser.  Having done this, one has somehow to
> > transfer the file to Emacs to look at it.  Not everybody is online
> > all the time.  Richard Stallman is well known for this.  There are
> > still some people who use a modem and need to pay telephone charges
> > by the minute.  I often read mail over an SSH link from a Linux text
> > terminal.

> What about email attachments.  Are they acceptable?

Sort of, I suppose.  But "acceptable" isn't perhaps the best way of
looking at it.  The posts on help-gnu-emacs@gnu.org are all competing for
the attention of people able to answer them.  Anything which makes it a
hassle to see what somebody is asking about reduces the chances of
anybody bothering with this hassle.

For me, the sort of post I'm most likely to answer are (i) ones which
just need a snappy 1-line answer, often from newbies who're still
struggling their way round the manuals; (ii) ones which I feel are my
responsibility (involving CC Mode); (iii) ones which look like I'll learn
something from.

Anything which makes it less obvious what a post's about makes it less
likely I'll answer it.  The same probably holds for other Emacs
developers.

> Using cut & paste from Emacs to Gmail splits lines at irrational
> positions making it hard to read such text.

Ouch!  I hate this sort of thing - software which imposes "helpful"
features on you.  "Hey!  Gmail fills text for you AUTOMATICALLY!!!!".
Then developers justify it with "but that's what \"most people\" want".

Does this line splitting happen when you're composing the email (which
you can correct, and isn't too bad, because you're only pasting in a
small amount of text ;-), or after you've posted it (which is
inexcusable)?

Does Gmail perhaps have some options you could set to fix this?
Something like "text width" or "automatic filling", or something?
Gmail's written by Google, isn't it?  I thought they were decent software
engineers.

How about submitting a bug report to Gmail?  And if that doesn't get you
anywhere, start using a decent email client instead?

Anyhow, any progress with your font-locking stuff?

> Sincerely and kindest regards, Davin.
> Davin Pearson    http://www.davinpearson.com

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Trouble fontifying /** ... */

[Davin Pearson]

2009/2/2 Alan Mackenzie <acm@muc.de>:
>> What about email attachments.  Are they acceptable?
>
> Sort of, I suppose.  But "acceptable" isn't perhaps the best way of
> looking at it.  The posts on help-gnu-emacs@gnu.org are all competing for
> the attention of people able to answer them.  Anything which makes it a
> hassle to see what somebody is asking about reduces the chances of
> anybody bothering with this hassle.

I see your point here.  Simpler & Quicker for people reading my email
messages is better.

> Ouch!  I hate this sort of thing - software which imposes "helpful"
> features on you.  "Hey!  Gmail fills text for you AUTOMATICALLY!!!!".
> Then developers justify it with "but that's what \"most people\" want".
>
> Does this line splitting happen when you're composing the email (which
> you can correct, and isn't too bad, because you're only pasting in a
> small amount of text ;-), or after you've posted it (which is
> inexcusable)?
>
> Does Gmail perhaps have some options you could set to fix this?
> Something like "text width" or "automatic filling", or something?
> Gmail's written by Google, isn't it?  I thought they were decent software
> engineers.

Not that I can find.

> How about submitting a bug report to Gmail?  And if that doesn't get you
> anywhere, start using a decent email client instead?
>
> Anyhow, any progress with your font-locking stuff?

No luck as yet!

By the way, were you responsible for writing the original Emacs java-mode?

-- 
Sincerely and kindest regards, Davin.
Davin Pearson    http://www.davinpearson.com

Trouble fontifying /** ... */

[Davin Pearson]

I have invented a language called SJS that it a mixture of Pascal and
Java for easier learning of the Java language.  In sjs-mode
I would like the following code:

/**
  I am a Javadoc-style comment.
*/

To be fontified in font-lock-doc-face but I cannot find an elegant way
to do this.  What follows is some Emacs version information,
via report-emacs-bug:

  In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600)
  of 2008-03-27 on RELEASE
  Windowing system distributor `Microsoft Corp.', version 5.1.2600
  configured using `configure --with-gcc (3.4)'

Re: Trouble fontifying /** ... */

[Xah Lee]

On Jan 8, 8:54 pm, Davin Pearson <davin.pear...@gmail.com> wrote:
> I have invented a language called SJS that it a mixture of Pascal and
> Java for easier learning of the Java language.  In sjs-mode
> I would like the following code:
>
> /**
>   I am a Javadoc-style comment.
> */
>
> To be fontified in font-lock-doc-face but I cannot find an elegant way
> to do this.  What follows is some Emacs version information,
> via report-emacs-bug:

your question is a FAQ but without much polished answer.

Emac's syntax tables for comments address only the following classes
of comment syntax

    * “# ...\n”. Start with a char to newline char.
    * “// ... \n”. Start with 2 identical chars to newline char.
    * “(* ... *)”. A matching pair chars with another char.
    * “/* ... */”. Two chars used in a ad hoc way as matching pair.

If your comment syntax is more complex, you cannot use syntax table
for it. You have to use font-lock-syntactic-keywords, and also you'll
need to implement your own comment-dwim.

• How To Add Comment Handling In Your Major Mode
  http://xahlee.org/emacs/elisp_comment_handling.html

See also Rick (rgb)'s experience, at

• http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/465e9d84d8e5dadd#

• http://groups.google.com/group/comp.emacs/browse_frm/thread/c1b7de4489be181?tvc=1

  Xah
∑ http://xahlee.org/

☄

Re: Trouble fontifying /** ... */

[Davin Pearson]

On Jan 10, 2:21 am, Xah Lee <xah...@gmail.com> wrote:
> On Jan 8, 8:54 pm, Davin Pearson <davin.pear...@gmail.com> wrote:
>
> > I have invented a language called SJS that it a mixture of Pascal and
> > Java for easier learning of the Java language.  In sjs-mode
> > I would like the following code:
>
> > /**
> >   I am a Javadoc-style comment.
> > */
>
> > To be fontified in font-lock-doc-face but I cannot find an elegant way
> > to do this.  What follows is some Emacs version information,
> > via report-emacs-bug:
>
> your question is a FAQ but without much polished answer.

Here is my existing code.  The trouble with it is
that it sometimes highlights the keyword end in font-lock-type-face.
This is a problem with inheriting from the java major mode.

(defun sjs-mode
()
 
(interactive)
  (font-lock-mode
0)
  (kill-all-local-
variables)
  (java-
mode)

  (setq major-mode 'sjs-
mode)
  (setq mode-name
"SJS")

  (set-syntax-table sjs-mode-syntax-
table)
  (use-local-map sjs-mode-
map)

  (local-set-key "\t" 'sjs--
tab)

  (local-set-key [(meta control \\)] 'sjs--meta-control-
backslash)

  (abbrev-mode
1)
  (setq local-abbrev-table java-mode-abbrev-
table)

  (font-lock-add-
keywords
 
nil
 
'(
     ("\\<\\(assert\\|begin\\|end\\|function\\|var\\|classVar\\|
instanceVariable\\|property\\|method\\|constructor\\|until\\|then\\|and
\\|or\\)\\>" (1 'font-lock-keyword-face nil))

     ("\\<\\(beginMain\\|endMain\\)\\>" 0 'font-lock-keyword-face
nil)

     ("\\<\\(null\\|true\\|false\\)\\>" 1 'font-lock-constant-face
nil)

     ("\\<\\(abstract\\|break\\|byte\\|case\\|catch\\|class\\|const\\|
continue\\|default\\|do\\|else\\|extends\\|final\\|finally\\|for\\|goto
\\|if\\|implements\\|import\\|instanceof\\|interface\\|native\\|new\\|
package\\|private\\|protected\\|public\\|return\\|static\\|super\\|
switch\\|synchronized\\|this\\|throw\\|throws\\|transient\\|try\\|
volatile\\|while\\|null\\)\\>" 1 'font-lock-keyword-face nil)


      ("\\<function [^ ]* \\([a-z][A-Za-z0-9_]*\\)" 1 'font-lock-
function-name-face nil)
      ("\\<method [^ ]* \\([a-z][A-Za-z0-9_]*\\)" 1 'font-lock-
function-name-face nil)

      ("\\<\\([A-Z]+[a-z][A-Za-z0-9]*\\|[A-Z]\\|boolean\\|char\\|int\\|
long\\|short\\|float\\|double\\)[][]*[ \t]+\\([a-z][A-Za-z0-9]*\\)"
       (1 'font-lock-type-face
nil)
       (2 'font-lock-variable-name-face
nil))

      ("\\<[A-Z]+[a-z][A-Za-z0-9_]*" 0 'font-lock-type-face
nil)
      ("\\<[A-Z]\\>" 0 'font-lock-type-face
nil)
      ("\\<\\(boolean\\|char\\|int\\|long\\|short\\|float\\|double\\|
void\\)\\>" 0 'font-lock-type-face nil t)

     ))


  (font-lock-mode
3)

  )

> If your comment syntax is more complex, you cannot use syntax table
> for it. You have to use font-lock-syntactic-keywords, and also you'll
> need to implement your own comment-dwim.

> • How To Add Comment Handling In Your Major Mode
>  http://xahlee.org/emacs/elisp_comment_handling.html
>
> See also Rick (rgb)'s experience, at
>
> •http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/465e9...
>
> •http://groups.google.com/group/comp.emacs/browse_frm/thread/c1b7de448...

Could you give me some more information as to how to proceed. I am
stuck.

Re: Trouble fontifying /** ... */

[Xah Lee]

On Jan 13, 7:18 pm, Davin Pearson <davin.pear...@gmail.com> wrote:
> On Jan 10, 2:21 am, Xah Lee <xah...@gmail.com> wrote:
>
> > On Jan 8, 8:54 pm, Davin Pearson <davin.pear...@gmail.com> wrote:
>
> > > I have invented a language called SJS that it a mixture of Pascal and
> > > Java for easier learning of the Java language.  In sjs-mode
> > > I would like the following code:
>
> > > /**
> > >   I am a Javadoc-style comment.
> > > */
>
> > > To be fontified in font-lock-doc-face but I cannot find an elegant way
> > > to do this.  What follows is some Emacs version information,
> > > via report-emacs-bug:
>
> > your question is a FAQ but without much polished answer.
>
> Here is my existing code.  The trouble with it is
> that it sometimes highlights the keyword end in font-lock-type-face.
> This is a problem with inheriting from the java major mode.
>
> (defun sjs-mode
> ()
>
> (interactive)
>   (font-lock-mode
> 0)
>   (kill-all-local-
> variables)
>   (java-
> mode)
>
>   (setq major-mode 'sjs-
> mode)
>   (setq mode-name
> "SJS")
>
>   (set-syntax-table sjs-mode-syntax-
> table)
>   (use-local-map sjs-mode-
> map)
>
>   (local-set-key "\t" 'sjs--
> tab)
>
>   (local-set-key [(meta control \\)] 'sjs--meta-control-
> backslash)
>
>   (abbrev-mode
> 1)
>   (setq local-abbrev-table java-mode-abbrev-
> table)
>
>   (font-lock-add-
> keywords
>
> nil
>
> '(
>      ("\\<\\(assert\\|begin\\|end\\|function\\|var\\|classVar\\|
> instanceVariable\\|property\\|method\\|constructor\\|until\\|then\\|and
> \\|or\\)\\>" (1 'font-lock-keyword-face nil))
>
>      ("\\<\\(beginMain\\|endMain\\)\\>" 0 'font-lock-keyword-face
> nil)
>
>      ("\\<\\(null\\|true\\|false\\)\\>" 1 'font-lock-constant-face
> nil)
>
>      ("\\<\\(abstract\\|break\\|byte\\|case\\|catch\\|class\\|const\\|
> continue\\|default\\|do\\|else\\|extends\\|final\\|finally\\|for\\|goto
> \\|if\\|implements\\|import\\|instanceof\\|interface\\|native\\|new\\|
> package\\|private\\|protected\\|public\\|return\\|static\\|super\\|
> switch\\|synchronized\\|this\\|throw\\|throws\\|transient\\|try\\|
> volatile\\|while\\|null\\)\\>" 1 'font-lock-keyword-face nil)
>
>       ("\\<function [^ ]* \\([a-z][A-Za-z0-9_]*\\)" 1 'font-lock-
> function-name-face nil)
>       ("\\<method [^ ]* \\([a-z][A-Za-z0-9_]*\\)" 1 'font-lock-
> function-name-face nil)
>
>       ("\\<\\([A-Z]+[a-z][A-Za-z0-9]*\\|[A-Z]\\|boolean\\|char\\|int\\|
> long\\|short\\|float\\|double\\)[][]*[ \t]+\\([a-z][A-Za-z0-9]*\\)"
>        (1 'font-lock-type-face
> nil)
>        (2 'font-lock-variable-name-face
> nil))
>
>       ("\\<[A-Z]+[a-z][A-Za-z0-9_]*" 0 'font-lock-type-face
> nil)
>       ("\\<[A-Z]\\>" 0 'font-lock-type-face
> nil)
>       ("\\<\\(boolean\\|char\\|int\\|long\\|short\\|float\\|double\\|
> void\\)\\>" 0 'font-lock-type-face nil t)
>
>      ))
>
>   (font-lock-mode
> 3)
>
>   )
>
> > If your comment syntax is more complex, you cannot use syntax table
> > for it. You have to use font-lock-syntactic-keywords, and also you'll
> > need to implement your own comment-dwim.
> > • How To Add Comment Handling In Your Major Mode
> >  http://xahlee.org/emacs/elisp_comment_handling.html
>
> > See also Rick (rgb)'s experience, at
>
> > •http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/465e9...
>
> > •http://groups.google.com/group/comp.emacs/browse_frm/thread/c1b7de448...
>
> Could you give me some more information as to how to proceed. I am
> stuck.

i'm not expert in dealing with emacs font lock... only wrote 1 mode
myself and only started to explore it in recent months. Your code is
too big for me to dig into and give helpful advice.

... maybe others here can pitch in.

i wouldn't inherit or call java mode though... but this may not be a
expert advice. I wouldn't because unless you really need to, calling
other modes esp complex mode like java, introduces a lot complexities
and behaviors into your mode, which is hard to guess what's going on
and you have little control.

  Xah
∑ http://xahlee.org/

☄