> > don't hesitate to send me email along the way for help > Thanks, will do that (i.e. not the hesitate :) > I'm not sure what you mean by "obtains a value t" but if you mean that > (car winprops) is t, then usually it happens when the buffer is not yet > displayed (`find-file` creates the buffer, enables the mode, and then > displays the buffer, so there's a time-window during which the buffer > is not displayed). Thanks, I've read about that value being 't' in one of the docstring. However, the motivation for it is better explained in your answer here I think (If I remember well, I will 'check' it when I see it again) Not sure I understand. My comment is about hardcoding "mutool" vs > obeying `doc-view-pdfdraw-program` which can refer to "mutool", > "mudraw", "pdfdraw", or any other file name (e.g. in case it's not in > $PATH). AFAIK they all end up running the same code. > Ah okay, I see now. I took note of the feedback, however I will first focus on the continuous scroll now, and then later come back to this patch. Thanks again, you all! On Tue, 11 Jan 2022 at 15:39, Stefan Monnier wrote: > > This I copied from pdf-tools. However, I am planning to enter this > > documentation myself, while I am implementing real continuous > > scroll. I have got that working in pdf-tools already, but I had to > > disable all kinds of minor modes there. So I thought let's start with > > a simpler task of implementing it in doc-view, however, the same > > difficulty, that I encountered also in pdf-tools is that somehow > > `bookroll-mode-winprops-alist` (which is exactly the equivalent/copy > > of `bookroll-mode-winprops-alist`) obtains a value `t`. I think I've > > spent some hours already investigating where it obtains it (somehow > > I fixed it after debugging for pdf-tools for few hours, but clearly > > I do not understand how, and have to repeat the same things again, > > well I guess it is a good exercise. Anyway, in the end I hope to add > > some useful documentation to prevent other hackers from 'wasting' > > their time :) Anyway, if I can keep it like this for now, that would > > be great, as the TODO really jumps out font lock wise, and also I can > > search for it. > > I've wrestled with this function a fair bit. It was quite some years > ago, so it would take time for me to remember all the details, don't > hesitate to send me email along the way for help. > > I'm not sure what you mean by "obtains a value t" but if you mean that > (car winprops) is t, then usually it happens when the buffer is not yet > displayed (`find-file` creates the buffer, enables the mode, and then > displays the buffer, so there's a time-window during which the buffer > is not displayed). > > >> @@ -738,7 +740,7 @@ doc-view-kill-proc > >> > (interactive) > >> > (while (consp doc-view--current-converter-processes) > >> > (ignore-errors ;; Some entries might not be processes, and maybe > >> > - ;; some are dead already? > >> > + ;; some are dead already? > >> > (kill-process (pop doc-view--current-converter-processes)))) > >> > (when doc-view--current-timer > >> > (cancel-timer doc-view--current-timer) > >> > >> Here the auto-indentation gets it wrong, sadly. > > > > You mean because it aligns with the line below so that it looks like > > it belongs to that one? > > Yes, that indentation suggests that the second comment is separate from > the first rather than being its continuation. > > I think we can get out cake and eat it by replacing the ";;" with ";" here. > > > Because otherwise, I think it does not look bad. > > It's not the end of the world, no. > > >> + ((memq type '(postscript ps eps pdf epub)) > >> > + (if-let (command (and (memq type '(pdf epub)) > (executable-find > >> "mutool"))) > >> > + command > >> > + (unless (eq type 'epub) > >> > + (and doc-view-ghostscript-program > >> > + (executable-find doc-view-ghostscript-program))))) > >> > ((eq type 'odf) > >> > (and doc-view-odf->pdf-converter-program > >> > (executable-find doc-view-odf->pdf-converter-program) > >> > >> Hmm... for PDF files, this changes the previous behavior where we > >> checked for the presence of `doc-view-pdfdraw-program` rather than > >> "mutool". > >> Was there a strong reason to hardcode "mutool" here > >> > > > > Ah yes, I was aware of that, but indeed I did that consciously. I have > > very good experiences with (py)mupdf (I have implemented an > > alternative pdf-tools server using it, and indeed it is much faster > > than the epdfinfo server, well at least the mupdf vs poppler parts. > > Not sure I understand. My comment is about hardcoding "mutool" vs > obeying `doc-view-pdfdraw-program` which can refer to "mutool", > "mudraw", "pdfdraw", or any other file name (e.g. in case it's not in > $PATH). AFAIK they all end up running the same code. > > > Stefan > >