14 ms·

Putting the I back in IDE

297 points by yminsky 9y ago

cromwellian 9y ago
I think they just described IntelliJ + Contexts and Tasks feature.
- fsloth 9y ago
  Or Visual studio.
patientplatypus 9y ago
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.
- Retric 9y ago
  It's really easy to start working on and switch between several different branches at the same time. O&M fixes may be handled by a different team and regularly need to be moved into development. Now add in some experimental branches used for various things etc.
- iBelieve 9y ago
  I recently started using Emacs in a tiling window manager on Linux after using "standard" GUI editors like PyCharm, AppCode, Atom, VSCode, etc. on macOS. At first, I felt exactly like you describe - it felt so constraining not having a tree view and tabs I could click on. But after a while I got used to using a keyboard shortcut to quickly jump between files or search for a file to open. I'm slowly getting used to it and find even the basic set of keyboard shortcuts I've learned feel so much more productive then combined use of a mouse and keyboard. Just one example of that - recently I needed to create some UUIDs to use in my code. Previously, I would have googled a UUID generator or used uuid on the command line and then pasted the output into my editor. With Emacs, I was able to easily insert the UUID directly into my code using `C-u M-! uuidgen` (that keyboard shortcut inserts the output of the given command at the current cursor location).
  - eadmund 9y ago
    > it felt so constraining not having a tree view and tabs I could click on There are emacs packages for tree views[0] and tabs[1], but as you note the built-in buffer management is more powerful. Stuff like Helm or Ivy is even better! There's also an emacs uuidgen package, which can generate a uuid & insert it with M-x uuidgen; you could of course bind it to a key sequence if you use it frequently. 0: https://github.com/jaypei/emacs-neotree https://github.com/jaypei/emacs-neotree 1: https://www.emacswiki.org/emacs/TabBarMode https://www.emacswiki.org/emacs/TabBarMode
    - nextlevelwizard 9y ago
      Thous things are pretty much things to avoid in my opinion. I used to have NERDTree in Vim and all kind of other useless nonsense. After I learned how to use fuzzy searching to jump between files and definitions all tree view does is take up space. Even with Atom finding files is way faster than clicking through the tree viewer.
      - eadmund 9y ago
        I agree re. tree views, but was merely noting that they exist, if one really wants them. rms may be doctrinaire, but emacs is not!
    - iBelieve 9y ago
      Thanks for the suggestions. I knew about tree views for Emacs, but I usually work with Emacs and a terminal side-by-side on a 13" laptop screen, so a tree view just takes up extra space and I ended up not missing it much. As for the uuidgen package, this was just a one-time thing for a few uuids, so using the uuidgen command I already had installed on Linux was simplier.
  - codemac 9y ago
    You can also try speedbar / speedbar-sr. Gives you a quick tree-like view when wanted, and then can be dismissed.
  - cup-of-tea 9y ago
- Const-me 9y ago
  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.
  - sid-kap 9y ago
    Spacemacs has excellent context menus. It was suprising how discoverable everything is!
  - yorwba 9y ago
    There are vim plugins for auto-completion and it supports code folding out of the box. I'm not sure what you use tooltips and context menus for, but that functionality is probably available via some : command. But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.
    - Const-me 9y ago
      > I'm not sure what you use tooltips They show documentation (pulled from comments) for functions, classes and arguments. > and context menus For context-sensitive commands I use once per week or less often, so I don’t bother memorizing keyboard shortcuts for them. > most command-line editors are actually GUIs in the terminal Most developers don’t use command line editors. Here’s recent data from this year: https://insights.stackoverflow.com/survey/2018#development-environments-and-tools https://insights.stackoverflow.com/survey/2018#development-e... As you see, 4 most popular editors are VS Code, Visual Studio, Notepad++ and Sublime Text, all of them are GUI applications. Only 26% developers use Vim, 4% Emacs.
      - oblio 9y ago
        Those stats are also probably skewed in favor of people actually bothering to fill their survey. Those are more likely to be active/proactive, which in my experience is correlated with tinkering with tools (ergo, using Vim or Emacs).
