GNU bug report logs - #43558
[PATCH]: Fix (forward-comment 1) when end delimiter is escaped.

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43558 <at> debbugs.gnu.org, Mattias Engdegård <mattiase <at> acm.org>
Subject: bug#43558: [PATCH]: Fix (forward-comment 1) when end delimiter is escaped.
Date: Thu, 24 Sep 2020 10:20:22 +0000

Hello, Stefan.

On Wed, Sep 23, 2020 at 14:44:54 -0400, Stefan Monnier wrote:
> > It seems that as well as the existing variable
> > comment-end-can-be-escaped, we need a new one, say
> > line-comment-end-can-be-escaped, too.

> syntax.c doesn't like to think of it as "line-comment" but rather as
> comment stay a, b, c, or nested and non-nested.

> > In C and C++ modes, these would be nil and t respectively.

> I sm-c-mode, I'd handle those corner cases in
> `syntax-propertize-function` (tho I think I don't bother with this one
> currently).

> So, I guess in CC-mode, you could handle those by placing `syntax-table`
> properties from ... wherever you place them ;-)

As already said, this is a(n ugly) workaround.  syntax.c should handle
comments in all their generality.  With a bit of consideration, the
method to do this is clear:

Introduce a new syntax flag `e' which takes effect in comment delimiters.
It means "escape characters are active in this type of comment".  In a
two character delimiter it would, like `b', only take effect on the inner
of the two characters.

So the syntaxes of the C++ comment characters would be amended to look
like
    /  ". 124be"
    *  ". 23"  (unchanged)
    \n "> be"

This would be an easy change to make, and (unlike using syntax-table text
properties) would cost negligible run time.

What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.