GNU bug report logs - #37874
27.0.50; A recent commit broke doc-view (and pdf-tools)

Previous Next

Full log

Message #8 received at 37874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 37874 <at> debbugs.gnu.org, 37578 <at> debbugs.gnu.org, politza <at> hochschule-trier.de
Subject: Re: bug#37578: closed (Re: bug#37578: 26.3; image-mode does not
 display the bottom edge of a tall image)
Date: Wed, 23 Oct 2019 20:58:15 +0300

> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: ynyaaa <at> gmail.com,  37578 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 23 Oct 2019 18:07:53 +0200
> 
> > image-mode.el was scrolling images vertically in units of canonical
> > character height, so it couldn't handle the last portion of an image
> > smaller than the height of one character.
> >
> > This is now fixed on the master branch.
> 
> Your change 9c66b09950cf2db50eb6d818656a268ef750bfe6 broke doc-view.el
> and the pdf-tools package whose author already filed bug#37874 for the
> issue.
> 
> Could you have a look?  If the image functions stay returning pixel
> values that's ok but Andreas and I will need to adapt pdf-tools and
> doc-view.el accordingly.

Sorry, I didn't think some other package will use that function, it
looked like an internal subroutine.  I should have checked.

To answer your question: I see no reason to go back to character units
in this function.  We could either adapt the other packages to the
change, or add a new function that will work like the previous
image-next-line.  What would you prefer?  If the only problem is with
comparing against the value returned by window-vscroll, then perhaps
the former is easier and simpler?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.