Re: failure of the \= regexp in buffers with non-ASCII text
Julian Bradfield writes:
Actually, I do believe this may be a very simple problem.
Around line 4078 of regex.c, we have the code:
/* In a forward search for something that starts with \=.
don't keep searching past point. */
if (bufp->used > 0 && (re_opcode_t) bufp->buffer[0] == at_dot
&& range > 0)
{
range = BUF_PT (regex_emacs_buffer) - BUF_BEGV (regex_emacs_buffer)
- startpos;
if (range < 0)
return -1;
}
I think BUF_PT and BUF_BEGV should be BI_BUF_PT and BI_BUF_BEGV,
Good catch!
That's the kind of thing I was expecting it to be, but I started with
the matching code and only found the looking_at anomoly as I was
writing up noninteractive tests. Didn't get a chance to look at the
search code. Thanks for saving me the effort!
since range and startpos are byte positions not buffer
positions. (A proper type system would have caught that, of
course...) Leastways, it seems to work for me after doing that!
It might not be too hard to make a "proper type system" for C++
builds. It might even be possible to get some help from the compiler
by using unions (some compilers will warn if you access a different
member of the union from the one last stored, but that's not reliable
the way type mismatches would be).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta