Re: [cedet-semantic] scrolling while editing RFC

Re: [cedet-semantic] scrolling while editing RFC

[Dave Milter]

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

Hi, any update on this?
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:
the-most-internal-scroll-buffer-function
the-most-internal-move-cursor-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
the-most-internal-scroll-buffer-function
the-most-internal-move-cursor-function
and what are their names,
and is it possible to check call stack and find out certain function on it?


On Fri, Jun 21, 2013 at 6:26 AM, Eric M. Ludlam <eric@siege-engine.com>wrote:

> On 06/18/2013 05:15 PM, Barry OReilly wrote:
> > While I'm editing C++ or Java source code, I find that there is
> > undesired scrolling, seemingly because of Semantic parsing new code. I
> > started seeing this when I customized scroll-margin to 4 and
> > scroll-conservatively to 101. I'll be in the middle of typing code
> > (nowhere near the scroll margins), then I see point briefly flash to the
> > function header and back to where I'm editing. While the point moved
> > however, it caused an automatic scroll.
> >
> > I experimented with something like this in a command:
> >
> >    (defun myfun ()
> >      (interactive)
> >      (save-excursion (goto-char 43) (sleep-for 1)))
> >
> > and found that M-x myfun never causes an automatic scroll, no matter
> > whether position 43 is outside view, in the scroll-margin, or in the
> > middle of view. Also, during the 1 second I don't even see point at 43,
> > like I do when I encounter this bug.
> >
> > Does Semantic ever move point outside of save-excursion and restore it
> > another way? Could you indicate the Semantic functions invoked while one
> > is writing code? Perhaps you could write code for a little with these
> > scroll settings to see if you can reproduce it.
>
> Hi Barry,
>
>    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.
>
>    An easy trick is to use the Development menu to turn off all the
> various service modes (like parse in idle time) and see which one causes
> the scroll.  Maybe tag summaries or tag completion is it.
>
> Good Luck
> Eric
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

[-- Attachment #2: Type: text/html, Size: 3967 bytes --]

Re: [cedet-semantic] scrolling while editing RFC

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

> Hi, any update on this?

I was planning to submit a bug report, but hadn't because I don't have a
reproduction recipe nor have I definitively pinned it down on Semantic.

Since I don't have a reproduction recipe, I haven't made much progress. I
tried advising my after change hooks:

  (defadvice semantic-change-function (around
my-advice-semantic-change-function activate)
    (let ((window-start-prior (window-start)))
      ad-do-it
      (my-msg "DEBUG: During semantic-change-function, window-start
change:%s,%s" window-start-prior (window-start))))

Same defadvice for: c-after-change jit-lock-after-change. I also activated
this advice for semantic-idle-core-handler. Basically this was to catch one
of them in the act of scrolling the buffer. However, I encountered the bug
with these in place and none showed a window-start discrepancy.

If you have a reliable reproduction recipe, that would be very helpful.

[-- Attachment #2: Type: text/html, Size: 1005 bytes --]

Re: [cedet-semantic] scrolling while editing RFC

[Eli Zaretskii]

> Date: Mon, 8 Jul 2013 15:55:22 +0400
> From: Dave Milter <davemilter@gmail.com>
> Cc: semantic cedet <cedet-semantic@lists.sourceforge.net>,
> 	"Eric M. Ludlam" <eric@siege-engine.com>
> 
> 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:
> the-most-internal-scroll-buffer-function
> the-most-internal-move-cursor-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
> the-most-internal-scroll-buffer-function
> the-most-internal-move-cursor-function
> 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
these scrolls.

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.

Re: [cedet-semantic] scrolling while editing RFC

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Thanks for the tips, I will try it out. Since I can't reproduce it at will,
I'm not sure when I'll secure the redisplay traces.

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

I have seen the undesired scrolling with
global-semantic-idle-completions-mode disabled. Specifically, with these
Semantic submodes:

  (setq semantic-default-submodes '(global-semantic-idle-scheduler-mode
                                    global-semanticdb-minor-mode
                                    global-semantic-mru-bookmark-mode
                                    global-cedet-m3-minor-mode))

[-- Attachment #2: Type: text/html, Size: 962 bytes --]

Re: [cedet-semantic] scrolling while editing RFC

[Eli Zaretskii]

> Date: Mon, 8 Jul 2013 14:48:22 -0400
> From: Barry OReilly <gundaetiapo@gmail.com>
> Cc: eric@siege-engine.com, cedet-semantic@lists.sourceforge.net,
> 	Dave Milter <davemilter@gmail.com>, emacs-devel@gnu.org
> 
> Thanks for the tips, I will try it out. Since I can't reproduce it at will,
> I'm not sure when I'll secure the redisplay traces.

You could wait for it to happen, and activate trace-redisplay then.  I
presume that once it starts happening, it doesn't stop too soon.