Putting the I back in IDE(blog.janestreet.com)
blog.janestreet.com
Putting the I back in IDE
https://blog.janestreet.com/putting-the-i-back-in-ide-towards-a-github-explorer/
151 comments
You may be interested in magithub (it’s on MELPA).
Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.
That’s not the UI’s fault - the JIRA backend is slow.
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.
What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...
I remember seeing one, though it may not have been under active development. Maybe search MELPA/Github.
If there’s nothing suitable it could be a fun thing to hack on! :)
If there’s nothing suitable it could be a fun thing to hack on! :)
"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?
Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?
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.
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.
It's darcs as well, and many other systems. Why not try to improve something that can be a pain when using git?
Or git worktree
Oh, I had never heard of that command before. Does it work well, i.e. does it improve your workflow?
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.
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.
+1 for git worktree, it's great for making temporary copies of a repo when you need them
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.
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.
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.
> but their internal tools use 80*25 text-mode UIs
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.
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.
Indeed.
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.
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.
Yep, you want to see ultra effecient computer usage go to Fry's Electronics and watch them wiz around the TUI POS system. Actually that goes for most TUI POS systems like, say, your standard grease smudged terminal at the local UHaul office.
Nothing to stop you adding the Shift+F9 shortcut to the gui.
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.
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.
> we developers are stuck
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.
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.
> they also get to weed out developers whose opinions would make for a poor fit
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?
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?
Not sure about Victor but Smalltalk is highly influenced by the LISP machine. I'm not sure Kay is as against Emacs as you might think.
For Janestreet? Definitely.
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.
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.
Like I said: an unfortunate local maximum that works but hinders progress.
That's not a refutation or argument but just restating your opinion in a pejorative way.
Just drop it.
Just drop it.
> It's not the company's fault
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".
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".
You know, Emacs isn't restricted to 80*25 characters. You can run it on double 4K monitors with tiling. What's the problem?
Only those that never took their eyes out of UNIX 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.
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.
Would you prefer a web app? Why?
No, HTML is limited in the same way as terminal emulation: it's not the right tool to describe UIs and interactions.
I'd like to see more progress made in real desktop interfaces.
I'd like to see more progress made in real desktop interfaces.
> I'd like to see more progress made in real desktop interfaces.
Come to the macOS/Windows developer culture.
Come to the macOS/Windows developer culture.
[deleted]
There is a middle ground between these positions :)
I would prefer IntelliJ IDEA for the majority of tasks (sadly, not git integration).
What do you mean by "not git integration"?
I personally find git integration in IDEA cumbersome and rather poorly designed. But I've seen my colleagues use it.
Similar to the sibling's comment, be sure to look at the freshly released 2018.1 version: they finally included partial commits, and did so in a fantastic way
https://blog.jetbrains.com/idea/2018/03/intellij-idea-2018-1...
https://blog.jetbrains.com/idea/2018/03/intellij-idea-2018-1...
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.
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.
and yet children read picturebooks and point with their fingers to explain things while adults read text and use language..
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.
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 probably OK at a company, though. Teams that I've worked on tend to converge on pretty similar workflows with respect to pull requests.
I think they just described IntelliJ + Contexts and Tasks feature.
Or Visual studio.
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.
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).
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).
Even without impatience/ignorance/incompetence. It's very hard to follow what everybody's doing. Seriously hard. Everyday people are making stuff, and have been doing so for 50 years. I'm a regular emacs user and I keep being surprised by new modes/extensions that I never heard of, but were released 2 years ago -_-;
True, my comment was a bit mean/dismissive. People do have to stop chasing the trends, cause that's a full time job.
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.
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.
Emacs user here. I have used lot's of IDE's in the past until I decided to take Emacs seriously. The problem with IDE's is that you have to learn one for each language. Working on multi-language projects becomes really annoying. With Emacs I can remain in the same place. If I spend a little bit configuring it I get most of the IDE features. I am always at home. Git is there too. Now I even check my email there, great for emailing about technical stuff. Muscle memory works until it is almost part of yourself.
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.
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.
JetBrains IDEs work pretty well as a polyglot system. I do like the language-differentiated IDEs they have since they streamline the interface a bit to what's relevant, but most (if not all) of them are implemented as plugins to IntelliJ too. It's comparable to language-specific Emacs distros vs. modes.
I've taken up learning emacs again via spacemacs so I can have an editor with console and gui modes. The increased discover-ability has helped me a lot. But what facets of emacs proved valuable after learning them?
Sounds reasonable, you're basically investing in an ecosystem that trades flexibility for polish.
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.
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.
I see your arguments as a meld of two separate ones:
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".
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".
To keep it brief (mobile keyboards suck): Vim’s strong suit is editing text. That’s all.
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”.
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”.
vi is unixy, in the sense of UNIX is supposed to be the "interpreter" or the IDE as some books said. vi let's you type a few keys and delegate to whoever is most capable of dealing with it. I'd love it if I was stronger with C and interprocess comms. My mind naturally wants everything into one core which is very lispy, so emacs suited me best at first.
It's quite true, IDE value is prepackaged, programmable editor value is flexibility. Both come with issues. Eclipse (because of Java culture mostly) is hell in resources and programmability. Emacs is seriously amazing here, but yeah I don't have a full fledged debugger out of the box. That said .. it only takes one guy to make it so. Just look at magit.. so far it's one of, if not the, best git interface.
The thing with Emacs and Vim is that I like polish. I like to tinker, but I like to know that if I need something people have banged their heads against the wall with the same tools and fixed them. With plugins and just hobbyists working on the plugins (or professionals only doing thing in their spare time) it's hard to get the level of polish high enough.
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.
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.
I lost the desire to tinker. Even well known and easy to install theming... I go vanilla.
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.
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.
The whole point of emacs is that it is extensible, and easily so. That is the core thing that makes emacs great. And it means that, far from having extensions that are inferior to those on IDEs, it has many extensions that are far, far superior to the IDE equivalents. For example, magit I find a far superior git extension than the IDE equivalents. Something like org-mode simply has no rival in the world of IDEs, it is an incredibly powerful and flexible tool which contains all my notes and integrates well with "languages" even.
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.
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.
For some (a lot of?) things that's true. But at that point you're basically writing your own stuff, just using a framework. You get the flexibility, but you're also "responsible" for making its level match up with that of something someone was probably paid to do (and that someone else is not always incompetent :) ).
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.
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.
This => "But at that point you're basically writing your own stuff, just using a framework."
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.
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.
[deleted]
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
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
I'm a fairly light user of VSCode, so I may be wrong here, but the integration goes even deeper in Visual Studio.
It lets you view a pull request's changes right there in a standard IDE window, so that you can get full code navigation features during code review, including stuff like peeking the docstring or implementation of any functions the code references. Or, if you notice something amiss while reviewing your changes before submitting a pull request, you can just make the change, re-run tests, and commit, without ever leaving the diff viewer. Or being able to just toggle gitblame annotations on and off right there in the editor.
It's nothing worth switching platforms or programming languages over, but, since switching away from .NET and seeing the gulf between the level of seamlessness you get out of Visual Studio and what's available in other IDEs, I can now see why they've come to have such a poor reputation. Visual Studio isn't exactly lightweight, but it manages to pack in enough cool tricks to justify itself.
(Until you install ReSharper. Then it becomes as memory-hungry and unstable as everyone else.)
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.)
> 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.
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.
I wouldn't chalk a lack of familiarity with Visual Studio down to snobbery and elitism.
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'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.)
This is true for me :(
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.
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.
Do it one step at a time.
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!
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!
I see, I see.
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 :)
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 :)
Well, if you're motivated enough, don't switch. Just fire up a VM.
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! :)
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! :)
Could go even easier by installing Git for Windows and using the included bash prompt.
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.
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.
If he has Windows 10 he could even go WSL, forgot about it.
Could, but, IMO, if you don't need to run arbitrary linux apps then gitbash is the better option. It's more performant for file operations, and you don't have to deal with gotchas like, "Don't edit files that don't belong to WSL from WSL, only read them."
Why did you want to use vim? If you want a full-featured modern C++ IDE on a non-windows platform, try Jetbrains CLion.
I have jumped around platforms quite a bit, and I try to use the IDEs that are available (right now I have XCode and PyCharm open on a Mac), but there is a steep learning and setup curve, and I usually don't have the time to work through a start-from-scratch tutorial, at least not initially. I am familiar with the sinking feeling that comes with realizing that my last hope is to use the search feature of the product's own help system, as it is so rarely productive.
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?
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've found that many IDEs can just copy keymaps from one another. That makes things A LOT easier during the transition period.
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 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.
Looks like the killer feature here wasn't doing everything from a single window. It was dedicating a sandbox per branch, saving everything, including uncommitted work and build artefacts.
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.
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.
It can be done from the command-line (https://www.janestreet.com/tech-talks/code-review/); many people just find the Emacs integration nicer. But there are plenty of vim users who use the command-line instead.
Visual Studio without git .. is barely usable. The whole team system integration is a UI disaster, busy, slow and takes gazillion clicks to get anywhere.
I like VS as an IDE. The TFS integration is a nightmare in my opinion.
I like VS as an IDE. The TFS integration is a nightmare in my opinion.
Good ol smug, dismissive top comment with bonus um-my-favorite-tool-is-the-best-why-would-anything-else-exist.
I disagree on being dismissive or smug. I did not claim VS was superior - my intent was to point it out as obvious prior art since the article and several comments in this thread gave the impression that an integrated view to development was a 'new' way to look at things or that one required this or that combination of third party tools to manage it. In this context I feel pointing out that VS has this 'single view' methodogy as the default setting was merited.
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?
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?
So you got to the third bullet point on the first page, forgot the first two, stopped reading and decided to comment?
The charitable way to put that would have been "I don't see how the features you listed are related to to the first two bullet points".
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.
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.
VS lets you save a sandbox per branch? May I ask since when? (The most recent version I have used was 2012).
In my work I use VS with TFS as the source control. Each branch is in a separate directory, and one can store explicit change sets at any point in time as "shelve sets" without actually committing them into the repository. So there are the two hierarchy levels to experimentation - one can create a new parallel branch on the fly, or do experimentation on top of a branch using shelve sets. That's not explicitly a sandbox, but provides for most cases where one needs to experiment / have distinct development lines / put away random experiments etc. So, uh, depending where you need a sandbox the features may or may not exist.
On the other hand, in Git there is no difference between a branch, a check-in, a shelve set and a code review (which is also a shelve set).
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.
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.
Worse, that interface would be a child's play to implement in Turbo Vision on MS-DOS.
Released in 1990.
Released in 1990.
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.
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.
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.
Check out Upsource for code reviews. It's pretty much exactly what you would expect from a JetBrains-built code review tool.
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.
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...
[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.).
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.
Is stashing an issue?
[deleted]
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..
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.
check out Eclipse Che: https://eclipse.org/che/
> 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?
But can the reviewer easily run the code they have just edited?
And does changing branches require a full rebuild?
They also build two build systems in ocaml http://jbuilder.readthedocs.io/en/latest/ and jenga, which support incremental fast compilation, so the answer is most likely yes.
[deleted]
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...)
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).
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).
> 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
1: https://www.emacswiki.org/emacs/TabBarMode
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
1: https://www.emacswiki.org/emacs/TabBarMode
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.
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.
Even with Atom finding files is way faster than clicking through the tree viewer.
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!
Every day around the world a few users discover that the most efficient input tool is directly in front of them, uses both hands and all digits.
You can also try speedbar / speedbar-sr. Gives you a quick tree-like view when wanted, and then can be dismissed.
And with pycharm you'd have simply used a generator preset for uuids.
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.
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.
PyCharm is great, and I use it along with AppCode and Android Studio. I'm mainly trying to learn Emacs because so many people have great things to say about it, plus I've started using Org Mode for todos and notes and it's awesome. In addition, I've tried using the VIM emulation in the Jetbrains IDEs and have always ended up turning it off each time as I kept forgetting I was in VIM mode and would try to use the editor like a normal editor. Emacs with Evil mode is different enough that I don't try to mix VIM and regular editor usage.
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.
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.
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.
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.
I don't use GUI file explorers that much, but I have to point out even Windows Explorer has path autocompletion.
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 :)
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 :)
> 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.
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.
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.
This is how I do all my file navigation.
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.
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.
I have mostly stopped using cd at all, working with absolute paths + tab almost exclusively. The benefit is that your ctrl + r archive of commands become immediately useful, independent of the current location. It's probably not that useful when you spend the whole day on the command line, but as an occasional visitor I find it quite convenient. I imagine it could make a real difference in a low latency console/high latency filesystem setting, if there is at least some repetition.
I think, I'll try this. It sounds like a good idea, but I wonder if the benefit outweights the cost of having to prefix all paths. It occurs to me that I can make a keybound function that inserts $CWD, so it ends up expanded in the history.
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.
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.
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.
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.
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.
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.
> 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.
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.
> Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages?
A fully-extensible, flexible environment which anyone (even a secretary!) can easily extend.
> About text editor features, your workarounds have flaws compared to good GUI.
They're not workarounds; they are the features. emacs has a GUI. I repeat: emacs has a GUI. Tooltips in a GUI display as you'd expect. Folding in a GUI displays as you'd expect.
> Another text editor feature hard to do in text mode is spell checking for strings and comments. Color is already used for syntax highlighting, so wavy red underlines come handy.
Terminals support underlines!
> But visual studio is more than an editor, it includes a build system, debuggers and profilers, package manager, and many more related features.
Have you ever used emacs? It's more than an editor; it connects to build systems like make, maven, gradle, ant, what-have-you. It has its own elisp debugger, connects to gdb, SLIME provides an integrated Common Lisp debugger &c. It has a profiler. It has a package manager. It has a best-of-breed git interface, Magit. It has a best-of-breed personal organiser, Org-mode. It has multiple email clients (rmail, vm, gnus & notmuch come to mind, but there are probably more). It has multiple web browsers (emacs-w3m, eww, w3 & a new experimental WebKit-based browser). It has multiple image viewers. It has multiple terminals & its own shell.
Emacs is far, far 'more than an editor.' It's probably the single editor which is the furthest from being just an editor. Don't trust me: give it a shot! It really is a wonderful experience.
And yes, it has a GUI. Images, scrollbars, menubar, toolbar: the works. Runs on X11, macOS & Windows. And it also runs perfectly well in a VT100 terminal. You can use the same emacs locally and remotely, over SSH. It's pretty awesome.
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.
> which anyone (even a secretary!) can easily extend
Even if that’s true, we’re talking about development environments here, so secretaries are irrelevant. I’ve been programming C++ and C# for decades, for me, visual studio is quite flexible and extensible.
> Terminals support underlines
I specifically told about wavy red underlines for spell checking, and terminals don’t support that. Simple underlines are too intrusive i.e. they often mask '_', and don’t stand out visually from normal text.
> It's more than an editor; it connects to build systems like make, maven, gradle, ant, what-have-you.
I know it’s possible to integrate everything in Linux ecosystem. I just don’t want to waste my time connecting, integrating, and then supporting the setup that just works out of the box on Windows, with freeware visual studio.
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.
Terminals do have rich text, I have to point that out. Not conhost, the default one on Windows (though I think the latest Windows update might have it).
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.
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.
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.
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...
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...
Emacs 25 GUI gives me wavy red lines (via Flyspell).
> tooltips
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
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
There doesn't seem to be anything about those features that makes them require a GUI.
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.
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.
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.
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.
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.
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).
> 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).
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.
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.
My point that those stats are not necessarily representative of the general population in that CLI editors are used by even less people than listed there. In my personal experience maybe 1% of the developers I know use them as their primary editors. They maybe edit some stuff with them on remote Unix systems, if you can call i<change some stuff>:wq real editing :)
[deleted]
Spacemacs has excellent context menus. It was suprising how discoverable everything is!
vim supports all of those things out of the box, both in GUI mode (gvim/MacVim) and terminal mode (vim).
Emacs supports all of those things out of the box as well.
Emacs supports all of those things out of the box as well.
Programming like 1980!
At least has colors instead of having everything in green.
Really the extent people go to avoid using modern developer tools.
At least has colors instead of having everything in green.
Really the extent people go to avoid using modern developer tools.
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.
And, unlike some of its competitors, it's free and easily user-extensible.
Emacs still lacks quite a few improvements XEmacs had over it, and many Lisp Machine features are yet to be available on it.
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/