Earlier quoted context omitted.
You may be interested in magithub (it’s on MELPA).
Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.
Putting the I back in IDE
131–140 of 152 posts
Re: Putting the I back in IDE
#132Programming like 1980! At least has colors instead of having everything in green. Really the extent people go to avoid using modern developer tools.
And so they should when modern is not as efficient as the alternative.
For me, efficiency is a synonym of Xerox PARC’s vision of computing, not improved teletypes.
Re: Putting the I back in IDE
#133This is pretty cool. Although, on large codebases a la facebook or google size, I would think having a copy of the repo per branch might be intractable - also, somewhat unnecessary since one can just switch branches...
The trouble with 'just switching branches' is that it quickly gets very complicated, if not impossible, without either checking in incomplete code or stashing it.
Re: Putting the I back in IDE
#134Earlier quoted context omitted.
> we developers are stuck No, only a subset is "stuck" not using the most fancy and shiniest. Janestreet seems to be interested in this particular subset. Maybe they found a correlation between robustness and efficiency, and not fooling around with tooling for the sake of optics too much. After all, finding correlations is what they do. If you want to argue "behind times," argue inefficiency, but I think you will com…
> they also get to weed out developers whose opinions would make for a poor fit Wow, that's aggressive. Such a policy would "weed out" people like Alan Kay or Bret Victor over a trivial difference in opinion about UI efficiency. Are you sure creating a monoculture of thought around this single issue makes sense for a company?
If you do Ocaml, you do emacs, if you do emacs, you do GNU (or some other sane unix). Anything else means you're stealing your own or company time.
> a trivial difference in opinion about UI efficiency.
That's one way to look at it. Another is that the quest for UI efficiency is a timesink and an upgrade threadmill susceptible to fashions. The counter to that is to learn it once, learn it well, and be done with it for the rest of your career. Emacs fits that profile just about perfectly.
Re: Putting the I back in IDE
#135Earlier quoted context omitted.
Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.
I wrote my own CLI (in C, just for the hell of it) for JIRA. It’s the server that’s the problem. Responses take seconds to return over my 100Mb/S connection. Horrible.
Re: Putting the I back in IDE
#136Earlier quoted context omitted.
Could go even easier by installing Git for Windows and using the included bash prompt. It's a MinGW environment with very good factory configurations. It won't let you apt-get and run any old app, but it does get you all the goodness of a bash prompt and all the standard Unix command-line apps. All right there in Windows, without having to also learn and get comfortable in a new operating system.
If he has Windows 10 he could even go WSL, forgot about it.
Re: Putting the I back in IDE
#137Re: Putting the I back in IDE
#138Earlier quoted context omitted.
> they also get to weed out developers whose opinions would make for a poor fit Wow, that's aggressive. Such a policy would "weed out" people like Alan Kay or Bret Victor over a trivial difference in opinion about UI efficiency. Are you sure creating a monoculture of thought around this single issue makes sense for a company?
For Janestreet? Definitely. If you do Ocaml, you do emacs, if you do emacs, you do GNU (or some other sane unix). Anything else means you're stealing your own or company time. > a trivial difference in opinion about UI efficiency. That's one way to look at it. Another is that the quest for UI efficiency is a timesink and an upgrade threadmill susceptible to fashions. The counter to that is to learn it once, learn it…
Re: Putting the I back in IDE
#139Earlier quoted context omitted.
True, my comment was a bit mean/dismissive. People do have to stop chasing the trends, cause that's a full time job. And it's easy to not notice productivity gains you've missed for years. In my opinion Emacs/Vim: - except for some specific roles: Emacs -> Lisp development, Vim -> to be honest, not sure what to say, what is Vim's strong suit? except for core editing commands - and unless you put in a ton of hours int…
To keep it brief (mobile keyboards suck): Vim’s strong suit is editing text. That’s all. But, and it’s a big but, that’s enough. As a vim user, I have the rest of the shell and browsers for the rest of my development environment. Version control: git. Building and testing tools: make (or similar). Debugging: gdb, pdb, the browsers debugger. Lots of single purpose tools that operate cleanly and so integrate into my pe…
Re: Putting the I back in IDE
#140Earlier quoted context omitted.
I wrote my own CLI (in C, just for the hell of it) for JIRA. It’s the server that’s the problem. Responses take seconds to return over my 100Mb/S connection. Horrible.
What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...
If there’s nothing suitable it could be a fun thing to hack on! :)