Added support for Sublime Text v2.

[mattst]

I've modified i_opener.py so that it now works with Sublime Text v2. It has been tested with the latest release versions of both ST2 and ST3 on both Linux (64 bit) and Windows XP (32 bit) and is working well.

Please note that I use the ST setting trim_trailing_white_space_on_save. When I did a git diff with the last commit, dozens of lines were shown as changed when they had not been and I realized they must have had trailing whitespace. Ignore these with the git diff --ignore-space-at-eol option (regular diff uses -Z to do the same thing). I can't seem to find any way to tell github to ignore trailing whitespace in the diff on the pull request page.

List of changes made in branch st2_support:

1) Added the set_sublime_text_version() function and a ST version check in the iOpenerCommand class.

2) Changed the get_current_path() method to use the ST window class method folders() instead of project_data() to get the project's folders (if any). folders() always provides the full path to project folders so the code to build the full path is no longer necessary. It returns an empty list if there is no open project or if an open project has no folders set. project_data() is only in the ST3 API, while folders() is in both the ST2 and ST3 APIs.

3) Removed the os.path import of isabs(); it is no longer needed due to 2).

4) Changed the on_query_context() method in the iOpenerEventListener class.

Instead of directly comparing the view objects, it now compares the view objects' ids. i.e.

Was: iOpenerCommand.input_panel.view == view
Now: iOpenerCommand.input_panel.view.id() == view.id()

This was done for compatibility with ST2 because the view object comparison always failed. It took me a while to work out why it was failing but, by inspecting the view class of both APIs, I discovered that the view class in the ST3 API has the special methods __eq__ and __ne__, which facilitate object comparison tests using == and !=, while the view class in the ST2 API does not have them. view.id() returns an integer which uniquely identifies the view, using this for the comparison works well with both ST2 and ST3 and is a suitable alternative to directly comparing the objects.

5) Several changes to the open_file() method in the Path_input class:

a) Fixed a minor bug by moving the call to add_to_history() below the check for empty paths, so that empty paths no longer get added to the history. The bug can be reproduced by opening an empty path and then scrolling up in the history.

b) If the user enters the path to a folder, the plugin adds that folder to the project folder list (in a new window by default). Project data can not be set using the ST2 API so this feature is incompatible with ST2. A check has been added to see if ST2 is running before trying to add a project folder, if it is then a status message is displayed saying that opening folders requires ST3 and the method returns.

c) Fixed a minor bug that allows users to create a new buffer with the same full path as an existing folder, they would never be able to save the file. The bug can be reproduced by opening a buffer with the same full path as an existing folder but without a trailing slash. It was fixed by changing the if filename == "": line to if isdir(path): which in ST3 opens the folder even if the path is missing the trailing slash, while ST2 users get the status message saying that opening folders requires ST3 as described in b).

Finally: It took great strength to resist changing the name of the Path_input class to iOpenerPathInput so that the class names all follow the same naming convention; but recognizing that it's a little OCD of me I left if for you to do so if you wish. [Actually I did change it but changed it back again after recognizing that it wasn't my place to do so.]

I hope this helps. All the best, mattst

[kevincobain2000]

+1

[rosshemsley]

Cool! On holidays up a mountain atm -will look nrxt week! (Feel free to bump this thread if I forget by Tuesday :) )

[rosshemsley]

[Actually I did change it but changed it back again after recognizing that it wasn't my place to do so.]

It's okay, that would have been totally the right thing to do.

This code is starting to feel it's age. I've got some time on a plane now and might bring some more of it into this century. Could be useful to have Windows/ST2 users test at some point.

Otherwise, looks great!

[mattst]

Well, you have done a lot.

Could be useful to have Windows/ST2 users test at some point.

You must have missed that in my post; I tested it in ST2 and ST3 on both Linux (64 bit) and Windows XP (32 bit) and it is working well. I don't actually have a computer with Windows on but I have Win XP 32 in a VirtualBox machine that I use for a few programs that won't work with Wine. I installed ST 2 and 3 for testing iOpener before doing my pull request.

changing the name of the Path_input class to iOpenerPathInput

Cool. :)

The changes you've made broke the ST2 support, but I've fixed that - it was just a module import problem so nothing major.

Thanks for giving me push privileges, I'll push the ST2 fix along with a new feature which I think you'll like.

All the best.

[rosshemsley]

Sweet, I'll look out for the PR!

There's another PR pending that allows you to hide hidden files and other junk in listings if you ever fancy looking.

If you can find a way to make a failing test for the ST2 fix, that would be awesome (I made it so circleci runs unit tests for both Python2 and 3 in all files but i_opener.py (because circle doesn't have sublime text modules))

[mattst]

There's another PR pending that allows you to hide hidden files and other junk in listings if you ever fancy looking.

I already took a look.

If you can find a way to make a failing test for the ST2 fix

Ok, but I've not used circleci before.

I've just finished the new feature I mentioned. My intention is to make the USE_PROJECT_DIR setting redundant, or at least less important. It's a copy of the history cycle feature, it works in the same way but cycles through all available folders; i.e. folder of current file, then all project folders. It only differs in that it's on an infinite loop, last goes to first and visa-versa. Key mapping is ctrl+up and ctrl+down (for Linux/Win, along the same lines for OSX, I'll look into that tomorrow). Working perfectly in both ST v3 and v2.

One other thing:- I think the way the settings are managed should be changed. At the moment a settings file is used:

SETTINGS_FILE = 'i_opener.sublime-settings'

The only way a setting can be changed is for the user to duplicate the settings file to their user folder and change the setting. I propose ditching that totally and creating settings like this:

iopener_use_project_dir
iopener_open_folders_in_new_window
iopener_case_sensitive
iopener_history_entries

The user would then change the iOpener settings in their User/Preferences.sublime-settings file. The default values for the settings can then be hard coded into i_opener.py or in a settings.py module if you prefer.

With the go ahead I'll do that tomorrow but won't start unless you give the nod.

By the way, some of the folder completion is broken. With 2 folders with the same name at the start, e.g. Temp and Templates, It'll autocomplete to the shortest adding the final slash and never offering the completion choice at all. I was going to take a look but did the folder cycling instead.

HTH.

[rosshemsley]

Interesting to folders idea (if users can also keep current behaviour too that would be good) Don't forget to update ReadMe

The settings file layout is pretty standard I think, I believe this is how you change settings for most plugins? (unless I missed something?) Open to being convinced.

Yes, the auto-complete thing is a bug, it should check that the completion was unique before adding a slash!

For circleci, it's pretty simple. It just runs the tests in matching.py and paths.py in Python2 & 3, causing PRs to be rejected if they fail. tox.ini controls this.

[mattst]

Interesting to folders idea (if users can also keep current behaviour too that would be good)

Ok. So start with current file folder if use_project_dir is false, and with the first project folder if it's true. I'll probably replace get_current_directory with a function to build the folder list, and use the first element of that list to set the initial input panel text.

The settings file layout is pretty standard I think, I believe this is how you change settings for most plugins? (unless I missed something?) Open to being convinced.

Nope, you're right. Apologies.

Just one more thing show_input_panel() uses Find file as its caption. Wouldn't Open file be better, given that's what is actually being done?!!