* line-move-partial too costly ?
@ 2006-09-13 14:11 Michaël Cadilhac
2006-09-13 22:51 ` Kim F. Storm
2006-09-14 12:29 ` Miles Bader
0 siblings, 2 replies; 14+ messages in thread
From: Michaël Cadilhac @ 2006-09-13 14:11 UTC (permalink / raw)
Cc: storm
[-- Attachment #1.1: Type: text/plain, Size: 1837 bytes --]
Since the creation of line-move-partial, going to the next few lines
has become a P*TA.
I don't think my computer, with an Athlon XP 2000+, is too old to not
be concerned by Emacs user-friendliness :-)
With emacs -Q, if I entirely fill the scratch buffer (150 columns, 75
lines) and then press C-n and _stay on it_,[1] the cursor is blocked
at the second line. When C-n is released, Emacs responds only after
a second or so.
If I remove the call to line-move-partial, everything is fine (except,
certainly, the display of partial images).
The guilty part seems to be this one:
(let* ((ppos (posn-at-point))
(py (cdr (or (posn-actual-col-row ppos)
(posn-col-row ppos))))
(vs (window-vscroll nil t))
Is there any solution ?
Footnotes:
[1] I use xset r rate 300 250, which is quite speedy.
----
In GNU Emacs 22.0.50.44 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2006-09-13 on mahaena
X server distributor `Gentoo (The X.Org Foundation 6.8.2, revision r6-0.1.13)', version 11.0.60802000
configured using `configure '--prefix=/usr' 'CFLAGS=-ggdb -O0''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
----
--
/!\ My mail address changed, please update your files accordingly.
| Michaël `Micha' Cadilhac | (\(\ This is the cute bunny virus, |
| Epita/LRDE Promo 2007 | (^.^) please copy this into your |
| http://michael.cadilhac.name | (")") sig so it can spread. |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-13 14:11 line-move-partial too costly ? Michaël Cadilhac
@ 2006-09-13 22:51 ` Kim F. Storm
2006-09-14 12:23 ` Michaël Cadilhac
2006-09-14 12:29 ` Miles Bader
1 sibling, 1 reply; 14+ messages in thread
From: Kim F. Storm @ 2006-09-13 22:51 UTC (permalink / raw)
Cc: emacs-devel
michael@cadilhac.name (Michaël Cadilhac) writes:
> Since the creation of line-move-partial, going to the next few lines
> has become a P*TA.
> Is there any solution ?
I installed a small optimization -- pls try again.
You could set redisplay-dont-pause to t.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-13 22:51 ` Kim F. Storm
@ 2006-09-14 12:23 ` Michaël Cadilhac
2006-09-14 14:15 ` Kim F. Storm
2006-09-15 21:06 ` Kim F. Storm
0 siblings, 2 replies; 14+ messages in thread
From: Michaël Cadilhac @ 2006-09-14 12:23 UTC (permalink / raw)
Cc: rms, emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 919 bytes --]
storm@cua.dk (Kim F. Storm) writes:
> michael@cadilhac.name (Michaël Cadilhac) writes:
>
>> Since the creation of line-move-partial, going to the next few lines
>> has become a P*TA.
>
>> Is there any solution ?
>
> I installed a small optimization -- pls try again.
>
> You could set redisplay-dont-pause to t.
AFAICT, it doesn't fix my problem. I recompiled Emacs with -O3, and
the problem remains, setting redisplay-dont-pause didn't help.
Maybe the feature provided by line-move-partial can be optional?
--
/!\ My mail address changed, please update your files accordingly.
| Michaël `Micha' Cadilhac | Mieux vaut se taire |
| Epita/LRDE Promo 2007 | Que de parler trop fort. |
| http://michael.cadilhac.name | -- As de trèfle |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-13 14:11 line-move-partial too costly ? Michaël Cadilhac
2006-09-13 22:51 ` Kim F. Storm
@ 2006-09-14 12:29 ` Miles Bader
2006-09-14 12:58 ` Michaël Cadilhac
1 sibling, 1 reply; 14+ messages in thread
From: Miles Bader @ 2006-09-14 12:29 UTC (permalink / raw)
Cc: storm, emacs-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 632 bytes --]
michael@cadilhac.name (Micha^[.A^[Nkl Cadilhac) writes:
> I don't think my computer, with an Athlon XP 2000+, is too old to not
> be concerned by Emacs user-friendliness :-)
>
> With emacs -Q, if I entirely fill the scratch buffer (150 columns, 75
> lines) and then press C-n and _stay on it_,[1] the cursor is blocked
> at the second line. When C-n is released, Emacs responds only after
> a second or so.
Something seems very strange -- I'm on a slower computer than you, but
see absolutely no slowdown in the above scenario.... This is true
whether I use -q or not.
-Miles
--
^[$B<+$i$r6u$K$7$F!"?4$r3+$/;~!"F;$O3+$+$l$k^[(B
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-14 12:29 ` Miles Bader
@ 2006-09-14 12:58 ` Michaël Cadilhac
2006-09-14 13:31 ` Miles Bader
0 siblings, 1 reply; 14+ messages in thread
From: Michaël Cadilhac @ 2006-09-14 12:58 UTC (permalink / raw)
Cc: emacs-devel, Michaël Cadilhac, storm
[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]
Miles Bader <miles.bader@necel.com> writes:
> michael@cadilhac.name (Michaël Cadilhac) writes:
>> I don't think my computer, with an Athlon XP 2000+, is too old to not
>> be concerned by Emacs user-friendliness :-)
>>
>> With emacs -Q, if I entirely fill the scratch buffer (150 columns, 75
>> lines) and then press C-n and _stay on it_,[1] the cursor is blocked
>> at the second line. When C-n is released, Emacs responds only after
>> a second or so.
>
> Something seems very strange -- I'm on a slower computer than you, but
> see absolutely no slowdown in the above scenario.... This is true
> whether I use -q or not.
Thanks for testing! Did you use a particular keyboard rate? With the
default X one, I don't have this problem.
--
/!\ My mail address changed, please update your files accordingly.
| Michaël `Micha' Cadilhac | Isn't vi that text editor with |
| Epita/LRDE Promo 2007 | two modes... One that beeps and |
| http://michael.cadilhac.name | one that corrupts your file? |
`-- - JID: micha@amessage.be --' -- Dan Jacobson - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-14 12:58 ` Michaël Cadilhac
@ 2006-09-14 13:31 ` Miles Bader
0 siblings, 0 replies; 14+ messages in thread
From: Miles Bader @ 2006-09-14 13:31 UTC (permalink / raw)
Cc: emacs-devel, storm
michael@cadilhac.name (Michaël Cadilhac) writes:
> Thanks for testing! Did you use a particular keyboard rate? With the
> default X one, I don't have this problem.
Ah, no. If I use your "very fast" kbd repeat rate I do see the issue.
I also notice:
* It only happens if font-lock is turned on (I guess just slowdown
from font-locking?)
* It only happens with C-n, not C-p. C-p is fast with no pauses
(regardless of font-lock status).
-Miles
--
I'd rather be consing.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-14 12:23 ` Michaël Cadilhac
@ 2006-09-14 14:15 ` Kim F. Storm
2006-09-15 21:06 ` Kim F. Storm
1 sibling, 0 replies; 14+ messages in thread
From: Kim F. Storm @ 2006-09-14 14:15 UTC (permalink / raw)
Cc: rms, emacs-devel
michael@cadilhac.name (Michaël Cadilhac) writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>> michael@cadilhac.name (Michaël Cadilhac) writes:
>>
>>> Since the creation of line-move-partial, going to the next few lines
>>> has become a P*TA.
>>
>>> Is there any solution ?
>>
>> I installed a small optimization -- pls try again.
>>
>> You could set redisplay-dont-pause to t.
>
> AFAICT, it doesn't fix my problem. I recompiled Emacs with -O3, and
> the problem remains,
I'll see if I can find some way to optimize it further.
> setting redisplay-dont-pause didn't help.
>
> Maybe the feature provided by line-move-partial can be optional?
M-: (setq auto-window-vscroll nil)
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-14 12:23 ` Michaël Cadilhac
2006-09-14 14:15 ` Kim F. Storm
@ 2006-09-15 21:06 ` Kim F. Storm
2006-09-18 15:52 ` Chong Yidong
2006-09-19 8:19 ` Michaël Cadilhac
1 sibling, 2 replies; 14+ messages in thread
From: Kim F. Storm @ 2006-09-15 21:06 UTC (permalink / raw)
Cc: rms, emacs-devel
michael@cadilhac.name (Michaël Cadilhac) writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>> michael@cadilhac.name (Michaël Cadilhac) writes:
>>
>>> Since the creation of line-move-partial, going to the next few lines
>>> has become a P*TA.
>>
>>> Is there any solution ?
>>
>> I installed a small optimization -- pls try again.
>>
> AFAICT, it doesn't fix my problem.
I have installed an more elaborate change to line-move-partial
(involving a new primitive `window-line-visibility').
Pls. see if that fixes the problem for you.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-15 21:06 ` Kim F. Storm
@ 2006-09-18 15:52 ` Chong Yidong
2006-09-18 20:42 ` Kim F. Storm
2006-09-19 8:19 ` Michaël Cadilhac
1 sibling, 1 reply; 14+ messages in thread
From: Chong Yidong @ 2006-09-18 15:52 UTC (permalink / raw)
Cc: rms, Michaël Cadilhac, emacs-devel
storm@cua.dk (Kim F. Storm) writes:
>>>> Since the creation of line-move-partial, going to the next few lines
>>>> has become a P*TA.
>>>
>>>> Is there any solution ?
>>>
>>> I installed a small optimization -- pls try again.
>>>
>> AFAICT, it doesn't fix my problem.
>
> I have installed an more elaborate change to line-move-partial
> (involving a new primitive `window-line-visibility').
Can we consider the FOR-RELEASE item fixed?
** Michael Cadilhac's line-move-partial is slow.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-18 15:52 ` Chong Yidong
@ 2006-09-18 20:42 ` Kim F. Storm
0 siblings, 0 replies; 14+ messages in thread
From: Kim F. Storm @ 2006-09-18 20:42 UTC (permalink / raw)
Cc: rms, Michaël Cadilhac, emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>>>>> Since the creation of line-move-partial, going to the next few lines
>>>>> has become a P*TA.
>>>>
>>>>> Is there any solution ?
>>>>
>>>> I installed a small optimization -- pls try again.
>>>>
>>> AFAICT, it doesn't fix my problem.
>>
>> I have installed an more elaborate change to line-move-partial
>> (involving a new primitive `window-line-visibility').
>
> Can we consider the FOR-RELEASE item fixed?
>
> ** Michael Cadilhac's line-move-partial is slow.
Michaël still has to confirm that the changes I made in the last few
days fixes the problem. If not, I have one more thing I can try....
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-15 21:06 ` Kim F. Storm
2006-09-18 15:52 ` Chong Yidong
@ 2006-09-19 8:19 ` Michaël Cadilhac
2006-09-19 12:07 ` Kim F. Storm
2006-09-19 22:57 ` Richard Stallman
1 sibling, 2 replies; 14+ messages in thread
From: Michaël Cadilhac @ 2006-09-19 8:19 UTC (permalink / raw)
Cc: rms, emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 3976 bytes --]
storm@cua.dk (Kim F. Storm) writes:
> michael@cadilhac.name (Michaël Cadilhac) writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> michael@cadilhac.name (Michaël Cadilhac) writes:
>>>
>>>> Since the creation of line-move-partial, going to the next few lines
>>>> has become a P*TA.
>>>
>>>> Is there any solution ?
>>>
>>> I installed a small optimization -- pls try again.
>>>
>> AFAICT, it doesn't fix my problem.
>
> I have installed an more elaborate change to line-move-partial
> (involving a new primitive `window-line-visibility').
(* Sorry for the delay *)
It makes the job ! I'm no longer stuck at the first line when going to
the next few lines.
To me, it's OK, but I have a minor issue (I don't know if it needs
attention).
After scrolling a couple of screens with C-n, the cursor stops, like
previously (it doesn't happen with auto-window-vscroll to nil), and
the display is buggy for the time I'm stuck (which could be quite
long [1]). The cursor stop happens on a screen change, and appears like
that :
http://www.lrde.org/~cadilh_m/freeze.png
As you can see, the first half of the screen is correct whilst the
other one hasn't been redrawn. Like if the redisplay was made before
the scroll change, and not after.
Voilà, FWIW :-)
Footnotes:
[1] I tried to make a fix for this one. The principle was : if
there's unread C-n when entering next-line, just buffer its arg.
The (dirty) patch, that moreover doesn't work, looks like that :
Index: simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.820
diff -b -u -w -r1.820 simple.el
@@ -3379,6 +3381,26 @@
:version "21.1"
:group 'editing-basics)
+(defvar next-or-previous-line-count 0
+ "Buffer for line moves.
+If `next-line' or `previous-line' are used repeatedly, the amount
+of line to scroll is stored to avoid freezing.")
+
+(defun update-next-or-previous-line-count (arg)
+ "Update `next-or-previous-line-count' by adding ARG to it if necessary."
+ (let ((unread (append unread-command-events
+ unread-post-input-method-events
+ unread-input-method-events
+ (if (> unread-command-char 0)
+ (list unread-command-char)
+ nil))))
+ (when (progn (while (and unread (not (memq (key-binding (car unread))
+ '(next-line previous-line))))
+ (setq unread (cdr unread)))
+ unread)
+ (setq next-or-previous-line-count (+ next-or-previous-line-count arg)))))
+
+
(defun next-line (&optional arg try-vscroll)
"Move cursor vertically down ARG lines.
Interactively, vscroll tall lines if `auto-window-vscroll' is enabled.
@@ -3402,6 +3424,9 @@
and more reliable (no dependence on goal column, etc.)."
(interactive "p\np")
(or arg (setq arg 1))
+ (when (not (update-next-or-previous-line-count arg))
+ (setq arg (+ arg next-or-previous-line-count)
+ next-or-previous-line-count 0)
(if (and next-line-add-newlines (= arg 1))
(if (save-excursion (end-of-line) (eobp))
;; When adding a newline, don't expand an abbrev.
@@ -3436,9 +3461,12 @@
(interactive "p\np")
(or arg (setq arg 1))
(if (interactive-p)
+ (when (not (update-next-or-previous-line-count arg))
+ (setq arg (+ arg next-or-previous-line-count)
+ next-or-previous-line-count 0)
(condition-case nil
(line-move (- arg) nil nil try-vscroll)
((beginning-of-buffer end-of-buffer) (ding)))
(line-move (- arg) nil nil try-vscroll))
nil)
--
/!\ My mail address changed, please update your files accordingly.
| Michaël `Micha' Cadilhac | Un certain Blaise Pascal |
| Epita/LRDE Promo 2007 | etc... etc... |
| http://michael.cadilhac.name | -- Prévert (Les paris stupides) |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-19 8:19 ` Michaël Cadilhac
@ 2006-09-19 12:07 ` Kim F. Storm
2006-09-19 22:57 ` Richard Stallman
1 sibling, 0 replies; 14+ messages in thread
From: Kim F. Storm @ 2006-09-19 12:07 UTC (permalink / raw)
Cc: rms, emacs-devel
michael@cadilhac.name (Michaël Cadilhac) writes:
> It makes the job ! I'm no longer stuck at the first line when going to
> the next few lines.
Good.
>
> To me, it's OK, but I have a minor issue (I don't know if it needs
> attention).
I have a few more changes pending, but I don't think they will fix this.
>
> After scrolling a couple of screens with C-n, the cursor stops, like
> previously (it doesn't happen with auto-window-vscroll to nil), and
> the display is buggy for the time I'm stuck (which could be quite
> long [1]).
That's because redisplay has fallen behind, and until it catches up,
new input keep on interrupting redisplay.
> As you can see, the first half of the screen is correct whilst the
> other one hasn't been redrawn. Like if the redisplay was made before
> the scroll change, and not after.
This should be fixed by setting redisplay-dont-pause to t.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-19 8:19 ` Michaël Cadilhac
2006-09-19 12:07 ` Kim F. Storm
@ 2006-09-19 22:57 ` Richard Stallman
2006-09-20 10:50 ` Kim F. Storm
1 sibling, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2006-09-19 22:57 UTC (permalink / raw)
Cc: emacs-devel, storm
After scrolling a couple of screens with C-n, the cursor stops, like
previously (it doesn't happen with auto-window-vscroll to nil), and
the display is buggy for the time I'm stuck (which could be quite
long [1]). The cursor stop happens on a screen change, and appears like
that :
This just means that C-n is slow. Kim Storm tried to optimize it;
were the optimizations made so far not sufficient?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: line-move-partial too costly ?
2006-09-19 22:57 ` Richard Stallman
@ 2006-09-20 10:50 ` Kim F. Storm
0 siblings, 0 replies; 14+ messages in thread
From: Kim F. Storm @ 2006-09-20 10:50 UTC (permalink / raw)
Cc: Michaël Cadilhac, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> After scrolling a couple of screens with C-n, the cursor stops, like
> previously (it doesn't happen with auto-window-vscroll to nil), and
> the display is buggy for the time I'm stuck (which could be quite
> long [1]). The cursor stop happens on a screen change, and appears like
> that :
>
> This just means that C-n is slow. Kim Storm tried to optimize it;
> were the optimizations made so far not sufficient?
My recent optimizations have been in the case where the display is
up-to-date (as when the cursor just moves within the window), but
not when the display actually needs to be updated / scrolled.
I have just installed a change that should make line-move-partial
about 3-4 times faster when the display is not up-to-date.
If this still doesn't help, I don't see what else I can do.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-09-20 10:50 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-13 14:11 line-move-partial too costly ? Michaël Cadilhac
2006-09-13 22:51 ` Kim F. Storm
2006-09-14 12:23 ` Michaël Cadilhac
2006-09-14 14:15 ` Kim F. Storm
2006-09-15 21:06 ` Kim F. Storm
2006-09-18 15:52 ` Chong Yidong
2006-09-18 20:42 ` Kim F. Storm
2006-09-19 8:19 ` Michaël Cadilhac
2006-09-19 12:07 ` Kim F. Storm
2006-09-19 22:57 ` Richard Stallman
2006-09-20 10:50 ` Kim F. Storm
2006-09-14 12:29 ` Miles Bader
2006-09-14 12:58 ` Michaël Cadilhac
2006-09-14 13:31 ` Miles Bader
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.