line-move-partial too costly ?

line-move-partial too costly ?

[Michaël Cadilhac]

[-- 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

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Michaël Cadilhac]

[-- 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

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Chong Yidong]

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.

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Michaël Cadilhac]

[-- 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

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Richard Stallman]

    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?

Re: line-move-partial too costly ?

[Kim F. Storm]

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

Re: line-move-partial too costly ?

[Miles Bader]

[-- 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

Re: line-move-partial too costly ?

[Michaël Cadilhac]

[-- 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

Re: line-move-partial too costly ?

[Miles Bader]

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.