It misses Bangalore, India. You could live a good life for $750.00 a month. For an additional $35 a month, you can get a 60MBps internet connection. Weather is pretty pleasant throughout the year. You could sample quite an assortment of cuisines too. Meetups are fairly active as well.
Negatives: Traffic is terrible, but I stay indoors most of the time. Vendors do not speak English, but the number of non-Indians is high and the one can speak in English in any mid-sized shop.
Disclaimer: I am an Indian, but am not a native of Bangalore. I was initially resentful of having to stay in Bangalore, but of late have started liking the city.
I use Emacs for almost all my work, but I find Vi(m)'s editing capability is superior. I use evil-mode and it does extremely well in emulating Vim. Even text-objects and ex-commands are available. ace-jump-mode and undo-tree are two other extensions that significantly improve my editing experience.
I find dired, tramp, org-mode, auctex, magit and good async support indispensible and the Vim equivalents are either less powerful or non-existent.
Yeah. They took ideas from things like PS1 setting with Bourne shell, and kept going. Keeping the variables to single letters was intended to have the format string be approximately the same length as it might actually be displayed. However, that doesn't work well in practice. It would be better to go with keywords (or maybe even key-phrases) instead.
+1 on the search part. I think Sublime shines there. I cannot imagine spending $70 for an editor, but I would really like it if Emacs' code browsing was as smooth as sublime's @
Curious, how do you browse code in Sublime that you can't in emacs? I've seen coworkers using Sublime navigate code much the same as I do in emacs which is mostly just by using incremental search.
I use Emacs at home and ST2 at work, and there are two things that ST2 does much, much better, both related to browsing large projects. One is scrolling - Emacs always wants to jump too many lines at a time, so it's very difficult to get lines of code exactly where you want them. The other is tree navigation - speedbar is more powerful, but you can't see multiple directories at once, which makes it hard to get a feel for the structure of the project as a whole.
Many times, I find myself just 'C-s' or 'C-r' (searching) in Emacs to the piece of code I want, even if it's already visible, then doing 'C-l' to get it centered. And when org-mode is loaded, 'C-l' will cycle through making the current line vertically centered, top of buffer, and bottom of buffer. Not sure it's what you're looking for, but that's what I do, and I'm sure there's a way to customize how far emacs will scroll ('M-x customize-variable RET scroll TAB TAB' might be a good starting point for looking into this).
I also mostly navigate using C-s and C-r. Also, when you do that you can recursively use C-u C-SPACE which brings you back to where you were previously, this feature is really awesome, since most of the time you move in the code temporarily to adjust something somewhere else or even just to lookup something somewhere else.
I was specifically talking about
C-r file@function_name
All the parts are fuzzy. So if I wanted to go to function install_local_package in helper_functions.py, I can type
C-r h_fu@ins_l_p (pretty much like we use ido)
While I use Emacs for all my editing, this would have been cool to have.
While I understand that it is useful to have semantic information (nothing stops Zed from having it from what I can see in its mode files which use ace-editor's modes currently), I don't really think a code-editor needs to come with semantic information for all languages it supports. I don't know if that is even possible in a generic way. I mean, the behaviour of scope itself isn't generic. There are dynamic-scoped languages (like elisp) vs block-scoped languages (Java) vs function-scoped languages (JavaScript) which are all syntax-highlighted by most popular editors. I would relegate such work to heavier IDEs.
Well, my point is not that multi-language code editor must provide semantic information for every language it can edit (that's just infeasible), but that editor's core must be designed with semantics in mind.
I.e., not "well, it's text and core has no idea what it is but plugins are free to do anything with that", but "well, core has no idea what that 'typeclass' thingy code analyzer says it is, but it's happy to keep track of it and provide standard interfaces to use this info so maybe highlighter or code folding parts would figure out how to use that information"
Then you could start with regexp mess-based parser that provides very basic understanding of the code and replace it with something that gives better code insight at later time, without rewriting the rest. And have generic refactoring module that can operate on many languages just by knowing about names and their possible scopes (whatever scoping type language is, in common cases I believe that still could be reduced to "in this text region").
I've heard LightTable is doing something like this, but never had a time to properly evaluate it and see for myself.
Also, JetBrains' IDEs (IntelliJ IDEA, PyCharm, etc.) are notorious to have good understanding of code semantics, both out of the box and through plugin system.
[1] http://plover.stenoknight.com/