2:28 p.m.
They don't behave like regular groups, they're non-greedy or
something. The documentation implies that the only difference is
whether the match is stored for back reference. This is not true in
21.2.41 "Polyhymnia":
$ xemacs -nw -no-autoloads
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, first visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
(let ((string "re: "))
(string-match "\\(\\(re:[\t ]*\\)*\\)\\([^ \t].*\\)?$" string)
(princ (format "match 1 is `%s', match 3 is `%s'\n\n"
(match-string 1 string)
(match-string 3 string)))
(string-match "\\(\\(?:re:[\t ]*\\)*\\)\\([^ \t].*\\)?$" string)
(princ (format "match 1 is `%s', match 2 is `%s'\n\n"
(match-string 1 string)
(match-string 2 string)))
nil)
match 1 is `re: ', match 3 is `nil'
match 1 is `', match 2 is `re: '
nil
Oops.
uname -a: Linux tleepslib 2.2.18 #1 SMP Tue Dec 26 11:36:10 JST 2000 i686 unknown
/coda/Projects/XEmacs/21.2-HEAD/configure
'--srcdir=/coda/Projects/XEmacs/21.2-HEAD' '--with-widgets=athena'
'--with-athena=3d' '--with-dialogs=athena' '--with-sound=none,nas'
'--with-mule' '--with-xim=xlib' '--with-xfs=no'
'--use-union-type' '--pdump'
XEmacs 21.2-b41 "Polyhymnia" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /coda/Projects/XEmacs/21.2-HEAD
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline
-Wmissing-prototypes -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for NAS (network audio system).
Databases:
Compiling in support for Berkeley database.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: postgresql/libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Using the union type for Lisp_Objects.
Using the new portable dumper.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:57 p.m.
>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
They don't behave like regular groups, they're non-greedy or something.
Nah, they're just plain broken.
The problem shows up under various circumstances, but a "*" right
after the shy group is a pretty good way to make it appear.
It took me a significant amount of rework to fix it for Emacs-21.
I sent the corresponding patch+changelog to Jan Vroonhof, but merging
them into XEmacs' regexp.c is not a piece of cake.
Stefan
11:22 a.m.
Thanks for picking up on this issue so quickly!
>>>> "Stefan" == Stefan Monnier
<monnier+lists.xemacs.beta/news/(a)RUM.cs.yale.edu> writes:
Stefan> It took me a significant amount of rework to fix it for
Stefan> Emacs-21.
Stefan> I sent the corresponding patch+changelog to Jan Vroonhof,
Stefan> but merging them into XEmacs' regexp.c is not a piece of
Stefan> cake.
OK, I found that patch, he forwarded it to xemacs-beta in February or
so. I did read through the patch, and although I don't understand the
code, the comments seem to be greatly improved. I did recognize a lot
of it from browsing the regex.c. It seems like a lot should be fairly
straightforward to merge, maybe 2/3 to 3/4.
If you don't mind, I have a few questions:
Do you have any further comments you might be willing to make on main
difficulties in merging, or whatever?
Do you have any other test cases, besides the two or three you put in
the patch?
Has your code stood up in test since last year, or have you had to
make any revisions? (No offense intended, but that was not just a
"tweak"!)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:46 p.m.
>>>>> "Stefan" == Stefan Monnier
<monnier+lists.xemacs.beta/news/(a)RUM.cs.yale.edu> writes:
Stefan> It took me a significant amount of rework to fix it for
Stefan> Emacs-21.
Stefan> I sent the corresponding patch+changelog to Jan Vroonhof,
Stefan> but merging them into XEmacs' regexp.c is not a piece of
Stefan> cake.
OK, I found that patch, he forwarded it to xemacs-beta in February or
so. I did read through the patch, and although I don't understand the
code, the comments seem to be greatly improved. I did recognize a lot
of it from browsing the regex.c. It seems like a lot should be fairly
straightforward to merge, maybe 2/3 to 3/4.
If you don't mind, I have a few questions:
Do you have any further comments you might be willing to make on main
difficulties in merging, or whatever?
When implementing shy-groups and non-greedy operators for Emacs,
I (of course) took a look at XEmacs' code and the regex.c code there
is clearly very similar to Emacs', so merging shouldn't be too difficult.
But I believe that there are many cosmetic differences in the code
which prevent "automatic" merging.
I think the cosmetic differences had mostly to do with MULE and with
syntax-tables (which can be overridden with text-properties in Emacs).
Do you have any other test cases, besides the two or three you put
in
the patch?
As I told Jan, I had more test cases, but I mistakenly deleted them
and couldn't find them on the backup tapes. I have some more by now.
I append my current test script.
I believe that we came across another bug recently that had to do with
intervals (counters were not reset when backtracking).
Has your code stood up in test since last year, or have you had to
make any revisions? (No offense intended, but that was not just a
"tweak"!).
No offense taken. Indeed I introduced a couple bugs, the latest one
was reported/fixed yesterday, as a matter of fact.
If anybody does the merge, I'll send him the remaining bug fixes.
Stefan
PS: while massaging the code I tried to factor out the details of the
multibyte support, so it *might* be easier to try and port Emacs' regex.c
to XEmacs than to merge my changes into the current code.
(the original motivation wasn't for XEmacs but rather for glibc, although
I haven't finished merging the glibc fixes/enhancements to regex.c
into Emacs'. And multibyte-regex support for glibc will require a good
bit more work that I don't intend to do).
8501
days inactive
8502
days old
3 comments
3 participants
participants (3)
-
Stefan Monnier -
Stefan Monnier -
Stephen J. Turnbull