Not to go all Stallmanesque here, but doesn't it bother you to use a proprietary text editor when there are so many excellent free/open-source ones around?
Not at all. Speaking for myself here, but while I much prefer open source to proprietary software, I find Sublime Text 2 blows any other editor I've used out of the water and I'm not going to not use it just because it's proprietary (same reason I use OS X, Photoshop (versus GIMP), etc).
The "problem" with Emacs and Vim is their out the box state is a bit daunting, if you allow a little time to get used to and configure Emacs, it'll blow the shit out of any editor you've ever used. ... Grab ocodo/emacsd from GitHub, it's a very sublime like setup.
This question really only makes sense to me from a Stallmanesque standpoint though (unless you don't have much money for some reason, in which case the financial considerations come into play.)
Surely unless you have some ideological reason to pick a FOSS editor, you'll simply use the best one available.
I'm certainly not Stallmanesque and I've got money -- in fact, I'm a registered owner of Sublime Text 2, but there is at least one real-world practical way in which ST2 being OSS would be preferable for me. I increasingly do my coding on ARM-based Linux devices as opposed to x86-based ones and ST2 has no ARM build, and repeated requests asking for one are, as far as I've seen, summarily ignored by the author.
If ST2 were OSS I could build it for ARM/Linux myself, everything it relies on is already available on those platforms. But it isn't, so I've had to quit using it and recommending it to others.
Yeah maybe a bit, but to me full Stallmanesque would be avoiding proprietary software even when the free alternative is non-existent or significantly less functional. That is not the situation with text editors, unless I am missing something big that Sublime Text can uniquely do.
Emacs can do all that. I wouldn't be surprised if Vim could too... The point about these two editors is that no matter what feature shows up in an editor, both of them could implement it.
Emacs lets you easily write plugins in python? It's been a while since I used it, but I remember an awful lot of parens any time I wanted to customize something.
Well, the lisp factor is obviously an issue, for people who aren't interested in learning another language, but that's knowledge friction.
It's not particularly difficult to learn Lisp, it needs a nice syntax highlighter to dim away all the parens, but really, it's a very simple language. I'm sure you could write some bad-ass shit if you gave it a little attention.
There are python -> emacslisp bindings available, but I can't speak to that, regarding completeness / stability etc. Frankly I wouldn't suggest anyone waste their time doing that.
But really with such a HUGE resource of functions / libraries, (and some of the cooler features of Lisp, I mean have you seen the loop macro!?) ... it's a bit of a waste to pass it up over its "(( big ears ))"
> Not to go all Stallmanesque here, but doesn't it bother you to use a proprietary text editor when there are so many excellent free/open-source ones around?
Use the best tool for the job. Screw extreme philosophies.
I don't feel like preferring a FOSS solution in a situation where there are plenty of good choices is that extreme. That's why I asked.
If anything, I feel like "Use the best tool for the job and ignore all other factors" is an "extreme" stance. (although Stallman's obviously is as well)
People decide which philosophies are extreme. As individuals (for themselves) and as groups (for their society, group, company, neighbourhood, etc).
Are you of the "anything goes" thinking? I for one, find that attitude TOO extreme. I don't wish to accept (or even tolerate) "anything" just because someone else finds it OK.
Ninja IDE for Python is trying to match up to ST2 (and it feels more IDE-like than ST). Until it succeeds, SublimeText remains a very attractive option.
> When those free/open-source editors come into the 21th century with regards to native integration/UI I might reconsider.
Though both vim and emacs have gui interfaces, most of the users use them inside a terminal. You can wait till 22nd century, but as long as your definition of 21st century isn't the same as developers definition, not much is going to happen.
BTW what century are terminals? If I have to take a bet, I would say come back in 22nd century, and terminals would still be around and kicking. If it was that black and white(ooh, gui is here; let's switch), the switch would have happened. Personally, vim is part of my work environment(terminator running tmux/screen; vim on 0; repl on 1; dbconsole on 2; running tests on 3; ...) and I don't see how a gui editor is supposed to replace that.
>Though both vim and emacs have gui interfaces, most of the users use them inside a terminal.
The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc.
>You can wait till 22nd century, but as long as your definition of 21st century isn't the same as developers definition, not much is going to happen.
I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already.
>BTW what century are terminals?
Mid-20th century.
I don't mind the terminal (I use one everyday and have done so since the day's Sun OS was SUN's offering), but it's also another technology stuck in the past.
Not because of the textual nature etc. Because most of the components are crappy old time things, from terminal emulators to userland unix commands, etc.
Bad support for millions of colors, bad support for Unicode, no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop. Where's a proper autocompletion in the shell that behaves like in a native app? Where's spell checking with wiggle lines?
Only ZSH and Fish tried a few things to take us further, but still very short of what a desktop could be.
I mean tmux/screen borking the scroll buffer? Is this 2013?
> The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc.
The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers.
> I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already.
My comment about waiting was with respect to vim/emacs(as examples of other open source editors). You can wait till 22nd century; it probably still won't happen. Users are mostly happy; developers don't care.
> Bad support for millions of colors, bad support for Unicode,
My terminal(terminator) does that fine.
> no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop.
Why and how would a terminal support JSON? What are those ad-hoc desktop things?
> Where's a proper autocompletion in the shell that behaves like in a native app?
shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. Whether shell offers completion or not depends on the external tool as well. You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>".
> I mean tmux/screen borking the scroll buffer? Is this 2013?
tmux/screen scroll buffers work fine. You are just making shit up.
>The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers.
Way to fuck up the discussion in a disingenuous and insulting way by summing down my arguments to "I like shiny things".
I specifically talked about native integration. That has myriads of aspects, of which "oh, shiny" is just an insignificant part of.
As for the "overwhelming majority of vim/emacs" users using them in the terminal, citation needed.
My anecdotal data tell me that they use them in both in both terminal and GUI form (terminal for working on stuff remotely, admin stuff etc, GUI for long term programming sessions).
Plus, no matter what the "overwhelming majority of vim/emacs" do, those do not represent the future or cutting edge of programming editor use in any conceivable way. And that is precisely what we are discussing.
>bad support for Unicode
>>My terminal(terminator) does that fine.
Does that answer mean that you don't have the mental capacity to follow the discussion? Maybe you're too tired or something?
Isn't it obvious from my comment that I mean Unicode support THROUGHOUT the system? That one or ten terminals has got it doesn't mean a thing if there are 200 other components involved in doing unicode CLI work. For example GNU/BSD unix userland programs supporting full unicode capabilities. Unicode and font-rendering without X-running, etc etc.
>Why and how would a terminal support JSON? What are those ad-hoc desktop things?
What is this stupid notion that I talk about terminal emulators ONLY? I specifically bloody state that I complain about all terminal-side stuff "from terminal emulators to userland unix commands".
In this case, what I ask for (when giving JSON as an example) is a structured way of communication between userland commands, to go beyond '70s style pipes. Microsoft's Powershell AFAIK has some of that built-in.
>shell has to support autocomplete in million things, compared to your native app which only does one thing say Java.
You'd be surprised. And context-sensitive autocomplete is so solved that it's not even a problem...
>You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>".
See how luck of imagination and blind acceptance of what's there cripples programmers?
Off the top of my head: programs could come with definition files for their autocompletion. Adding a program adds those to your shell (in the same way programs come with man-pages).
I seriously hope you don't work in R&D.
>tmux/screen scroll buffers work fine. You are just making shit up.
Only if "switching in copy-mode to scroll, instead of transparently incorporating the terminal scroll buffer" fits your definition of "fine".
