I see you installed a change that looks like it MIGHT fix this.
Does it in fact fix this?
It does in my tests.
Thanks. I can consider it done.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
I see you installed a change that looks like it MIGHT fix this.
Does it in fact fix this?
It does in my tests. There may be other cases, of course, but this patch
seemed like a good idea in any case.
Stefan
___
Emacs-pretest-bug mailing
I see you installed a change that looks like it MIGHT fix this.
Does it in fact fix this?
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
lazy-lock works OK. The OP's problem has to do with some details of
how he turns it on.
So, can we fix the mechanism for turning it on, so that customary ways
of doing so will once again work ok?
Sure. The infinite-lopping is the following:
- (font-lock-mode 1)
- (when (or
Stefan == Stefan Monnier [EMAIL PROTECTED]
on Tue, 30 Aug 2005 22:50:47 -0400 writes:
Since lazy-lock is now obsolete, perhaps we should
simply redefine turn-on-lazy-lock as a no-op, so that it
won't do any harm.
I think that making such a change on the basis that
How can compiling the functions in obsolete do any harm?
It wastes maintainers' time fixing up compilation problems in that
code. Also, producing autoloads from those files can conflict with
other things.
Do you also plan to remove obsolete from load-path?
I think not, at least not for
Many of the packages in `obsolete' simply don't work.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Funny: not that long ago you rejected my suggestion to remove obsolete from
the directories processed for cus-load.el and finder-inf.el.
I guess I have come around to your way of thinking.
___
Emacs-pretest-bug mailing list
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
I think that making such a change on the basis that lazy-lock is obsolete is
a bad idea.
Apparently it is not merely inferior--it seems it doesn't work
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
I think that making such a change on the basis that lazy-lock is
obsolete is a bad idea.
Apparently it is not merely inferior--it seems it doesn't work at
Jason == Jason Rumney [EMAIL PROTECTED]
on Sun, 28 Aug 2005 20:45:09 +0100 writes:
Jason Richard M. Stallman [EMAIL PROTECTED] writes:
We should probably also change the doc string for
font-lock-support-mode. Currently it lists
fast-lock-mode, lazy-lock-mode and
Richard M. Stallman [EMAIL PROTECTED] writes:
If we do that, we might as well delete lazy-lock.el and fast-lock.el
rather than leave them in obsolete.
We don't normally delete packages that are obsolete, we normally put
them in the `obsolete' directory. Is there a reason to treat
Richard M. Stallman [EMAIL PROTECTED] writes:
If we do that, we might as well delete lazy-lock.el and fast-lock.el
rather than leave them in obsolete.
We don't normally delete packages that are obsolete, we normally put
them in the `obsolete' directory. Is there a reason to treat
Jason Rumney [EMAIL PROTECTED] writes:
We don't normally delete packages that are obsolete, we normally put
them in the `obsolete' directory. Is there a reason to treat these
differently?
If we alias their main functions to a function from a non-obsolete
package, we are treating them
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
It might be more useful to print a message. Something like
lazy-lock is obsolete since Emacs 21. jit-lock is the recommended
replacement. See
To make SURE it does no harm, I will turn off compilation and other
such processing of the `obsolete' subdir.
Funny: not that long ago you rejected my suggestion to remove obsolete from
the directories processed for cus-load.el and finder-inf.el.
Stefan
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
I think that making such a change on the basis that lazy-lock is obsolete is
a bad idea.
OTOH, I agree with this change because turn-on-lazy-lock is obsolete: the
user
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
It might be more useful to print a message. Something like
lazy-lock is obsolete since Emacs 21. jit-lock is the recommended
replacement.
Why
Richard M. Stallman [EMAIL PROTECTED] writes:
We should probably also change the doc string for
font-lock-support-mode. Currently it lists fast-lock-mode,
lazy-lock-mode and jit-lock-mode in that order, with no mention of any
being obsolete.
Thanks for noticig that. I will
Richard M. Stallman [EMAIL PROTECTED] writes:
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
It might be more useful to print a message. Something like
lazy-lock is obsolete since Emacs 21.
Richard M. Stallman [EMAIL PROTECTED] writes:
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any harm.
It might be more useful to print a message. Something like
lazy-lock is obsolete since Emacs 21. jit-lock is the
emacs -Q --eval=
(progn (setq debug-on-error t)
(add-hook 'font-lock-mode-hook 'turn-on-lazy-lock)
(global-font-lock-mode t))
Since lazy-lock is now obsolete, perhaps we should simply redefine
turn-on-lazy-lock as a no-op, so that it won't do any
Chris == Chris Moore [EMAIL PROTECTED]
on Wed, 24 Aug 2005 19:11:15 +0200 writes:
Because of my ~/.emacs and our site-local default.el are not
small and load dozens of other files, I'd need quite a bit of time
for producing a smallish single-file ~/.emacs which
Well, I've taken the time and have succeeded:
The following reproducibly produces the bug
emacs-22.0.50 -q -l emacs-22.0-bug.el
where I've attached the emacs-22.0-bug.el file (in text/plain)
I can confirm that I see an error with that file. And here's a
command line that needs no
Chris Moore wrote:
Perhaps the creation of jit-lock-mode is what
obsoleted lazy-lock-mode.
Correct. When variable font support was added, some of the assumptions
lazy-lock makes about what needs fontifying became invalid. A completely
different strategy involving hooks into the low level
RMS == Richard M Stallman [EMAIL PROTECTED]
on Wed, 24 Aug 2005 06:33:05 -0400 writes:
RMS It also seems like the problem I was seeing has been fixed in the
RMS latest CVS code anyway - I can no longer reproduce it.
RMS That is good news.
for Chris' problem, yes.
But I am
Because of my ~/.emacs and our site-local default.el are not
small and load dozens of other files, I'd need quite a bit of time
for producing a smallish single-file ~/.emacs which
reproduces the problem.
If you can't tell us how to reproduce the problem then we have no
chance of fixing it.
Hi Martin.
I found that simply putting:
(require 'tramp)
as the first line of my ~/.emacs solved the problem for me.
It also seems like the problem I was seeing has been fixed in the
latest CVS code anyway - I can no longer reproduce it.
Chris.
On 8/22/05, Martin Maechler [EMAIL PROTECTED]
Dear Chris,
I've started to use Emacs CVS (22.50.1) today and quickly got
problems with a permanently reproduced 1) error message
Error in post-command-hook: (error Lisp nesting exceeds `max-lisp-eval-depth')
When googling for this, I quickly found your posting to the
emacs-pretest-bug mailing
To debug this, we need a test case.
Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.
___
Emacs-pretest-bug mailing list
30 matches
Mail list logo
