An update: I created a new branch named `upstream-pdf-roll` which is based on `vedang/pdf-tools` and made a draft pull request too,
https://github.com/vedang/pdf-tools/pull/224 So if you have been using this please try the `upstream-pdf-roll` branch and report back if something got broken, although since I was able to cherry-pick commits cleanly I feel it is unlikely (but I don't git so my feelings might be very off the mark) and cursory usage by me suggests that everything is fine. Rahguzar Rahguzar <rahgu...@zohomail.eu> writes: > Hi Peter, > > Peter Mao <peter....@gmail.com> writes: > >> Rahguzar -- are you going to be making pull-requests to the upstream >> repos? I notice that you are a fork of a fork of the "official" >> pdf-tools repo (vedang/pdf-tools), and your code has diverged >> significantly from vedang/pdf-tools (96 ahead/44 behind). Since >> vedang/pdf-tools is under active maintainership, I think the best >> course of action is to make a PR (or a series of PRs, as it looks like >> you've done a **lot** of work on this feature). > > The reason that it is a fork of a fork is that once upon a time I > was using a feature from that fork which has a pull-request waiting to > be merged into vedang/pdf-tools. When I switched to Daniel Nicolai's > fork, I just rebased on top of that which looking back now is > unfortunate. You can probably tell I am not too familiar with git and > also not a software developer by trade. I have made changes to quite > a few places in the pdf-tools repo but what you see at first glance > vastly overstates them. By my estimation the changes for this feature > come to about 700 lines and probably a majority of them were by Daniel > Nicolai. In fact, although I fixed issues I had with pdf-tools when > using continuous scroll, I think I made more extensive changes to > image-roll than to pdf-tools. > > For that reason I will like Daniel Nicolai to chime in about PR to > pdf-tools first and I opened an issue about changes to image-roll on his > repository. In any case the changes to pdf-tools are extensive but still > probably incomplete. Most likely there are features that break but I > haven't come across. As a result I think a pr to pdf-tools will take a > long time to review and merge. For a short term solution I think it > might be worthwhile to package the changes to pdf-tools as advices, this > will duplicate quite a lot of code but will allow people to test this > feature more easily with upstream pdf-tools. I don't have bandwidth to > take this on but if someone wants to try this, they are welcome. > > Rahguzar