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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Sun, Nov 22, 2020 at 22:39:08 +0200, Dmitry Gutov wrote:
> On 22.11.2020 20:19, Alan Mackenzie wrote:
> > On Sun, Nov 22, 2020 at 19:46:24 +0200, Dmitry Gutov wrote:
> >> On 22.11.2020 19:08, Alan Mackenzie wrote:
> >>> Really?  Are there any other programming language modes whose comments
> >>> syntax.c cannot handle without syntax-table text properties?

> >> Ruby is just one example.

> > Thanks.

> > I've just searched the web for that.  Ruby has block comment delimiters
> > =begin and =end.

> > It would be possible to handle these in syntax.c, but somewhat clumsy
> > and awkward.

> Just like the C comments syntax discussed here.

Not at all.  The amendment we're talking about is to handle escaped
newlines inside line comments.  Which takes precedence, the comment to
EOL, or the escape?  It's rather arbitrary, and should be configurable.

Coding up the Ruby block comments in syntax.c would involve string
comparisons, for example, and would be an entirely new flavour inside
that file.  It would involve examining individual letters rather than
just their syntax.

By contrast, coding up the escaped NL in syntax.c was straightforward and
natural.

Have you looked at the patch?

> > Presumably ruby-mode handles these with syntax-table text properties
> > applied to the = sign and the terminating d, which is a little clumsy,
> > but not too bad, at the Lisp level.

> This is just two more regexps to search for (and propertize). I don't 
> expect that the slowdown from them is in any way perceptible.

> And the general point is that the Emacs syntax table structure doesn't 
> necessarily have to mirror the syntax of the C language.

Maybe not, but the point remains, that for this fix, a fix at the C level
is objectively better than a fix at the Lisp level.  Furthermore, the C
level change is already implemented and has been well tested.

-- 
Alan Mackenzie (Nuremberg, Germany).