Hi All,
I'm working on an all new version of the Latex and View command. See my earlier message for you you can switch to this branch of the svn repository if you'd like to beta test. I'm hoping to commit a major new version today. I've attached a screenshot of the configuration window.
Whats missing? Is the wording on the options for opening the viewer clear?
Here is another big question I've been thinking about. Since all of these new configuration settings will be stored along with the standard TextMate prefereces in a preferences file, how much backward compatibility should this new version try to maintain?
The current Latex and View command has grown organically over the life of TextMate and there are lots of environment variables that have been added over time, some that are semi-redundant even.
TM_LATEX_PROGRAM TM_LATEX_COMPILER TM_LATEX_VIEWER TM_LATEX_ERRLVL TM_LATEX_OPTIONS
All of the above can/will be replaced with the new interface, and I think we should make a break and do away with these.
TM_LATEX_MASTER This one is more interesting. We currently have two ways to specify a master/root file. Using this variable, or using the TexShop %!TEX directive embedded directly in the file. The TexShop way seems clearly superior to me since it allows for more flexibility than a single environment variable per directory or project. So my proposal is that the environment variable goes away.
TEX_PSTRICKS Since we can automatically detect when we should use latex instead of pdflatex this is redundant and should go away.
As I mentioned above, TexShop allows authors to embed directives right in their source file that specify a master file, there are others as well. I propose that we use that same set of directives and allow the following in-file settings to take precedence over the preferences set in the preference dialog box:
TS-options -- command line options passed to the latex engine TS-program -- the typesetting engine to use just for this file encoding -- how the file is encoded, I don't really know what to do with this one. Anybody?
I've looked at the TexShop documentation and I think this is it, are there other %!TEX directives I'm missing?
Thanks,
Brad
It's wonderful that you're doing this! Having a configuration dialog is a great idea. Also, it means there is one less thing for me to feel guilty about not doing. :-)
It seems a little odd to have -interaction=nonstopmode -file-line-error being configurable, given that the output parser will fail without them. How is the user supposed to know that these options are required, without knowing the inner workings of the bundle? What's wrong with just adding them automatically, as now?
I am hoping that these settings will be stored in such a way that Latex Watch can easily find them. (Also, I'd be delighted if Watch were integrated into the main LaTeX bundle. I can see no particular reason for it not to be, and people seem to find it useful.)
I agree that supporting the existing environment variables is not an essential feature. The current situation is such a mess, it's probably a good idea to ditch it and start again.
Robin
Le lundi 23 juillet 2007 à 18:35 +0100, Robin Houston a écrit :
It's wonderful that you're doing this! Having a configuration dialog is a great idea. Also, it means there is one less thing for me to feel guilty about not doing. :-)
It seems a little odd to have -interaction=nonstopmode -file-line-error being configurable, given that the output parser will fail without them. How is the user supposed to know that these options are required, without knowing the inner workings of the bundle? What's wrong with just adding them automatically, as now?
Hello:)
Don't forget --shell-escape is very(more) useful for some users. So it's very interesting to can put them in a box !
Perhaps, it's useful to can restore the defaults like in TexShop
Thanks for your very useful tools !
Greetings Alain
On 7/23/07, Alain Matthes alain.matthes@mac.com wrote:
Don't forget --shell-escape is very(more) useful for some users. So it's very interesting to can put them in a box !
Oh, I think it's a great idea to have a box to which you can add options!
I was suggesting that the script should run something to the effect of
"$TEX_COMPILER" -interaction=nonstopmode -file-line-error $TEX_OPTIONS "$SOURCE_FILE"
You could even override these by specifying -no-file-line-error or some other -interaction switch in the TEX_OPTIONS, if you had some special reason to, but the output parsing would work by default without any elaborate explanations needed.
Robin
Robin,
I tried to move the Latex Watch command into the branch today. But I'm not having much luck when I try to use it.
When I first try to watch a file I it compiles and displays just fine. But, if I make any changes the view does not update. I get the following error in the log:
entering extended mode This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode true Use of uninitialized value in system at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 690.
More importantly, I think there are two issues to think about:
1. It feels like there must be a ton of duplicated effort between the typeset and view command as implemented in texMate.py and friends and what you have done. texMate.py is pretty modular, and may be able to do much of what latex_watch.pl does.
2. I don't understand the limitation about not being able to watch files that have the \begin document in an included header file. If there is some previous discussion on this maybe you could point me to the email. If not could you give me a quick overview of the problem.
Thanks,
Brad
On 7/23/07, Robin Houston robin.houston@gmail.com wrote:
It's wonderful that you're doing this! Having a configuration dialog is a great idea. Also, it means there is one less thing for me to feel guilty about not doing. :-)
It seems a little odd to have -interaction=nonstopmode -file-line-error being configurable, given that the output parser will fail without them. How is the user supposed to know that these options are required, without knowing the inner workings of the bundle? What's wrong with just adding them automatically, as now?
I am hoping that these settings will be stored in such a way that Latex Watch can easily find them. (Also, I'd be delighted if Watch were integrated into the main LaTeX bundle. I can see no particular reason for it not to be, and people seem to find it useful.)
I agree that supporting the existing environment variables is not an essential feature. The current situation is such a mess, it's probably a good idea to ditch it and start again.
Robin
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 31/07/07, Brad Miller bmiller@luther.edu wrote:
But, if I make any changes the view does not update. I get the following error in the log:
Use of uninitialized value in system at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 690.
What version of Watch did you use? In the current version (2.5), line 690 is a comment!
- It feels like there must be a ton of duplicated effort between the
typeset and view command as implemented in texMate.py and friends and what you have done. texMate.py is pretty modular, and may be able to do much of what latex_watch.pl does.
It may well be that some logic is duplicated, and can be factored out. I suspect there may be less than you think. Have you looked at the Watch code? Most of it is fairly specific to the monitor-and-update model used by Watch.
- I don't understand the limitation about not being able to watch files
that have the \begin document in an included header file.
Watch needs to be able to distinguish the preamble from the document body. The preamble is extracted and used to compile a custom format file (TeX memory dump) which is used to compile the body. This format is regenerated only when the preamble is changed. If the preamble is spread across multiple files, it is more complicated to keep track of. There are any number of ways that this could be improved to some extent: since I do not know a perfect solution, I thought I would address such cases as they arise. To date, no one has shown me a "real world" document that suffers from this problem.
(Incidentally, I did find a cunning solution to *half* the problem: see the contents of the Support/tex/generic directory in the bundle.)
Robin
On 7/31/07, Robin Houston robin.houston@gmail.com wrote:
On 31/07/07, Brad Miller bmiller@luther.edu wrote:
But, if I make any changes the view does not update. I get the
following
error in the log:
Use of uninitialized value in system at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 690.
What version of Watch did you use? In the current version (2.5), line 690 is a comment!
OK, I was using version 2.4 I'll grab the latest after lunch and try it.
- It feels like there must be a ton of duplicated effort between the
typeset and view command as implemented in texMate.py and friends and
what
you have done. texMate.py is pretty modular, and may be able to do much
of
what latex_watch.pl does.
It may well be that some logic is duplicated, and can be factored out. I suspect there may be less than you think. Have you looked at the Watch code? Most of it is fairly specific to the monitor-and-update model used by Watch.
I was thinking mostly of the compiling and finding options and getting preferences...
- I don't understand the limitation about not being able to watch files
that have the \begin document in an included header file.
Watch needs to be able to distinguish the preamble from the document body. The preamble is extracted and used to compile a custom format file (TeX memory dump) which is used to compile the body. This format is regenerated only when the preamble is changed. If the preamble is spread across multiple files, it is more complicated to keep track of. There are any number of ways that this could be improved to some extent: since I do not know a perfect solution, I thought I would address such cases as they arise. To date, no one has shown me a "real world" document that suffers from this problem.
(Incidentally, I did find a cunning solution to *half* the problem: see the contents of the Support/tex/generic directory in the bundle.)
Here's my real world example for you then :-) I'm working on a book with another author. We have a master file for when we want to typeset the entire book, but most of the time we just want to typeset individual chapters. So we have a header and a footer file that we put into each chapter, as well as the master file for the whole book. These headers and footers are smart enough to detect when we are typesetting the whole book, or just a chapter.
It works much better than both of us having to comment out various parts of the entire master file when we are working on a single chapter.
I think this approach was talked about on the TM list a while (over a year) back.
How hard would it be to solve this problem the brute force way and just provide a flag that would have the script recompile the whole document. I wonder whether precompiling the preamble really saves you that much time for most documents on modern hardware??
Brad
Robin
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 31/07/07, Brad Miller bmiller@luther.edu wrote:
Here's my real world example for you then :-)
Interesting situation; thanks!
There is a kludgey workaround: write something like
\include{myheader} % <- includes \begin{document}
The string '\begin{document}' is taken to indicate the end of the preamble, even if it's in a comment. That's intentional, precisely to permit this kind of workaround; though perhaps it would be prettier to also recognise a special comment "% End of preamble" or some such.
How hard would it be to solve this problem the brute force way and just provide a flag that would have the script recompile the whole document.
I'm inclined to say, if that's what you want then Watch is not the tool you are looking for, since you won't get any benefit from it. If you do want to use Watch in such a situation, it is not hard to implement a workaround as described above.
Of course ideally I'd like it to work without the need for a special workaround. When luaTeX is properly released (in about a year, if it goes to plan), I think I could implement a reasonable solution using that.
I wonder whether precompiling the preamble really saves you that much time for most documents on modern hardware??
All I know is that it saves an awful lot of time for my documents on my hardware. I wouldn't have bothered to write it otherwise! Do you not find that it does for yours? I know my Powerbook G4 is getting on a bit.
Robin
On 7/31/07, Robin Houston robin.houston@gmail.com wrote:
On 31/07/07, Brad Miller bmiller@luther.edu wrote:
Here's my real world example for you then :-)
Interesting situation; thanks!
There is a kludgey workaround: write something like
\include{myheader} % <- includes \begin{document}
Cool, that gets me past that hurdle.
The string '\begin{document}' is taken to indicate the end of the
preamble, even if it's in a comment. That's intentional, precisely to permit this kind of workaround; though perhaps it would be prettier to also recognise a special comment "% End of preamble" or some such.
How hard would it be to solve this problem the brute force way and just provide a flag that would have the script recompile the whole document.
I'm inclined to say, if that's what you want then Watch is not the tool you are looking for, since you won't get any benefit from it. If you do want to use Watch in such a situation, it is not hard to implement a workaround as described above.
You may be right. I've been perfectly happy using the latex & view command and having Skim set up to auto update when the file changes. Plus, I have to do bibtexing and makeindexing a fair amount in my documents.
But, since I dove into it to add it to the branch and move it into the Latex bundle, you are the victim of some of my random thoughts along the way. :-)
Of course ideally I'd like it to work without the need for a special
workaround. When luaTeX is properly released (in about a year, if it goes to plan), I think I could implement a reasonable solution using that.
luaTeX interesting... Would you use lua to replace some of the stuff that is written in TeX today?
I wonder whether precompiling the preamble really saves you that much time for
most documents on modern hardware??
All I know is that it saves an awful lot of time for my documents on my hardware. I wouldn't have bothered to write it otherwise! Do you not find that it does for yours? I know my Powerbook G4 is getting on a bit.
On my mbp It takes about .75 seconds to typeset a 30 page chapter, which includes about 25 different packages. I don't even find that time noticeable given that I have to switch focus to a new window.
Brad
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 7/31/07, Robin Houston robin.houston@gmail.com wrote:
On 31/07/07, Brad Miller bmiller@luther.edu wrote:
But, if I make any changes the view does not update. I get the
following
error in the log:
Use of uninitialized value in system at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 690.
What version of Watch did you use? In the current version (2.5), line 690 is a comment!
I installed version 2.5 now I'm getting the same error, but on line 713 system(@)_);
Here's info from the console: Latex Watch INFO: Closing progress bar window (15940) Use of uninitialized value in join or string at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 681. Latex Watch INFO: Executing check_open -q mlu.tex Use of uninitialized value in system at /Users/bmiller/Library/Application Support/TextMate/Bundles/Latex.tmbundle/Support/bin/latex_watch.pl line 713. Latex Watch INFO: Viewer appears to have been closed. Exiting. Latex Watch INFO: Cleaning up
Brad
Brad,
If you can send me the LaTeX bundle that you're doing this with, I'll look into it and fix the problem. (I have updated from CVS, and the Watch code does not seem to be included there.)
Robin
I just committed all the code I moved over from the Latex Watch bundle. If you svn up you should get it all.
Brad
On 7/31/07, Robin Houston robin.houston@gmail.com wrote:
Brad,
If you can send me the LaTeX bundle that you're doing this with, I'll look into it and fix the problem. (I have updated from CVS, and the Watch code does not seem to be included there.)
Robin
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
TM_LATEX_MASTER This one is more interesting. We currently have two ways to specify a master/root file. Using this variable, or using the TexShop %!TEX directive embedded directly in the file. The TexShop way seems clearly superior to me since it allows for more flexibility than a single environment variable per directory or project. So my proposal is that the environment variable goes away.
I agree that the %!TEX directive allows for more flexibility, but I think that there are several reasons that support for the environment variable should not be dropped. First, at least in my case, it has always sufficed to use the TM_LATEX_MASTER environment variable, and I'm not sure that I can imagine a realistic situation in which one would need more than one master file per project. Is there a common scenario in which one uses several "master" files for the same project?
Second, if I'm not mistaken, the %!TEX directive must be placed manually in every new file that is created in a project; however, if one uses the TM_LATEX_MASTER environment variable, a new file in a project is automatically assumed to have the same master file as the environment variable.
Basically, I think that one master file per project makes sense because, well, it's a "master" file!
The dialog looks great, but I do have some questions. How does one add a viewer to the list of choices for default viewer? Also, I'm slightly confused about how the options for opening the viewer interact with the error reporting. Do these settings have any effect on the error reporting window? If they don't, how will one set what is currently known as TM_LATEX_ERRLVL? I think that these settings (error reporting and viewer settings) should be independent. Personally, I would like to have the viewer always open, but I would also like to always be shown the errors/warnings that result from a compile.
Thanks,
Mike Miller
Thanks for the comments, see below...
On Jul 23, 2007, at 2:54 PM, Brad Miller wrote:
Thanks for the comments, see below...
-- Brad Miller Assistant Professor, Computer Science Luther College
On 7/23/07, Mike Miller mightymiller19@gmail.com wrote: > TM_LATEX_MASTER
This one is more interesting. We currently have two ways to specify a master/root file. Using this variable, or using the TexShop %!TEX directive embedded directly in the file. The TexShop way seems clearly superior to me since it allows for more flexibility than a single environment variable per directory or project. So my proposal is that the environment variable goes away.
I agree that the %!TEX directive allows for more flexibility, but I think that there are several reasons that support for the environment variable should not be dropped. First, at least in my case, it has always sufficed to use the TM_LATEX_MASTER environment variable, and I'm not sure that I can imagine a realistic situation in which one would need more than one master file per project. Is there a common scenario in which one uses several "master" files for the same project?
Here's my scenario in the book I am writing. I have a master file for the entire book which includes the master files for each chapter. But each chapter is broken down into individual files for big sections. This scenario breaks the TM_LATEX_MASTER approach.
I assume then that one of the two levels of inclusion is with \input commands instead of \include commands, since \include commands can't be nested ASAIK?
I have to say that I would like to keep TM_LATEX_MASTER and the %!TEX directives, and have the directives take precedence if present. I suppose this adds complexity which we are trying to avoid, but for me the fact that the directives need to be included in each file is quite bothersome, especially when moving files around to new projects or whatnot. But I can also see its usefulness in your case.
I suppose the way I would organize your situation is that I would have a separate tmproj file for each chapter, when I want to work with a particular project.
So, I assume that your are solving the problem of having each chapter compile on its own and at the same time be includable in the master document in the standard not very pretty method using conditionals?
Second, if I'm not mistaken, the %!TEX directive must be placed manually in every new file that is created in a project; however, if one uses the TM_LATEX_MASTER environment variable, a new file in a project is automatically assumed to have the same master file as the environment variable.
This could be solved by modifying the standard latex templates, or adding another command to the latex bundle that allows you to quickly add a directive line to a new file.
As well as edit an existing directive line. Would that command try to automatically figure out the name of the master file, or would the user be expected to type it in?
Basically, I think that one master file per project makes sense because, well, it's a "master" file!
The dialog looks great, but I do have some questions. How does one add a viewer to the list of choices for default viewer?
You would have to modify the nib.
Also, I'm slightly confused about how the options for opening the viewer interact with the error reporting. Do these settings have any effect on the error reporting window? If they don't, how will one set what is currently known as TM_LATEX_ERRLVL? I think that these settings (error reporting and viewer settings) should be independent. Personally, I would like to have the viewer always open, but I would also like to always be shown the errors/warnings that result from a compile.
The three radio boxes were meant to take the place of the TM_LATEX_ERRLVL environment variable. Always open viewer means that the script will always try to open the viewer regardless of errors or warnings. Open viewer unless errrors means that the script will open the viewer unless there are errors Open manually means you will always have to press the button to open the viewer
If you use an external viewer then the textmate window with any errors or warnings will always stay around. Just like it does now, or am I missing something? I may be slightly confused on this based on how I've had my ERRLVL set...
Do we need a separate checkbox that says keep textmate html window open?
No, but we do need to make sure that it does stay open based on which of the three preferences the user has selected ;)
Brad
Thanks,
Mike Miller
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 7/23/07, Charilaos Skiadas skiadas@hanover.edu wrote:
On Jul 23, 2007, at 2:54 PM, Brad Miller wrote:
Thanks for the comments, see below...
-- Brad Miller Assistant Professor, Computer Science Luther College
On 7/23/07, Mike Miller mightymiller19@gmail.com wrote: > TM_LATEX_MASTER
This one is more interesting. We currently have two ways to specify a master/root file. Using this variable, or using the TexShop %!TEX directive embedded directly in the file. The TexShop way seems clearly superior to me since it allows for more flexibility than a single environment variable per directory or project. So my proposal is that the environment variable goes away.
I agree that the %!TEX directive allows for more flexibility, but I think that there are several reasons that support for the environment variable should not be dropped. First, at least in my case, it has always sufficed to use the TM_LATEX_MASTER environment variable, and I'm not sure that I can imagine a realistic situation in which one would need more than one master file per project. Is there a common scenario in which one uses several "master" files for the same project?
Here's my scenario in the book I am writing. I have a master file for the entire book which includes the master files for each chapter. But each chapter is broken down into individual files for big sections. This scenario breaks the TM_LATEX_MASTER approach.
I assume then that one of the two levels of inclusion is with \input commands instead of \include commands, since \include commands can't be nested ASAIK?
I have to say that I would like to keep TM_LATEX_MASTER and the %!TEX directives, and have the directives take precedence if present. I suppose this adds complexity which we are trying to avoid, but for me the fact that the directives need to be included in each file is quite bothersome, especially when moving files around to new projects or whatnot. But I can also see its usefulness in your case.
I suppose the way I would organize your situation is that I would have a separate tmproj file for each chapter, when I want to work with a particular project.
So, I assume that your are solving the problem of having each chapter compile on its own and at the same time be includable in the master document in the standard not very pretty method using conditionals?
Second, if I'm not mistaken, the %!TEX directive must be placed
manually in every new file that is created in a project; however, if one uses the TM_LATEX_MASTER environment variable, a new file in a project is automatically assumed to have the same master file as the environment variable.
Yes.
I don't think that keeping TM_LATEX_MASTER around is that much extra work. In fact I had already coded up using it before I started work on this configuration interface. I have plenty of old papers and projects that will break if I remove TM_LATEX_MASTER so I don't know how strongly I feel about getting rid of this one variable.
But, the question is how should we let the user set their root file? Through the standard way of setting a project environment variable? Tell them to edit .textmate_init, or provide another dialog that either writes to .textmate_init or adds a line to the current file? It seems a bit confusing to give the user two totally different ways of configuring something as simple as the master file.
This could be solved by modifying the standard latex templates, or adding another command to the latex bundle that allows you to quickly add a directive line to a new file.
As well as edit an existing directive line. Would that command try to automatically figure out the name of the master file, or would the user be expected to type it in?
I suppose it could look for other .tex files in the same directory and if they have a root directive already in place that could be suggested.
Do we need a separate checkbox that says keep textmate html window open?
No, but we do need to make sure that it does stay open based on which of the three preferences the user has selected ;)
So, maybe we should be more clear in the preferences window:
Provide a checkbox that says: Automatically start external Viewer
And the radio boxes should say:
Close output if no errors Close output if no errors or warnings Do not close output window
That may be a more direct way of saying what the ERRLVL variable is really getting at. What do you think??
Brad
Brad
Thanks,
Mike Miller
Haris Skiadas Department of Mathematics and Computer Science Hanover College
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Hi Everyone,
Lots of progress on the new LaTeX and View command over the last two days. If you can, please check out the branch and give it a try. It should work for you right out of the box with no additional configuration.
Both TM_LATEX_MASTER, and the TexShop directives are supported.
I think the configuration interface now handles the old ERRLVL stuff in a much more end user friendly way.
Thanks,
Brad
On 7/23/07, Brad Miller bmiller@luther.edu wrote:
On 7/23/07, Charilaos Skiadas skiadas@hanover.edu wrote:
On Jul 23, 2007, at 2:54 PM, Brad Miller wrote:
Thanks for the comments, see below...
-- Brad Miller Assistant Professor, Computer Science Luther College
On 7/23/07, Mike Miller < mightymiller19@gmail.com> wrote: > TM_LATEX_MASTER
This one is more interesting. We currently have two ways to specify a master/root file. Using this variable, or using the TexShop %!TEX directive embedded directly in the file. The TexShop way seems clearly superior to me since it allows for more flexibility than a single environment variable per directory or project. So my proposal is that the environment variable goes away.
I agree that the %!TEX directive allows for more flexibility, but I think that there are several reasons that support for the environment variable should not be dropped. First, at least in my case, it has always sufficed to use the TM_LATEX_MASTER environment variable, and I'm not sure that I can imagine a realistic situation in which one would need more than one master file per project. Is there a common scenario in which one uses several "master" files for the same project?
Here's my scenario in the book I am writing. I have a master file for the entire book which includes the master files for each chapter. But each chapter is broken down into individual files for big sections. This scenario breaks the TM_LATEX_MASTER approach.
I assume then that one of the two levels of inclusion is with \input commands instead of \include commands, since \include commands can't be nested ASAIK?
I have to say that I would like to keep TM_LATEX_MASTER and the %!TEX directives, and have the directives take precedence if present. I suppose this adds complexity which we are trying to avoid, but for me the fact that the directives need to be included in each file is quite bothersome, especially when moving files around to new projects or whatnot. But I can also see its usefulness in your case.
I suppose the way I would organize your situation is that I would have a separate tmproj file for each chapter, when I want to work with a particular project.
So, I assume that your are solving the problem of having each chapter compile on its own and at the same time be includable in the master document in the standard not very pretty method using conditionals?
Second, if I'm not mistaken, the %!TEX directive must be placed
manually in every new file that is created in a project; however, if one uses the TM_LATEX_MASTER environment variable, a new file in a project is automatically assumed to have the same master file as the environment variable.
Yes.
I don't think that keeping TM_LATEX_MASTER around is that much extra work. In fact I had already coded up using it before I started work on this configuration interface. I have plenty of old papers and projects that will break if I remove TM_LATEX_MASTER so I don't know how strongly I feel about getting rid of this one variable.
But, the question is how should we let the user set their root file? Through the standard way of setting a project environment variable? Tell them to edit .textmate_init, or provide another dialog that either writes to .textmate_init or adds a line to the current file? It seems a bit confusing to give the user two totally different ways of configuring something as simple as the master file.
This could be solved by modifying the standard latex templates, or adding another command to the latex bundle that allows you to quickly add a directive line to a new file.
As well as edit an existing directive line. Would that command try to automatically figure out the name of the master file, or would the user be expected to type it in?
I suppose it could look for other .tex files in the same directory and if they have a root directive already in place that could be suggested.
Do we need a separate checkbox that says keep textmate html window open?
No, but we do need to make sure that it does stay open based on which of the three preferences the user has selected ;)
So, maybe we should be more clear in the preferences window:
Provide a checkbox that says: Automatically start external Viewer
And the radio boxes should say:
Close output if no errors Close output if no errors or warnings Do not close output window
That may be a more direct way of saying what the ERRLVL variable is really getting at. What do you think??
Brad
Brad
Thanks,
Mike Miller
Haris Skiadas Department of Mathematics and Computer Science Hanover College
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-- Brad Miller Assistant Professor, Computer Science Luther College
On Jul 24, 2007, at 11:51, Brad Miller wrote:
Hi Everyone,
Lots of progress on the new LaTeX and View command over the last two days. If you can, please check out the branch and give it a try. It should work for you right out of the box with no additional configuration.
Your message yesterday said "See my earlier message for you you can switch to this branch of the svn repository if you'd like to beta test."...but I can't find that message.
What's the best way to accomplish the switch if I'm currently using an svn checkout in /Library/Application Support/TextMate? I suppose I could go poke around the repository if I have to.
thanks, Adam
I think it might be a reference to the following bundle dev post: http://comox.textdrive.com/pipermail/textmate-dev/2007-July/009600.html
Following the directions found there I was able to switch to the typeset_and_view branch.
Oh, and thanks Adam for all the great work on BibDesk the ISI stuff is brilliant! Peter
On 7/24/07, Adam R. Maxwell amaxwell@mac.com wrote:
On Jul 24, 2007, at 11:51, Brad Miller wrote:
Hi Everyone,
Lots of progress on the new LaTeX and View command over the last two days. If you can, please check out the branch and give it a try. It should work for you right out of the box with no additional configuration.
Your message yesterday said "See my earlier message for you you can switch to this branch of the svn repository if you'd like to beta test."...but I can't find that message.
What's the best way to accomplish the switch if I'm currently using an svn checkout in /Library/Application Support/TextMate? I suppose I could go poke around the repository if I have to.
thanks, Adam
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Jul 24, 2007, at 21:48, Peter Cowan wrote:
I think it might be a reference to the following bundle dev post: <http://comox.textdrive.com/pipermail/textmate-dev/2007-July/009600.html
Following the directions found there I was able to switch to the typeset_and_view branch.
Ah, many thanks; I didn't think to look at the archives of that list.
Oh, and thanks Adam for all the great work on BibDesk the ISI stuff is brilliant!
You're welcome; glad you like it! Hopefully that version will be released soon.
regards, Adam
On 24 Jul 2007, at 19:51, Brad Miller wrote:
Lots of progress on the new LaTeX and View command over the last two days. If you can, please check out the branch and give it a try. It should work for you right out of the box with no additional configuration.
I must have done something wrong. I navigated to the Latex.tmbundle directory and used the command svn switch http://macromates.com/svn/Bundles/branches/typeset_and_view/ Latex.tmbundle. But when I typeset I get the following error:
Traceback (most recent call last): File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/texMate.py", line 215, in ? tmPrefs = tmprefs.Preferences() File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/tmprefs.py", line 18, in __init__ self.prefs.update(self.readTMPrefs()) File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/tmprefs.py", line 39, in readTMPrefs plDict = plistlib.readPlist(pl) AttributeError: 'module' object has no attribute 'readPlist'
Best, Mark
Mark,
I just svn up'd and get the same error. Reverting to revision 7790, gives me a functioning command.
I'm not a SVN expert so I don't know if this is the preferred way to revert, but in the Latex.tmbundle I typed:
svn up -r 7790
Peter
On 7/24/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
On 24 Jul 2007, at 19:51, Brad Miller wrote:
Lots of progress on the new LaTeX and View command over the last two days. If you can, please check out the branch and give it a try. It should work for you right out of the box with no additional configuration.
I must have done something wrong. I navigated to the Latex.tmbundle directory and used the command svn switch http://macromates.com/svn/Bundles/branches/typeset_and_view/ Latex.tmbundle. But when I typeset I get the following error:
Traceback (most recent call last): File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/texMate.py", line 215, in ? tmPrefs = tmprefs.Preferences() File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/tmprefs.py", line 18, in __init__ self.prefs.update(self.readTMPrefs()) File "/Library/Application Support/TextMate/Bundles/Latex.tmbundle/ Support/bin/tmprefs.py", line 39, in readTMPrefs plDict = plistlib.readPlist(pl) AttributeError: 'module' object has no attribute 'readPlist'
Best, Mark
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Sorry about that problem. It is because the version of python apple ships is two revisions out of date. I've been developing with 2.5 and apple ships 2.3. Unfortunately plistlib.readPlist is not a supported function in the older release. I'll have to see what I can do to work around that.
Brad
On 25/07/07, Brad Miller bmiller@luther.edu wrote:
Unfortunately plistlib.readPlist is not a supported function in the older release. I'll have to see what I can do to work around that.
popen("defaults read ...") ?
Robin
It turns out the easiest solution is to drop the new version of plistlib.pyfrom python2.5 into the bundle. It works just fine with 2.3.
I have verified this by forcing texMate to run using python2.3 so if you were having trouble before, please update to the latest.
Thanks,
Brad
On 25. Jul 2007, at 14:02, Robin Houston wrote:
On 25/07/07, Brad Miller bmiller@luther.edu wrote:
Unfortunately plistlib.readPlist is not a supported function in the older release. I'll have to see what I can do to work around that.
popen("defaults read ...") ?
Just for the records; the result of ‘defaults’ looks like old-style plist, but it is not. As of such, the result is only useful as a human-readable format.
In case you are not on the svn list or you missed my earlier message, I have fixed the problem with plistlib.readPlist, so the latest version should work for everyone.
In addition I've made some improvements to handling the output from commands when you start them up by pressing the button at the bottom of the screen. The output should scroll more smoothly now.
Please let me know if you find anything missing, or broken. I'd also like to hear of any other ideas you may have to make the LaTeX and View command better. As long as I'm in the mess, now is the time.
Thanks!
Brad
On 7/25/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 25. Jul 2007, at 14:02, Robin Houston wrote:
On 25/07/07, Brad Miller bmiller@luther.edu wrote:
Unfortunately plistlib.readPlist is not a supported function in the older release. I'll have to see what I can do to work around that.
popen("defaults read ...") ?
Just for the records; the result of 'defaults' looks like old-style plist, but it is not. As of such, the result is only useful as a human-readable format.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Jul 25 2007, at 13:34, Brad Miller wrote:
It turns out the easiest solution is to drop the new version of plistlib.pyfrom python2.5 into the bundle. It works just fine with 2.3.
I have verified this by forcing texMate to run using python2.3 so if you were having trouble before, please update to the latest.
Thanks Brad, I tried again, but starting TextMate, I get the following message:
The Latex bundle located in /Library/Application Support/TextMate/Bundles could not be loaded and will be skipped. The contained info.plist appears to be corrupt or missing.
Best, Mark
Mark,
Is it possible that when you svn up'd you had a conflict in your info.plistfile due to some local modification you made?
I'm not sure what else it could be as the plist I have, which is the one I checked in looks clean.
Brad
On 7/26/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
On Jul 25 2007, at 13:34, Brad Miller wrote:
It turns out the easiest solution is to drop the new version of
plistlib.pyfrom
python2.5 into the bundle. It works just fine with 2.3.
I have verified this by forcing texMate to run using python2.3 so
if you
were having trouble before, please update to the latest.
Thanks Brad, I tried again, but starting TextMate, I get the following message:
The "Latex" bundle located in /Library/Application Support/TextMate/Bundles could not be loaded and will be skipped. The contained info.plist appears to be corrupt or missing.
Best, Mark
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Has anyone tried the new typeset command with xelatex? When I try to typeset a xelatex document, the command can't find the source. My documents would typeset fine with the old command, but I am getting the following error with the new one:
This is XeTeXk, Version 3.141592-2.2-0.996 (Web2C 7.5.6)
%&-line parsing enabled. entering extended mode
! I can't find file `'"selectionproblem.tex"''.
<*> '"selectionproblem.tex"' Please type another input file name
! Emergency stop.
<*> '"selectionproblem.tex"' No pages of output.
Best, Mark
Mark,
I just checked in a fix. I was putting one too many levels of shell quoting around the file name (to protect against spaces in the file name) the other version of tex seemed to accomodate the quotes just fine but not xelatex. Thanks. I don't use xelatex at all so I'm glad you are giving it a workout.
Brad
On 7/26/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
Has anyone tried the new typeset command with xelatex? When I try to typeset a xelatex document, the command can't find the source. My documents would typeset fine with the old command, but I am getting the following error with the new one:
This is XeTeXk, Version 3.141592-2.2-0.996 (Web2C 7.5.6)
%&-line parsing enabled. entering extended mode
! I can't find file `'"selectionproblem.tex"''.
<*> '"selectionproblem.tex"'
Please type another input file name
! Emergency stop.
<*> '"selectionproblem.tex"'
No pages of output.
Best, Mark
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
I just checked in a fix. I was putting one too many levels of shell quoting around the file name (to protect against spaces in the file name) the other version of tex seemed to accomodate the quotes just fine but not xelatex. Thanks. I don't use xelatex at all so I'm glad you are giving it a workout.
Thanks Brad, that worked. But I am experiencing some more xelatex wierdness. The command seems to choke when the url package is loaded (see below for the error) with the result that I get garbage in the first page. This didn't happen with the old command; it doesn't happen when the document is typeset from the command line; and documents with the url package typeset fine when using pdflatex.
While I am at it, I have a UI question/comment. It seems odd that the option to configure the typesetting engine appears when you typeset a document. This makes switching engines cumbersome since you have to typeset the document with the wrong engine before configuring. (Though, of course, using the appropriate %!TEX directives solves this problem, but still...)
Here is the relevant part of the log:
/usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:42: Undefined cont rol sequence. l.42 \Url@OTnonTT % more for any but typewriter /usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:43: Too many }'s. l.43 }
/usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:51: Undefined cont rol sequence. l.51 \do 젴hchar184 }} /usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:51: Undefined cont rol sequence. l.51 \do젴hchar 184 }}
Latex Error: /usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:51 Missing \begin{document}.
See the LaTeX manual or LaTeX Companion for explanation. Type H for immediate help. ...
l.51 \do젴hchar1 84 }} /usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:51: Too many }'s. l.51 \do젴hchar184 } } /usr/local/texlive/2007/texmf-dist/tex/latex/ltxmisc/url.sty:51: Too many }'s. l.51 \do젴hchar184 }}
On 7/26/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
I just checked in a fix. I was putting one too many levels of shell
quoting around the file name (to protect against spaces in the file name) the other version of tex seemed to accomodate the quotes just fine but not xelatex. Thanks. I don't use xelatex at all so I'm glad you are giving it a workout.
Thanks Brad, that worked. But I am experiencing some more xelatex wierdness. The command seems to choke when the url package is loaded (see below for the error) with the result that I get garbage in the first page. This didn't happen with the old command; it doesn't happen when the document is typeset from the command line; and documents with the url package typeset fine when using pdflatex.
Mark,
I added a print statement and switching from pdflatex to xelatex only changes the first part of the command, so I'm not sure what is going on.
Command is: pdflatex -interaction=nonstopmode -file-line-error-style " mlu.tex" Command is: xelatex -interaction=nonstopmode -file-line-error-style " mlu.tex"
I do know that if I add \usepackage{url} I get the same errors you do about a missing \begin document. This makes me think that there is something in the environment or some other option that should be used to make the url package behave with xelatex.
Do you have some TM_LATEX_OPTIONS set in the project where you use xelatex?
I've looked through the old script and I cannot see where there is any special handling of xelatex other than automatically figuring out when it should be used.
Maybe someone who added support for xelatex in the older version has an idea??
While I am at it, I have a UI question/comment. It seems odd that the
option to configure the typesetting engine appears when you typeset a document. This makes switching engines cumbersome since you have to typeset the document with the wrong engine before configuring. (Though, of course, using the appropriate %!TEX directives solves this problem, but still...)
There is a bundle command called Configure which also brings up the configuration window, so you don't have to typeset a document to find the Configure button, you can choose it from the bundle menu before you typeset.
Brad
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Thanks Brad for checking this out.
I do know that if I add \usepackage{url} I get the same errors you do about a missing \begin document. This makes me think that there is something in the environment or some other option that should be used to make the url package behave with xelatex.
This can't be the case. As I mentioned, it successfully loads without errors when typeset from the command line.
Do you have some TM_LATEX_OPTIONS set in the project where you use xelatex?
No.
There is a bundle command called Configure which also brings up the configuration window, so you don't have to typeset a document to find the Configure button, you can choose it from the bundle menu before you typeset.
Sorry, I missed that.
Best, Mark
Mark, As I said, it must be something with the environment. Sure enough the one thing I didn't remove from the old script and move into python was the export TEXINPUTS command. But this command was failing silently in the shell script because the $TEX variable was no longer set.
I've fixed the code and checked it in. I'm no longer seeing any errors with url in my test.
Thanks again for being the xelatex tester.
Brad
On 7/26/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
Thanks Brad for checking this out.
I do know that if I add \usepackage{url} I get the same errors you do about a missing \begin document. This makes me think that there is something in the environment or some other option that should be used to make the url package behave with xelatex.
This can't be the case. As I mentioned, it successfully loads without errors when typeset from the command line.
Do you have some TM_LATEX_OPTIONS set in the project where you use xelatex?
No.
There is a bundle command called Configure which also brings up the configuration window, so you don't have to typeset a document to find the Configure button, you can choose it from the bundle menu before you typeset.
Sorry, I missed that.
Best, Mark
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Is TM_LATEX_MASTER required to be an absolute path? I switched to the typeset_and_view branch on my work system and had an error in texMate.py determine_ts_directory(), since I have TM_LATEX_MASTER="master.tex" set in the project. Removing that variable and switching to master.tex allowed me to compile with cmd-r as usual. Sorry I don't have the exact error message; the project is on my work system.
thanks, Adam
Adam, This should be fixed in the new version I just checked in.
Brad
On 8/1/07, Adam R. Maxwell amaxwell@mac.com wrote:
Is TM_LATEX_MASTER required to be an absolute path? I switched to the typeset_and_view branch on my work system and had an error in texMate.py determine_ts_directory(), since I have TM_LATEX_MASTER="master.tex" set in the project. Removing that variable and switching to master.tex allowed me to compile with cmd-r as usual. Sorry I don't have the exact error message; the project is on my work system.
thanks, Adam
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Dear Brad,
While your working on the LaTeX bundle, I thought I would mention a couple of things.
First, the "Keep log window open" checkbox is working imperfectly for me. I checked it and it kept the window open. But unchecking it, the window still remains open.
It is less than optimal that the engine and options work independently of one another. If you have options set for pdflatex and the switch your engine to xetex, say, these options persist even though they may not be valid options for the selected engine.
It would also be nice if the user could save options and select among them instead of having to retype them.
Just some thoughts.
Thanks for all the hard work. I am definitely enjoying the new Typeset and Preview command.
All the best, Mark
On 8/2/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
Dear Brad,
While your working on the LaTeX bundle, I thought I would mention a couple of things.
First, the "Keep log window open" checkbox is working imperfectly for me. I checked it and it kept the window open. But unchecking it, the window still remains open.
The keep log window open attempts to replicate most of the functionality of the old ERRLVL environment variable with less confusion. So if you have the box unchecked the window will still stay open if you have errors or warnings. Unless you are using the built-in viewer in which case having the box unchecked will cause the pdf to replace the log in the window even if you have warnings.
Yeah... Writing that out reminds me exactly how confusing that is. I wish there were a simple yet obvious way to cover all those bases.
So, if you still think the window is misbehaving, let me know exactly what was going on and I'll try to replicate.
It is less than optimal that the engine and options work
independently of one another. If you have options set for pdflatex and the switch your engine to xetex, say, these options persist even though they may not be valid options for the selected engine.
It would also be nice if the user could save options and select among them instead of having to retype them.
Thanks,
I'll have to give some thought to how I could do that. My skill with interface builder is pretty minimal so if you or anyone have suggestions as to how that kind of interface would work, let me know.
I'd also like to figure out a way for a user to add their own custom command. See the emails with Flo for her situation.
Just some thoughts.
Thanks for all the hard work. I am definitely enjoying the new Typeset and Preview command.
All the best, Mark
Glad you are enjoying it, and thanks for the ideas.
Brad
______________________________________________________________________
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
The keep log window open attempts to replicate most of the functionality of the old ERRLVL environment variable with less confusion. So if you have the box unchecked the window will still stay open if you have errors or warnings. Unless you are using the built-in viewer in which case having the box unchecked will cause the pdf to replace the log in the window even if you have warnings.
Yeah... Writing that out reminds me exactly how confusing that is. I wish there were a simple yet obvious way to cover all those bases.
OK, works as designed, if not as expected.
On 25/07/07, Allan Odgaard throw-away-1@macromates.com wrote:
Just for the records; the result of 'defaults' looks like old-style plist, but it is not. As of such, the result is only useful as a human-readable format.
Surely it is at least useful for reading single preference items, e.g.
last_root=$(defaults read -app TextMate NSNavLastRootDirectory)
in a shell script?
Robin
On 26. Jul 2007, at 16:39, Robin Houston wrote:
On 25/07/07, Allan Odgaard throw-away-1@macromates.com wrote:
Just for the records; the result of 'defaults' looks like old-style plist, but it is not. As of such, the result is only useful as a human-readable format.
Surely it is at least useful for reading single preference items, e.g.
last_root=$(defaults read -app TextMate NSNavLastRootDirectory)
in a shell script?
Not really, e.g.:
% defaults write test foo bar && defaults read test foo bar
% defaults write test foo 'æble' && defaults read test foo \346ble
% defaults write test foo '⌘' && defaults read test foo \u2318
So in addition to the coercing of integers, booleans, and dates into strings, there is the problem that non-ASCII strings are returned using escape codes for the non-ASCII part.
On Jul 23 2007, at 18:14, Brad Miller wrote:
As I mentioned above, TexShop allows authors to embed directives right in their source file that specify a master file, there are others as well. I propose that we use that same set of directives and allow the following in-file settings to take precedence over the preferences set in the preference dialog box:
TS-options -- command line options passed to the latex engine
TS-options seems not to be working correctly. The following causes typeset and preview to hang:
%!TEX TS-program = xelatex %!TEX TS-options = -output-driver="xdvipdfmx -q -E"
But if I just use the same TS-program directive and specify:
output-driver="xdvipdfmx -q -E"
in the options of the LaTeX Bundle Preferences, then everything works fine.
Best, Mark
Fixed.
The regular expression was just too restrictive for the right hand side of the TS-options = xxxx equation.
Thanks again Mark.
Brad
On 7/27/07, Mark Eli Kalderon eli@markelikalderon.com wrote:
On Jul 23 2007, at 18:14, Brad Miller wrote:
As I mentioned above, TexShop allows authors to embed directives right in their source file that specify a master file, there are others as well. I propose that we use that same set of directives and allow the following in-file settings to take precedence over the preferences set in the preference dialog box:
TS-options -- command line options passed to the latex engine
TS-options seems not to be working correctly. The following causes typeset and preview to hang:
%!TEX TS-program = xelatex %!TEX TS-options = -output-driver="xdvipdfmx -q -E"But if I just use the same TS-program directive and specify:
output-driver="xdvipdfmx -q -E"in the options of the LaTeX Bundle Preferences, then everything works fine.
Best, Mark
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-
Adam R. Maxwell -
Alain Matthes -
Allan Odgaard -
Brad Miller -
Charilaos Skiadas -
Mark Eli Kalderon -
Mike Miller -
Peter Cowan -
Robin Houston