check out Eclipse Che: https://eclipse.org/che/
Putting the I back in IDE
21–30 of 152 posts
Re: Putting the I back in IDE
#22Earlier quoted context omitted.
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.
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.
> 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-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.
Re: Putting the I back in IDE
#23This 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…
> 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.
Re: Putting the I back in IDE
#24This 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]
Re: Putting the I back in IDE
#25This 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.
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.
Re: Putting the I back in IDE
#26I think they just described IntelliJ + Contexts and Tasks feature.
Or Visual studio.
Re: Putting the I back in IDE
#27Visual 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.
Re: Putting the I back in IDE
#28This 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…
You can also try speedbar / speedbar-sr. Gives you a quick tree-like view when wanted, and then can be dismissed.
Re: Putting the I back in IDE
#29Visual 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.
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).
Re: Putting the I back in IDE
#30Earlier quoted context omitted.
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.
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 th…
> 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.