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

[Dmitry Gutov <dgutov@yandex.ru>]

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.

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

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.

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