- yorwba 9y ago
  There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything. When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with high branching factor.
  - flukus 9y ago
    > When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.
    - jolmg 9y ago
      Another way to navigate with cd is to use tab completion instead of ls. "cd "+tab and you get a listing of files. You might have your shell configured to cycle among the options with tab or select with arrow keys. If you've selected a directory, press "/"+tab and repeat. If you want to go back up a level, quickly hit ctrl+w to delete the last piece of the path (that's the behavior of vi keybindings, emacs keybindings delete the whole path). You might in the end have found the file you want to work with and forego cd by using key shortcuts to quickly navigate to the beginning of the command line and switch the command. This is how I do all my file navigation.
      - flukus 9y ago
        This is great locally or at home, a lot of the time when I'm "browsing" it's on remote windows shares on another continent though, the latency from windows and the network is simply to high for tab completion to be usable, it makes using FTP over dialup seem snappy. This is through cygwin, real linux is another story. I don't know what the difference is between how windows and linux mount remote drives, but the performance difference is stark, ls on a mounted network drive in linux is essentially instant but there is a noticeable lag doing the same from a windows machine.
- hollerith 9y ago
  Just want to make sure that people realize that Emacs has decent support for pointing devices and can link with the native GUI libraries on Windows and Mac and GTK+ on Linux. So for example although the (very old) version of Emacs (/usr/bin/emacs) that comes with OS X was built in such a way that it can communicate with the user only via the terminal, the following command line will install a GUI-capable Emacs: brew tap railwaycat/emacsmacport && brew update && brew install emacs-mac (The simpler command line `brew update && brew install emacs` would install a GUI-capable Emacs, too, but delivers the pure-FSF version of Emacs, which for mac for many years now has been buggier than the FSF version plus Mitsuharu's patches, which is what the first command line delivers. In the past there have been times when `brew install emacs` would install an Emacs that is just not usable because of bugs while `brew install emacs-mac` would install and Emacs that works fine.) Whether or not the code Jane Street added to Emacs can be used with a pointing device I do not know.
- Lio 9y ago
  I use NeoVim in tmux pretty much exclusively. You can turn on mouse support for terminal apps like Vim and Emacs and still click things like the file viewer, scroll text with two fingers and resize windows with a mouse. You just have to configure it. This to my mind is the real difference between classic editors like Vim and Emacs and GUI IDEs. With the terminal editors you can be at least sure that you'll get a comprehensive keyboard interface system, I haven't always found that with GUI IDEs especially when it comes to third party plugins.
pentagonpapers 9y ago
Vim day in and day out for years. What am I missing from IDE I feel like there's a lot
iBelieve 9y ago
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 9y ago
  You may be interested in magithub (it’s on MELPA).
  - pimeys 9y ago
    Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.
    - ynniv 9y ago
      That’s not the UI’s fault - the JIRA backend is slow.
    - girvo 9y ago
      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 9y ago
        What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...
DiabloD3 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
augbog 9y ago
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 9y ago
  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.
nartz 9y ago
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...
- deleted 9y ago
  [deleted]
- oneeyedpigeon 9y ago
  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 9y ago
    Is stashing an issue?
- QasimK 9y ago
  [git-worktree](https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree) allows you to have "copies" of the repo cheaply. This can be useful when switching branches would have a high overhead, for example you need to reconfigure your local environment (database, dependencies, etc.).
caniszczyk 9y ago
check out Eclipse Che: https://eclipse.org/che/ https://eclipse.org/che/
fsloth 9y ago
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 9y ago
  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 9y ago
    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
    - oblio 9y ago
      > seemingly little features add up You can say that again. These really polished software products such as Microsoft Office (don't laugh!), IntelliJ, Visual Studio Code, 7-Zip, Chrome, Firefox have tons of hidden features you can easily miss and that have tons of thought put into them. For example I started using Visual Studio Code and I accidentally clicked things in the status bar. Did you know that the text there is actually buttons? They take you to the command bar, where they have a pre-filtered list of commands which set their respective options (!!!). That's power user UX Nirvana, embedding discoverability and teaching in a subtle way that doesn't interfere with your normal workflow. You don't know what you're doing? You click the menus and your life is just fine. You read the Welcome page and maybe change some user settings, with full auto completion (!!!), or maybe you click around the app, and like a modern game with a physics engine, the app reacts to your action, doesn't just sit there like a slab of rock.
pjmlp 9y ago
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 9y ago
  And so they should when modern is not as efficient as the alternative.
  - pjmlp 9y ago
    Efficiency is on the eyes of beholder. For me, efficiency is a synonym of Xerox PARC’s vision of computing, not improved teletypes.
- zeveb 9y ago
  emacs is a modern developer tool. Its most recent version is just about to be released. It supports all major and several minor OSes. It's used by modern developers (e.g. the folks at Jane Street …). And, unlike some of its competitors, it's free and easily user-extensible.
  - pjmlp 9y ago
    Emacs still lacks quite a few improvements XEmacs had over it, and many Lisp Machine features are yet to be available on it.
_ZeD_ 9y ago
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...)
pavlov 9y ago
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 9y ago
  Would you prefer a web app? Why?
  - stevedonovan 9y ago
    There is a middle ground between these positions :)
  - dmitriid 9y ago
    I would prefer IntelliJ IDEA for the majority of tasks (sadly, not git integration).
    - rantanplan 9y ago
      What do you mean by "not git integration"?
      - dmitriid 9y ago
        I personally find git integration in IDEA cumbersome and rather poorly designed. But I've seen my colleagues use it.
        timrichard 9y ago
        I have to disagree there.... I think Git integration in the Jetbrains IDEs are amazing. There's a general attitude the command line gives more power and flexibility than fancy graphical interfaces, and I'm with that 99% of the time. For me, Git integration is the exception. I've found in many shops that people memorise a few favourite Git riffs and then just try to make any VCS task fit those regardless. I find the Webstorm/IntelliJ Git integration to be very flexible... the Log view gives a lot of useful options to reason about the state of the various branches when there are several features in flight across the team simultaneously. Selective log view modes and the ability to group/visually reorder commits is useful too. I get a lot of use out of the Branch Compare tool (which is integrated with the diff merge tool), to show a snapshot of the differences between any two branches at any point of time, and to selectively merge across any small pieces of code interactively when a cherrypick of an entire commit would be too broad a brush. I expect there are ways of doing similar things in the CLI, but I find the Jetbrains IDE implementation gives a lot of clarity and confidence in what needs to be done and what's about to happen. Certainly more so than most dev shops I have experience of, where it's a small set menu of pull/commit/ push, merge, and optimism.
