I've never gotten that plugin to work well with my PHP code. Code complete is awful. I've switched over to PhpStorm for PHP code because it has static analysis and refactoring.
Seconded; GoSublime gives you a nice REPL for Go's build and test commands, package completion and linting. It is the second Sublime Package I install, after Package Control and before my own Antiki.
It's spelled "Emmet" (docs.emmet.io) and it's more widely known as "Zen Coding". (I asked the author about the name change and forgot why now - some sort of trademark dispute).
Yeah, it seems like Emmet removed one of my favorite features with Zencoding. I could hop into a string of HTML attributes and hit "." or "#" and it would create a new attribute of class="|" or id="|" respectively, and place the cursor in between the quotes.
I never had to use a hotkey in the past. I do for regular expansion, and I haven't looked into why koans stopped working, but I imagine that is hotkey related.
I've always struggled to get SublimeCodeIntel to work under Linux, and when I've seen it work, it's not very good.
CTags is absolutely fantastic though, I live and die by it in large code bases. It's backed by ctags on the system too, so it has an impressive list of supported languages.
He earned a 6 month holiday considering the workrate he put in on those early builds, and the amount of cash he must have made in the intervening time.
It's not like the thing is riddled with outstanding issues.
I'd love to see that, too! Jon's been putting out updates way too fast [0] to be able to keep that up forever, though. The API[1] is good enough that generations of plugins could be considered future versions. I'm glad it's successful enough that he can afford a vacation.
Speaking as the developer of the Git plugin on that list, the only thing I feel is missing from the API is a way to add colors or labels to filenames in tabs and the sidebar. Otherwise it's been pretty great.
If you use a dark color scheme, you should install a theme that has a similarly dark background for the sidebar.
The "Soda Dark" theme goes well with the default color scheme. (The ui theme is separate from the syntax highlighting color scheme, you don't have to use the text colors seen on the github examples)
Not a plugin, but if you haven't realised it yet, know that the multiple cursors each come with their own separate clipboard. Learning how to combine this with the move and select by word and the parenthesis-movement commands is what will make the vim users eventually respect you.
Oh and you can hack your language syntax definition files to make more things apart from function definitions turn up in the function browser. This is especially useful for ruby DSLs, sinatra etc.
Back in the day, that's all we had. Microsoft editors were all white-on-blue and Borland editors were all yellow-on-blue. We didn't even have syntax highlighting. And some of us liked it that way. Get off my lawn!
pfft, you had blue? ;) I was happy to finally, one day, have a CURSOR! Oh crap, it blinks! Wow, high tech type!
Well, all this fun talk of SublimeText2, and my .2c .. I have been using ST2 for a long time now as an editor for MOAI, in which facility it really works well and .. well I've come to really love the editor, like love it, but am a vim user, 100%, and often get sad when I switch back and forth .. ;(
ST2, for MOAI and the Lua language, actually is really a sublime IDE experience, and imho the word sublime can be applied to this experience: I am using the same editor on both editor'ish platforms (osx, linux), and then building an app with its own language/VM wordspace that runs on .. everything .. iOS/OSX/Linux/Win/NCl/etc.
Right now in space-cadet mode, hacking on a laptop in some cafe, I sit in SublimeText2 .. hit alt-R, the MOAI app runs, its great, I commit to repo, the buildserver builds and runs the very same app on the nexus7, iphone5, pandora, osx, linux desktops, and various other sundry devices around the place.
In this capacity, ST2 has mastered my needs for integrated development. I guess I should learn how to read HN with it, next ..
I'm a big fan of the Nil theme (https://github.com/nilium/st2-nil-theme). I really love the modified indicator on the tabs. Just be sure to follow the instructions when installing, because you have to turn on a sublime setting. Also, be sure to restart when switching themes, sometimes not everything works right unless you do. This goes for every theme though.
You can also check Tuts+ free tutorial about ST2. It contains a list of interesting plugins (most of them mentionned in this article) alongside others I find quite useful.
This is interesting. I guess it's so that if you cat a file, it doesn't clobber your cursor? I've always noticed that git will say "No new line at end of file", but I've never really known if that's a bad or good thing, or why it matters.
When someone opens up a file created with Sublime Text 2 with vim or emacs and saves it, it clutters the commit messages. It's clutter whether the file contains other changes or not. It still shows up in diffs unless you suppress whitespace.
I would argue that the person with their vim set up to create that clutter is to blame here. If there's no objective reason to fix it other then "well, this is what vim does", then fix vim.
If i'm not mistaken, it is the lack of inserting a newline on sublimes part that is to blame here. It doesn't just break vim, but other software such as cat, git, etc.
Some might argue that when you save a file that hasn't changed that should be a no-op. I don't think so, though. I appreciate a program that does exactly what I tell it to do.
First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical)... But I'll bite.
First the parent mentioned "if you're on Unx". What makes you think you* are the one correct with your text editor's behavior and that the traditional Unxy way of doing it is not correct? (and OS X is a Unx variant).
Then it's trivial to modify Emacs so that it exhibit the behavior you want. Is it trivial to modify Sublime Text Editor 2 to that it behaves on Un*x like vim and Emacs do?
I'll never ever understand "programmers" who aren't using a programmable text editor.
But I don't care: time is on my side. Emacs was there 35 years and still shall exist long after all these glorified Notepad shall long be dead ; )
The diff tools can ignore the reality of the files, but it would be a foolish default.
It's right because the vast majority of newcomers believe that they are adopting UNIX and having a newline and the end of a file is an important tradition. There are some good places to upset the status quo but this is not one of them.
>First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical).
As long as you (or anyone else) doesn't write any new cooler diffs (though part of what you ask already exists), what they "should do" doesn't matter and doesn't change the fact at all.
"I'll never ever understand "programmers" who aren't using a programmable text editor."
I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them. Sublime is perfectly programmable through judicious use of plugins and snippets anyway.
A subset of that, I'll never understand emacs users.
You can use both Emacs and vim in this "judicious use of plugins" style, and there's such an abundance of starter kits and battle tested configurations that the default of either is nothing you need to spend hours configuring your way out of.... There's a reason why these tools are so long lasting, and both absorb every new feature displayed by new editors. TextMate is clearly surpassed by Sublime, even though you could feasibly mod it to adopt those features which make ST2 better.
Emacs (and possibly Vim) could also implement any feature you could reasonably expect from a text editor, and in many cases it already has them, you maybe just don't know.
But this is 2013, and you're not alone, people all around the world are improving Emacs all the time, and have been for 30 years+ ... you don't HAVE to do all the work, you can just use it.
As the man says, Emacs and Vim will be here long after John Skinner has got tired of ST2 and quits developing it.
I still have a habit, even in vim, of putting a newline at the end of the file (such that now I end up with two newlines). Old habits die hard, I guess.
For everyone using SublimeLinter - I'm curious if you've tried sublimelint (the parent project) recently and if there's any reason you chose SublimeLinter over it.
Uh, I'm in the same boat as the person you responded to and I am still confused. What are the advantages of sublime over vim (rather than ways that Sublime can emulate vim)?
I tried this after learning vim, and it seemed to suffer from an uncanny valley problem. Once you get into the flow of things, you'll start treating it like vim, and then when something suddenly behaves slightly different or doesn't work at all, it's very disruptive. I can't think of a specific example right now unfortunately, as that was a while ago, but it happened regularly.
I switched to vim a year ago, and I fucking love it. The one thing I miss from ST2 is column editing/multiple cursors. Column editing fulfills the same kind of need as basic usage of vim macros, I think (i.e., applying some kind of sequence of edits to multiple rows), but it's visual and you get instant feedback (across all rows), which makes it easier and something you can sort of feel out iteratively.
For example, supposed I have a row like (making up these names as I go, and suppose the list is longer):
and I want to insert after the first underscore the word class, so I'd get Controller_Class_Section and so on (this is a contrived example, but one has to do these kinds of things sometimes.)
In vim, I think I'd record a macro, but I'd probably forget some parts (like moving to the next line at the end) and have to undo and whatnot (could use a regex too, but that's a bit harder--I'm practicing recently to be able to do it more effortlessly.)
In ST2, what you do first is create a cursor at the beginning of each row (option + down arrow on OS X.) Then you move ahead one word (Opt + Right arrow on OS X.) Now the cursor is right before the underscore, even though the underscore is in a different position on each row. You can see that it's in the right place on each row, so it's hard to make a mistake, and if you need to do something more complicated, that remains true. Then, you just type _Class, and it types live on each row, once again making it so you get instant feedback, and it's hard to make a mistake.
That to me is the biggest actual advantage of ST2 over VIM, but there are other reason to not switch, like vim's steeper learning curve (when most of us are already busy, and learning other stuff at the same time), and the fact that some people prefer the mouse, which behaves strangely in vim.
Multiple cursors sound cool! In vim, you can do something more limited by using visual block mode (C-v) to insert on multiple lines, but you're restricted to insertion on the same column.
The perhaps the closest thing I can think of for your example would be this (starting in normal mode with the cursor at the beginning of your list):
f_i_Class<Esc>+;.+;.
("Move forward to the next '_', enter insert mode, insert '_Class', leave insert mode, move down one line to the first non-blank character, repeat the forward motion, repeat the insertion, repeat forward motion, repeat insertion." Vim does have word motions, but it includes underscores as parts of words.)
Edit - formatting and a clarification that it's the closest I can think of (I'm doubtful it's the closest you can get).
Macros are the way I solve this as well. A little practice, and you won't even notice the difference. Just hit `Esc j` before ending the macro recording and moving down a line is no longer a problem :)
Rather than replaying it line by line, you can play it over a range. If you do this in your vimrc:
vnoremap @q :normal @q<CR>
You can record the macro in q register, select the visual range, and then do @q to run it over the range. The advantage of doing it thus is you don't have to run the macro manually on every line, and you can undo all change with one u.
Also, normal takes ranges(and not just visual ranges). If you want to run the macro recorded in q over lines 15,49, you can do:
:15,49normal @q<CR>
I use the same trick for repeating commands over a range too.
vnoremap . normal .<CR>
As usual, it doesn't have to be visual range. But I mostly use visual ranges, and so I have defined shortcuts for visual ranges.
Yeah, that's totally what you'd do, in either editor. But my broader point is that there are situations where the immediate feedback and interactivity of using multiple cursors is valuable.
How is immediate feedback and interactivity going to help if the changes span more than one page? If you are going to extrapolate(looks fine on this page, must be fine elsewhere), you can very well extrapolate from a smaller sample size(run :s/some_crap/some_other_crap/gc, check one or two occurrences, then do 'a' for all).
To do the task you mentioned in vim I would move the cursor to the first letter of the word Section in the first line. Then I'd insert "Class_" and go back to normal mode. After that I'd move the cursor to the first letter in the word Model in the second line. And then I'd press the dot key and do the same with the other lines in supposedly longer list.
I do that with Sublime Text 2 using the vim plugin (vintage). I would've never switched from vim if not for this plugin. Now I have (most) of the best of both worlds.
> And then I'd press the dot key and do the same with the other lines in supposedly longer list.
I am posting this again(posted above about running a macro on a range), but I guess lot of people don't know about this.You need not manually press . on every line. You can run . operator on a range. Do a visual select and then
:'<,'>normal .<CR>
The range('<,'>) is inserted automatically when : is pressed from visual mode. So it boils down to visual mode, select, :normal . <CR>
You can have any ranges you want.
:15,49normal .<CR>
I have a shortcut for visual range defined in my vimrc
I use Sublime Text 2 for its GUI powers: proportional-width fonts (I use Verdana), the code minimap, and the pretty file-browser sidebar with easy-to-click disclosure triangles.
I also like that it’s easier to remember most Sublime Text 2 commands – the Command Palette (⇧⌘P) lets you fuzzy search all commands. So you can search for “syntru” and find the option “Set Syntax: Ruby” instead of having to remember Vim’s “:setf ruby”.
Finally, I use Expand Selection to Word (⌘D) to quickly select multiple instances of a variable whose name I want to change – it’s slightly more convenient than it would be in Vim.
On the other hand, I miss Vim’s editing model. It’s a lot more cumbersome to edit line-wise or move the cursor with Sublime Text’s keyboard shortcuts. And Sublime Text’s “Vintage” Vim emulation mode is a poor substitute. As another commenter said, Vintage is in the uncanny valley. Every now and then you run into a Vim command that just doesn’t work and it breaks your flow. For example, Escape is overloaded as both “go from Insert mode to Normal mode” and “collapse multiple carets into one”, and I never remember which it will do when I have a multiple selection in Insert mode.
I've been in the process of switching from Vim to ST2 for a couple months (custom plugins in both, not in a hurry) and the main reason for doing it is because Python and the extension API are MUCH better than the Vim equivalents. If you don't do custom plugins, it really doesn't matter.
Part of the reason for the delay is the lack of equivalent Vim workflows in Vintage. This has been improving a lot thanks to the people working on Vintage and at this point the only holes in my set are c-i/c-o and surround.vim shortcuts. I had to re-train myself to go from Esc to ctrl-[ since Esc conflicts heavily in ST2 but I've been meaning to do that for years in Vim anyway so I consider that a benefit.
I find Coda to have too much stuff. I don't want something that has a bunch of fancy icons and I have to scroll left/right to find my files and has 15 different areas all with extra garbage you don't need (such as the entire right bar which is mostly useless too me).
However the project control part of Coda is amazing.
So it's a matter of how experienced web developer and what exactly do you do? If you do mostly HTML/CSS/JS, then Coda is for you. If you do mostly other stuff hardcore JS, ruby, php, lua, blah blah blah. I'd say sublime.
You might also want to try (my plugin) BrowserRefresh: Save the file you are working on and refresh your browser (or many browsers) with one keystroke.
I would avoid Prefixr like the plague as it's broken to the point of being destructive, and not maintained. Installed it today before I saw this post, stopped using it immediately.
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.
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 ))"
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.
> 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.
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.
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)
> 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".
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.
Sublime Text 2 plugin writing is surprisingly easy via python. I recently wrote a plugin (SublimeJump https://github.com/tednaleid/SublimeJump) to let you jump to any visible character with a couple of keystrokes. It's similar to AceJump (emacs) or EasyMotion (vim) if you're familiar with those.
I used SublimeCodeIntel some time ago and while it worked as advertised, I ended up having to remove it since it was causing ST2 to hang especially on large codebases.
159 comments
[ 3.3 ms ] story [ 245 ms ] threadI've had some luck using the branch version which you can grab here: https://github.com/Kronuz/SublimeCodeIntel
[1] https://github.com/DisposaBoy/GoSublime
Emmet is kind of version 2 of zencoding. But for as far as you should concern yourself they are two different plugins.
Link to plugin: https://github.com/SublimeText/CTags
CTags is absolutely fantastic though, I live and die by it in large code bases. It's backed by ctags on the system too, so it has an impressive list of supported languages.
Additionally, as a scientist, I use a lot (and like a lot) https://github.com/SublimeText/LaTeXTools.
It's not like the thing is riddled with outstanding issues.
[0] https://www.sublimetext.com/dev
[1] http://www.sublimetext.com/docs/2/api_reference.html
The "Soda Dark" theme goes well with the default color scheme. (The ui theme is separate from the syntax highlighting color scheme, you don't have to use the text colors seen on the github examples)
https://github.com/buymeasoda/soda-theme/
In terms of plugins, apart from the ones mentioned here, Quick File Creator is indispensable: https://github.com/noklesta/SublimeQuickFileCreator
Not a plugin, but if you haven't realised it yet, know that the multiple cursors each come with their own separate clipboard. Learning how to combine this with the move and select by word and the parenthesis-movement commands is what will make the vim users eventually respect you.
Oh and you can hack your language syntax definition files to make more things apart from function definitions turn up in the function browser. This is especially useful for ruby DSLs, sinatra etc.
http://wesbos.com/cobalt2-theme-sublime-text-2/
Well, all this fun talk of SublimeText2, and my .2c .. I have been using ST2 for a long time now as an editor for MOAI, in which facility it really works well and .. well I've come to really love the editor, like love it, but am a vim user, 100%, and often get sad when I switch back and forth .. ;(
ST2, for MOAI and the Lua language, actually is really a sublime IDE experience, and imho the word sublime can be applied to this experience: I am using the same editor on both editor'ish platforms (osx, linux), and then building an app with its own language/VM wordspace that runs on .. everything .. iOS/OSX/Linux/Win/NCl/etc.
Right now in space-cadet mode, hacking on a laptop in some cafe, I sit in SublimeText2 .. hit alt-R, the MOAI app runs, its great, I commit to repo, the buildserver builds and runs the very same app on the nexus7, iphone5, pandora, osx, linux desktops, and various other sundry devices around the place.
In this capacity, ST2 has mastered my needs for integrated development. I guess I should learn how to read HN with it, next ..
https://tutsplus.com/course/improve-workflow-in-sublime-text...
SublimeREPL - run an interpreter inside ST2 (Clojure, CoffeeScript, F#, Groovy, Haskell, Lua, MozRepl, NodeJS, Python, R, Ruby, Scala, shell or configure one yourself) https://github.com/wuub/SublimeREPL
"ensure_newline_at_eof_on_save": true,
to the user settings fixes this.
First the parent mentioned "if you're on Unx". What makes you think you* are the one correct with your text editor's behavior and that the traditional Unxy way of doing it is not correct? (and OS X is a Unx variant).
Then it's trivial to modify Emacs so that it exhibit the behavior you want. Is it trivial to modify Sublime Text Editor 2 to that it behaves on Un*x like vim and Emacs do?
I'll never ever understand "programmers" who aren't using a programmable text editor.
But I don't care: time is on my side. Emacs was there 35 years and still shall exist long after all these glorified Notepad shall long be dead ; )
It's right because the vast majority of newcomers believe that they are adopting UNIX and having a newline and the end of a file is an important tradition. There are some good places to upset the status quo but this is not one of them.
As long as you (or anyone else) doesn't write any new cooler diffs (though part of what you ask already exists), what they "should do" doesn't matter and doesn't change the fact at all.
Actually it reminds me of the "sufficiently smart compiler": http://c2.com/cgi/wiki?SufficientlySmartCompiler
I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them. Sublime is perfectly programmable through judicious use of plugins and snippets anyway.
A subset of that, I'll never understand emacs users.
Emacs (and possibly Vim) could also implement any feature you could reasonably expect from a text editor, and in many cases it already has them, you maybe just don't know.
But this is 2013, and you're not alone, people all around the world are improving Emacs all the time, and have been for 30 years+ ... you don't HAVE to do all the work, you can just use it.
As the man says, Emacs and Vim will be here long after John Skinner has got tired of ST2 and quits developing it.
I have no desires to spend hours configuring my editor, but I need an extensible editor.
> Sublime is perfectly programmable through judicious use of plugins and snippets anyway.
Yes. Sublime qualifies as a programmable editor.
Could you clarify this? I work with text files on both Windows and Linux all the time, and
View -> Line Endings -> {Platform}
seems to convert between EOL conventions on the different platforms as I would expect.
http://www.sublimetext.com/docs/2/vintage.html
Also see https://github.com/SublimeText/VintageEx which adds the vim command line.
For example, supposed I have a row like (making up these names as I go, and suppose the list is longer):
and I want to insert after the first underscore the word class, so I'd get Controller_Class_Section and so on (this is a contrived example, but one has to do these kinds of things sometimes.)In vim, I think I'd record a macro, but I'd probably forget some parts (like moving to the next line at the end) and have to undo and whatnot (could use a regex too, but that's a bit harder--I'm practicing recently to be able to do it more effortlessly.)
In ST2, what you do first is create a cursor at the beginning of each row (option + down arrow on OS X.) Then you move ahead one word (Opt + Right arrow on OS X.) Now the cursor is right before the underscore, even though the underscore is in a different position on each row. You can see that it's in the right place on each row, so it's hard to make a mistake, and if you need to do something more complicated, that remains true. Then, you just type _Class, and it types live on each row, once again making it so you get instant feedback, and it's hard to make a mistake.
That to me is the biggest actual advantage of ST2 over VIM, but there are other reason to not switch, like vim's steeper learning curve (when most of us are already busy, and learning other stuff at the same time), and the fact that some people prefer the mouse, which behaves strangely in vim.
The perhaps the closest thing I can think of for your example would be this (starting in normal mode with the cursor at the beginning of your list):
("Move forward to the next '_', enter insert mode, insert '_Class', leave insert mode, move down one line to the first non-blank character, repeat the forward motion, repeat the insertion, repeat forward motion, repeat insertion." Vim does have word motions, but it includes underscores as parts of words.)Edit - formatting and a clarification that it's the closest I can think of (I'm doubtful it's the closest you can get).
Also, normal takes ranges(and not just visual ranges). If you want to run the macro recorded in q over lines 15,49, you can do:
I use the same trick for repeating commands over a range too. As usual, it doesn't have to be visual range. But I mostly use visual ranges, and so I have defined shortcuts for visual ranges.To do the task you mentioned in vim I would move the cursor to the first letter of the word Section in the first line. Then I'd insert "Class_" and go back to normal mode. After that I'd move the cursor to the first letter in the word Model in the second line. And then I'd press the dot key and do the same with the other lines in supposedly longer list.
Now I seem to spend a few months with vim as my primary editor, get tired of it, switch to ST2 for a few months and then switch back.
I am posting this again(posted above about running a macro on a range), but I guess lot of people don't know about this.You need not manually press . on every line. You can run . operator on a range. Do a visual select and then
The range('<,'>) is inserted automatically when : is pressed from visual mode. So it boils down to visual mode, select, :normal . <CR>You can have any ranges you want.
I have a shortcut for visual range defined in my vimrcYour example is not a candidate for a macro, a simple substitution is enough:
If you are comfortable with ranges, the operation can be done in one go: Also there are already a few plugin authors exploring the multiple cursors idea, however gimmicky it is.I also like that it’s easier to remember most Sublime Text 2 commands – the Command Palette (⇧⌘P) lets you fuzzy search all commands. So you can search for “syntru” and find the option “Set Syntax: Ruby” instead of having to remember Vim’s “:setf ruby”.
Finally, I use Expand Selection to Word (⌘D) to quickly select multiple instances of a variable whose name I want to change – it’s slightly more convenient than it would be in Vim.
On the other hand, I miss Vim’s editing model. It’s a lot more cumbersome to edit line-wise or move the cursor with Sublime Text’s keyboard shortcuts. And Sublime Text’s “Vintage” Vim emulation mode is a poor substitute. As another commenter said, Vintage is in the uncanny valley. Every now and then you run into a Vim command that just doesn’t work and it breaks your flow. For example, Escape is overloaded as both “go from Insert mode to Normal mode” and “collapse multiple carets into one”, and I never remember which it will do when I have a multiple selection in Insert mode.
Part of the reason for the delay is the lack of equivalent Vim workflows in Vintage. This has been improving a lot thanks to the people working on Vintage and at this point the only holes in my set are c-i/c-o and surround.vim shortcuts. I had to re-train myself to go from Esc to ctrl-[ since Esc conflicts heavily in ST2 but I've been meaning to do that for years in Vim anyway so I consider that a benefit.
However the project control part of Coda is amazing.
So it's a matter of how experienced web developer and what exactly do you do? If you do mostly HTML/CSS/JS, then Coda is for you. If you do mostly other stuff hardcore JS, ruby, php, lua, blah blah blah. I'd say sublime.
It especially is great for ruby/html/css. Give it a shot :)
http://gcollazo.github.com/BrowserRefresh-Sublime/
#ShamelessPlug
https://github.com/wbond/sublime_prefixr/issues/4
Surely unless you have some ideological reason to pick a FOSS editor, you'll simply use the best one available.
+ Multiple cursors + Column edit + JSON configuration files + Plugin support + Textmate themes + Python code base (easy to create plugins)
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 ))"
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.
Use the best tool for the job. Screw extreme philosophies.
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.
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)
(And I'm saying it as a long time Vim user, from the Sun O.S/fvwm days of lore as well as a heavy Eclipse user in the early to mid '00s).
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.
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 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.
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".
Does anyone know if that's possible in Sublime Text?
Link to the xterm font: http://yootles.com/outbox/FixedMedium6x13.dfont
PS: It also needs the line spacing set to .8 which I've found a way to do in TextMate and Terminal.app.
See http://www.reddshift.com/2011/10/turn-off-anti-alias-for-sub... for how to turn off anti-aliasing, and https://gist.github.com/1149379#file-sublime-text-2-settings... for line spacing.