[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forward-comment doesn't (quite) match its documentation

From: Alan Mackenzie
Subject: Re: forward-comment doesn't (quite) match its documentation
Date: 27 Nov 2001 23:09:42 +0100
Date: Tue, 27 Nov 2001 19:21:55 +0000
User-agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (Linux/2.0.35 (i686))

Stefan Monnier <monnier+gnu.emacs.bug/news/@rum.cs.yale.edu> wrote on 27
Nov 2001 11:52:37 -0500:
>> I'm working on getting awk-mode (derived from cc-mode) working again.

> [ What do you mean by `again' ?  When did it get worse ? ]

It doesn't indent properly - if an awk statement isn't terminated by a
';' (and they usually aren't), the next statement is treated as a
continuation, and indented a further n columns.  This makes it unusable,
and has been complained about quite a lot on comp.lang.awk.

I presume that at one time, awk-mode was fine, but as c-mode was
gradually enhanced, awk-mode got left behind.

> Are you working on the version that's in the CVS repository ?  If not,
> you should.

Yes, with the approval of and under the guidance of Martin Stjernholm,
cc-mode's maintainer.  The bulk of the changes will be within the cc-mode

[ .... ]

> But since you know how it [forward-comment] works, you can just do
> (forward-char 1) before (forward-comment -1).

Indeed so, now that I know.

>> awk is a syntactic jungle:  '/' is sometimes a regexp delimiter (which
>> will have string syntax), sometimes a division sign.  That means I'll
>> have to do the work to check that a '#' (comment start) is not within
>> '/'s (when they are regexp brackets).

> The version that's in the CVS repository has font-lock tricks to 
> (try to) take care of it.

They're not yet perfect:  For example, in a statement like:
/^[ \t]*#/ {comments += 1}
the text from the '#' to the end of the line gets the comment face,
although it's not a comment.  This was the sort of thing that was
getting me more annoyed with forward-comment.

At the moment I'm planning on setting the syntax-table text property on
certain awkward characters ('/' when it's a division sign, and possibly
'#' when it's within a string).  I've written a finite state machine for
this purpose - I'm not sure that regular expressions are adequate here,
and even if they are I think they'd be too complicated to be sensible.

>       Stefan

Alan Mackenzie (Munich, Germany)
Email: address@hidden; to decode, wherever there is a repeated letter
(like "aa"), remove one of them (leaving, say, "a").

reply via email to

[Prev in Thread] Current Thread [Next in Thread]