[TxMt] Announcing LaTeX Watch 2.0, with PDF support

[Robin Houston]

On 4/5/07, Charilaos Skiadas <skiadas at hanover.edu> wrote:
>
> It's basically the viewer we are suggesting at the moment (once I
> update the help file that is). It has the advantages of TeXniscope
> along with some other ones of its own, and works on Intels much better.


Ah, okay. Unfortunately it doesn't work brilliantly with Watch, because its
AppleEvents support really sucks, so there's no way to tell if the user has
closed the document. Also, it insists on updating the PDF file whenever it's
changed, and there's no way to externally signal it to update instead, so
presumably it will sometimes detect the change while the PDF is
half-generated, and break.

> I thought it might be useful to have the option of using a
> > different previewer for watching than for 'Typeset & View', but
> > perhaps no one would ever want to do that. At the very least, it
> > could be an undocumented option, and we could say that the
> > recommended way to change the viewer is to set TM_LATEX_VIEWER.
>
> Yeah we could have it as an undocumented option.


I've removed it. If there turns out to be a need for it, it's trivial to put
it back.

> Because of the non-standard name, I didn't realise this was an
> > official configuration option. If it is, I agree that the name
> > should be changed!
>
> Well it's semi-official ;)  Supporting pstricks and the dvi->ps->pdf
> route is relatively new and hasn't settled in much. So TEX_PSTRICKS
> was really at that point just an internal variable defined within the
> LaTeX&View command, not supposed to be settable by the user really.


That's what I'd imagined.

I wonder if it is necessary at all. Is that really different than
> setting the TS-program to "latex" instead of "pdflatex"?


No, not at all. But it's nice to have a global option, so you don't have to
edit every single source file when you want the same for all them. But it
should be possible to override the global default in the file.

I guess this is the question: Should the user have to specify
> anything else other than whether they want pdflatex or latex->dvi->ps-
> >pdf ? Ideally one variable should do the trick, and even that
> should only be needed rarely.


I heartily agree with the sentiment that it should be as simple as possible.
(And maybe one day someone will write a nice graphical interface for the
configuration.)

But it's not *quite* this simple. People do use xelatex, for example.
Perhaps we should just use the same names as TeXShop does (so people don't
have to learn two different ways of specifying the same thing), and have a
variable TS_LATEX_PROGRAM that can be (at least in principle – I guess not
all the options will be supported immediately) set to the same things that
you can put after TS-program =.

So, for example, TX_LATEX_PROGRAM=latex would force the DVI route unless
it's over-ridden by an explicit %!TEX line in the document, etc.

What do you think of this idea?

Hm, that's a bug in the way we do these things currently I would say,
> the %!TEX directive should probably be taking precedence. Basically
> the whole setting sniffing method in the Typeset&View command needs a
> good cleanup. It has been patched so many times that it is somewhat
> inefficient/buggy atm.


I don't mind fixing up this script to support the mechanism I suggested
above, if you agree it's a good idea.

Yes I meant to make the binary available somewhere, and then link to
> it from the documentation. I was thinking of someone's webpage. I can
> put it on my blog somewhere, or you can host in on your homepage.


I don't really have a proper homepage at the moment. Well, I have my
university one, but that will go away fairly soon, and I have a small amount
of webspace from my ISP (where I put the 2.0 bundle), but I don't know how
long I'll keep the same ISP.

If you have room for it on your blog, perhaps that would be the best place.

> GPL.
>
> Then I am not sure we can actually include it in a bundle that ships
> with TM, or include it at all for that matter. Can we?


I hope so! CocoaDialog is GPL, and that's included.

I'm pretty sure it's okay. The GPL specifically excludes "mere aggregation"
in its viral clause.

Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20070405/62d0236f/attachment.html>