Finster 9y ago
"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?
- geezerjay 9y ago
  I agree, that's pretty much SVN shoehorned onto a git workflow. With git there is no need to save branches into folders. At most, push feature branches to a remote repository and check them out when needed.
- EnderMB 9y ago
  I'm glad that I wasn't the first (or second) person to notice this. Admittedly, 99% of people are using git as a centralised source control system, and outside of branching/merging there hasn't been much of a change in workflow for many. I've not used their system, so I don't know how well this svn-like system works, but every time I think back to svn all I can think of is how painful this workflow was.
- rasjani 9y ago
  Or git worktree
  - sjakobi 9y ago
    Oh, I had never heard of that command before. Does it work well, i.e. does it improve your workflow?
    - lozenge 9y ago
      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.
yueq 9y ago
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..
deleted 9y ago
[deleted]
amelius 9y ago
> 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 9y ago
  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.
iLemming 9y ago
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.

297 points by yminsky 9y ago

cromwellian 9y ago

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

fsloth 9y ago
Or Visual studio.

patientplatypus 9y ago

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.

Retric 9y ago
It's really easy to start working on and switch between several different branches at the same time. O&M fixes may be handled by a different team and regularly need to be moved into development. Now add in some experimental branches used for various things etc.
iBelieve 9y ago
I recently started using Emacs in a tiling window manager on Linux after using "standard" GUI editors like PyCharm, AppCode, Atom, VSCode, etc. on macOS. At first, I felt exactly like you describe - it felt so constraining not having a tree view and tabs I could click on. But after a while I got used to using a keyboard shortcut to quickly jump between files or search for a file to open. I'm slowly getting used to it and find even the basic set of keyboard shortcuts I've learned feel so much more productive then combined use of a mouse and keyboard. Just one example of that - recently I needed to create some UUIDs to use in my code. Previously, I would have googled a UUID generator or used uuid on the command line and then pasted the output into my editor. With Emacs, I was able to easily insert the UUID directly into my code using `C-u M-! uuidgen` (that keyboard shortcut inserts the output of the given command at the current cursor location).
- eadmund 9y ago
  > it felt so constraining not having a tree view and tabs I could click on There are emacs packages for tree views[0] and tabs[1], but as you note the built-in buffer management is more powerful. Stuff like Helm or Ivy is even better! There's also an emacs uuidgen package, which can generate a uuid & insert it with M-x uuidgen; you could of course bind it to a key sequence if you use it frequently. 0: https://github.com/jaypei/emacs-neotree https://github.com/jaypei/emacs-neotree 1: https://www.emacswiki.org/emacs/TabBarMode https://www.emacswiki.org/emacs/TabBarMode
  - nextlevelwizard 9y ago
    Thous things are pretty much things to avoid in my opinion. I used to have NERDTree in Vim and all kind of other useless nonsense. After I learned how to use fuzzy searching to jump between files and definitions all tree view does is take up space. Even with Atom finding files is way faster than clicking through the tree viewer.
    - eadmund 9y ago
      I agree re. tree views, but was merely noting that they exist, if one really wants them. rms may be doctrinaire, but emacs is not!
  - iBelieve 9y ago
    Thanks for the suggestions. I knew about tree views for Emacs, but I usually work with Emacs and a terminal side-by-side on a 13" laptop screen, so a tree view just takes up extra space and I ended up not missing it much. As for the uuidgen package, this was just a one-time thing for a few uuids, so using the uuidgen command I already had installed on Linux was simplier.
- codemac 9y ago
  You can also try speedbar / speedbar-sr. Gives you a quick tree-like view when wanted, and then can be dismissed.
- cup-of-tea 9y ago
Const-me 9y ago
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.
- sid-kap 9y ago
  Spacemacs has excellent context menus. It was suprising how discoverable everything is!
- yorwba 9y ago
  There are vim plugins for auto-completion and it supports code folding out of the box. I'm not sure what you use tooltips and context menus for, but that functionality is probably available via some : command. But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.
  - Const-me 9y ago
    > I'm not sure what you use tooltips They show documentation (pulled from comments) for functions, classes and arguments. > and context menus For context-sensitive commands I use once per week or less often, so I don’t bother memorizing keyboard shortcuts for them. > most command-line editors are actually GUIs in the terminal Most developers don’t use command line editors. Here’s recent data from this year: https://insights.stackoverflow.com/survey/2018#development-environments-and-tools https://insights.stackoverflow.com/survey/2018#development-e... As you see, 4 most popular editors are VS Code, Visual Studio, Notepad++ and Sublime Text, all of them are GUI applications. Only 26% developers use Vim, 4% Emacs.
    - oblio 9y ago
      Those stats are also probably skewed in favor of people actually bothering to fill their survey. Those are more likely to be active/proactive, which in my experience is correlated with tinkering with tools (ergo, using Vim or Emacs).
yorwba 9y ago
There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything. When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with high branching factor.
- flukus 9y ago
  > When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.
  - jolmg 9y ago
    Another way to navigate with cd is to use tab completion instead of ls. "cd "+tab and you get a listing of files. You might have your shell configured to cycle among the options with tab or select with arrow keys. If you've selected a directory, press "/"+tab and repeat. If you want to go back up a level, quickly hit ctrl+w to delete the last piece of the path (that's the behavior of vi keybindings, emacs keybindings delete the whole path). You might in the end have found the file you want to work with and forego cd by using key shortcuts to quickly navigate to the beginning of the command line and switch the command. This is how I do all my file navigation.
    - flukus 9y ago
      This is great locally or at home, a lot of the time when I'm "browsing" it's on remote windows shares on another continent though, the latency from windows and the network is simply to high for tab completion to be usable, it makes using FTP over dialup seem snappy. This is through cygwin, real linux is another story. I don't know what the difference is between how windows and linux mount remote drives, but the performance difference is stark, ls on a mounted network drive in linux is essentially instant but there is a noticeable lag doing the same from a windows machine.
