bug#23809: 24.5; Positive argument to 'posn-at-point' throws erros as being negative

[Eli Zaretskii <eliz@gnu.org>]

> From: Lluís Vilanova <vilanova@ac.upc.edu>
> Cc: 23809@debbugs.gnu.org
> Date: Tue, 21 Jun 2016 15:17:46 +0200
> 
> > The question is how that -14 coordinate came into existence.  If you
> > can step with a debugger into Fpos_visible_in_window_p, and see what's
> > going on there, that would be helpful.  (I cannot try that myself, as
> > my systems don't support pdf-view-mode.)
> 
> I have zero knowledge on Emacs' source code, but here's the little information I
> could gather:
> 
>   Fposn_at_point(...)
>     Fvisible_in_window_p(...) -> (824 . -98)
>       pos_visible_p(...) ->
>         line 1713 : *x = it2.current_x;
>         value            824
>         line 1714 : *y = it2.current_y + it2.max_ascent - it2.ascent;
>         value            -98             533              533
>     Fposn_at_x_y(824, -98, window, nil)
> 
> After reading [1], it sounds to me that pdf-tools (and doc-view) let you scroll
> the buffer, but never move point. That could be a reason to get a negative
> position AFAIU.
> 
> Tell me if you want something more specific, since the problem is pretty easy to
> reproduce. But remember I have zero knowledge on emacs' sources, some I'm pretty
> blind here.

Thanks, the above is already a lot of valuable info.

I have a couple of follow up questions:

  . Can you show the entire value returned by Fpos_visible_in_window_p
    when its call from Fposn_at_point returns, when this problem is
    reproduced?  If you load the file .gdbinit that is located in the
    Emacs src directory, then displaying the return value is simple:
    type "pp tem" at the GDB prompt, after Fpos_visible_in_window_p
    returns.

  . You say "pdf-tools (and doc-view) let you scroll the buffer, but
    never move point" -- can you point me to code in pdf-tools that
    does this?

Thanks.