Stephen J. Turnbull writes: http://ftp.us.xemacs.org/ftp/pub/xemacs/packages/ispell-1.24-pkg.tar.gz says: ;; return library path. (re-search-forward "LIBDIR = \\\"\\([^ \t\n]*\\)\\\"" nil t) (if (match-beginning 0) (setq result (buffer-substring (match-beginning 1) (match-end 1))))) Sometimes, re-search-forward would not find the expression. But match-beginning still returned a true boolean value. That caused the "if" function to execute the true block which used match data from some previous search. Eventually it led to the ispell feature giving some error message. It was an intermittent bug, so you will probably have difficulty reproducing it. However, there is a fix at http://www.kdstevens.com/~stevens/ispell-page.html#download ispell.el version 3.6 says: ;; return library path. (if (re-search-forward "LIBDIR = \\\"\\([^ \t\n]*\\)\\\"" nil t) (setq result (buffer-substring (match-beginning 1) (match-end 1)))) So the fix was to use the return value of re-search-forward rather than the return value of match-beginning to determine if the search found anything. No. That sounds like a good technique. However, I think the technique in ispell.el 3.6 is even more straightforward and understandable. You mentioned that you agreed that the old behavior of xemacs is inconsistent with the documentation. Since you are planning to use the old behavior, I recommend changing the documentation to better describe that behavior. Maybe the documentation should mention the techniques of store-match-data and ispell.el 3.6. BTW, if you keep the old behavior of match-beginning, then I recommend that you have the xemacs project officially distribute ispell.el 3.6 since 3.6 works around the old behavior of match-beginning. BTW, there are still other bugs in ispell.el 3.6 which are not related to match-beginning, and I submitted fixes to ispell-el-bugs(a)itcorp.com. But, I did not get a response, and the web site I mentioned above does not appear to have my fixes. Let me know if you would like me to submit my fixes to you so you can add them to the xemacs official web site.

Thank you for your prompt, complete reply! bjacob> http://ftp.us.xemacs.org/ftp/pub/xemacs/packages/ispell-1.24-pkg.tar.gz OK, I'll see about updating ispell. bjacob> No. That sounds like a good technique. However, I think bjacob> the technique in ispell.el 3.6 is even more bjacob> straightforward and understandable. Agreed, for this case. However, if you had a "polymorphic" situation, I think something like (cond ((match-beginning 3) ...) ; handle 3-match case ((match-beginning 2) ...) ; handle 2-match case ((match-beginning 1) ...) ; handle 1-match case is elegant, and I would use the (store-match-data nil) case there. bjacob> You mentioned that you agreed that the old behavior of bjacob> xemacs is inconsistent with the documentation. Since you bjacob> are planning to use the old behavior, I recommend changing bjacob> the documentation to better describe that behavior. Maybe bjacob> the documentation should mention the techniques of bjacob> store-match-data Already in CVS ;-) and a proposal to GNU to synch is on emacs-devel. bjacob> and ispell.el 3.6. That's a good idea, but not as easy to write. Later.... :-) bjacob> Let me know if you would like me to submit my fixes to you bjacob> so you can add them to the xemacs official web site. Yes, please do. Send them to xemacs-patches(a)xemacs.org, and send a formatted ChangeLog so you'll get proper credit. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.