hollerith 9y ago
Just want to make sure that people realize that Emacs has decent support for pointing devices and can link with the native GUI libraries on Windows and Mac and GTK+ on Linux. So for example although the (very old) version of Emacs (/usr/bin/emacs) that comes with OS X was built in such a way that it can communicate with the user only via the terminal, the following command line will install a GUI-capable Emacs: brew tap railwaycat/emacsmacport && brew update && brew install emacs-mac (The simpler command line `brew update && brew install emacs` would install a GUI-capable Emacs, too, but delivers the pure-FSF version of Emacs, which for mac for many years now has been buggier than the FSF version plus Mitsuharu's patches, which is what the first command line delivers. In the past there have been times when `brew install emacs` would install an Emacs that is just not usable because of bugs while `brew install emacs-mac` would install and Emacs that works fine.) Whether or not the code Jane Street added to Emacs can be used with a pointing device I do not know.
Lio 9y ago
I use NeoVim in tmux pretty much exclusively. You can turn on mouse support for terminal apps like Vim and Emacs and still click things like the file viewer, scroll text with two fingers and resize windows with a mouse. You just have to configure it. This to my mind is the real difference between classic editors like Vim and Emacs and GUI IDEs. With the terminal editors you can be at least sure that you'll get a comprehensive keyboard interface system, I haven't always found that with GUI IDEs especially when it comes to third party plugins.

pentagonpapers 9y ago

Vim day in and day out for years. What am I missing from IDE I feel like there's a lot

iBelieve 9y ago

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 9y ago
You may be interested in magithub (it’s on MELPA).
- pimeys 9y ago
  Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.
  - ynniv 9y ago
    That’s not the UI’s fault - the JIRA backend is slow.
  - girvo 9y ago
    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 9y ago
      What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...

DiabloD3 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.

augbog 9y ago

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 9y ago
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.

nartz 9y ago

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

deleted 9y ago
[deleted]
oneeyedpigeon 9y ago
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 9y ago
  Is stashing an issue?
QasimK 9y ago
[git-worktree](https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree) allows you to have "copies" of the repo cheaply. This can be useful when switching branches would have a high overhead, for example you need to reconfigure your local environment (database, dependencies, etc.).

caniszczyk 9y ago

check out Eclipse Che: https://eclipse.org/che/ https://eclipse.org/che/

fsloth 9y ago

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 9y ago
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 9y ago
  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
  - oblio 9y ago
    > seemingly little features add up You can say that again. These really polished software products such as Microsoft Office (don't laugh!), IntelliJ, Visual Studio Code, 7-Zip, Chrome, Firefox have tons of hidden features you can easily miss and that have tons of thought put into them. For example I started using Visual Studio Code and I accidentally clicked things in the status bar. Did you know that the text there is actually buttons? They take you to the command bar, where they have a pre-filtered list of commands which set their respective options (!!!). That's power user UX Nirvana, embedding discoverability and teaching in a subtle way that doesn't interfere with your normal workflow. You don't know what you're doing? You click the menus and your life is just fine. You read the Welcome page and maybe change some user settings, with full auto completion (!!!), or maybe you click around the app, and like a modern game with a physics engine, the app reacts to your action, doesn't just sit there like a slab of rock.

pjmlp 9y ago

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 9y ago
And so they should when modern is not as efficient as the alternative.
- pjmlp 9y ago
  Efficiency is on the eyes of beholder. For me, efficiency is a synonym of Xerox PARC’s vision of computing, not improved teletypes.
zeveb 9y ago
emacs is a modern developer tool. Its most recent version is just about to be released. It supports all major and several minor OSes. It's used by modern developers (e.g. the folks at Jane Street …). And, unlike some of its competitors, it's free and easily user-extensible.
- pjmlp 9y ago
  Emacs still lacks quite a few improvements XEmacs had over it, and many Lisp Machine features are yet to be available on it.

_ZeD_ 9y ago

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...)

pavlov 9y ago

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 9y ago
Would you prefer a web app? Why?
- stevedonovan 9y ago
  There is a middle ground between these positions :)
- dmitriid 9y ago
  I would prefer IntelliJ IDEA for the majority of tasks (sadly, not git integration).
  - rantanplan 9y ago
    What do you mean by "not git integration"?
    - dmitriid 9y ago
      I personally find git integration in IDEA cumbersome and rather poorly designed. But I've seen my colleagues use it.
      - timrichard 9y ago
        I have to disagree there.... I think Git integration in the Jetbrains IDEs are amazing. There's a general attitude the command line gives more power and flexibility than fancy graphical interfaces, and I'm with that 99% of the time. For me, Git integration is the exception. I've found in many shops that people memorise a few favourite Git riffs and then just try to make any VCS task fit those regardless. I find the Webstorm/IntelliJ Git integration to be very flexible... the Log view gives a lot of useful options to reason about the state of the various branches when there are several features in flight across the team simultaneously. Selective log view modes and the ability to group/visually reorder commits is useful too. I get a lot of use out of the Branch Compare tool (which is integrated with the diff merge tool), to show a snapshot of the differences between any two branches at any point of time, and to selectively merge across any small pieces of code interactively when a cherrypick of an entire commit would be too broad a brush. I expect there are ways of doing similar things in the CLI, but I find the Jetbrains IDE implementation gives a lot of clarity and confidence in what needs to be done and what's about to happen. Certainly more so than most dev shops I have experience of, where it's a small set menu of pull/commit/ push, merge, and optimism.

Finster 9y ago

"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?

geezerjay 9y ago
I agree, that's pretty much SVN shoehorned onto a git workflow. With git there is no need to save branches into folders. At most, push feature branches to a remote repository and check them out when needed.
EnderMB 9y ago
I'm glad that I wasn't the first (or second) person to notice this. Admittedly, 99% of people are using git as a centralised source control system, and outside of branching/merging there hasn't been much of a change in workflow for many. I've not used their system, so I don't know how well this svn-like system works, but every time I think back to svn all I can think of is how painful this workflow was.
rasjani 9y ago
Or git worktree
- sjakobi 9y ago
  Oh, I had never heard of that command before. Does it work well, i.e. does it improve your workflow?
  - lozenge 9y ago
    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.

yueq 9y ago

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

deleted 9y ago

[deleted]

amelius 9y ago

> 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 9y ago
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.

iLemming 9y ago

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.