bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#30063: 26.0.90; Silent fail with `rst-compile-pdf-preview'


From: Stefan Merten
Subject: bug#30063: 26.0.90; Silent fail with `rst-compile-pdf-preview'
Date: Thu, 03 Oct 2019 22:53:43 +0200

Hi all!

Sorry for not looking into this for so long. This whole part of
`rst.el' needs a couple of improvements. I did not write this code and
frankly did not care much about it - besides adding some FIXMEs.

4 days ago Lars Ingebrigtsen wrote:
> Simen Heggestøyl <simenheg@gmail.com> writes:
> 
>> * lisp/textmodes/rst.el (rst-compile-pdf-preview): Warn about missing
>> executables when attempting to compile and preview an RST file as PDF.
>> (Bug#30218)
> 
> [...]
> 
>> +    (unless (executable-find pdf-compile-program)
>> +      (error "Cannot find executable `%s'" pdf-compile-program))
>> +    (unless (executable-find rst-pdf-program)
>> +      (error "Cannot find executable `%s'" rst-pdf-program))
> 
> Others pointed out that it might be nice to report error messages back
> from the pdf commands, and that's true, but I think this patch makes
> sense, too, because it gives good, early feedback on a likely problem,
> so I think it should be applied.

Well, IMHO this patch would be less than optimal. There is already

      (defcustom rst-compile-toolsets ...)

There is an `executable-find' already for the default values. Although
it only takes an alternative if it doesn't find the first guess. This
is also less than optimal :-( .

`rst-pdf-program' on the other hand is not yet integrated in
`rst-compile-toolsets'. This is a necessary improvement.


A good solution IMHO would be to have a reasonable list of defaults
for (all) the executables in `rst-compile-toolsets', then check this
list of defaults for executability and then set the default
customization accordingly. If none of the defaults is found the
customization for the respective symbol should be set to nil and the
error should appear when the executable is to be used.

[...browsing through the code...]

Ok, a sensible solution would need quite an effort. So it's probably
best to apply this patch now and when at any point in the future I
come up with a more general solution it will do something equivalent
or rather something better.


                                                Grüße

                                                Stefan





reply via email to

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