Created attachment 1068490 [details] basicart.sty package--the one that triggers AucTeX to use pdfamstex. Description of problem: emacs-auctex tries to determine which of several tex/latex binaries should be used to process the file being edited. For some files, it will attempt to invoke pdfamstex, but there doesn't seem to be any TeXLive package in Fedora that provides that binary. Version-Release number of selected component (if applicable): texlive-2014-8.20140525_r34255.fc22.x86_64 How reproducible: Always for certain LaTeX source files. Steps to Reproduce: 1. Install emacs and emacs-auctex RPMs 2. Create a LaTeX document using the article \documentstyle and including the attached article.sty package with \usepackage{basicart} 3. Edit the file with emacs and attempt to compile with C-c C-c Actual results: One of the pop-down menus in Emacs is for AmS-TeX. The C-c C-c command shows in the status window "Command: (default AmSTeX)". The default command fails with the following error in the output buffer: Running `AmSTeX' on `hack' with ``pdfamstex -interaction=nonstopmode "\input" hack.tex'' /bin/sh: pdfamstex: command not found Expected results: The compile works. Additional info: I'm not sure if this is an AucTeX bug or a TeXLive bug. I don't know how AucTeX decides which binary to invoke or what about the attached style file triggers the use of pdfamstex instead of pdflatex, but it seems as though if pdfamstex exists, it should be available in TeXLive. Fedora's TeXLive does include amstex, but not pdfamstex. But plain latex or amstex won't work with certain kinds of included graphics--one needs to go directly to PDF in those cases. The latest AucTeX seems to default to the direct-to-pdf commands, such as pdflatex.
Created attachment 1068491 [details] Example LaTeX file that uses package basicart.sty and illustrates the failure when edited with emacs and AucTeX.
I think you want to use pdftex (not pdfamstex). I'm not sure where the pdfamstex reference is coming from. It seems like this probably should be fixed by emacs-auctex updating to the latest code in git.
Can you switch this bug to emacs-auctex, or should I refile?
Never mind, I see I can make the change.
Can't reproduce that. That basicart.sty seems broken. When I try to compile this: \documentclass{article} \usepackage{basicart} \begin{document} hello \end{document} I get: ERROR: Undefined control sequence. --- TeX said --- <argument> \footnotesize \@LeftHead l.6 \end{document} --- HELP --- TeX encountered an unknown command name. You probably misspelled the name. If this message occurs when a LaTeX command is being processed, the command is probably in the wrong place---for example, the error can be produced by an \item command that's not inside a list-making environment. The error can also be caused by a missing \documentclass command. Upload a minimal example demonstrating the problem so I can reproduce please.
Sidenote: when you reassign the component in bugzilla, you also need to re-assign the person who the bug is assigned to. I am sure BZ used to do that automatically, but perhaps I misremember.
Created attachment 1069234 [details] basicart.sty with most stuff removed. Deleted most of the complexity of basicart.sty.
Created attachment 1069237 [details] Simlified LaTeX file using basicart1.sty that illustrates the issue. Commented out the line with the email address that appears to cause your issue. Also deleted all package references other than basicart1.sty. This should build with pdflatex. When you open with emacs and auctex, the indicated incorrect behavior is exhibited.
(In reply to Jonathan Underwood from comment #6) > Sidenote: when you reassign the component in bugzilla, you also need to > re-assign the person who the bug is assigned to. I am sure BZ used to do > that automatically, but perhaps I misremember. Sorry, this is the first time I've tried to reassign a bug. Not sure how I would know how to find the right person.
OK, have confirmed this issue still arises in AucTeX 11.88.6 from ELPA, so it's really an upstream issue. I've sent a bug report upstream, although the arcane and ridiculous bug tracker they use means it won't appear in the auctex-bug archive until it's next refreshed. Closing as an upstream issue.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21401