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 23:34:18 +0200, Dmitry Gutov wrote:
> Hi Alan,

> On 22.11.2020 23:13, Alan Mackenzie wrote:

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

> It could be made to support a new syntax using a finite state machine,
> something like that. And the strings could be converted to such by the
> major mode. But you're right, it would be more difficult.

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

> > Have you looked at the patch?

> Yup.

> It's not terrible, but it's still a bunch of new if/elses that one
> would need to grasp to maintain that code.

It's character, the general use of ifs/elses, and so on, is unchanged.
Only somebody with a very detailed memory of exact statements would be
inconvenienced, and that only slightly.

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

> Why is it objectively better?

It's faster, and it avoids fragmenting the handling of CC Mode comments
between C and Lisp the way that of strings, for example, has been.  It
provides a mechanism which might be useful to other major modes in the
future.

> With user experience (speed, latencies, etc) being equal or within the 
> margin of error, I think it's more logical to go with simpler data 
> structures and low level APIs.

Fixing things in syntax.c was simpler than a Lisp solution using
syntax-table text properties would have been.

> Finally, as I recall you feel strongly about supporting older Emacs 
> versions, a significant number of them. Doing that fix in Lisp would 
> allow you to fix the bug for those versions too. Not just Emacs 28+.

Yes.  That appears to be the sole drawback of the fix being in syntax.c.

-- 
Alan Mackenzie (Nuremberg, Germany).