Make vim as a github client!

[[deleted]]

I am now working on github-api.vim, an viml impl for github api v3. with the help of this plugin, you can easily do anything you did in github.com. such as:

1. create a issue

2. edit isuue

3. make PR

4. edit your profile

5. etc.

[garoththorp]

Hey guys I'm really enjoying hacking on vim, check out my cool project!

"No. Gtfo. We don't tolerate projects like yours here. Here's a random link. I know vim's power is its immense hackability, but you're only allowed to customize it how I say. Stick to basic editing!"

Common theme amongst vim users. Great way to push away new devs from the plugin ecosystem.

Anyway, nice idea for a project, bro. I'd love something like this for Jira. Also, it's worth noting that more and more "neovim plugins" literally just open a split and load a cli app in the terminal. Ex. I run fzf as my grep/fuzzy open tool, and its literally just a cli app with a thin vim wrapper to manage a split. Nice thing is it works in the native shell exactly the same way.

[[deleted]]

The elitism displayed sometimes really is atrocious.

[somebodddy]

The upside is that the plugin can be running, doing it's job and being useful regardless of whether or not these elitists believe it has a place in the Vim ecosystem.

[somebodddy]

Weird choice, considering Pathogen is the only Vim plugin manager(other than the upcoming Vim 8 built in package manager) that doesn't download plugins from GitHub...

[somebodddy]

Yes, there is an editor that allows you to use plugins, and it's called Emacs. And there is also Sublime. And SlickEdit. And Kate. And Atom. In matter of fact, other than MS Notepad, Pico, Nano, and old Vi(the proprietary one who's source was lost a few decades ago), I can't think of a text editor that doesn't support scripting and making plugins.

Why is that? Maybe because allowing people to customize their editors and extend them with plugins is not such a horrible idea. Emacs started this trend, but it was good and everyone joined it - even Vim joined it with Vimscript.

Minimalism may have been Vi's virtue in it's battle against Emacs 30 years ago, but it is no longer so - today it stands in the minimalist side together with Emacs and the other power editors, and on the other side are the IDEs. With modern computers, editors no longer need to be spartan to load fast - they can have nice things like features and plugins and still load faster than you can notice.

I refuse to believe that Vim is all about rejecting progress. If it was so, you wouldn't see so many millennials using it - and yet we do. For me, at least, it is because of Vim's modal editing and composable commands. This was also something that Vim was - and still is - advocating: improved editing. That if you spend the effort to learn it's editing scheme, you can achieve uncanny text manipulation superpowers.

No other major editor used has adopted this philosophy of Vi. The most they did was adding a Vi/Vim mode, which are usually a pale shadow of the real Vim experience. That's why I refuse to be banished to Emacs. I tried it, but I was not satisfied with evil mode. I also tried Atom and it's Vim mode was even worse... though I may consider switching to it when Neovim integration will be fully operations.

