One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
andrewbrookins.com
One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
1–10 of 41 posts
Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#2Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#3Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#4What i think he really missed in features though:
- VCS integration is really really good
- Plugins for the Atlassian suite (never open Jira in a browser again!)
- virtualenv support
- remote debugging and execution and uploading support
- vagrant support
Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#5I can only agree, PyCharm ist really great work by JetBrains, i love it. What i think he really missed in features though: - VCS integration is really really good - Plugins for the Atlassian suite (never open Jira in a browser again!) - virtualenv support - remote debugging and execution and uploading support - vagrant support
The only outstanding gripe I have is the lack of full PyQt support in the autocompletion / intelligent import features. I know it's a hard problem and there are hacks, but if they could fix it for good it'd make it The Only True Python IDE for me.
Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#6http://www.reddit.com/r/Python/comments/182siy/pycharm_27_is...
Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#7Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#8For those wondering, us Emacs creatures use Rope + ropemacs + rope-mode to achieve the same thing. Vim has access to the same tooling more or less.
> Rope-based completion was always unreliable, slow or both.
I haven't used rope. Is the author wrong about this?
Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#9Unless they fix their 64bit Linux version [1] I'm not bothering try it out again and give up within a few minutes. http://www.reddit.com/r/Python/comments/182siy/pycharm_27_is...
-Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
to the pycharm64.vmoptions file.Re: One Year Later: Review of PyCharm 2.7 from a Vim User’s Perspective
#10For those wondering, us Emacs creatures use Rope + ropemacs + rope-mode to achieve the same thing. Vim has access to the same tooling more or less.
I really like Jetbrains products though, and when I am on Windows those are my goto tools as I don't have the UNIX user space to leverage alongside Emacs or VIM.
They provide a great environment for those languages that don't have great support outside of commercial IDEs or for people turned off by Emacs/VIM.
My first experience was using IDEA for Java (both VIM and Emacs support for Java is an area where they are weakest somewhat surprisingly) and I was very happy with IDEA, so I tried PyCharm later on when I was on Windows and using Python there.
However, Emacs makes use of Python's REPL much more fluently than what I've experienced in PyCharm where the IDE has no interaction with the REPL outside of user engagement.
PyCharm in comparison seems entirely ignorant that it has a REPL it can exploit and integrating tightly with it would pay dividends.
Coming from Emacs where REPL integrations tend to have at least some sense of intelligence about them this was jarring.
PyCharm's intentions though are also very nice and isn't something I've found in Emacs or VIM to the same extent.
The IDE still has the same trait I've seen in Eclipse, VisualStudio, XCode, and Jetbrains' products though where it makes determining what the project entails into an overly complicated affair though, an area where VIM and Emacs have less red tape to get into.
There seems to be a great deal of improvement in that area for tools to get into where they are smarter without requiring so much user facing bureaucracy up front.
On one hand we have Emacs and VIM that largely pretend there is no such thing as a project and that tools could perform actions on that as a unit.
Then on the other side IDEs want to recognize that a project is an actionable unit and that it is a unit but then engage in 20 questions just to get started on a project and even after that get easily confused when moving files around.
Anyways, as far as IDEs go, Jetbrains' products have been the most enjoyable to use.
I do wish they were full open sourced though so that contributing improvements voluntarily wasn't a comparatively precarious trade off compared to VIM or Emacs or whatever open source tools you use.
Also, I wish IDEAVim was a lot nicer support of VIM's features than what it currently has so that I didn't have to want for some functionality at times.
Both the Emacs and VIM or typical IDEs have a lot of room for improvement in general though, tooling could be a lot nicer and homogenous across languages to the extent possible.
I really wish anyone would run with Bret Victor's idea of closing the feedback loop in programming (http://vimeo.com/36579366) adamantly and also implement Douglas Crockford's idea of scope based coloring everywhere (https://www.youtube.com/watch?v=dkZFtimgAcM), the latter of which I really want in functional languages like Haskell/OCaml.
Those two alone would add significant utility to the available tools.
After seeing Crockford's scope based coloring idea syntax based coloring seems incredibly superfluous even though I use it myself.
It really feels like we are in a tooling stone age with a great deal of retreading and regression in some respects despite having a lot more man-months thrown at the area.