https://github.com/WarWithinMe/xVim -- this basically lets your editor have "vim mode" for free.  It's awesome.

Like (S)FTP(S) support, dedicated applications usually do a better job.  SourceTree (made by the Bitbucket folks) is amazing (staging sub-file chunks is great!) and even the GitHub application is pretty spiffy.  Limited integration, like some way of seeing if a file is 'dirty', OTOH, would be a nice reminder.

(If you spend time in a terminal, you can also get some nice shell integration for watching the status of whatever repo your CWD is contained within.)

+9001 -- the difficulty is that Python is highly dynamic, and even static completions (stdlib functions) would be dependent on the version of Python in use.  I use Pypy, as an example, and it has a number of additional features over standard Python.

If this is implemented, it'd be nice to pick a specific color theme to print using, or to print without formatting.  Most of the rest of the settings (wrap, etc.) could be inherited.

With quotes: there's also the concept of selecting text and pressing ' or " or ( or [, then wrapping the text in those symbols.  Can make sense for other symbols depending on active language.

I like task isolation in the apps I use.  A dedicated file transfer application can pretty much always trump file transfer integrated into other software.  For file transfers I use version control software (like all developers really ought to ;) or ForkLift.  Transmit is also quite excellent.  Both of the dedicated FTP(S)/SFTP apps support change notification or are able to keep trees in sync.  There's also the ultimate solution of mounting your remote filesystem: why "transfer" files when you can literally just modify them remotely?  (Both of the mentioned packages support configuration of FUSE graphically for this purpose.)

Automatic code folding ("focus mode") is also really handy; collapse all possible blocks of code except the one the cursor is currently in.  Track the cursor and automatically unfold/fold as you go (or search, jump to symbol, etc.)

You can avoid the sandboxing requirements by bundling the CLI script as a .pkg installation package; the preferable location to install the script (or binary if you go that route) would be /usr/local/bin.  The user wishing to have such a script would select an application menu item to launch the installer.

My own workaround has been to simply associate the relevant code files with the app, and run open filename