Link-back opening a new window instead of a tab

[taiya]

I use TM and Skim to navigate my latex project. When I Shift+Command+Click in skim this sends a message to TextMate making it open the file and position within that file that best matches the search.

Unfortunately, even though TM is configured to open new tabs and not new windows by default, this option is completely ignored (a new window is opened instead).

This is particularly annoying when using split-screen in OSX El Capitan, as this causes a new fullscreen tab to be opened.

[sanssecours]

Hi Andrea,

please follow the guidelines mentioned in “Writing Bug Reports” when you open a new issue. One important part that your bug report is missing are the steps to reproduce the problem.

Unfortunately, even though TM is configured to open new tabs and not new windows by default, this option is completely ignored (a new window is opened instead).

As far as I know, there is no option to tell TextMate to always open files in an already opened window or in a new one. The behaviour depends on the state that TextMate is in and how you open the file. If I am wrong about that, and there is an option to always open a tab in the current window, then please provide the steps that I need to take to activate this option.

I tried the following:

1. Open TextMate

2. Close all open windows

3. Create a new file via ⌘ + N

4. Save the file as Test.tex in the Folder ~/Downloads

5. Paste the following content into the file:

   \documentclass{article}
   
   \begin{document}
   Test
   \end{document}

6. Open a new tab via ⌥ + ⌘ + N

7. Save the current file as Test.txt in the folder ~/Downloads

8. Switch back to the tab containing Test.tex

9. Activate “Watch Document”

10. Close the current tab (containing Test.tex)

11. Hold ⇧ + ^ and click on any part of Test.pdf in Skim

12. Result: TextMate opens a new window containing the content of Test.tex, instead of opening the file in the already existing window.

The command that Skim calls to open a new window is mate -l %line "%file". If I close the file opened in step 12 and run mate -l 1 "Test.tex" in iTerm, then TextMate opens the file in a new tab in the old window. Honestly, I do not know what is the cause of this behaviour at all. Whatever it is, it does not look like this is a bug in the LaTeX bundle.

@sorbits: Allan, could you please describe what is the cause of the behaviour? Is there something like an option to always open a file in the last active window? I had the problem Andrea reported sometimes myself, even if I did not close the .tex file I was working on. Ctrl-Shift-Clicking on the PDF in Skim opened a new instance of the file, even though the file was already open in another TextMate window. It looks like I can now even reproduce the problem most of the time. Below I included a video of the bug. Here are the steps I used to reproduce the problems shown in the video:

1. Open TextMate

2. Close all open windows

3. Create a new file via ⌘ + N

4. Save the file as Test.tex in the Folder ~/Downloads

5. Paste the following content into the file:

   \documentclass{article}
   
   \begin{document}
   Test
   \end{document}

6. Activate “Watch Document”

7. Hold ⇧ + ^ and click on any part of Test.pdf in Skim

Expected Result: TextMate activates the window created in step 3.
Actual Result: TextMate opens another window containing the content of Test.tex.

Bug.zip

[taiya]

Sorry if I was a bit sloppy.
You can refer to this screencast to reproduce the problem:
https://www.youtube.com/watch?v=e7XLyys1UeY&feature=youtu.be

And as I don't know why youtube downscaled the resolution, here is the raw:
https://www.dropbox.com/s/80rc2pnnak2hmj0/textmate_bugreport.mov?dl=0

[sorbits]

Is it possible for you to log the value of %file?

In theory it should be possible to reproduce the problem using the exact same value of this variable from the terminal (without involving Skim).

The way TextMate works is that it tries to match the path to an already open file, and if that fails, match the directory of the file to an already open window. So my best guess would be that %file is a path that TextMate somehow incorrectly normalizes, e.g. it could be something along the lines of ~/Downloads/../Downloads/Test.tex (although that one ought to work).

[sanssecours]

Is it possible for you to log the value of %file?

Yes. I wrote a script arguments with the following content:

#!/usr/bin/env ruby

File.open("#{ENV['HOME']}/Downloads/arguments.txt", 'w') do |file|
   file.write(ARGV.join ' ')
end

and saved it as ~/bin/arguments. Then I used the “Custom” option inside “Skim→Preferences…→Sync”:

The content of arguments.txt looks fine:

-l 4 /Users/rene/Downloads/Test.tex

In theory it should be possible to reproduce the problem using the exact same value of this variable from the terminal (without involving Skim).

Unfortunately that does not seem to be the case. Calling mate -l 4 /Users/rene/Downloads/Test.tex does not open a new instance of the file. If I do not close the second window – the one that appeared after Ctrl-Shift-Clicking the PDF –, then the command activates this window. If I close the second window, then the command activates the (remaining) initial window.

One thing I also noticed: If I close the initial window too, then Ctrl-Shift-clicking the PDF will only open one instance of the file. That is even the case if I Ctrl-Shift-click the PDF, and open the file via mate in iTerm, multiple times.

[sorbits]

Can I have you try using this version of the arguments script:

#!/usr/bin/env ruby
require 'shellwords'

File.open("#{ENV['HOME']}/Downloads/arguments.txt", 'w') do |file|
  ENV.each { |key, value| file << "#{key}=#{value.shellescape} " if key =~ /^TM_/ }
  file << "mate " << ARGV.map { |arg| arg.shellescape }.join(' ')
  file << "\n"
end

This will capture all TM_-prefixed variables. The resulting file should be executable as-is to replicate the call to mate but with the same (TM) environment as when called from Skim.

mate does look at variables like TM_PROJECT_UUID as a hint about what project to use and TM_DOCUMENT_UUID (when there is no filename).

I’m thinking that if Skim is launched from TextMate, it inherits some of these variables, and when Skim is then calling mate these variables are causing mate to behave in an unexpected/undesired way.

[sorbits]

So after clicking the link in Skim, run sh ~/Downloads/arguments.txt in a terminal to see if that cause the file to open in a new window.

If it does, I am almost certain the issue is with TM_PROJECT_UUID, so try remove that from arguments.txt.

[sanssecours]

So after clicking the link in Skim, run sh ~/Downloads/arguments.txt in a terminal to see if that cause the file to open in a new window.

Yes, running the above command does indeed open a new window \o/.

If it does, I am almost certain the issue is with TM_PROJECT_UUID, so try remove that from arguments.txt.

You are right. If I remove the environment variable – TM_PROJECT_UUID had the value 89586BE9-0D60-47D3-8681-B9791A1589C0 in my test –, then mate does not open a new window.

[sorbits]

Thanks for the work debugging! The idea was that one could use TM_PROJECT_UUID to target a specific project (window) and if the uuid did not exist, force a new project to be opened.

But I think this “feature” should be suppressed when the file requested is already open, so I will address that in TextMate and link the commit to this issue.

For now, opening Skim from Finder (rather than have TextMate open it) should result in proper behavior.