bug#42824: 26.3; Feature request: implement 'smooth scroll' in djvu.el package

[dalanicolai <dalanicolai@gmail.com>]

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

> I have been looking into doc-view.  It offers more complete and more
> consistent support for scrolling and I am trying to find out how
> this can possibly be ported to djvu.el

I do not fully understand what you are referring to with 'more complete and
consistent,
but  the functions I've sent in the request are really small, only 5 lines,
and I think
they implement the essence of doc-view its scrolling feature. It was really
meant as just
a small extra convenient addition to solve the small, but inconvenient
problem, as explained
in the original request.

> On the other hand, I am also wondering whether it could make sense
> to add a backend for djvu files to doc-view.  Probably this depends
> on what users want to do.  I started djvu.el for editing djvu
> documents which is often very different from viewing such files.

Well, in the djvu2.el <https://github.com/dalanicolai/djvu2.el> package, I
use the info in the annotation buffer to draw the annotations
(using imagemagick its convert command). Of course as just a plain reader
(without annotation
features), doc-view is already a fine reader for djvu documents.

> > While I am here anyway, I have also created some code to implement
> > `djvu-occur` similar to `pdf-occur` (but synchronous instead of
> > async) which works fine for most djvu documents.
>
> Did I see correctly that this code relies on `convert' from
> imagemagic for updating the images?

I am not sure if you are referring to the pdf-occur functionality because
that does not rely
on convert. Convert is used for drawing the annotations, the code for
djvu-occur is in the
djvu-occur section (idicated with ;;; Djvu occur). The djvu-occur function
uses the tablist
mode from pdf-tools to provide occur functionality similar to that of
pdf-tools.

Anyway, the message about djvu2.el was just as a comment that maybe you are
interested to
hear of it, nothing more. The request was just to add the two scroll
functions (because I was not aware
that doc-view was already perfectly able to show djvu document with
"acceptable" scrolling functionality).

I understand that djvu.el was meant especially for editing. Also, I think
doc-view does a fine job when reading
djvu documents. I was just experimenting to see if I could, with not too
much effort, view my edits from djvu.el
within some Emacs reader. So this is what djvu2.el solves, but in a hacky
way. Also implementing occur, is not essential
but I really like it in pdf-tools, and it was quite easy and
straightforward to port to djvu.el (so I did that in djvu2.el).
But djvu2.el is just experimental, a short study to find out if the
required work is worth the effort...


On Fri, 6 Nov 2020 at 19:51, Roland Winkler <winkler@gnu.org> wrote:

> On Thu Oct 29 2020 dalanicolai wrote:
> > Well, it is just more or less the function
> > `doc-view-next-line-or-next-page` (i.e. `C-n`) slightly adapted to
> > djvu-mode, because djvu-mode works slightly differently.  It is
> > meant for `djvu-image-mode-only` but I have simply bound it in the
> > `djvu-read-mode-map` and it seems to handle things fine.  It is
> > just a small addition that slightly improves the scrolling
> > experience (i.e. it becomes like that in doc-view).
>
> Update:
>
> I have been looking into doc-view.  It offers more complete and more
> consistent support for scrolling and I am trying to find out how
> this can possibly be ported to djvu.el.
>
> On the other hand, I am also wondering whether it could make sense
> to add a backend for djvu files to doc-view.  Probably this depends
> on what users want to do.  I started djvu.el for editing djvu
> documents which is often very different from viewing such files.
>
> > While I am here anyway, I have also created some code to implement
> > `djvu-occur` similar to `pdf-occur` (but synchronous instead of
> > async) which works fine for most djvu documents.
>
> Did I see correctly that this code relies on `convert' from
> imagemagic for updating the images?
>
> I need some more time to understand better what the code is doing.
>

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