Home Download Buy Blog Forum Support

Porting to ST3

Porting to ST3

Postby jbrooksuk on Mon Mar 25, 2013 11:53 am

I'm looking at porting my Sublime Evaluate plugin to ST3, and after reading the documentation for porting, I'm none the wiser.

I have a sub class of sublime_plugin.TextCommand which edits the view (now restricted?) but I have no idea how to change it. I want to attempt it myself, but I have no idea what changes need to be made.

On OSX I've ran 2to3 -w . which didn't seem to do anything either.
jbrooksuk
 
Posts: 765
Joined: Sun Apr 11, 2010 10:37 am
Location: England


Re: Porting to ST3

Postby jbrooksuk on Mon Mar 25, 2013 12:28 pm



jbrooksuk wrote:and after reading the documentation for porting, I'm none the wiser.


Yes, but it didn't really help me.
jbrooksuk
 
Posts: 765
Joined: Sun Apr 11, 2010 10:37 am
Location: England

Re: Porting to ST3

Postby jbrooksuk on Mon Mar 25, 2013 12:40 pm

Turns out, all I had to do was comment out begin_edit, well I thought it was, but now when I continue typing my cursor is left at the last edit position. What the?

Weird, moving self.view.end_edit() to just after when I edit the stack works. Oh well...
jbrooksuk
 
Posts: 765
Joined: Sun Apr 11, 2010 10:37 am
Location: England

Re: Porting to ST3

Postby sapphirehamster on Mon Mar 25, 2013 7:32 pm

You should not manually call end_edit(). It is called for you when your TextCommand exits. See the code in sublime_plugin.py.
sapphirehamster
 
Posts: 88
Joined: Sun Jul 01, 2012 11:19 pm

Re: Porting to ST3

Postby jps on Mon Mar 25, 2013 11:44 pm

You get an edit object passed in to a TextCommands run() function. This is used to encapsulate all the modifications that are done by the text command into a single undo group. You can pass edit objects to other functions, but it doesn't make sense to store them in objects, pass them to other threads, or pass them to set_timeout calls. When the run() function of the text command returns, the edit object should never be accessed again: it wouldn't make sense to try and group the modifications into the same undo group, as other undo groups may have been created in the mean time.

In S3, using an edit object after run() has returned will result in your insert/erase/replace calls silently failing. I'll change this so an exception is thrown, making things a little more explicit.

begin_edit() was removed from the S3 API because it was too easy for plugins to call begin_edit without a matching end_edit, or to call begin_edit and expect the edit object to be valid over time, and leave the undo stack in an invalid state.
jps
Site Admin
 
Posts: 3067
Joined: Wed Mar 19, 2008 12:33 pm

Re: Porting to ST3

Postby sublimator on Tue Mar 26, 2013 4:09 am

In other words, Sublime Text is a nanny state, and we are its hapless moron inhabitants, unfit to wield sharp knives.
It is better to remain silent and be thought a fool, than to speak out and remove all doubt
sublimator
 
Posts: 649
Joined: Thu Mar 20, 2008 5:41 am

Re: Porting to ST3

Postby tito on Tue Mar 26, 2013 4:31 am

I like that poetry :)
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: Porting to ST3

Postby jps on Wed Mar 27, 2013 12:41 am

castles_made_of_sand wrote:In other words, Sublime Text is a nanny state, and we are its hapless moron inhabitants, unfit to wield sharp knives.

Well, the real-real reason begin_edit was removed is that it's easy to get it wrong, and when it does go wrong, it's not obvious to a user what's gone wrong, or what caused it. An alternative would have been to find a way where this situation could have been detected and reported to the user, but getting rid of begin_edit results in less code, and run_command(...) is a reasonable substitute.
jps
Site Admin
 
Posts: 3067
Joined: Wed Mar 19, 2008 12:33 pm

Re: Porting to ST3

Postby jbrooksuk on Wed Mar 27, 2013 9:12 am

jps wrote:
castles_made_of_sand wrote:In other words, Sublime Text is a nanny state, and we are its hapless moron inhabitants, unfit to wield sharp knives.

Well, the real-real reason begin_edit was removed is that it's easy to get it wrong, and when it does go wrong, it's not obvious to a user what's gone wrong, or what caused it. An alternative would have been to find a way where this situation could have been detected and reported to the user, but getting rid of begin_edit results in less code, and run_command(...) is a reasonable substitute.

I for one appreciate your decision to make our lives easier Jon. Thank you :)
jbrooksuk
 
Posts: 765
Joined: Sun Apr 11, 2010 10:37 am
Location: England

Next

Return to Plugin Development

Who is online

Users browsing this forum: Majestic-12 [Bot] and 3 guests