I am running Version 1.0.2 (v20) of Skim, Version 1.5.7 (1455) of TextMate, Leopard (10.5.1). I could give you a file if you want, but all you need to do is have two distinct .tex files with the exact same name and in different directories on your computer. Have both of them open in TextMate. Compile one and it will show up in Skim. Compile the other and it will think that you're trying to update the first file that you compiled because they have the same name.
Keith
On Jan 9, 2008, at 5:26 PM, Keith Penrod wrote:
I am running Version 1.0.2 (v20) of Skim, Version 1.5.7 (1455) of TextMate, Leopard (10.5.1). I could give you a file if you want, but all you need to do is have two distinct .tex files with the exact same name and in different directories on your computer. Have both of them open in TextMate. Compile one and it will show up in Skim. Compile the other and it will think that you're trying to update the first file that you compiled because they have the same name.
Yes I did that, and it was not a problem. It showed me the second file just fine. That's why I wanted a sample file from you, thinking that perhaps there was some weird setting in the file that was affecting things. Though I can't possibly imagine what it might be.
Keith
Haris Skiadas Department of Mathematics and Computer Science Hanover College
Greetings all,
I can confirm the behaviour Keith described: for me it's evident when I
1. start in directory "x" and create a simple "article.tex" using the article template in TextMate 2. create a "deeper" directory in "x" and create another " article.tex" file within "x/deeper". Add a simple line of text to distinguish the two outputs. 3. open up directory "x" in TextMate
The processing works fine the first time (eg on "x/article.tex"), but on processing "x/deeper/article.tex" nothing changes in the previewer, and it's not brought to the front. Similarly a click on the button "View in ((name of preview app))" in the web output window produces no change (and no change of focus). I tried with both Skim and TeXShop as previewer.
I did have a poke around in the latex processing scripts, but am probably a bit out of my depth here. The one thing that looks a bit suspicious is that "refreshViewer(viewer,pdfFile)" in texMate.py seems to use the filename, rather than the path of the file to send the osascript to refresh the view. In "Skim" for example, the command reads (in essence):
tell application "Skim" to revert document "filename"
instead of something like
tell application "Skim" to revert (every document whose path is "/path/to/article.pdf")
(I'll contain my hatred of Applescript to this set of brackets...) Is that the command in your version Haris? If it is I'm surprised it could work with two identically named files unless the act of refreshing was somehow changing the order in which they were indexed. Anyway, I hope this might give someone else a key to fixing the issue. It's also possible that I'm misreading the chain of command(s).
Cheers, Paul (happy user of the latex system in TextMate for quite some time now!)
On Jan 9, 2008, at 10:09 PM, Paul McCann wrote:
Greetings all,
I can confirm the behaviour Keith described: for me it's evident when I
- start in directory "x" and create a simple "article.tex" using
the article template in TextMate 2. create a "deeper" directory in "x" and create another " article.tex" file within "x/deeper". Add a simple line of text to distinguish the two outputs. 3. open up directory "x" in TextMate
The processing works fine the first time (eg on "x/article.tex"), but on processing "x/deeper/article.tex" nothing changes in the previewer, and it's not brought to the front. Similarly a click on the button "View in ((name of preview app))" in the web output window produces no change (and no change of focus). I tried with both Skim and TeXShop as previewer.
I did have a poke around in the latex processing scripts, but am probably a bit out of my depth here. The one thing that looks a bit suspicious is that "refreshViewer(viewer,pdfFile)" in texMate.py seems to use the filename, rather than the path of the file to send the osascript to refresh the view. In "Skim" for example, the command reads (in essence):
tell application "Skim" to revert document "filename"
instead of something like
tell application "Skim" to revert (every document whose path is "/ path/to/article.pdf")
(I'll contain my hatred of Applescript to this set of brackets...) Is that the command in your version Haris?
Now I am really confused. I am looking at texMate.py, and I am not seeing neither a refreshViewer method, nor any mention of any applescript terms. In my version, /usr/bin/open is used, on line 111, in a method called run_viewer. In which lines of texMate.py exactly are the applescript calls supposed to be at?
If it is I'm surprised it could work with two identically named files unless the act of refreshing was somehow changing the order in which they were indexed. Anyway, I hope this might give someone else a key to fixing the issue. It's also possible that I'm misreading the chain of command(s).
Cheers, Paul (happy user of the latex system in TextMate for quite some time now!)
Haris Skiadas Department of Mathematics and Computer Science Hanover College
Hi again,
Now I am really confused. I am looking at texMate.py, and I am not seeing neither a refreshViewer method, nor any mention of any applescript terms. In my version, /usr/bin/open is used, on line 111, in a method called run_viewer. In which lines of texMate.py exactly are the applescript calls supposed to be at?
Ditto re the confusion: my texMate.py has "refreshViewer" defined on line 122 (and "run_viewer" on line 143). It's the texMate.py that's part of TextMate revision 1455. I've thrown a copy of the file texMate.py from
/Applications/TextMate.app/Contents/SharedSupport/Bundles/Latex.tmbundle/Support/bin
to
http://staff.maths.adelaide.edu.au/~pmccann/texMate.pyhttp://staff.maths.adelaide.edu.au/%7Epmccann/texMate.py
if you wish to try to decipher its provenance! There's an identical version of it contained within "texMate.app".
Cheers, Paul
On Jan 10, 2008, at 1:19 AM, Paul McCann wrote:
Hi again,
Now I am really confused. I am looking at texMate.py , and I am not seeing neither a refreshViewer method, nor any mention of any applescript terms. In my version, /usr/bin/open is used, on line 111, in a method called run_viewer. In which lines of texMate.py exactly are the applescript calls supposed to be at?
Ditto re the confusion: my texMate.py has "refreshViewer" defined on line 122 (and "run_viewer" on line 143). It's the texMate.py that's part of TextMate revision 1455. I've thrown a copy of the file texMate.py from
/Applications/TextMate.app/Contents/SharedSupport/Bundles/ Latex.tmbundle/Support/bin
to
http://staff.maths.adelaide.edu.au/~pmccann/texMate.py
if you wish to try to decipher its provenance! There's an identical version of it contained within "texMate.app".
Ok, the confusion is resolved. I've been working on a branch of the bundle, and had an old version of most files over there. switching to the main trunk gives me a file like yours.
So now I am running the latest from trunk, which I assume is where you are as well. I cannot reproduce the problem on most files, BUT I can reproduce it on files with spaces in the filepath. Which leads me to believe the problem is with quoting the filename somewhere. Does this perhaps match your experience? I.e. if for instance you have a folder Desktop/testing, and in it a file ab.tex, and then another folder Desktop/testing2 and a file ab.tex there, do you still see the problem?
Cheers, Paul
Haris Skiadas Department of Mathematics and Computer Science Hanover College
Hi again,
Does this perhaps match your experience? I.e. if for instance you have a
folder Desktop/testing, and in it a file ab.tex, and then another folder Desktop/testing2 and a file ab.tex there, do you still see the problem?
Yep, completely unchanged. (There were no spaces in my original test cases, but I checked "parallel" directories with no spaces in the complete paths just to be sure.)
Please pardon any repetition, but maybe it can help us get to the bottom of this: it looks to me like the root of the problem I'm seeing is in the "check_open" command, the output of which doesn't seem to depend on the location of the pdf file, but only its name. That is, consider the following sequence...
[the file "fred.pdf" from "~/Desktop/testing" is open in TeXShop; it's the only thing open in TeXShop]
% cd Desktop/testing % /Applications/TextMate.app/Contents/SharedSupport/Bundles/Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[That is, it correctly reports that the file is open. Now just change dir and see if it thinks the other pdf file is open too...]
% cd ../testing2 % /Applications/TextMate.app/Contents/SharedSupport/Bundles/Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[Here's where I think the problem lies: check_open is again reporting that " fred.pdf" is open, but I'm betting that the command above should be referring to the "fred.pdf" in "testing2", not that from "testing".]
In the command "runViewer" this causes control to pass to the refreshViewer command instead of invoking the "open -a ........." command that's required.
Does this make any sense?
Cheers, Paul
On Jan 10, 2008, at 9:36 AM, Paul McCann wrote:
Hi again,
Does this perhaps match your experience? I.e. if for instance you have a folder Desktop/testing, and in it a file ab.tex, and then another folder Desktop/testing2 and a file ab.tex there, do you still see the problem? Yep, completely unchanged. (There were no spaces in my original test cases, but I checked "parallel" directories with no spaces in the complete paths just to be sure.)
Please pardon any repetition, but maybe it can help us get to the bottom of this: it looks to me like the root of the problem I'm seeing is in the "check_open" command, the output of which doesn't seem to depend on the location of the pdf file, but only its name. That is, consider the following sequence...
[the file "fred.pdf" from "~/Desktop/testing" is open in TeXShop; it's the only thing open in TeXShop]
% cd Desktop/testing % /Applications/TextMate.app/Contents/SharedSupport/Bundles/ Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[That is, it correctly reports that the file is open. Now just change dir and see if it thinks the other pdf file is open too...]
% cd ../testing2 % /Applications/TextMate.app/Contents/SharedSupport/Bundles/ Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[Here's where I think the problem lies: check_open is again reporting that "fred.pdf" is open, but I'm betting that the command above should be referring to the "fred.pdf" in "testing2", not that from "testing".]
In the command "runViewer" this causes control to pass to the refreshViewer command instead of invoking the "open -a ........." command that's required.
Does this make any sense?
Yes, I am suspecting the same thing, but this doesn't explain why it works in my computer and not yours. check_open seems to have the same behaviour in my computer as you describe, yet things seem to work out. In fact, as far as I can tell, check_open will report the file as open regardless of which directory you currently are in, even if no such pdf file exists in the directory. I'm guessing it uses applescript to ask Skim about a file with that name, though I don't know for sure.
What I don't understand though is why pdfFile is not the full path to the file to begin with, and why check_open does not work with full pathnames. Since Brad is the mastermind behind this part of the bundle, I hope he'll find some time to chime in. It does look as though that part of the process might be somewhat fragile, anything involving Applescript is. Actually, I cannot even tell if check_open is applescript or not. Brad?
Cheers, Paul
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
What I don't understand though is why pdfFile is not the full path to the file to begin with, and why check_open does not work with full pathnames. Since Brad is the mastermind behind this part of the bundle, I hope he'll find some time to chime in.
Maybe I should answer this (as best I can), since I wrote check_open.
check_open doesn't use AppleScript as such, but it does use AppleEvents. The event is sends is built using AEBuildAppleEvent from the template
'----':obj{form:enum('name'),want:type('docu'),seld:TEXT(@),from:null()}
which has the same effect as AppleScript along the lines of
tell application "App" to get document "doc".
This form of request just uses the document name; essentially the name that's used as the window title. This can indeed cause false positives when you have two documents in different folders with the same name.
The original application of check_open was in the Watch document command, where it's used to terminate the watcher when the document window is closed. In this situation, the crucial thing is to avoid false NEGATIVES. However, in the situation under discussion here, it's more important to avoid false positives!
Does anyone know whether there's a reasonably reliable way to detect whether a document is open that does not suffer from this problem?
Robin
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
Does anyone know whether there's a reasonably reliable way to detect whether a document is open that does not suffer from this problem?
It looks as though it may indeed be possible to check the document by path, using the AppleEvent corresponding to script like:
tell application "Foo" to get documents whose path is "/path/to/docum.ent"
I'll see if I can improve check_open to allow this kind of check.
Robin
On Jan 10, 2008, at 12:51 PM, Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
Does anyone know whether there's a reasonably reliable way to detect whether a document is open that does not suffer from this problem?
It looks as though it may indeed be possible to check the document by path, using the AppleEvent corresponding to script like:
tell application "Foo" to get documents whose path is "/path/to/ docum.ent"
I'll see if I can improve check_open to allow this kind of check.
Please do submit the source code for check_open as well this time, along with any necessary compile instructions. So that future generations can figure out what this file is and how to change it.
I still don't quite see why this problem isn't showing up on my computer though... Anyway...
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Please do submit the source code for check_open as well this time, along with any necessary compile instructions. So that future generations can figure out what this file is and how to change it.
The source code is already there (Bundles/LaTeX.tmbundle/Support/src/check_open.c) and has compile instructions in a comment at the head of the file.
Robin
On Jan 10, 2008, at 1:00 PM, Robin Houston wrote:
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Please do submit the source code for check_open as well this time, along with any necessary compile instructions. So that future generations can figure out what this file is and how to change it.
The source code is already there (Bundles/LaTeX.tmbundle/Support/src/check_open.c) and has compile instructions in a comment at the head of the file.
Ah, sorry, my bad. I had expected it to be on the same directory ;)
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
Robin
Thanks Robin, for the quick fix. I just committed the patch. Paul, Keith, please update and let us know if the problem persists.
On Jan 10, 2008, at 1:32 PM, Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
Robin <check_open_3.patch>
Haris Skiadas Department of Mathematics and Computer Science Hanover College
Hi again,
Paul, Keith, please update and let us know if the problem persists.
No such luck at this end: I checked out release 8773, which looks like the patched version. But then replaying the check_open sequence from above while pointing at the new binary gives me:
[the file "fred.pdf" is in both "~/Desktop/testing" and "~/Desktop/testing2", but only the former version is open in TeXShop; and it's the only file open in TeXShop]
% cd Desktop/testing % /Library/Application\ Support/TextMate/Bundles/Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[That is, it correctly reports that the file is open. Now just change dir and see if it thinks the other pdf file is open too...]
% cd ../testing2 % /Library/Application\ Support/TextMate/Bundles/Latex.tmbundle/Support/bin/check_open TeXShop fred.pdf %
[the output from check_open isn't distinguishing between the two. Can anyone else verify that this behaviour is persisting?]
Cheers, Paul
On 10/01/2008, Paul McCann paul.mccann@adelaide.edu.au wrote:
[the output from check_open isn't distinguishing between the two. Can anyone else verify that this behaviour is persisting?]
You have to specify the absolute path to the document. It doesn't matter what the current working directory is. The new check_open does one of two things, depending on whether the supplied document name looks like an absolute path (i.e. starts with a slash). If it doesn't start with a slash, it does the old check, which won't distinguish the two files. If it does start with a slash, it checks the full path. So if you do
…check_open ~/Desktop/testing/fred.pdf …check_open ~/Desktop/testing2/fred.pdf
it ought to give the correct results.
I assumed that Charilaos had updated the Typeset and View command so that it passes the absolute path to check_open, but I don't see any changes to the command when I do an svn update. Sorry Charilaos, I should have made it clearer!
Robin
On Jan 10, 2008, at 5:13 PM, Robin Houston wrote:
On 10/01/2008, Paul McCann paul.mccann@adelaide.edu.au wrote:
[the output from check_open isn't distinguishing between the two. Can anyone else verify that this behaviour is persisting?]
You have to specify the absolute path to the document. It doesn't matter what the current working directory is. The new check_open does one of two things, depending on whether the supplied document name looks like an absolute path (i.e. starts with a slash). If it doesn't start with a slash, it does the old check, which won't distinguish the two files. If it does start with a slash, it checks the full path. So if you do
…check_open ~/Desktop/testing/fred.pdf …check_open ~/Desktop/testing2/fred.pdf
it ought to give the correct results.
I assumed that Charilaos had updated the Typeset and View command so that it passes the absolute path to check_open, but I don't see any changes to the command when I do an svn update. Sorry Charilaos, I should have made it clearer!
Heh, I'm not messing with that command, it's in Pytrhon ;). I'll dig through it when I have a moment, but if someone with more python-foo can fix that quicker, that would be great.
Partly, I wasn't sure if the pdfFile variable needed for some reason to only have the relative path to the file.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Heh, I'm not messing with that command, it's in Pytrhon ;). I'll dig through it when I have a moment, but if someone with more python-foo can fix that quicker, that would be great.
How about the attached patch then?
Robin
On Jan 11, 2008, at 6:49 AM, Robin Houston wrote:
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Heh, I'm not messing with that command, it's in Pytrhon ;). I'll dig through it when I have a moment, but if someone with more python-foo can fix that quicker, that would be great.
How about the attached patch then?
Since I cannot reproduce the problem here, I can't say if this works or not, but I submitted it and hope someone can tell us if it worked or not. I do keep getting those beeping sounds I told you about. Brad, can you think of anything in texMate.py that could cause the system to beep, but without showing anything in the console? It happens to me whenever the file is already open in the viewer, and I ask for a recompile. I do also get this error:
There was a problem reading the preferences file, continuing with defaults
But that shows up always, while the beeping is there only when the file is already open in say Skim.
Also, focus doesn't seem to switch to Skim.
Robin <texmate.patch>
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 11/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Also, focus doesn't seem to switch to Skim.
Is it supposed to? That would be easy to do: just add an "activate" to the AppleScript.
Robin
Haris wrote...
Since I cannot reproduce the problem here, I can't say if this works or not, but I submitted it and hope someone can tell us if it worked or not.
OK, someone reporting for duty: I can happily report that the updated Latex bundle no longer has the problem with identically named tex files in different directories. Nice work!
[Are you still there Keith? Can you confirm the death of the original symptoms after updating to the latest version of the bundle?]
Cheers, Paul
On Jan 11, 2008, at 6:12 AM, Charilaos Skiadas wrote:
On Jan 11, 2008, at 6:49 AM, Robin Houston wrote:
On 10/01/2008, Charilaos Skiadas cskiadas@gmail.com wrote:
Heh, I'm not messing with that command, it's in Pytrhon ;). I'll dig through it when I have a moment, but if someone with more python-foo can fix that quicker, that would be great.
How about the attached patch then?
Thanks Robin, I've got an extremely busy January so I don't have much time to think about the Latex bundle except maybe weekends. The patch works fine for me and looking at all the changes they seem OK. I'm going to roll back in a different patch that I got for Texniscope that I had not got around to committing before Haris applied yours.
Since I cannot reproduce the problem here, I can't say if this works or not, but I submitted it and hope someone can tell us if it worked or not. I do keep getting those beeping sounds I told you about. Brad, can you think of anything in texMate.py that could cause the system to beep, but without showing anything in the console? It happens to me whenever the file is already open in the viewer, and I ask for a recompile. I do also get this error:
Haris, I cannot reproduce the beeping, but I am on 10.5.1 and I'm assuming that you are still on 10.4.x since you have the error with the preferences. Can you check in the Latex bundle Support/bin/ newplistlib.py and make sure you are using at least r8620. Allan put in a fix that should avoid a strange bug with dates in the distant past or distant future. If you are using Leopard then the bundle uses the binary plist reader that ships with Leopards version of Python.
Yesterday sometime you asked about why the Latex bundle writes preferences to the com.macromates.textmate plist file. The answer is because thats how the example that Allan posted did it. That is also how the SQL bundle and others do it. Personally I don't know enough Objective C and/or interface builder foo to do it any other way. I could definitely see some advantage in using a separate plist file for the bundle though since then our reading/parsing would not be affected by any other preferences.
There was a problem reading the preferences file, continuing with defaults
But that shows up always, while the beeping is there only when the file is already open in say Skim.
Also, focus doesn't seem to switch to Skim.
Again this works for me. But it also worked for me without Robin's patch to tell Skim to activate! I hate applescript.
Brad
Robin <texmate.patch>
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
On 11/01/2008, Brad Miller bonelake@gmail.com wrote:
Haris, I cannot reproduce the beeping,
I can reproduce it if I turn on the "Check for file changes" option in the Skim prefs. Haris told me that he had that option on, so I suspect that's the explanation. What happens is that Skim starts to reload the file, having noticed that it has changed, and then the AppleEvent arrives while the file is already reloading, causing Skim to beep. (Because it's timing-dependent, it doesn't happen every time, and how frequently it happens probably depends on the size and complexity of the file and the speed of the machine.)
On Jan 11, 2008, at 6:12 AM, Charilaos Skiadas wrote:
Also, focus doesn't seem to switch to Skim.
Again this works for me. But it also worked for me without Robin's patch to tell Skim to activate! I hate applescript.
But I haven't posted my patch to tell the viewer to activate! It's attached here.
Robin
On Jan 11, 2008, at 3:57 PM, Robin Houston wrote:
On 11/01/2008, Brad Miller bonelake@gmail.com wrote:
Haris, I cannot reproduce the beeping,
I can reproduce it if I turn on the "Check for file changes" option in the Skim prefs. Haris told me that he had that option on, so I suspect that's the explanation. What happens is that Skim starts to reload the file, having noticed that it has changed, and then the AppleEvent arrives while the file is already reloading, causing Skim to beep. (Because it's timing-dependent, it doesn't happen every time, and how frequently it happens probably depends on the size and complexity of the file and the speed of the machine.)
That makes sense. I wonder if we could tell skim to turn that option off automatically, since it really should not be turned on when you are using Skim and TextMate together.
On Jan 11, 2008, at 6:12 AM, Charilaos Skiadas wrote:
Also, focus doesn't seem to switch to Skim.
Again this works for me. But it also worked for me without Robin's patch to tell Skim to activate! I hate applescript.
But I haven't posted my patch to tell the viewer to activate! It's attached here.
OK, now I guess I'm just losing my mind. I could swear I saw a patch go by earlier today that had "... active\n end tell" as part of the patch. I don't see it in the code now so I guess I was dreaming.
Brad
Robin <activate.patch> ______________________________________________________________________ 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 Jan 11, 2008, at 3:57 PM, Robin Houston wrote:
On 11/01/2008, Brad Miller bonelake@gmail.com wrote:
Haris, I cannot reproduce the beeping,
I can reproduce it if I turn on the "Check for file changes" option in the Skim prefs. Haris told me that he had that option on, so I suspect that's the explanation. What happens is that Skim starts to reload the file, having noticed that it has changed, and then the AppleEvent arrives while the file is already reloading, causing Skim to beep. (Because it's timing-dependent, it doesn't happen every time, and how frequently it happens probably depends on the size and complexity of the file and the speed of the machine.)
I too can reproduce the beep by turning on Check for changes....
On Jan 11, 2008, at 6:12 AM, Charilaos Skiadas wrote:
Also, focus doesn't seem to switch to Skim.
Again this works for me. But it also worked for me without Robin's patch to tell Skim to activate! I hate applescript.
But I haven't posted my patch to tell the viewer to activate! It's attached here.
Before I apply and commit this patch I would like to know how many people have a problem. I cannot reproduce the failure to activate problem on my powerbook running 10.5.1. For me, the code (without this patch) activates Skim just fine after typesetting the document. If Skim does not activate for you after a successful typeset I would like to know more about your environment to see if this is really necessary or not. Extra applescript just slows everything down.
- do you have Check for changes checked in Skim? - What settings do you have in Latex Preferences? - What version of Mac OS are you using?
Thanks,
Brad
Robin <activate.patch> ______________________________________________________________________ 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 11/01/2008, Brad Miller bonelake@gmail.com wrote:
Before I apply and commit this patch I would like to know how many people have a problem. I cannot reproduce the failure to activate problem on my powerbook running 10.5.1.
Try it with TeXShop as the viewer, rather than Skim. It seems to be a quirk of Skim that the document window jumps to the front when it's refreshed, and doesn't happen with the other previewers. Also, I think I've seen cases where it doesn't happen with Skim, though I can't reproduce it now so my memory might be mistaken.
Having said that, I personally prefer the UNpatched behaviour, where the refreshed document window pops up so it's immediately behind the Typeset and View window. It makes it easier to see both the source and the document at once, even if there are lots of windows open both in TextMate and in the viewer app. So I'd be happy for the patch not to be applied: it depends what the intended behaviour is.
Robin
On Jan 12, 2008, at 4:56 AM, Robin Houston wrote:
On 11/01/2008, Brad Miller bonelake@gmail.com wrote:
Before I apply and commit this patch I would like to know how many people have a problem. I cannot reproduce the failure to activate problem on my powerbook running 10.5.1.
Try it with TeXShop as the viewer, rather than Skim. It seems to be a quirk of Skim that the document window jumps to the front when it's refreshed, and doesn't happen with the other previewers. Also, I think I've seen cases where it doesn't happen with Skim, though I can't reproduce it now so my memory might be mistaken.
Having said that, I personally prefer the UNpatched behaviour, where the refreshed document window pops up so it's immediately behind the Typeset and View window. It makes it easier to see both the source and the document at once, even if there are lots of windows open both in TextMate and in the viewer app. So I'd be happy for the patch not to be applied: it depends what the intended behaviour is.
I think we should leave it as is, i.e. not activate the viewer by default, and add a "bring viewer to front" preference for it. I'm guessing people with double screens etc would rather have focus stay with TM.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
I've just upgraded Skim to 1.0.3, and now I find that Skim does not activate when the document is updated, bringing its behaviour into line with that of the other previewers.
Do other people see the same, and, if so, does this affect whether or not we want to activate the document after refresh? We could do something like
tell application "Skim" to tell (documents whose path is "/path/to/file.pdf") revert activate end tell
to avoid a second invocation of osascript.
Robin
I also upgraded to Skim 1.0.3 and Skim does activate when the document is updated.
This seems like it would be a reasonable option to add to the latex preferences, but I don't want to do it until the behavior from the viewers shows some kind of consistency.
Brad
On Jan 14, 2008, at 8:00 AM, Robin Houston wrote:
I've just upgraded Skim to 1.0.3, and now I find that Skim does not activate when the document is updated, bringing its behaviour into line with that of the other previewers.
Do other people see the same, and, if so, does this affect whether or not we want to activate the document after refresh? We could do something like
tell application "Skim" to tell (documents whose path is "/path/to/ file.pdf") revert activate end tell
to avoid a second invocation of osascript.
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
I'm sorry, but I have no idea what to do with the patch. I downloaded it and opened it, but I'm not exactly sure what I'm supposed to do with it.
Keith
Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
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
I take it you are not following the subversion version of the LaTeX bundle? If not, you might want to start:
http://macromates.com/textmate/manual/bundles#getting_more_bundles
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Jan 11, 2008, at 11:04 AM, gandalfxviv wrote:
I'm sorry, but I have no idea what to do with the patch. I downloaded it and opened it, but I'm not exactly sure what I'm supposed to do with it.
Keith
Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
Robin
No, I don't even know what subversion is. I installed it, but that manual only tells how to install bundles. I didn't see anything about patches.
Keith
Charilaos Skiadas-3 wrote:
I take it you are not following the subversion version of the LaTeX bundle? If not, you might want to start:
http://macromates.com/textmate/manual/bundles#getting_more_bundles
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Jan 11, 2008, at 11:04 AM, gandalfxviv wrote:
I'm sorry, but I have no idea what to do with the patch. I downloaded it and opened it, but I'm not exactly sure what I'm supposed to do with it.
Keith
Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
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
Keith, you don't need to use the patch. It is already incorporated in the latest version of the LaTeX bundle. So if you can checkout the latest bundles from the subversion repository, it should work for you. All the best, Mark On Jan 11 2008, at 17:12, gandalfxviv wrote:
No, I don't even know what subversion is. I installed it, but that manual only tells how to install bundles. I didn't see anything about patches.
Keith
Charilaos Skiadas-3 wrote:
I take it you are not following the subversion version of the LaTeX bundle? If not, you might want to start:
http://macromates.com/textmate/manual/bundles#getting_more_bundles
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Jan 11, 2008, at 11:04 AM, gandalfxviv wrote:
I'm sorry, but I have no idea what to do with the patch. I downloaded it and opened it, but I'm not exactly sure what I'm supposed to do with it.
Keith
Robin Houston wrote:
On 10/01/2008, Robin Houston robin.houston@gmail.com wrote:
I'll see if I can improve check_open to allow this kind of check.
The attached patch updates the check_open tool so that documents can be specified by (absolute) path.
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
-- View this message in context: http://www.nabble.com/LaTeX---opening-PDFs-tp14716936p14760795.html Sent from the textmate users mailing list archive at Nabble.com.
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
Okay, I guess I'm not doing something right. I typed "svn co http://macromates.com/svn/Bundles/trunk/Bundles/Latex.tmbundle/" in my terminal, and it output a bunch of stuff, ending with "Checked out revision 8796." Then I ran the "Reload Bundles" command in TextMate and retried and I still had the same problem, so I restarted both Skim and TextMate and still nothing has changed.
Keith
Keith, you don't need to use the patch. It is already incorporated in the latest version of the LaTeX bundle. So if you can checkout the latest bundles from the subversion repository, it should work for you. All the best, Mark
Hi Keith,
Where did you check out the bundles to? Have a look at this very helpful post by Haris Skiadas:
http://skiadas.dcostanet.net/afterthought/2006/12/20/subversion-and-textmate...
(You can skip the bit about installing subversion.) If you still have troubles write back but make sure to describe each of the steps you have taken.
All the best, Mark
On 1/14/2008, "gandalfxviv" keith.penrod@gmail.com wrote:
Okay, I guess I'm not doing something right. I typed "svn co http://macromates.com/svn/Bundles/trunk/Bundles/Latex.tmbundle/" in my terminal, and it output a bunch of stuff, ending with "Checked out revision 8796." Then I ran the "Reload Bundles" command in TextMate and retried and I still had the same problem, so I restarted both Skim and TextMate and still nothing has changed.
Keith
Keith, you don't need to use the patch. It is already incorporated in the latest version of the LaTeX bundle. So if you can checkout the latest bundles from the subversion repository, it should work for you. All the best, Mark -- View this message in context: http://www.nabble.com/LaTeX---opening-PDFs-tp14716936p14803673.html Sent from the textmate users mailing list archive at Nabble.com.
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
Okay, I got that working now. I also switched to TeXShop since someone said that it puts the output window immediately behind the editor window whenever it refreshes, which is much better than Skim which doesn't even raise the window any amount when it refreshes. Anyway, after compiling a couple times, sometimes TeXShop doesn't redraw the PDF until I click on the window to bring it into focus. Anyone else having this problem?
Keith
Yes, but I discovered that if I keep the toolbar of the TexShop preview window open, the PDF gets redrawn without my having to click on it! --Gildas Hamel
gandalfxviv wrote:
Okay, I got that working now. I also switched to TeXShop since someone said that it puts the output window immediately behind the editor window whenever it refreshes, which is much better than Skim which doesn't even raise the window any amount when it refreshes. Anyway, after compiling a couple times, sometimes TeXShop doesn't redraw the PDF until I click on the window to bring it into focus. Anyone else having this problem?
Keith
Well, I never hid my toolbar, so I don't see how that would help me.
Keith
Gildas Hamel wrote:
Yes, but I discovered that if I keep the toolbar of the TexShop preview window open, the PDF gets redrawn without my having to click on it! --Gildas Hamel
gandalfxviv wrote:
Okay, I got that working now. I also switched to TeXShop since someone said that it puts the output window immediately behind the editor window whenever it refreshes, which is much better than Skim which doesn't even raise the window any amount when it refreshes. Anyway, after compiling a couple times, sometimes TeXShop doesn't redraw the PDF until I click on the window to bring it into focus. Anyone else having this problem?
Keith
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
Le 9 janv. 08 à 23:26, Keith Penrod a écrit :
I am running Version 1.0.2 (v20) of Skim, Version 1.5.7 (1455) of TextMate, Leopard (10.5.1). I could give you a file if you want, but all you need to do is have two distinct .tex files with the exact same name and in different directories on your computer. Have both of them open in TextMate. Compile one and it will show up in Skim. Compile the other and it will think that you're trying to update the first file that you compiled because they have the same name.
I'm also running Version 1.0.2 (v20) of Skim, Version 1.5.7 (1455) of TextMate, Leopard (10.5.1) and like Haris I cannot reproduce the problem but like Paul my texMate.py has "refreshViewer" defined on line 122.
Sometimes I have an alert message about refresh but not in this case.
Best Regards
Alain Matthes
-
Alain Matthes -
Brad Miller -
Charilaos Skiadas -
gandalfxviv -
Gildas Hamel -
Keith Penrod
-
Mark Eli Kalderon -
Paul McCann -
Robin Houston