[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14838: 24.3.50; repeating next-line or previous-line is broken
From: |
Eli Zaretskii |
Subject: |
bug#14838: 24.3.50; repeating next-line or previous-line is broken |
Date: |
Thu, 11 Jul 2013 18:59:14 +0300 |
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 14838@debbugs.gnu.org
> Date: Thu, 11 Jul 2013 12:04:07 +0200
>
> Yes. First, I found out that the problems I observed do not happen when
> I repeat exactly the above recipe after having removed my ~/.Xresources
> file and logged in again. That file contains this:
>
> Emacs.FontBackend: xft
> Emacs.Font: DejaVu Sans Mono-9
>
> ! ---------[ xft ] ---------
> Xft*antialias: true
> Xft*autohint: true
>
> Without this, when I start Emacs with -Q, the font is still the one I
> reported above, but now holding down C-n in NEWS works fine. I don't
> understand why, since I thought -Q means no X resources are read.
It should. Is inhibit-x-resources set when you invoke with -Q?
Maybe the fact that X resources matter is a GTK thing? Just
guessing. Jan, could you please comment on this?
> When I start Emacs with my init file but without the .Xresources file, I
> also don't observe the problem with C-n. In my initializations, I have
> the font DejaVu Sans Mono-9 set as default in a custom theme loaded from
> my init file (I've been using the .Xresources file since long before
> creating the them, and didn't try removing till now). So without the
> .Xresources file, I have no problem using C-n with this font, but with
> the above .Xresources, the problem occurs with this font.
FWIW, I tried such a font as well (but without anti-aliasing), and
didn't see any problem.
> I started Emacs like this:
>
> emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el
>
> switched the default font to Adobe Courier as described above and then
> followed your instructions; here is the report:
>
> + call-interactively 6758 29%
> + next-line 6059 26%
> + if 5176 22%
> + line-move 3875 16%
> + command-execute 522 2%
> Automatic GC 445 1%
> + let 86 0%
> + redisplay_internal (C function) 35 0%
> + prog1 26 0%
> + read-from-minibuffer 24 0%
> + find-file-noselect 19 0%
> + run-hooks 18 0%
> + condition-case 16 0%
> + cond 12 0%
> + view-file 8 0%
> + mapc 4 0%
> + list 4 0%
> + read-extended-command 4 0%
> + vc-mode-line 3 0%
> + line-move-visual 3 0%
> + file-truename 2 0%
> + vc-find-file-hook 2 0%
> + vc-backend 2 0%
> + after-find-file 2 0%
> + completing-read 2 0%
> + let* 1 0%
> + view-emacs-news 1 0%
> + find-file-noselect-1 1 0%
> + vc-call-backend 1 0%
> internal-timer-start-idle 1 0%
> + and 1 0%
What do you see if you completely expand the profile? Do you see
line-move-partial anywhere in the profile? That's the only function
where I made significant changes in the offending revisions, so if
it's not high in the profile, I don't know what to think.
> followed by exactly 175 repetitions of these two lines (I used `M-x
> occur' to make sure they were all identical):
>
> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
> 2
>
> and nothing else.
The "py 0" part is very strange. "py" is the vertical coordinate of
point in screen line units. Since this was with C-n, I expect py
never to be less than half the screen height, which is 16. How come
it is zero, i.e. point is in the first line? Can you step through
line-move-partial in Edebug and see what is going on there?
> > I also asked to try reducing the keyboard auto-repeat rate, and see if
> > that makes any difference.
>
> The default rate in my setup is 25 repeats/s. I lowered it to 15 and
> repeated the above experiment, and the problem again occurs, but starts
> later, around line 300. Then I lowered the repeat rate to 10, which is
> annoyingly slow, and here too the problem occurs, starting around line
> 500.
This is consistent with the high CPU load you see. But I'd be damned
if I understand what is causing that CPU load, or why it happens with
some fonts, but not others.
Btw, do you have any local changes in your builds?
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/10
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/10
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/11
- bug#14838: 24.3.50; repeating next-line or previous-line is broken,
Eli Zaretskii <=
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/11
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/11
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/11
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/11
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/12
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/12
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/12
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Eli Zaretskii, 2013/07/13
- bug#14838: 24.3.50; repeating next-line or previous-line is broken, Stephen Berman, 2013/07/13