WIP on supporting ST4 side-by-side opening

[themilkman]

Hello again @robinmalburn,

I've been working with this since a while and it mostly works fine so far. What it does? It adopts the ST4 behaviour to open a transient view to the right when pressing shift+enter on selection.

But it comes at the price that it only works with SublimeText 4 APIs. For the sake of simplicity I didn't want to guard it with version checks yet. In addition I do not have a local copy of ST3 on my PC to test (not to mention ST2). Thus, in case you are open to it, I'd investigate how to use the API-Level based releases of ST plugins on package control (I think it is tag based <build of ST which should correspond the API usage>-, like seen in the the Sublime LSP package: 4070-1.7.0) If we'd take that route I'd also suggest creating a .python-version file to use the newer python 3.8 plugin host.

Open points are currently:

• not supporting unsaved files for it
• add the ST4 default behaviour with ctrl+enter, too (I don't use it thus it is not there yet)
• cleanup/extend comments
• add docs to README

I just wanted to know whether you are open for this and what your thoughts are about it.

Cheers Erik

[robinmalburn]

Hey again @themilkman,

That's a neat little WIP addition, I like it in principle. It's funny you should mention the ST4 move, I fixed a bug recently that made me realise I really need to drop ST2 support so that I can just use Python 3 stdlib and make maintenance easier, so I was looking into targeting specific releases as part of that. I want to finish the feature I've been working on to close #7, but after that, my next goal would be to:

• create a fixed tag release that just worked on ST2 as a final legacy release
• re-write the next release to be purely Python 3 based and support >=ST3

I didn't realise the .python-version feature existed, but I love the idea of that; I kinda like the idea of using type hints for my own personal sanity, so being able to use a 3.5+ compatible version of python at some point in the near future sounds glorious. That's probably not an overnight change, I need to think about that, because I don't want to make a maintenance nightmare for myself by having dueling branches of the plugin to maintain... it might just be that I decide the legacy release is action ST2 and ST3 and all new releases are >=ST4. I need to think a little about that and whether there's a way around the API support checks.

For now, essentially, this is something I'm interested in, but in the interest of not wasting your time given that I want to migrate to a Python 3 rewrite, do you want me to ping you a message when that rewrite is complete and then pick the branch back up?

Thanks again for the contributions - it was great working with you on the last one, so really happy to see another contribution 😄

[themilkman]

Hi @robinmalburn,

great, of course, feel free to ping me any time. I'll look forward into keep my branch up-to-date with your further development. I just saw your recent commits, sorry for introducing troubles with ST2.. Glad you also think that stop supporting old versions and providing an legacy version is an option for you. Tab Filter as it is works fine for older ST releases, but having the opportunity to use newer features is a good thing in my opinion.

For the records, docs about the .python-version are provided here.

Thanks for sharing your thoughts and hopefully until soon! :)

[robinmalburn]

Hey @themilkman,

If you're still keeping an eye on this, just as a heads up, I released the new version of the package this morning - 2.0.0. It drops support for Sublime Text 2 & 3 and goes full on ST4 and Python 3.8 support. Also added a full suite of Unit Tests and whatnot, so it's a pretty significant update, so it's probably going to cause havoc with merge conflicts - sorry! 😅 Hopefully you'll agree the code is way easier to reason about and manage now though - it was way overdue modernising.

[themilkman]

Hey @robinmalburn, really glad to see the new release - also thanks for the note. I'll hopefully soon find some time to add the feature from above. So far I only had the chance to take a quick look at the new source code but really looking forward to work with it. I'll push a new version as soon as I can :)

[themilkman]

Just as a quick follow up: I currently have no time to work on this so I just commited/pushed what I have (in another branch currently). My state for the 2.0 version is there but it does not behave the way I wish and either the APIs are not great for what is in my mind or I just didn't manage to use them right. https://github.com/themilkman/sublime-tabfilter/tree/feature/side_by_side_opening

Just in case someone is interested in this or wants to use it as inspiration. Maybe I am going to create a stripped down version without the ctrl/alt additions but even the origin shift modifier does not allow to open multiple files side-by-side (I thought that would have been working at some point but actually I don't need this often/at all). I use this code at my everyday work but currently I wouldn't consider it as "ready for production" at all.

So far, thank you for this great plugin (I really like the way of your rewrite and again learned quite a few things about python!) and all the best, @robinmalburn. Hopefully I'll be back at this point in the not so far future :-)

[robinmalburn]

Hey @themilkman

Good to hear from you, and not a problem at all - life gets busy sometimes, so totally understand having to put working on this on hold. I've taken a quick look at the source code myself and when I have more time might pull in the branch and see if I can get the feature working since you've already put so much into it 😄

From a quick look at the code, I think I might actually see what the issue is that's causing a headache. As an example, you've got:

self.window.open_file(self.views[index].file_name(), sublime.ADD_TO_SELECTION, sublime.REPLACE_MRU)

Now, the API for window.open_file() indicates it expects the second argument you're passing their to be a bitwise flag, whereas we're giving it a list of flags. So, to make that match the API docs, I'd expect it to look more like:

self.window.open_file(self.views[index].file_name(), sublime.ADD_TO_SELECTION | sublime.REPLACE_MRU)

Note how we're OR'ing together the sublime.ADD_TO_SELECTION and sublime.REPLACE_MRU flags to produce a combined bitwise flag of the two.

As it is, stands, it's trying to treat the second flag as a group identifier instead of a flag.