Dear Richard, Thank you for pointing out "debug-on-entry" to me. This seems to be the easiest solution if I find other new problems with pretest version concerning old elisp libraries that are OUTSIDE the standard distribution. I no longer have to load the emacs lisp source file and interactively define debug break point.
Richard Stallman wrote:
Now, I tried in vain to figure out where the lazy-lock-mode is possibly set in *my own library files. and/or impoted from emacs archive*. You can debug that by means of debug-on-entry; call it at the start of your .emacs file and you should find out what enables lazy-lock. I would not want to change turn-on-lazy-lock to enable jit-lock instead of lazy-lock; that would be incoherent. What MIGHT make sense is to make lazy-lock-mode an alias for jit-lock-mode. That is coherent, but somewhat drastic. Are we sure that there is no reason at all for anyone to use lazy-lock any more?
Now, I have no idea whether depreciating lazy-lock may cause problems for others, but given that emacs 21 version has been around for a quite a while, it may take the users a prolonged time to update their *own* library files, initialization files, etc. to move over to newer packages/libraries. I leave the decision for the fate of lazy-lock to the experienced emacs hackers. But from the lusers's point of view, it would be nice to have a guideline of how to move over to newer and more powerful libraries/packages such as jit-lock from lazy-lock. (Info doesn't seem to have been updated... Just a thought. Happy Hacking, Chiaki Ishikawa _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug