
Putting the I back in IDE - yminsky
https://blog.janestreet.com/putting-the-i-back-in-ide-towards-a-github-explorer/
======
iBelieve
That's really neat. I love the idea of doing as much as possible from text-
based UIs, especially using Emacs.

I see this is built on top of Emacs, but it looks like it's entirely custom.
It would be interesting to build something like this integrating with standard
Emacs features. For example, merge requests could show up in an orgmode agenda
list, and reviewing the merge request could be done through a layer on top of
magit. You could also go a step further and offer an orgmode-like interface
for working with tickets/issues.

Outside of the text-based UI world, GitLab has a neat feature called Review
Apps [0] that lets you preview branches/merge requests for web projects, but
this takes things a step further by letting you make changes and run locally.

[0] [https://about.gitlab.com/features/review-
apps/](https://about.gitlab.com/features/review-apps/)

~~~
confounded
You may be interested in magithub (it’s on MELPA).

~~~
pimeys
Is there something similar for Bitbucket and JIRA? We're stuck with those and
the web UI's are very slow.

~~~
girvo
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.

~~~
pimeys
What are the good alternatives for JIRA then? Would be nice to command all of
that from Emacs...

~~~
confounded
I remember seeing one, though it may not have been under active development.
Maybe search MELPA/Github.

If there’s nothing suitable it could be a fun thing to hack on! :)

------
Finster
"Every branch of every repo gets its own sandboxed directory. Your revision
history in each branch, including uncommitted stuff, is persisted, as are
build artifacts. When you switch contexts, each project is just as you left
it."

Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?

~~~
rasjani
Or git worktree

~~~
sjakobi
Oh, I had never heard of that command before. Does it work well, i.e. does it
improve your workflow?

~~~
lozenge
I generally have a worktree to develop in, and one for code reviews. So I can
leave some indexed and some uncommitted changes in the first one, open a
second IDE against the second one and use "find usages", "go to
implementation" and other code navigation features missing from GitHub.

You can also create a worktree for a quick experiment (eg how many conflicts
when I merge X and Y) and just rm it when you're done.

Sure, all these things can be achieved with git stash and git reset... but
they are both difficult to keep track of and will cause your IDE to run its
expensive reindexing.

It's kind of like how you could use pushd/popd and open subshells to work in
one shell, but people prefer to just open another terminal window.

------
pavlov
If you walked into an office and saw them using 1984 equipment — fax machines,
landlines and Rolodexes — you'd think the company is hopelessly behind times.

Jane Street is a cutting-edge technology corporation, but their internal tools
use 80*25 text-mode UIs just like the ones you'd find on a 1984 IBM PC/AT.

It's not the company's fault: we developers are stuck in the tar pit of an
unfortunate local maximum with all these tools built around text streams
printed into a window that emulates a late '70s terminal.

~~~
confounded
Would you prefer a web app? Why?

~~~
pavlov
No, HTML is limited in the same way as terminal emulation: it's not the right
tool to describe UIs and interactions.

I'd like to see more progress made in real desktop interfaces.

~~~
pjmlp
> I'd like to see more progress made in real desktop interfaces.

Come to the macOS/Windows developer culture.

------
augbog
It sounds really cool but also very opinionated workflow. Not to say I don't
agree with it but I can only imagine the amount of effort making this whole
workflow was also what went into defining what that workflow was.

There are a lot of workflows and I personally don't think it's on an IDE to
enforce that. Yeah sure it's "integrated" but it's to the extreme which I
somewhat disagree with.

If their workflow and emacs scripts were open sourced, I could actually try it
and watch my tongue but since it's all proprietary all I can really say is
good for you, thanks for sharing but I probably wouldn't use it myself.

~~~
titanomachy
It's probably OK at a company, though. Teams that I've worked on tend to
converge on pretty similar workflows with respect to pull requests.

------
cromwellian
I think they just described IntelliJ + Contexts and Tasks feature.

~~~
fsloth
Or Visual studio.

------
fsloth
Visual Studio does everything within the same window (source code management,
code review, diffs). Yes, it's great. It does not need any 'new' paradigm,
that's the standard operating modus.

It's a good thing this ideology of tools that simplify the process is
spreading. But it's not novel.

This article sounds like the author never used Visual Studio.

~~~
oblio
You'd be surprised. Our domain has so much snobbery and elitism that it's
entirely possible that a developer tried 1 (one) IDE, maybe decades ago,
didn't configure it at all (or couldn't, at the time) and decided for all
eternity that IDEs are bad.

It's quite funny sometimes when you show someone modern functionality in a
modern IDE and they have to accept that the people making IDEs are, basically,
not all morons (which is a sort of hidden assumption for many of these
attitudes).

~~~
inceptionnames
I recently switched over to Visual Studio Code and even though I previously
had a bit experience with it, switching over was frustrating. It takes time to
change your work flow, to set up the IDE as needed, to get plugins and what
not fine-tuned.

Now I can't imagine working without Visual Studio Code because all those
seemingly little features add up and what do you mean I can seamlessly use Git
to manage my code or easily rename variables and functions without breaking
stuff WHAT

~~~
bunderbunder
I'm a fairly light user of VSCode, so I may be wrong here, but the integration
goes even deeper in Visual Studio.

It lets you view a pull request's changes right there in a standard IDE
window, so that you can get full code navigation features during code review,
including stuff like peeking the docstring or implementation of any functions
the code references. Or, if you notice something amiss while reviewing your
changes before submitting a pull request, you can just make the change, re-run
tests, and commit, without ever leaving the diff viewer. Or being able to just
toggle gitblame annotations on and off right there in the editor.

It's nothing worth switching platforms or programming languages over, but,
since switching away from .NET and seeing the gulf between the level of
seamlessness you get out of Visual Studio and what's available in other IDEs,
I can now see why they've come to have such a poor reputation. Visual Studio
isn't exactly lightweight, but it manages to pack in enough cool tricks to
justify itself.

(Until you install ReSharper. Then it becomes as memory-hungry and unstable as
everyone else.)

------
DiabloD3
So what does this do that IntelliJ and other IDEA-based IDEs can't do for me?
They already have Github API integration plugins.

~~~
crispinb
I think (as @cromwellian pointed out), IntelliJ has most of this covered with
tasks, contexts, shelving, etc. Better, possibly, as it has quite a number of
built-in tracker integrations.

Not sure about the code review aspect though. I haven't tried any of the code
review plugins (gerrit etc). They could be good if they integrate with diff
viewer, as it is IMO one of IntelliJ's best features.

~~~
pgwhalen
I agree on the diff viewer.

Check out Upsource for code reviews. It's pretty much exactly what you would
expect from a JetBrains-built code review tool.

~~~
crispinb
I've glanced at Upsource out of curiosity only (I mainly work solo). It looked
good of course. I was commenting about code review here with regard to the
Jane Street article -- it does seem IntelliJ does nearly everything their
custom tool does out of the box.

------
nartz
This 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...

~~~
oneeyedpigeon
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.

~~~
nartz
Is stashing an issue?

------
yueq
this is a HCI problem. I dont think text is better than IDE or web-based code
review or branch management. I'm a vim user and i have to say making
everything in one terminal looks cool but really not that intuitive..

------
iLemming
Magit combined with Magithub already offers much of what's described in the
article and there's a lot on the roadmap. Jonas and Sean are doing
mindblowing, amazing work in these projects. I've seen many different UI
shells for Git - everything else feels childish compared to what's possible in
Emacs. I learned Git mostly by trial, error and reading man pages, but only
after a few months of using Magit I've become truly dangerous.

