1:34 p.m.
This is driving me nuts. The regexp \= (match empty string at point)
fails anywhere after the first non-ascii character in a buffer.
I'm using XEmacs 21.4.20, Mule build, no exotic config options.
To recreate, start xemacs -q, find a new file, either leave it in the
default ISO8 coding system or switch it to some other,
type
aáa
and then do M-C-s \ =
at each of the four points. It will succeed at points 1 and 2, and fail
at points 3 and 4.
The problem also occurs in 21.5(beta28).
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:41 a.m.
Julian Bradfield writes:
This is driving me nuts. The regexp \= (match empty string at point)
fails anywhere after the first non-ascii character in a buffer.
Thank you for the report and the recipe!
I can replicate the case with your example of M-C-s \ = in the mail
presentation buffer, and with M-: (re-search-forward "\\="), but it
works fine with M-: (looking-at "\\=") RET.
For now, is there any chance you can work around with `looking-at'?
I've added some tests for this locally (need to test the tests :-),
but when I tried to get at it in the debugger, for some reason
(optimization, I bet) I've been unable to hit the problem code with a
breakpoint. The function is several thousand lines long, so just
stepping isn't going to be much fun.... It may take a bit to get this
fixed.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:49 a.m.
> This is driving me nuts. The regexp \= (match empty string at
point)
> fails anywhere after the first non-ascii character in a buffer.
I can replicate the case with your example of M-C-s \ = in the mail
presentation buffer, and with M-: (re-search-forward "\\="), but it
works fine with M-: (looking-at "\\=") RET.
For now, is there any chance you can work around with `looking-at'?
Not really, or at least not without undue effort. It's deep inside a
function that munges my mail for me.
I've added some tests for this locally (need to test the tests
:-),
but when I tried to get at it in the debugger, for some reason
(optimization, I bet) I've been unable to hit the problem code with a
breakpoint.
Glad this happens to you to.
I might try to look at it this weekend.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:01 a.m.
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, 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!
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:04 a.m.
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
5898
days inactive
5901
days old
4 comments
2 participants
participants (2)
-
Julian Bradfield -
Stephen J. Turnbull