Re: Output to directory patch

[Ikumi Keita]

Hi Al,

>>>>> Al Haji-Ali <abdo.haji.ali@gmail.com> writes:
> I want to take this chance to discuss TeX-region to gather feedback
> and suggestions.

> I opted to not have the output files of TeX-region in `TeX-output-dir`
> for one main reason. I believe that the "_region_.tex" file itself
> (being an AUCTeX output file that is usually cleaned) should be in a
> sub-directory for the same reasons that AUCTeX style files (and
> eventually tex output files) can be in a sub-directory. The output
> files can then reside in that same sub-directory. For this reason, the
> solution I think should be implemented is to have the variable
> `TeX-region` accept a path, for example, "region/_region_" or even
> "build/_region_". The output files from TeX-region would then reside
> in the same directory, for example, "region/_region_.pdf" or
> "build/_region_.pdf". In my experience, making this change is not
> difficult (in fact I tested it lightly with my patch and it seems to
> work without any further changes. Only tex-preview'ing a region needs
> one small change to make it work). Alternatively, I could also instead
> put both _region_.tex and its output files in TeX-output-dir directly
> when that variable is non-nil.

> What do you think?

The latter looks more natural to me. I was formerly worrying that it
would fail when _region_.tex contains input/include/includegraphics in
it, but test-driving with simple example seems to tell that it wouldn't
as long as the latex command is called with the current directory being
where the master file is.

My other concern is that error parsing of AUCTeX. Please test whether it
is affected or not when _region_.tex is placed in sub directory.

> Regarding your proposed solution of splicing the output-directory in
> the correct location in the `name` variable which contains the path of
> the tex file. While certainly doable, it seems to me that keeping all
> path splicing in one place (i.e., in the case of my implementation, in
> TeX-master-file) is the more consistent solution (it is also more
> consistent with the region treatment I mentioned above).

That's what I suggested before :-)

> Hence, here's how I propose this complication can be fixed instead:

> 1. Update documentation/implementation of TeX-command to enforce
> file-fn being TeX-region-file or TeX-master-file. I can then inspect
> `TeX-current-process-region-p` to find the source function so I can
> call it with the correct extension.

I prefer this simplest way. It would be enough only to clarify its doc
string, I think it would be too much to modify it to bail out when
file-fn is neither TeX-region-file nor TeX-master-file.

> 2c. Make them accept an optional 'file-fn' in addition to `name` which
> is the function that was called to get `name` (just like TeX-command
> accepts both `name` and `file-fn`).

I think you misunderstand the meaning of `name' argument of TeX-command.
It isn't the file name to be processed but rather "LaTeX", "View",
"Print" etc.

By the way, I'll stay where I have poor internet connectivity for a week
from tomorrow. So my next reply would be after that. Sorry for repeated
interruption.

Regards,
Ikumi Keita