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
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
