2016-09-12 14:06 GMT+02:00 Arash Esbati <arash.esbati...@gmail.com>:
> Hi Mosè,
> Mosè Giordano <m...@gnu.org> writes:
>> 2016-09-09 17:09 GMT+02:00 Arash Esbati <arash.esbati...@gmail.com>:
>>>>> I also have a question: How can I figure out which engine/binary is
>>>>> ultimaltely used when compiling a document? I would like to address the
>>>> The relevant variables should be `TeX-engine', `TeX-PDF-mode',
>>>> `TeX-PDF-from-DVI', `TeX-DVI-via-PDFTeX'.
>>> Thank you, `TeX-engine', `TeX-PDF-mode' do the job, I think.
>> I don't think they suffice: if `TeX-PDF-from-DVI' function (remember
>> to use the function in place of the variable) returns non nil, the
>> engine used is tex, not pdftex. The converse happens with
>> `TeX-DVI-via-PDFTeX' non-nil.
> Thanks for your advice. I went through `TeX-expand-list-builtin' and I
> hope this time I have it right. Please find attached the current diff.
> I've also patched graphics.el in order to ask for package options when
> loaded. The macros in graphicx.el are guraded to do the right thing
> when loaded through graphics.el (it should be the way around, but moving
> everything into graphics.el is not an option). WDYT?
I agree that it should be the other way around (graphicx.sty requires
graphics.sty), but why you say this is not an option? Maybe not now
if there is no one willing to undertake this task, but in the future?
> If ok for you,
Only a question: why do you remove eps from the list of extensions
allowed with pdflatex? It's true that it isn't natively supported,
but epstopdf is allowed to run in restricted shell escape since TeX
Live 2011 and I often use EPS images when I compile with pdflatex.
Other than above comments, the patch looks overall good, thank you!
auctex-devel mailing list