11:22 a.m.
Hi, XEmacs!
In syntax.c, update_syntax_cache calls
next_previous_single_property_change. This function searches for a
property change WITHIN THE ACCESSIBLE REGION.
However, when it drops off the end, update_syntax_cache wrongly sets its
boundary positions to the ABSOLUTE BEGINNING/END of buffer. This is
clearly wrong.
Here is a patch to fix this. Would somebody please check it and commit
it. This fix is necessary for CC Mode to work.
Thanks!
diff -r 1b054bc2ac40 src/syntax.c
--- a/src/syntax.c Sun Jul 03 14:17:39 2011 +0100
+++ b/src/syntax.c Sun Aug 07 10:17:22 2011 +0000
＠＠ -423,7 +424,7 ＠＠
cache->object, -1, 1, 0);
if (lim < 0)
{
- next = buffer_or_string_absolute_end_byte (cache->object);
+ next = buffer_or_string_accessible_end_byte (cache->object);
at_begin = 1;
}
else
＠＠ -435,7 +436,7 ＠＠
cache->object, -1, 0, 0);
if (lim < 0)
{
- prev = buffer_or_string_absolute_begin_byte (cache->object);
+ prev = buffer_or_string_accessible_begin_byte (cache->object);
at_end = 1;
}
else
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:05 p.m.
Alan Mackenzie writes:
However, when it drops off the end, update_syntax_cache wrongly sets
its
boundary positions to the ABSOLUTE BEGINNING/END of buffer. This is
clearly wrong.
Do you have a test case that shows actual erroneous behavior fixed by
changing this? While I agree with your intuition, the syntax cache
has a ton of unintuitive code, and the specification for its behavior
is completely undocumented. Patches based on intuition make me very
nervous.
Here is a patch to fix this. Would somebody please check it and
commit
it. This fix is necessary for CC Mode to work.
Does CC mode use narrowing internally? A bug that exhibits in an
never-narrowed buffer should not be fixed by this.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:37 p.m.
Hi, Stephen.
On Sun, Aug 07, 2011 at 10:05:58PM +0900, Stephen J. Turnbull wrote:
Alan Mackenzie writes:
> However, when it drops off the end, update_syntax_cache wrongly
sets
> its boundary positions to the ABSOLUTE BEGINNING/END of buffer.
> This is clearly wrong.
Do you have a test case that shows actual erroneous behavior fixed
by
changing this?
Yes. My patch is a solution to the C-M-f/b problems with the AWK file in
the other thread. I shouldn't have started a new thread here. Sorry for
the annoyance.
While I agree with your intuition, the syntax cache has a ton of
unintuitive code, and the specification for its behavior is completely
undocumented. Patches based on intuition make me very nervous.
In the AWK file, a looking-at was done with the buffer narrowed. This
did an update_syntax_cache which spuriously set the cache over the entire
buffer, rather than the pertinent piece of the accessible portion. This
cache masked out the sytax-table properties on the slashes.
> Here is a patch to fix this. Would somebody please check it
and commit
> it. This fix is necessary for CC Mode to work.
Does CC mode use narrowing internally?
A great deal.
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:38 p.m.
Stephen J. Turnbull writes:
Alan Mackenzie writes:
> However, when it drops off the end, update_syntax_cache wrongly sets its
> boundary positions to the ABSOLUTE BEGINNING/END of buffer. This is
> clearly wrong.
Do you have a test case that shows actual erroneous behavior fixed by
changing this? While I agree with your intuition, the syntax cache
has a ton of unintuitive code, and the specification for its behavior
is completely undocumented. Patches based on intuition make me very
nervous.
OK, I have a test case that basically follows your recipe given
elsewhere and shows the bug, and is fixed by your suggested patch. It
took a bit of fiddling to get something that works in a vanilla temp
buffer, but I understand this stuff a lot better now. :-/
I'll be committing something tomorrow, but I want to go over the whole
function first. (There was a third instance of the same "absolute
vs. accessible" bug sandwiched between the ones you proposed fixing.
Given that we've already found about 5 bugs in the syntax cache code,
there are probably more....)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:22 p.m.
Alan Mackenzie writes:
In the AWK file, a looking-at was done with the buffer narrowed.
This did an update_syntax_cache which spuriously set the cache over
the entire buffer,
This seems like a bad thing to do anyway. Why should a function that
mutates nothing and doesn't move point invalidate a cache? It's
probably cheaper to copy the cache ....
(This isn't relevant to your suggested patch, which I've convinced
myself is correct. Any update_syntax_cache will exercise the bug, and
in fact in the automated test I developed, I use forward-sexp rather
than looking-at.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4640
days inactive
4640
days old
4 comments
2 participants
participants (2)
-
Alan Mackenzie -
Stephen J. Turnbull