------
caniszczyk
check out Eclipse Che: [https://eclipse.org/che/](https://eclipse.org/che/)

------
amelius
> Code review happens entirely within the editor. You’re fed a series of
> diffs: one keystroke to approve, one keystroke to start editing. Dive in,
> make your changes, leave comments for the author, push, and move on.

But can the reviewer easily run the code they have just edited?

And does changing branches require a full rebuild?

~~~
orbifold
They also build two build systems in ocaml
[http://jbuilder.readthedocs.io/en/latest/](http://jbuilder.readthedocs.io/en/latest/)
and jenga, which support incremental fast compilation, so the answer is most
likely yes.

------
_ZeD_
come on! just another couple of years and we can have eclipse again (I still
miss the integration between the tasks, the revision system, the code and the
autodeploy stuff I had in the '90 when I was a junior dev...)

------
pjmlp
Programming like 1980!

At least has colors instead of having everything in green.

Really the extent people go to avoid using modern developer tools.

~~~
aspett
And so they should when modern is not as efficient as the alternative.

~~~
pjmlp
Efficiency is on the eyes of beholder.

For me, efficiency is a synonym of Xerox PARC’s vision of computing, not
improved teletypes.

------
patientplatypus
This is cool, I guess. Personally coding in a terminal like window for me
would be awful - I like using my mouse to navigate among folders and save
stuff etc in Atom/VSCode like environments. Plus, how often are people
switching branches of code that the number of key strokes for git becomes a
problem? Seems like an overengineered solution for a very niche audience - if
it works for them great though.

~~~
Const-me
I agree.

Another reasons why I prefer GUI are auto complete, tooltips and context
menus. Also for some documents like xml, also when working with other people’s
code, I find it useful to collapse/expand blocks of text.

All these features pretty much require a GUI-based editor.

~~~
eadmund
Those features are available in emacs, and work in both the GUI and the
terminal.

For auto-complete, vanilla emacs has dynamic abbreviations; there are several
packages for fancier auto-completion; company-mode, for example, works just
fine in the terminal, as well of course as in the GUI (X11, macOS or Windows).

Likewise with tooltips, which in the terminal generally are generally
displayed in a special region of the terminal instead.

Likewise with context menus, which can be shown just fine in a VT100 terminal.

Likewise with expanding & collapsing text ('folding'). Org-mode, to take just
one example, is built on folding — and is easily one of modern emacs's killer
features.

Seriously, give emacs a shot. Both Prelude & spacemacs are excellent configs
for it.

~~~
Const-me
> give emacs a shot. Both Prelude & spacemacs are excellent configs for it.

Are there any advantages over Visual Studio + Visual Assist, for C++ or C#
languages?

Because I see many disadvantages.

About text editor features, your workarounds have flaws compared to good GUI.
For tooltips, that special region of the terminal is physically separate from
the cursor. For folding, a separate, visually distinct indicators of what’s
folded/unfolded help navigating the code faster.

Another text editor feature hard to do in text mode is spell checking for
strings and comments. Color is already used for syntax highlighting, so wavy
red underlines come handy.

But visual studio is more than an editor, it includes a build system,
debuggers and profilers, package manager, and many more related features.
Everything comes already integrated and just works out of the box.

~~~
eadmund
> Are there any advantages over Visual Studio + Visual Assist, for C++ or C#
> languages?

A fully-extensible, flexible environment which anyone (even a secretary!) can
easily extend.

> About text editor features, your workarounds have flaws compared to good
> GUI.

They're not workarounds; they _are_ the features. emacs has a GUI. I repeat:
_emacs has a GUI_. Tooltips in a GUI display as you'd expect. Folding in a GUI
displays as you'd expect.

> Another text editor feature hard to do in text mode is spell checking for
> strings and comments. Color is already used for syntax highlighting, so wavy
> red underlines come handy.

Terminals support underlines!

> But visual studio is more than an editor, it includes a build system,
> debuggers and profilers, package manager, and many more related features.

Have you ever used emacs? It's more than an editor; it connects to build
systems like make, maven, gradle, ant, what-have-you. It has its own elisp
debugger, connects to gdb, SLIME provides an integrated Common Lisp debugger
&c. It has a profiler. It has a package manager. It has a best-of-breed git
interface, Magit. It has a best-of-breed personal organiser, Org-mode. It has
multiple email clients (rmail, vm, gnus & notmuch come to mind, but there are
probably more). It has multiple web browsers (emacs-w3m, eww, w3 & a new
experimental WebKit-based browser). It has multiple image viewers. It has
multiple terminals & its own shell.

Emacs is far, _far_ 'more than an editor.' It's probably the single editor
which is the _furthest_ from being just an editor. Don't trust me: give it a
shot! It really is a wonderful experience.

And yes, it has a GUI. Images, scrollbars, menubar, toolbar: the works. Runs
on X11, macOS & Windows. And it _also_ runs perfectly well in a VT100
terminal. You can use the same emacs locally and remotely, over SSH. It's
pretty awesome.

~~~
Const-me
> which anyone (even a secretary!) can easily extend

Even if that’s true, we’re talking about development environments here, so
secretaries are irrelevant. I’ve been programming C++ and C# for decades, for
me, visual studio is quite flexible and extensible.

> Terminals support underlines

I specifically told about wavy red underlines for spell checking, and
terminals don’t support that. Simple underlines are too intrusive i.e. they
often mask '_', and don’t stand out visually from normal text.

> It's more than an editor; it connects to build systems like make, maven,
> gradle, ant, what-have-you.

I know it’s possible to integrate everything in Linux ecosystem. I just don’t
want to waste my time connecting, integrating, and then supporting the setup
that just works out of the box on Windows, with freeware visual studio.

