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

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Tue, 22 Sep 2020 09:36:02 UTC

Severity: normal

Tags: confirmed

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: Wed, 23 Sep 2020 19:44:41 +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 [ ?? style ?? ] a, b, c, or nested and non-nested.

Hmm.  It could be quite troublesome to decide on an interface for major
modes specifying "comment style b can have its ender escaped, but
comment styles a and c cannot".

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

Thanks, that's an idea - either putting a neutral s-t prop on the \ of
\*/, or something on the \n of \\n in a line comment.  I think the first
of these is a better idea than the second.

But on the other hand, it feels like a workaround for the lack of a
full-featured comment-end-can-be-escaped.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 3 years and 47 days ago.

Previous Next


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