Home Download Buy Blog Forum Support

ST2/3 Edit Abstraction

ST2/3 Edit Abstraction

Postby lunixbochs on Wed May 29, 2013 9:41 pm

While porting some of my plugins to ST3, I was annoyed enough with the edit changes (view.insert, replace, erase can only be used in a TextCommand now) to make an edit abstraction with easy syntax that works with both ST2 and ST3.

https://github.com/lunixbochs/SublimeXiki/blob/st3/edit.py

This module allows use of insert, replace, and erase. It also batches all edits made inside the "with" block so they appear as one "edit" to Sublime.

Hopefully this makes your life easier if you enjoy writing text manipulation plugins as much as me ;)

Example (should work in both ST2 and ST3):
Code: Select all
with Edit(view) as edit:
    edit.insert(0, 'hi\n')
    edit.insert(0, 'more stuff\n')


----
Compare to:

ST2 edit:
Code: Select all
edit = view.begin_edit()
view.insert(edit, 0, 'hi\n')
view.insert(edit, 0, 'more stuff\n')
view.end_edit(edit)

ST3 edit (repeat for erase, replace? or roll your own / use callbacks if you want multiple operations in a single edit):
Code: Select all
class InsertCommand(sublime_plugin.TextCommand):
    def run(self, edit, pos, text):
        self.view.insert(edit, pos, text)

view.run_command('insert', {'pos': 0, 'text': 'hi\n'})
view.run_command('insert', {'pos': 0, 'text': 'more stuff\n'})
lunixbochs
 
Posts: 91
Joined: Fri Oct 08, 2010 10:18 pm

Re: ST2/3 Edit Abstraction

Postby aziz on Thu May 30, 2013 11:31 am

Awesome. Would be great to publish more of these abstractions.
PlainTasks: my opinionated todo plugin
tmThemeEditor color-scheme editor for SumblimeText and Textmate (code on github)
aziz
 
Posts: 40
Joined: Thu Jan 12, 2012 6:29 pm

Re: ST2/3 Edit Abstraction

Postby tito on Thu May 30, 2013 3:03 pm

Thanks!
Give APIs, let the community build the rest!
https://github.com/titoBouzout
tito
 
Posts: 854
Joined: Thu Sep 29, 2011 2:27 pm
Location: Montevideo, Uruguay

Re: ST2/3 Edit Abstraction

Postby adzenith on Fri May 31, 2013 2:11 pm

This is awesome. Thank you.
adzenith
 
Posts: 1214
Joined: Mon Oct 19, 2009 9:12 pm

Re: ST2/3 Edit Abstraction

Postby FichteFoll on Thu Jun 06, 2013 11:50 pm

Really like it, can't think of any way to improve it right now.

I found this in this commit and since we already have something "similar" for ST2 in sublime_lib I'd like to add this too when migrating to ST3.

Hopefully, Package Control will, at some point, get a decent dependency and python-only packages so other packages/pugins can use sublime_lib without requiring AAAPackageDev (which could then finally be renamed to "PackageDev"). Really excited about that.

Edit: Well, there is a way to improve it, imo. Instead of monkeypatching "sublime.edit_storage" you could use a global (in that module) or just pass "self.run" as is, because command arguments are preserved even if they are non-linear types (like a function/method here). Should not be unsafe because the Edit instance will be unreferenced anyway at the execution of __exit__, as long as the programmer uses it sanely.
FichteFoll
 
Posts: 388
Joined: Fri Mar 16, 2012 11:49 pm
Location: Germany

Re: ST2/3 Edit Abstraction

Postby lunixbochs on Wed Jun 12, 2013 4:51 am

FichteFoll wrote:Edit: Well, there is a way to improve it, imo. Instead of monkeypatching "sublime.edit_storage" you could use a global (in that module) or just pass "self.run" as is, because command arguments are preserved even if they are non-linear types (like a function/method here).

This wasn't my experience. I had bad results when I put persistent data anywhere but in an imported Python module. I picked sublime.edit_storage because I could guarantee a working import (sublime) in both ST2/3. When I tried storing it in other places (like the current module) or passing the callback directly, I had issues with edits failing.
lunixbochs
 
Posts: 91
Joined: Fri Oct 08, 2010 10:18 pm

