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).