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 <rahguzar@zohomail.eu> writes:
> Hi Peter,
>
> Peter Mao <peter.mao@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