> Date: Mon, 8 Jul 2013 15:55:22 +0400
> From: Dave Milter <davemilter@...>
> Cc: semantic cedet <cedet-semantic@...>,
> "Eric M. Ludlam" <eric@...>
> I met the same problem.
> It is fun to see what happens for example when I use 'C-x 2' to work with
> two buffers.
> While I editing one buffer, another buffer scroll forward and backward, it
> looks like ghost work on my machine with me.
> May be experienced emacs developer suggest how track down this problem?
> I see it like for example exists two function:
> I put breakpoints on them with condition that on top of call stack is
> "timer event", not "key event". And then see who is ghost.
> Anybody from top emacs coders know is it possible?
> Are there
> and what are their names,
What you see is not some scroll-buffer function, it is redisplay
trying to keep point in view. This part of Emacs is written in C, so
you'd need to set breakpoints in GDB.
But there are too many places that could be involved in these
unwarranted scrolls; setting breakpoints on all of them will produce
gobs of clutter. The best I can suggest is this:
. build Emacs with -DGLYPH_DEBUG=1
. run it as you do usually, and after setting up the stage for these
scrolls, type "M-x trace-redisplay RET"
. watch the screen where Emacs's stderr goes, and try to identify the
traces emitted when those "ghost" scrolls happen
. post those traces here
Armed with the above, I might be able to tell you where to set
breakpoints in GDB so that you catch the Lisp code which triggers
That said, I'm not sure what you expect to find, since Eric already
told you where this is done, and even said this is on purpose:
> The place to start is in cedet/semantic/idle.el. The outward call to
> the various work functions purposely does not use 'save-excursion' so
> tools like completion can move things around for you.
Or maybe I don't understand what he meant.