unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: dalanicolai <dalanicolai@gmail.com>
Cc: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: [PATCH] add epub support to doc-view
Date: Tue, 11 Jan 2022 09:39:26 -0500	[thread overview]
Message-ID: <jwvfspu1h87.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CACJP=3k_jQVv0xJ8EM-joOgdqMitkbQ_qz6RY6PdLsFQ2Pa=kA@mail.gmail.com> (dalanicolai@gmail.com's message of "Tue, 11 Jan 2022 10:59:31 +0100")

> 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




  parent reply	other threads:[~2022-01-11 14:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  2:20 [PATCH] add epub support to doc-view dalanicolai
2022-01-11  2:32 ` Po Lu
2022-01-11  9:34   ` dalanicolai
2022-01-11  9:50     ` Tassilo Horn
2022-01-11 10:04       ` dalanicolai
2022-01-11 10:08         ` dalanicolai
2022-01-11 10:15         ` Robert Pluim
2022-01-11  9:59     ` Robert Pluim
2022-01-11 10:09       ` dalanicolai
2022-01-11  2:48 ` Stefan Monnier
2022-01-11  3:30   ` Stefan Kangas
2022-01-11 10:01     ` dalanicolai
2022-01-11 10:16       ` Robert Pluim
2022-01-13  9:14         ` dalanicolai
2022-01-11  9:59   ` dalanicolai
2022-01-11 10:13     ` dalanicolai
2022-01-11 14:39     ` Stefan Monnier [this message]
2022-01-13  9:25       ` dalanicolai
2022-01-14 16:15         ` dalanicolai
2022-01-14 20:02           ` dalanicolai
2022-01-26 20:28             ` dalanicolai
2022-01-27 16:05               ` Lars Ingebrigtsen
2022-01-27 21:09                 ` Iñigo Serna
2022-01-28 13:47                   ` Lars Ingebrigtsen
2022-01-28 19:51                     ` Iñigo Serna
2022-01-29 17:07                 ` dalanicolai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvfspu1h87.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dalanicolai@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).