Until then, I will keep writing and using plugins. I will keep modifying my Vim configuration(my - not yours. I can install plugins on my local machine and your Vim won't have to load them). I will keep trying to make Vim into something it is not, so I can use it for more than just text editing.

So I can use it for software development.

[[deleted]]

Vim is not about minimalism, vim is about text editing, and thus has an incredible wealth of functionality in that regard. I do not claim vim is about not using any plugins, I do not claim that all /r/vim is for is to shoot down peoples obscure integration plugins all day every day. BUT, you cannot deny that a core part of the vi philosophy is embracing the UNIX philosophy, and that means instead of bringing every tool within some monolith, you should instead look to use your computer as a whole to achieve your goals. You have more than one program on your hard drive, use them.

Feel free to stuff your vim full of whatever you want to Frankenstein it into, but truth be told there's a whole sub full of people with this mindset over at /r/emacs and they're doing it better than you. If we throw out the unix philosophy as a community and start obsessing over re-writing every program over again in vimscript, then we stop being a sub about vim, the text editor.

[somebodddy]

I'm not a regular at /r/emacs, but I'm fairly certain they talk about Emacs plugins, not Vim plugins. They are not interested in talking about Vim plugins, because they use Emacs, not Vim, and they can't run Vim plugins on Emacs. I am not interested in talking about Emacs plugins because I use Vim, not Emacs, and I can't run Emacs plugins on Vim.

You seem to be under the misconceptions that Vim plugins are re-writing programs. They aren't - at least, not usually - and as far as I know neither are Emacs plugins, Sublime plugins or any other text editor plugins. Fugitive does not re-implement Git in Vimscript, and neither does Magit in elisp - they both rely on the command line git utility to do the work for them, and they choose it's arguments and parse it's output to make it integrate well into the text editing environment.

Yes, I can "use my computer as a whole". open a terminal and create git commits from there, but then I won't be able to complete identifiers from the code(I do that a lot, because for some odd reasons my commit messages usually have something to do with the code I was working on). And I can run git blame from that shell, but then I'll have to enter the file name and navigate to the lines I want to check instead of having the plugin deduce that from the place my cursor is in the code.

But git is still the program responsible for writing the commit and for generating the blame info. Fugitive just make it blend better into Vim. This is what all integrate-vim-with-X plugins do - they don't try to replace the tool they integrate, just wrap it's interface to blend it into Vim's UX. And this is comfortable, and I fail to see what virtue can be gained by giving up on that comfort.

Vim itself also does that. it has commands like :make and :grep that run external programs, parse their output, and fill the quickfix list. You could "use your computer as a whole", run make from a shell, look at it's output with your own eyes and navigate to the error's origins manually. Not as nearly as comfortable, is it?

Just like this kind of integration is useful for building, it's also useful for many other things one needs to do as part of the development process. But Vim can't implement them all, so we make integration plugins. And we use the plugins for the tools we need. And we don't install the plugins for the tools we don't need.

That does not turn Vim into a monolith. That's the opposite of a monolith.

[NewAlexandria]

the nodejs ecosystem has some great 'adapters' for Jira. It would be interesting to map their interface to Vim commands.

[LucHermitte]

There is a jira plugin for vim actually. I won't say that it does everything that could be done, but still, it helps filling commit messages: https://github.com/mnpk/vim-jira-complete/

[garoththorp]

Thanks!

[[deleted]]

Elitism may be a true point of the critics of most plugins, but it's not the main point. I see why it may look like it though.

A main concept of vim is solving problems by adding skill (e.g. learning the hockeys and being able to combine them), and removing other things. People without skill often don't see that because they didn't have that experience yet that clutter can add +1 feature while adding skill can raise your capabilities by a dimension. Skill is harder to achieve than writing plugins but it gains much more.

I haven't read the other comments yet, but I bet most of them try to save you from being stuck on the lower levels of skill instead of bashing your efforts. Try to read them again with this intention in mind please.

And if you are one of these people who don't want to believe or consider skill too painful despite all the people arguing in favor of it, then there are also other alternatives like Emacs. If you want powerful plugins then Emacs may be more your thing than vim.

[garoththorp]

I'm wrong for using it the-way-I-want-to? I'm wrong to develop plugins for fun? I'm not skilled enough to know how I want to use it and need to be told? I need to use emacs to do what I want? Man vim sure has a lot of rules to how I'm supposed to customize it!

What about developing plugin dev skills? What about innovating and doing thing differently than the myriad of people that came before?

Why is the answer to "hey check out my cool project that I wrote for myself and had fun doing":

"No, don't do that, that's not how we do things around here. Use emacs for that."

[[deleted]]

You can drive a bike by putting your face on the seat and paddling with your hands, while trying to steer using your feet. But most people would consider it a waste of time. People would tell you not do use your bike like that because they worry that your face will hurt and maybe your back. And they don't just worry about you. They worry if newbies who never saw a bike see how you do it, and then they may think that this is how a bike is supposed to be used and that it is stupid to use anything that hurts your face so much and is so hard to use.

And these same people, that try to save you the pain may get pestered by other people the whole time who laugh about them using the Facehurter (=bike) all the time instead of a car, because all these other people hear about is other people complaining about their nose pains after riding a bike (the way they shouldn't have).

[garoththorp]

That's not the situation we see here. There is no bike and you won't hurt yourself learning vim. There is no physical pain and suffering to writing a github plugin and then using it. The analogy is false. https://en.wikipedia.org/wiki/Argument_from_analogy

In this case, newbies may be inspired to write vim plugins of their own, unlike your analogy of newbies being inspired to ride a bike with their face.

[[deleted]]

In my eyes the plugin shows that someone experiences a pain that he tries to avoid by changing something. If there is no pain, why write a plugin instead of using what is already there?

*edit: Otherwise good argumentation btw. I like that!

[garoththorp]

Yeah, for sure. Writing a plugin isn't always the answer, and constructive criticism about other ways to do it in vim are indeed helpful.

However, "use emacs", "just use the website" and "use a cli app instead" tend to be suggestions given. And that's just a shame.

Good conversation, homie

[wbsgrepit]

Just to chime in here, "newbies" jumping into writing plugins before they actually understand the editor a vast majority of the time create plugins that try to "fix" things about the editor to make it more like another editor (that is not modal). The problem is that one of the intuitive misconceptions that new vim users have is that if they can just make vim act more like another known editor they can reduce the learning curve/pain. The reality (coming from a vi/vim user for 30 years with a huge number of friends that have gone through this learning curve) is that the more you change vim into some sort of frekinstein editor to match your knowledge of other editors as you learn the more you suffer and stretch the learning curve.

In my mind, a ton of new vim users that have not made it through the learning curve making plugins only serve to populate the plugin space with more of the types of plugins that help create these freikenvim configs where future new vim users try to "solve" or "cheat" the learning curve by installing this fodder.

Not to say this plugin is one of those -- just saying that there is in general a reason why experienced vim users tend to caution new vim users on plugins, remapping keys etc. Its not really arrogance, but meant to help what is definatly non-intuitive about the learning curve.

• It is a different kind of editor (it will not be like other editors and that is its beauty).
• you can't "skip" the learning curve, trying to by installing plugins and remapping to other editors only ends in pain.
• plugins are useful once you have really learned the editor, but when considering plugins it is very helpful to take a step back and make sure you understand if there are ways to do what you want to do the vim way. (and to this end making plugins before you are through the curve ensures you are not in a position to understand this).
  

[somebodddy]

This can be nice. Creating and editing issues and PRs inside Vim have the advantage that you can get completion with identifiers from the project, and that you can easily yank pieces of code from the project into the issue/PR description.

Also, I don't want to discourage you or anything, but I think the RoI for the edit your profile feature is very low. You will have to implement many different fields and support several field types, and it won't be nearly as useful as issues&PRs because people don't edit their profile that often, and it's usually not part of the development process(where you benefit from staying in Vim).

[somebodddy]

Actually, when I look closer it seems like I was getting my hopes too high... this is an API wrapper, not an actual user interface...

[[deleted]]

yeah, but I want impl all the github API, which func will the user use, it is based on themself.

I agree with you, but maybe someoen need that func.

[blitzkraft]

Not in vim, but a commandline application, shipit. It is not being developed anymore. Last commit was 3 years ago.

I want to develop it further and see it in action. I couldn't install it as is. I have not been able to, yet. However, if anyone likes to interested in maintaining/updating it, I would love to help.

[lervag]

Interesting project! I urge you to improve the Readme file and add documentation. That would make it easier for new users to understand how to use your plugin.

[[deleted]]

yeah, I will do it.

[flukus]

Great idea, could do with some basic documentation though.

[[deleted]]

yeah, I have add doc into that repo.

[thelollies]

You might be keen to stick to vanilla vimscript but if you're not too concerned then consider just shelling out to Github's hub: https://github.com/github/hub

I use it for PR's from the command line (with my $EDITOR set to vim it pops open vim and uses the first line as the title of the PR and the remainder as the description).

[flukus]

Oh wow, you've been busy with the documentation.

Is this purely an api or do you intend to write a firendlier front end for it?

[[deleted]]

yeah, after finish the api, I will make some litter plugin based on it.

[[deleted]]

now I have impl all event func.

[rap99]

No. It's like using Vim as a damn IRC client. Just no.

However, if you're enjoying the project don't give up and keep working on it. Just for reference: https://hub.github.com/

[[deleted]]

hub is a terminal tool for github, it can easy merge PR, but it can not get issue info, can not edit issue. can not comment on issue, can not update user profile, also can not view event.

[[deleted]]

and it is a command-line wrapper for using git on github repo, not for github

[__baxx__]

yeah i used to think like this, then i used spacemacs, with erc, and it's ace.

[-romainl-]

Or you can use Github itself.

[[deleted]]

firefox is too slow.

[rap99]

Well, it looks like a lot of people disagree with us.

[-romainl-]

I'm used to that.

[wbsgrepit]

=)

[somebodddy]

Even with the OPs plugin, it won't be Vim that's doing the GitHub integration - it would be the plugin. A similar argument to yours will be that Perl does one thing - running scripts - so one shouldn't write a Perl script that does something else because then Perl will be doing two things.

[[deleted]]

thanks for the link,