Re: ST2/3 Edit Abstraction

Postby wbond on Thu Jun 13, 2013 1:28 am

FichteFoll wrote:Hopefully, Package Control will, at some point, get a decent dependency and python-only packages so other packages/pugins can use sublime_lib without requiring AAAPackageDev (which could then finally be renamed to "PackageDev"). Really excited about that.


The load order is still controlled by ST, so I wouldn't get your hopes up.

Dependency management and things like it are on my mind, but unlikely to happen in the near term just dealing with what I have on my plate for now. More than happy to have contributions to the discussion https://github.com/wbond/sublime_packag ... issues/166. Mostly someone needs to come up with a good plan for dealing with dependencies. Probably not going to be able to pin dependencies to specific versions since everything is loaded into a single process. But yeah, install-time dependency resolution would be great.
wbond
 
Posts: 527
Joined: Mon Feb 28, 2011 5:33 am

Re: ST2/3 Edit Abstraction

Postby FichteFoll on Thu Jun 13, 2013 1:00 pm

wbond wrote:The load order is still controlled by ST, so I wouldn't get your hopes up.


Yes, this is true. However, in ST3 (mainly) you can also directly import modules that are not exactly a plugin because the packages directory is added to sys.path. At least this is what I think, so you should be able to load required modules if you need them without relying on ST's load order. And if that doesn't work you can also import in "plugin_loaded()".

wbond wrote:Dependency management and things like it are on my mind, but unlikely to happen in the near term just dealing with what I have on my plate for now. More than happy to have contributions to the discussion https://github.com/wbond/sublime_packag ... issues/166. Mostly someone needs to come up with a good plan for dealing with dependencies. Probably not going to be able to pin dependencies to specific versions since everything is loaded into a single process. But yeah, install-time dependency resolution would be great.


I am monitoring that issue and plan to step onto the discussion 1) when PC2.0 is ready and 2) when I have a decent (implementation) idea. I'm perfectly fine with no version dependencies because that introcudes a bunch of complexity for both, the dependency and the depedency-using packages (even a simple thing). But well, this does not really belong here but in #166.

Edit: While I think about this, it could lead to terrible name clashes (e.g. "YAML" package and "yaml" Python module)...
FichteFoll
 
Posts: 388
Joined: Fri Mar 16, 2012 11:49 pm
Location: Germany

Re: ST2/3 Edit Abstraction

Postby lunixbochs on Mon Jun 17, 2013 2:06 am

FichteFoll wrote:Edit: While I think about this, it could lead to terrible name clashes (e.g. "YAML" package and "yaml" Python module)...

So toss them in a package folder - you can import somethingunique.yaml instead of just yaml if you don't want name collisions
lunixbochs
 
Posts: 91
Joined: Fri Oct 08, 2010 10:18 pm

Re: ST2/3 Edit Abstraction

Postby FichteFoll on Mon Jun 17, 2013 3:04 pm

lunixbochs wrote:
FichteFoll wrote:Edit: While I think about this, it could lead to terrible name clashes (e.g. "YAML" package and "yaml" Python module)...

So toss them in a package folder - you can import somethingunique.yaml instead of just yaml if you don't want name collisions


Yes, I could do that. I could just as well just name it "pyyaml" instead but that is out of the purpose because in real world Python you use "import yaml" and not "import pyyaml" or "import somepackage.yaml". So I currently see one main with two sub options:

1. Let the package manager wrap all these packages into their own dictionary. Probably preceded by some characters that are guaranteed to be the first in Sublime Text's loading precedence or at least show visually that there's not a package in this folder.
1.1. Let packages include these using "import _pc.yaml" for example. (ST3 only but no name clashes)
1.2. Have a "plugin" that adds the above directory to "sys.path" and thus enables plugins to write "import yaml". While this would work for both ST2 and ST3 it also reintroduces name clashes because "Packages/yaml" and "Packages/_pc/yaml" would again both map to "yaml" (example, the real YAML packages is written in caps which I think makes a difference).


Either way, this is not the right place to discuss this even though this small snippet would certainly be useful when distributable.
FichteFoll
 
Posts: 388
Joined: Fri Mar 16, 2012 11:49 pm
Location: Germany

Next

Return to Plugin Development

Who is online

Users browsing this forum: No registered users and 4 guests