Sublime Text 2 plugin to show git commit history for selected line(s) of code (github.com)
I created a Sublime Text 2 plugin that lets you see the commit message history (messages & file stats) for selected line(s) of code with a simple shortcut: cmd+shift+m on Mac, alt+shift+m on Linux/Windows.<p>Inspired by this earlier post (https://news.ycombinator.com/item?id=7202146).
44 comments
[ 2.8 ms ] story [ 104 ms ] threadScratch that. There are a couple of API changes I believe, but I should be able to fix these too.
Edit: I can't even get the command to work for me.
I was about to push my changes even though the command doesn't work for me.
When people extend their text editor (be it sublime, vim, emacs) with all these (often outdated) plugins i am left wondering why there is still so much hate for IDEs ? I use IDEs from Jetbrains for most of my stuff and they do all these things oob with a consistent UI and are well tested. Why would i want to fiddle together my text editor with one-man plugins that often dont even work 100% ?
I love Sublime etc. for what it does best, which is editing text, but i still use IDEs for most of my coding so i dont have to think about configuring my editor all day.
Jetbrains do go some way towards addressing the point you raise, with their language specific editors. I use a broad enough cross-section of those languages that I stick with IDEA ultimate, but my experiences with PyCharm, RubyMine and WebStorm have been nothing but positive.
Qualifier: All IDEs, and especially IDE interfaces, are not created equal!
Note that I'm talking about personal use. If I were a full time developer, I might force myself into an IDE.
Command-shift-a, type some letters. Done :). It's pretty much like Command-shift-p in Sublime Text.
Of course, the result won't be as light as Sublime text, because it is already a Java IDE :).
Also, I don't really see the point. I start or restart my IDE (IntelliJ) one time a week. So, it's not really the startup time that matters. Once started, IntelliJ is fast on all my machines (including my work iMac, which still has spinning platters).
So I assume you don't use your IDE for modifying local configuration files, or taking random notes, then. Startup time (and having multiple lightweight instances) is important in these cases.
People replace Notepad/vi with Sublime Text, in order to get all the benefits and power they're used to in Sublime Text when editing even the most mundane or ephemeral document. You can't really do that with IntelliJ.
Because most (all?) IDE's are slow. I've used Eclipse for years. Have also tried Idea and dabbled with NetBeans. I don't like their slow operation, nor they clunky UIs. And I don't find their speed, even today with an SSD and 8+GB of RAM, good enough. Tolerable might be a better word.
Plus their text-editing abilities leave a lot to be desired too.
>Why would i want to fiddle together my text editor with one-man plugins that often dont even work 100% ?
Well, my experience with IDEs is that their plugins and core functionality is not all roses either.
This plugin is maybe 30 lines of code.
With 1,988 packages and 1,436 authors(in Sublime's case) they turn into customised IDE's that 2.15 million package users are using. If there is a bug, you can submit a patch, or fork a plugin - and people do. This means plugins can be fixed quickly and easily by many people if there is a need. Plugins compete against each other, and cooperate with each other in the same space.
The core stays simple, optimized, highly crafted, and stable. The innovation, and quick implementations of solutions to new problems happen inside plugins. High levels of integration is possible, and does happen within the plugins.
Check out Arduino-like, which turns Sublime into an Arduino IDE https://sublime.wbond.net/packages/Arduino-like%20IDE
An IDE is simply loading all the plugins at once, even the parts you don't need.
I also hardly no anyone that works with C#, Java or Objective-C without an IDE, because you lose a lot of productivity. I enjoy working with ST in JS/php and other dynamic languages though where intellisense etc does not matter too much.
For me its all pretty simple, ides in Linux or Mac get in my way. That is the only reason. Sublime, vim. They take learning, yes you have to spend hours configuring over their lifetime of usage, yes you have to have a core understanding about how they work. But its worth it. They're fast - like blistering fast. Once they're setup to my liking: they get right the fuck out my way and take a back seat to writing code. They do exactly what I expect, and they do it exactly how I told them to do it. (Can you tell I'm a developer yet) They dont bug me about my syntax mid thought, they wait till I'm done and save or consciously call on them for a clean up.
Also as a personal opinion and an anecdotal one at that: eclipse and netbeans are pretty ugly, menu systems and configuration is done in XML. Why would any human want anything to do with that kind of thing? BTW I'd have something to say about xcode but its still loading...
- Which classes implement this interface ?
- What was the namespace of that class again ?
- take me to the definition of this (in a different file)
- show me uses of this function across the entire codebase
Yes you can also do all of that with some nifty search action in Sublime, but i don't think its as efficient.
When you work for example with a node or angular project that doesnt matter, i am happy with Sublime there, but i currently built a huge application on top of symfony2 in php with tons of third party libraries and in that case it just doesnt work well.
I hate to be one of those people who say you're doing it wrong but it sort of sounds like it. I manage just fine with cmd+p and large projects.
I would have to suggest installing a few plugins there are quite a lot of "perfect php sublime setup" blog posts around to give you ideas.
We have a large symfony install and a large api I work on and never really feel "I wish I had an ide" I guess to each their own. Sublime and vim are really what you make it. As for any tech, ides included you have to master them before you can get the most out of them.
If coding in a text editor causes you to think about configuring your text editor "all day", then you should definitely use an IDE. (Or see a therapist?)
I tweak my Emacs configuration about once per year.
Because Vim ,Emacs or Sublime are easy to extend or hack. Try to extend VisualStudio or any Jetbrain IDE...
Because lightweight editors can open huge files without issues,try to open a 10 mo data/sql file in VS ... no problem with ST or VIM.
Because they run on older hardware.
Now you say some plugins are outdated , but it's easier to fix 20 lines of python than a C# or java project.
To sum up,if I want a new feature in ST or Vim I can code it myself quickly,I dont need to wait/pay for a new version of the editor.
Both are useful because they're universal for all languages, simple, quick, and pretty much are guaranteed to have a high base-line level of quality. vim is also useful because it's available on virtually every Unix machine, meaning I can use it on remote machines I've ssh'd into.
With these editors, I also think there's a certain pleasure in starting from a mostly blank slate and installing only the plugins you're personally interested in. The result feels less bloated because it's optimized for precisely one person: you.
In statically typed languages, that's often a tradeoff I'm happy to make; IDEs give you a lot more information than text editors in that case. But in a dynamically typed language, where I'll need to run the program to find errors anyway, the lag is just a nuisance.
As I've primarily worked in dynamic languages for the last several years, I've had no desire to put up with IDE lag for minimal gain.
IDEs can be great when they understand your code well enough to do things like renaming all uses of a function, refactoring, applying code-style formatting, highlighting errors in code (I've caught a lot of errors from co-workers that use ST, while my IDE clearly highlights the bug), etc.
In cases where code is harder to analyze, like JavaScript, IDEs can be far less useful.
Furthermore, I select my plugins carefully with future-proofing as my number one priority. This means that I do not use (or at least certainly do not rely on) software that I am not confident will stick around at least until I retire or software that I could not reproduce if necessary. I am confident that Vim will stick around that long and I am confident that the plugins which I use with Vim will either continue to work, become obsolete when Vim absorbs their ideas, or are tools that I could recreate myself should future vim updates ever break them (this has not been happening so far).
In some cases, these constraints prove problematic. One example is web browsers. I have zero confidence that Firefox or Chrome will exist and/or be recognizable in even 10 years. I therefore do not rely on any special Firefox or Chrome functionality, particularly any plugins or extensions. Additionally I split my usage of the browsers evenly between the two in an attempt to ensure that I do not become reliant on Firefox or Chrome specific behavior or abilities that I may lose access to in the future.
My problem with Firefox/Chrome is a problem that I have with IDEs. They come and go, they change and "improve" over time in ways that are not backwards compatible from a UX perspective. I want none of that. A carpenter does not worry about the interface to his tablesaw changing in 10 years, forcing him learn a new set of skills to experience the same functionality. That sort of stability is what I strive for.
Edit: As for text editor plugins typically being out of date... I just checked. The most 'out of date' plugin that I have is actually just my colorscheme, having it's last commit on Fri Mar 2 14:59:51 2012 -0600. All of the rest have had commits in the past 6 months. A quarter of them have had updates in the past month.
I use certain software right now for programming that is completely different than what I used even two years ago. I work in completely different technology stacks and completely different tools.
Why would restrict myself to only using a set of tools that I KNOW will existing 20-30 years? What happens when some breakthrough technology comes that comes with it's own stack and toolset? Do you ignore it or adapt?
I actually enjoy switching between various technologies and tools. You get a different perspective, learn new things, get out of the rut and into a new challenge.
I really hope that in 3 years I'm not using the same tools I am using today.
> I actually enjoy switching between various [...] tools
I guess that's the difference between you and I. I don't, at all. I find satisfaction in what I do, not how I do it. Learning new tools for no reason other than I picked the wrong one to learn five years ago and the developers of my old tool packed up shop is something that I think is to be avoided at all costs.
And to be clear, I am more than willing to pick up knew technology that I believe will have significant staying power. Git is an example; whatever version control system that will replace it in 10-15 years will look significantly like it. Git's CLI interface is not an example; I know how to do what I need to do in Git, I know how Git works 'under the hood', and I know how to teach myself the rest on demand, but I do not spend time memorizing the intricacies of the various flags to the various git commands. That knowledge will likely become useless in 10 years or less.
* a giant that IDE that wants to own my code and my entire workflow and
* a little plugin for a text editor that shows me "git blame" output
Would you say that I should go without syntax highlighting because that's one step on the road to IDEs? No, of course I can pick the features I want a la carte.
Besides, what's it to you? If you like it, use it, if you don't, don't use it. Why criticise in the first place?
Will install it manually, seems a great trick!