[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] add epub support to doc-view

From: Stefan Monnier
Subject: Re: [PATCH] add epub support to doc-view
Date: Tue, 11 Jan 2022 09:39:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]