Putting the I back in IDE
blog.janestreet.com
blog.janestreet.com
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.
If there’s nothing suitable it could be a fun thing to hack on! :)
Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?
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.
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.
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.
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.
https://blog.jetbrains.com/idea/2018/03/intellij-idea-2018-1...
I'd like to see more progress made in real desktop interfaces.
Come to the macOS/Windows developer culture.
Those of us that made a pilgrimage in other more graphics friendly environments, Xerox, ETHZ, Amiga, Atari, ...., have long left the 70's AT&T concept of programing behind.
On the contrary, I think Jane Street's entire modus operandi is doing things in a novel way, to attract/keep talent (and this is self perpetuating). There are many firms as successful as Jane Street, or more so, that use completely boring, but functional tools: Java, C++, Visual Studio, IntelliJ, and so on. But Jane Street PR is through the roof - everyone knows it, everyone wants to work there, whether any of it is practical or not. It's a counter-example to the mantra of "choose boring tools".
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 come up short on arguments. Not only do they get to have an efficient workflow, they also get to weed out developers whose opinions would make for a poor fit naturally.
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.
Just drop it.
A long time ago, I worked for a company wanting to sell advertising devices with an accompanying booking UI to Titan - we had a shiny web booking system; they had their crufty old 80x25 text mode system.
Turns out that 80x25 text mode system was orders of magnitude faster for the day to day workflow of booking ads on devices, etc.
I've seen two AS/400 via Telnet(-like) systems replaced with a modern GUI (first case) and a web based GUI (second case) and aside from all the usual problems associated with an en masse migration they ended up been far slower for the end user.
TUI's with complete keyboard shortcuts are just hard to beat for domain specific software.
Things like "Click Orders - Click Open - Click Create New Order" vs SHIFT+F9.
The other thing is that once your users have learnt the shortcuts they become internalised and they don't even think about them anymore.
I've seen developers where you'd need crowbars and grease to seperate them from vim advocating for replacing a TUI with a web GUI.
That one did make me giggle from the sheer level of irony.
Gui's are often preferred for the speed at which new hires can use them. In environments with high turnover this is important. You can have the best of both worlds with a GUI that has good shortcuts and clever cursor placement. I agree though that most gui implementations have not put enough effort into this.
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.
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.
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).
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
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.
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.)
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 into Emacs/Vim: a lot more than you need to put into mastering a powerful IDE
don't have as many features or don't reach the level of quality offered by modern, mainstream IDEs, for their respective languages. By this I mean that you need to bundle a ton of plugins into these editors and their plugin ecosystems are not as well integrated and as mature as the finished product provided by these IDE creators.
And for most devs who roll their own on top of Emacs and Vim, the balancing out between editor speed and IDE features is really, really hard. I think maybe 1% of the devs actually doing this are more productive, many of the others are fooling themselves, or as you said, haven't had the time to re-check the alternatives.
That being said, generic programmable editors like Emacs or Vim serve as nice catch-alls for those times when you don't have the proper "high-tech" tool. For example you're using a DSL, a niche language, etc.
A couple of things might take a bit more to configure (C++ smartness). But it is a free software program that has been around like 30 years. I am confident it is a tool I can invest in and it won't let me down. I can not say the same about proprietary IDE's and editors.
However, I have to point something out which proved to be an eye-opener for some people I've discussed the second point you bring up:
> But it is a free software program that has been around like 30 years. I am confident it is a tool I can invest in and it won't let me down. I can not say the same about proprietary IDE's and editors.
This argument is a bit dated, I think it harks back to the days of Borland IDEs and the Halloween Papers for Microsoft.
Why do I think it's a bit dated:
1. Quite a few of the commercial IDEs are not fully proprietary anymore, for example the core of the Jetbrains IDEs is Open Source; Visual Studio is proprietary but large parts of what it offered have been split into external components which are Open Source, more precisely Roslyn; I'll grant you XCode, but at that point you know you're locking yourself into the proprietary Apple ecosystem anyway; the other major IDEs are actually fully Open Source: Eclipse, Netbeans, Visual Studio Code, Atom
2. The Cathedral and the Bazaar predictions kind of failed ... Open Source didn't take over the world; it carved a segment in the market, a huge one, but still, a segment; proprietary software adjusted and now both coexist in various combinations in between Free Software and fully proprietary software. Both FOSS and commercial projects and products have to please their "clients". They do that, or they die. So the commercial side is in my opinion a lot more flexible than it used to be.
3. The software market is way more mature than it was when the GNU propaganda machine and later the Eric Raymond Open Source-hype machine were fully operational (with IBM backing it) - I'm only half joking about the FSF/Open Source propaganda, we have to acknowledge it for what it was and we aware of it , even if we consider its goals as noble; anyway, just because software vendors were dying like flies back in the 80's and 90's, it doesn't mean that mature software companies today will suffer the same fate. They might be somewhat fickle, and yes, even big companies can go bankrupt, but let's not discuss hypotheticals, let's discuss based on actual data:
* Visual Studio was launched in 1997, 21 (!) years ago; Visual Basic was launched in 1991, 27 (!) years ago; I know that Visual Basic didn't transition cleanly to Visual Studio, my point is that many principles from the Visual Basic IDE applied to Visual Studio
* Netbeans was launched in 1996, 22 years ago
* IntelliJ IDEA was launched in 2001, 17 years ago
* Eclipse was launched in 2001
My point is that was impressive to say "Emacs was launched 20 years ago" back in 1999, when the oldest mainstream IDE was 7-8 years old and you had common failures of companies selling IDEs (therefore losing support). However in 2018, as I said, this is a bit dated.
Many a Visual Studio developer have fed their family by using this tool from Microsoft over more than 2 decades. Same for Eclipse, Netbeans, IntelliJ. I suspect Visual Studio Code and maybe even Atom will follow this trajectory.
So let's stop this FUD, please. Looking at my arguments, I think you can agree with me that based on the data we have, a Visual Studio developer can probably retire successfully in 2040 while still using Visual Studio. And Visual Studio is "risky" because it's majority proprietary. But Eclipse, for example, is fully Open Source, backed by an organization, etc.
1. Very good IDEs — which may be proprietary — do exist and have existed for a while (the Visual Studio argument); and
2. Free Software IDEs do exist and have existed for a while (the Eclipse argument).
However, neither Visual Studio nor Eclipse on its own fulfills both arguments. I think your parent was trying to say that their customized install of Emacs does.
As for the point about people being able to make a living off of an IDE for two decades ... well, that's a low bar, isn't it? Lots of people make a living off of no IDEs (the Vim argument) for decades. The argument wasn't really about acceptably good IDEs for the general public, rather about IDEs sufficiently good to the parent's standards. Something they can invest in and reap rewards off of instead of merely using it, thus implying a higher standard than just "does the job".
I'm a bit sad that Emacs kind of failed as a commercial IDE. Note: commercial, not proprietary. Free Software can be commercial. I guess it's because GNU never got into the second wave of UX that popped up basically in the early 90's.
Emacs badly needed something like a successful Lucid: https://en.wikipedia.org/wiki/Lucid_Inc.
That Lucid company would have had to push for UX features for all kinds of programmers, for a set of blessed extensions that are tested together, for proper documentation with modern terminology, for sane, modern defaults, etc. You know, turn a software project into a software product. Imagine Sublime Text levels of polish, but with the power of Emacs.
Why I stick to emacs: light compared to most advanced editors. elisp.
If I ever need something I know I can, if someone didn't do it already, add it to emacs. When you crossed that line, it's very hard to feel stuck and unable to eval a few lines to improve your workflow.
Or look at macro support. IDEs still have either non-existent, or comparatively poor macro support, which I consider vital. The amount of times as a developer I have to do some repetitive task, or worse, some semi-repetitive but needs a bit of intelligence here and there task, which can be accomplished using a macro with a bit of logic, is insane.
Emacs really is like a superset of IDEs. It does a whole lot of things that IDEs just don't do as well, and then it also does a bunch of things that IDEs do as well.
That is not to say I don't use IDEs. If I have to do java, I'll do it in intellij. If I have to do nearly anything else, I'll do it in emacs. And luckily, most IDEs seem to come with a set of emacs keybindings and plugins so jumping back and forth isn't even that painful.
Regarding macros, I agree. However in the languages supported by the IDE, I rarely find that I need macros. I use refactorings, which are like macros on steroids, since they understand the actual language.
I really wish there was some modern Open Source editing environment which was extendable easily and also had commercial backing for the key parts. Visual Studio Code is remarkable close to what I want, it seems to have a solid architecture. The fact that it runs on Elecron is a kind of a drawback, but Microsoft really wants to make it competitive and I expect once WebAssembly hits the shelves things could take a very interesting turn.
is what makes Emacs so comfortable for me. In fact, that was a moment of revelation when I found that Emacs is not an editor as they said, but a platform to build your editor/IDE/environment. Probably, it is because my brain is trained to think in a programming way, it feels much more natural to tune everything by coding, then by knobs, and buttons. And, yes, it provides more extensibility. I mean, for real. That's why I, as many before me, started to do a lot of things unrelated to programming in Emacs - because I can make it to assist me better, in ways unachievable with other software, in spite of the fact that the latter could be specially developed for a purpose.
I don't proclaim Emacs is the panacea for everything, it has it's ugly sides too. I just want to say if you like to rule you working environment, not just learn how to live with it - Emacs can offer you something.
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 personal workflow easily. Every time I’ve picked up an ide, I’ve been disappointed by the compromises which were made to make it “integrated”.
I'm a career-long .NET dev and I've wanted to step away and begin learning C++ on a non-Windows platform with VIM and my only attempts were met with so much frustration that I gave up. To be clear, I believe in the power of VIM, I just never got acclimated to it.
Maybe this year is the year I stop making excuses and just learn.
P.S. I see lots of arguments elsewhere about whether VIM is an IDE. Either way I think your first point stands in my case @oblio.
Use dotnet core on Windows, with Visual Studio.
Use dotnet core on Windows, with Visual Studio Code.
Use dotnet core on Linux, with Visual Studio Code, etc.
Then maybe try dotnet core on Linux, with Vim.
But don't believe the hype. I use Vim as an editor because I do a lot of scripting. I use it even on Windows. But I use it because I'm already used to most of its commands, I have a decent config file for it (somewhat lean, not that many plugins) and for my job I need to know it cause I often interact with various systems which use it.
Despite being a touch typist and knowing most of the commands, I'm still a Vim heathen. That is, I don't use numbered yank buffers, I just use the default one, I also remapped Ctrl-c, Ctrl-v to do visual block operations for when I'm too lazy to come up with fancy selections, etc.
Anyway, my point is, using Vim might not pay off fully. My brain just isn't wired to work in Vim commands. And I know and use w, W, b, B, f, t, folds, blah, blah. I definitely don't use it to "magician" level.
You know what? I think in the end it doesn't matter. The only time Vim's nature actually helps is when I pre-process some sort of text data dumps.
For the other moments I'm thinking way more than I'm writing or editing. So it's not the text editor that's the blocking point.
Damn blocking IO. Getting outputs from the brain is hard and slow!
Thank you for the advice!
I tend to want to learn how things "on the other side of the tracks" work mostly because I get tired of the heated debates around tooling and I'm determined to learn as much as I can so that I can be well-rounded (that and C++ has been the beast I never finished taming).
Do you have any recommendations for a distro of Linux that would be easy to switch to? Go gentle on me, I'm a Wandows kid by day!
EDIT: Seems I can't reply to you anymore. Thanks again for your recommendations. I think a VM is a good route too. I'm not too concerned with purity at this point as much as learning. I can find beauty in most systems regardless of ideology :)
Unixen are generally the same, but you won't figure that out at first, so you do want something a bit friendlier.
My personal opinion would be to go with the mainstream distributions, since you want support from fellow humans on chat, forums, etc. I'm more of an Ubuntu guy, but people seem to like and use Mint or Debian or Fedora.
Don't fall into an Arch or Slackware trap early on, I don't really see the benefit of going for "purity" at this stage. There's this curve, I find, where you first go for newbie friendly, then you go for hardcore, and then you find a balance. The mainstream distros can be user friendly and are balanced. If you want to learn a lot, IMO go all in and either go Linux From Scratch (LFS) one time, or Gentoo for a while. But since you're a professional, after getting a hang of things with some deep learning (see LFS or Gentoo), you probably want to stay close to corporate environments. Those generally are Red Hat/Cent OS (so Fedora is somewhat close) or Ubuntu/Debian (Mint is also close).
TL;DR: Make an Ubuntu VM, start using it full-screened as much as possible instead of your Windows host. See how far that takes you. Good luck and have fun! :)
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.
Stack Exchange often makes the difference, but unfortunately many of both the questions and their answers are version-specific, but do not state the version they apply to.
There is a real art to making an IDE in which how to do all the common things is easy to find, and all the more esoteric features are discoverable. Maybe game designers could help?
I also like to play with the UI, they're generally quite configurable, you can move windows, panels, show/hide buttons, etc.
By using these two tricks I generally get the core stuff quickly and then I branch out.
I'd chalk it down to Visual Studio only running on one operating system, not being particularly useful for developing apps that aren't targeted at that platform, and having a very high price tag.
(The last two have changed, but only recently.)
I might have misunderstood some technical nuance in the article but I could honestly use the exactly same statements as in the first two bullet points to describe my workflow with VS.
This is not with Git though, so that might complexify the process. Maybe someone who is working with Git repos using a Visual Studio integrated tool can comment on this detail.
How nice would it be if you could just compile and run the code review yourself, reject it, and then immediately continue with your own work?
Or even better, just run both the code review and latest at the same time and see the difference, not just read it.
Released in 1990.
This is the first time I hear of this functionality. And it would be great to do that even in a disintegrated way, like, from the command line.
I like VS as an IDE. The TFS integration is a nightmare in my opinion.
Our company is split in half for historical reasons and uses both on TFS.
How would have you liked me to expose the prior art on Visual Studio, other than state that it existed, that it was very nice, and that it was a bit strange it was not mentioned in the article?
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.
Check out Upsource for code reviews. It's pretty much exactly what you would expect from a JetBrains-built code review tool.
But can the reviewer easily run the code they have just edited?
And does changing branches require a full rebuild?
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).
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.
Even with Atom finding files is way faster than clicking through the tree viewer.
There's even a dozen of generator presets integrated, you can just easily invoke them from your keyboard, without pressing all modifier keys at once.
And PyCharm even has all the keyboard navigation as well, you can even get emacs or vi keybindings, if you wish, I only use the mouse when the app's already running and I'm going through the log.
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.
But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.
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.
and yet:
> 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.
Emacs supports all of those things out of the box as well.
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.
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.
So you can have underline, bold, italic, squiggles, I think even strikethrough. Also you can have tooltip "windows" but since they're harder to create and manage few applications use them. Those that do are generally based on ncurses, a library for TUI (think Norton Commander or Turbo Pascal)
Vim even has a spell checker built in.
What the terminal does not have is usually consistent support because terminal emulators are really shady, there's no actual standard (most just do what xterm does). For the TUI thing, there's also no real conventions plus I'm pretty sure both Vim and Emacs don't use ncurses and roll their own (see: lack of consistency).
You also need to cobble things together out of packages with varying degrees of quality and documentation, from long forgotten wikis and 90's pages belongings to ex post-docs.
No wavy red lines, but there's still two different types of coloring (letters vs cell background): https://i1.wp.com/www.tjansson.dk/wp-content/vim-spell-error...
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.
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.
Tooltips work in the terminal, they're just text after all. See Vim + YouCompleteMe (which, as the name indicates, also provides auto-complete): https://camo.githubusercontent.com/1f3f922431d5363224b20e994...
> I find it useful to collapse/expand blocks of text
For that you don't even need plugins, folding has been a standard feature for many years
e.g. I'm using ZSH specifically for it's command line autocomplete stuff. Emacs has helm for context narrowing and really good support for context menus. Vim will let you collapse/expand blocks of text including in XML using a mouse in a terminal window.
For spelling errors Vim will give you an straight red underline in the terminal and squiggly underline in its "GUI" versions. I assume that Emacs is the same.
I'm not suggesting you leave VS by the way. I'm just saying that your GUI only examples aren't GUI only.
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.
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.
This is how I do all my file navigation.
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.
Just like using CLIs does not preclude using a mouse, using GUIs does not preclude using keyboard shortcuts ;)
Quick Explorer example (sometimes I mix and match, maybe I want to show something to a colleague):
explorer . # does what you'd expect; alternatively Win-e
Alt-d # focus path in Explorer
Start typing, Explorer autocompletes stuff
Enter
Tab around, if need be, to change panels
And this is with what is, basically, the dumbest common GUI file manager out there :)
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.
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.
At least has colors instead of having everything in green.
Really the extent people go to avoid using modern developer tools.
For me, efficiency is a synonym of Xerox PARC’s vision of computing, not improved teletypes.
And, unlike some of its competitors, it's free and easily user-extensible.