I noticed the same thing and did it today.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I've just noticed that you added
(overlay-recenter (point-max))
to `remove-overlays'. That might cause a slowdown if you remove
overlays near bob and there are many overlays between the ones you
remove and eob. Please consider replacing this by
(overlay-recenter end)
after the value of `end'
So, if I understand you correctly, the change to make is to replace
(remove-overlays nil nil 'face 'whitespace-highlight)
(overlay-recenter (point-max))
with
(overlay-recenter (point-max))
(remove-overlays nil nil 'face 'whitespace-highlight)
Is that right?
Right.
_
martin rudalics <[EMAIL PROTECTED]> writes:
> On the other hand, doing "(overlay-recenter (point-max))" before
> deleting the overlays seems crucial. Apparently, `overlays-in' always
> returns a list of overlays in reverse order of their buffer positions.
> With the overlay center at bob, unchain
> If you've found a slowness in remove-overlays, could you aim to make
> that function faster, rather than making its caller faster by not using
> remove-overlays?
Using `remove-overlays' to delete all overlays with a given property is
overkill. The tests
(if (< (overlay-start o) beg)
If you've found a slowness in remove-overlays, could you aim to make
that function faster, rather than making its caller faster by not using
remove-overlays?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/list
> Thanks for your prompt answer!
> Yes, with this last fix finally whitespace-buffer seems to be quite
> fast each time.
Thanks for you cooperation. Please keep an eye on this.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists
2006/11/5, martin rudalics <[EMAIL PROTECTED]>:
I see. Please replace the two lines
(remove-overlays nil nil 'face 'whitespace-highlight)
(overlay-recenter (point-max))
by
(overlay-recenter (point-max))
(dolist (overlay (overlays-in (point-min) (point-m
> I tried M-: (remove-overlays nil nil 'face 'whitespace-highlight) and
> it took about the same time what was the increment between first and
> other runs. Evaluating it when point is at bottom, very fast, but when
> point is at top, it is slow.
>
> I think you can easily test it by making slowts
2006/11/2, martin rudalics <[EMAIL PROTECTED]>:
> 1. whitespace-buffer on slowtst.el takes ~9 seconds (=the same result
> what I got with your previous fix) IF point is at the beginning of the
> buffer. If point is somewhere down (e.g. at (point-max))
> whitespace-buffer finishes in ~2 second
> From: Richard Stallman <[EMAIL PROTECTED]>
> Date: Sat, 04 Nov 2006 01:38:42 -0500
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
>
> Would someone please install Martin's patch?
Done.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Could *please* someone document the function `overlay-recenter' in the
Elisp manual.
I will do so.
Would someone please install Martin's patch?
It appears that nothing in Emacs normally calls overlay-recenter.
Shouldn't we set up some occasional calls (overlay-recenter (point))?
Would
So if you could find the reason of this strange difference related to
(point), then there would be no performace problem with whitespace.
I suspect this has to do with the way overlays are stored -- in two lists,
those before the "center" and those after the "center".
(The center can be an
> Interesting things again! I tried this latest whitespace.el and found
> the followings:
>
> 1. whitespace-buffer on slowtst.el takes ~9 seconds (=the same result
> what I got with your previous fix) IF point is at the beginning of the
> buffer. If point is somewhere down (e.g. at (point-max))
>
2006/11/1, Richard Stallman <[EMAIL PROTECTED]>:
Yes, OK. I sent these info only for your information. (Unfortunately I
don't work on opensorce sw officially,
Please don't think of GNU Emacs as "open source".
GNU is part of the free software movement; we developed
GNU Emacs for the sake
2006/11/1, martin rudalics <[EMAIL PROTECTED]>:
OK. Attached find my latest version of whitespace.el. Please try it
for all five sorts of whitespace bemoaned by that program and whether
the cleanup routines fix it in the expected manner.
Interesting things again! I tried this latest whitespac
So for me it seems your patches improve whitespace.el a lot and fix
another bug (=doing nothing for 18 seconds?).
OK. Attached find my latest version of whitespace.el. Please try it
for all five sorts of whitespace bemoaned by that program and whether
the cleanup routines fix it in the expecte
Attached find patch and ChangeLog entry for this.
* whitespace.el (whitespace-indent-regexp): Make this match any
multiples of eight spaces near the beginning of a line.
(whitespace-buffer): Use `remove-overlays' instead of
`whitespace-unhighlight-the-space' to spee
Yes, OK. I sent these info only for your information. (Unfortunately I
don't work on opensorce sw officially,
Please don't think of GNU Emacs as "open source".
GNU is part of the free software movement; we developed
GNU Emacs for the sake of users' freedom.
See http://www.gnu.org/philosop
2006/10/31, martin rudalics <[EMAIL PROTECTED]>:
I'll send you my latest copy separately.
Thanks! Now I've tried (with patched EmacsW32 version CvsP061023 ) it
and found the followings:
1. starting Emacs with -Q and using the official whitespace.el (not
the .elc to be fair) whitespace-buffer
2006/10/31, martin rudalics <[EMAIL PROTECTED]>:
Since I don't know your "problematic original source file" I can only
refer to slowtst.el.
Yes, OK. I sent these info only for your information. (Unfortunately I
don't work on opensorce sw officially, that is why I dare not send
that proprietary
> What shall I check exactly here? I ran this white() and yes, it
> finishes in 1-2 seconds. However I also ran (M-:)
> (whitespace-buffer-search whitespace-ateol-regexp) and it also took
> 1-2 seconds on my problematic original source file (it has only one
> eol "error").
> However with my slowts
2006/10/20, martin rudalics <[EMAIL PROTECTED]>:
Try the below. It mimics the ateol part of the `whitespace-buffer' loop
and completes on my system in less than 4 seconds. The analogous part
of `whitespace-buffer' takes almost 30 seconds to complete. I can't
tell what makes the difference but
2006/10/19, Peter Tury <[EMAIL PROTECTED]>:
Especially because "older" v22(!) Emacs (e.g. EmacsW32 of May -- see
my previous letters) was much more faster: they opened the problematic
files in 1-3(?) seconds -- and whitespace.el wasn't really modified
since then!? (I will double check that versio
I think (1) the timer should become an idle-timer, (2) quitting must be
permitted,
You can permit quitting by using with-local-quit. Want to do that?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/lis
I forgot to say that I can't follow Peter's argument that older 2006 Emacsen
didn't have this problem. I tried with a couple of versions starting with a
mid-2005 one and all exhibited the same behavior as the most recent one.
___
emacs-pretest-bug ma
> It looks like we could speed it up even more
> by producing this list
>
> ! (setq whitespace-retval (cons (match-beginning 0)
whitespace-retval))
>
> only if it is actually wanted. Calling from whitespace-buffer
> could pass t as an optional argument saying do produce this list.
We c
It looks like we could speed it up even more
by producing this list
! (setq whitespace-retval (cons (match-beginning 0) whitespace-retval))
only if it is actually wanted. Calling from whitespace-buffer
could pass t as an optional argument saying do produce this list.
The overhead fo
> In fact I realized this problem when I wanted to switch from "old" v22
> EmacsW32 to the newest one, but after installing the new one, it
> seemed not to start properly (=it hanged for long time, and I killed
> it in that state). Finally I realized that I had desktop saving in my
> .emacs, and t
2006/10/20, martin rudalics <[EMAIL PROTECTED]>:
> (Though I still think that the real problem is introduced
> outside of whitespace.el).
Try the below. It mimics the ateol part of the `whitespace-buffer' loop
and completes on my system in less than 4 seconds.
OK, I'll try it. Thanks!
But I
>> > It seems whitespace-buffer slows down my Emacs so terribly: my .emacs
>> > sets whitespace-global-mode with its all bells and whistles
>> > finally I found that if I M-x whitespace-buffer with my critical file
>> > opened in the buffer (regardless of whitespace-global-mode setting) I
>> >
> As far as I know normal font-lock solves this problem by colorizing
> only some parts of the file (~what can be seen in the buffer
> actually(?)). Would it be too hard to modify whitespace to work in
> this way?
It's jit-lock actually. The problem is that whitespace is written in an
XEmacs-com
2006/10/19, martin rudalics <[EMAIL PROTECTED]>:
>> > However I see that it is not
>> > really modified between the fast (old) and slow (new) Emacses...
Emacs 21.3 had whitespace 3.1 which did not highlight incriminated areas
and used slightly simpler regexps. Emacs 22 has whitespace 3.5 whic
> Date: Tue, 17 Oct 2006 23:00:34 +0200
> From: "Peter Tury" <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org
>
> It seems whitespace-buffer slows down my Emacs so terribly: my .emacs
> sets whitespace-global-mode with its all bells and whistles
> finally I found that if I M-x whitespace-bu
2006/10/12, Eli Zaretskii <[EMAIL PROTECTED]>:
> Date: Wed, 11 Oct 2006 22:54:05 +0200
> From: "Peter Tury" <[EMAIL PROTECTED]>
>
> Now I've tried emacs.exe -Q; then opening the 1MB file: it's fine (1-2
> seconds), but fundamental mode was used. In this running "pure" emacs
> I loaded the files f
> Date: Wed, 11 Oct 2006 22:54:05 +0200
> From: "Peter Tury" <[EMAIL PROTECTED]>
>
> normally I start emacs with the "default EmacsW32 icon" (= gnuclientw.exe
> -sqf).
>
> Now I've tried emacs.exe -Q; then opening the 1MB file: it's fine (1-2
> seconds), but fundamental mode was used. In this ru
Hi,
additional info:
normally I start emacs with the "default EmacsW32 icon" (= gnuclientw.exe -sqf).
Now I've tried emacs.exe -Q; then opening the 1MB file: it's fine (1-2
seconds), but fundamental mode was used. In this running "pure" emacs
I loaded the files for the specific mode support for
37 matches
Mail list logo
