Live data from Hacker News

Putting the I back in IDE

blog.janestreet.com

1–10 of 152 posts

Re: Putting the I back in IDE

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

Re: Putting the I back in IDE

#4

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.

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.

Re: Putting the I back in IDE

#6
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/

Re: Putting the I back in IDE

#7

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.

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

Re: Putting the I back in IDE

#9
post #8

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

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.

Re: Putting the I back in IDE

#10

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.

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.

Post reply on HN