some changes to make it work like Emacs vertical file completion.

[yangwen0228]

[skuroda]

Hey @yangwen0228 , just as a note I do see these coming in but have been busy. I appreciate you enhancing this. I see you're iterating on this. Can you add a comment when you're ready for this to be merged (and casually reviewed). I'm not up to date on the latest sublime text APIs so if you're using any of those, I'll rely on trusting what you're doing :D

[yangwen0228]

OK! I find your package is the best one in the Package Control to handle the file operation. And I enhance this package to almost the same experience in Emacs. Emacs is very handy and extensible, but the speed is not quite good when use in company computers with disk encrypt software. I use this package after enhanced for hours. It is becoming handy now. But it still needs some improvements to increase the large project files sorting performance, and increase the stability when popup frequently. Maybe I should expend some time to research the partial APIs. I use the Sublime Text4, but not test in the old versions. Just wait the weekend to improve this.

[yangwen0228]

Hey @yangwen0228 , just as a note I do see these coming in but have been busy. I appreciate you enhancing this. I see you're iterating on this. Can you add a comment when you're ready for this to be merged (and casually reviewed). I'm not up to date on the latest sublime text APIs so if you're using any of those, I'll rely on trusting what you're doing :D

I think everything works as expected, now! Do you want to have a try? Or just merge in?

[skuroda]

Hey @yangwen0228 catching up on this. In some chats with the SublimeText organization, we're going to move this project into their space. I'll likely let them help manage the approvals as well (because they are far more up to date than I am with practices around plugins today). I do notice the removal of some of the settings. What's the impact to those that that either used the default false value, or had it as true?

[yangwen0228]

Great! No problem!

[skuroda]

I took not so brief look as I initially intended at this and have added a few comments with some questions as well as suggestions.

Generally, I think adding a completion list is a good idea, but this is going into the wrong direction because it introduces a UX foreign to ST in general. Using the native completions feature would feel much more natural and should work better even, though it may require some more detailed knowledge on how the corresponding API needs to be handled. I wish I had the time to work on it, however, because it sounds nice.

The PR also breaks compatibility with both ST2 and ST3 at the moment and is missing a .python-vesion file to declare the plugin host since it uses 3.6+ syntax. I would be very much fine with dropping compatibility for new code & features, but moving unsupported versions to mainenance mode needs to be mentioned in the readme. (This is a heads-up for @skuroda.)

Also good with putting ST2 and 3 versions of the plug in into maintenance mode. I vaguely recall the package control entry having something to pin the versions there (for ST2 at the time). Am I correct in assuming that's the same action that needs to happen still?

[FichteFoll]

Am I correct in assuming that's the same action that needs to happen still?

Yes, it still works the same way. The suggested course of action is to create a prefixed tag for the legacy version (e.g. st3-1.7.0 which would just be a re-tag of the current latest version) and then split the release channels in two, one for ST3 and older with "tags": "st3-" and the other already existing one for the latest versions (can remain unchanged as "tags": true.

[skuroda]

Tag pushed and https://github.com/wbond/package_control_channel/pull/8571 to pin the version.

[skuroda]

I've merged in a couple readme updates in #186 that I'm guessing will conflict with some of the changes in this PR.