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
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).
This bug report was last modified 3 years and 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.