If it doesn't come with a vim-mode or that vim-mode is slow and painful to customize, then this will be useless.
That's not true.
People like myself who don't use Vim can still navigate code at speed.
GitHub's new text editor leaked on Twitter
231–240 of 262 posts
Re: GitHub's new text editor leaked on Twitter
#232Re: GitHub's new text editor leaked on Twitter
#233Apparently it collects usage information? https://github.com/atom/welcome/pull/7 Thanks, but no thanks. I don't need my editor sending usage information anywhere.
That commit summary is "Be up front about collecting usage information." If a company can make a better product because they collect usage information, and if they are up front about it and allow you to disable the data collection, then I'm all for it.
Re: GitHub's new text editor leaked on Twitter
#234Earlier quoted context omitted.
I’ve used Evil in Emacs with http://orgmode.org/ , after having learned Vim. I’d say Evil is another great, thorough emulation of Vim. It includes even relatively-obscure features like visual block mode, R, K, v_o, :%!sort, ^W window split/switch/close commands, and Vim’s tree undo model. My only problems with Evil are where Emacs or Emacs plugins’ bindings conflict with Vim bindings, such as v_^G (that is, Ctrl-G in…
I recall this most recent emacs effort the best of all the previous attempts (Viper etc). I believe there was one thing I couldn't fix: When in command mode (such as when you type :e etc), hitting back space stops at the last deletion. In Vim, if you continue pressing backspace, the editor cursor starts moving back (as if you're pressing `h` in normal mode). (Did you figure out how to fix this?) It's the little thing…
I don’t understand your backspace problem. In all of the following cases, Vim 7.3 and Emacs 24 with Evil act the same:
In Command-line mode (by typing `:`), when there is text after ‘:’ and before the cursor, typing Backspace deletes one character behind the cursor. In Command-line mode, if there is no text left but ‘:’, it exits Command-line mode, changing to Normal mode. Emacs displays Quit in this case, while Vim just exits silently. If I press Backspace in Normal mode while the cursor in the middle of a line, the cursor moves back one character as if you pressed `h`.
My full Evil config is here: https://github.com/roryokane/emacs.d/blob/master/init.el#L12.... But I don’t see anything in it that would change the behavior of Backspace.
I did just notice an inconsistency with Backspace, but it doesn’t sound like what you’re talking about: if you press Backspace in Normal mode while the cursor is at the leftmost column, the cursor wraps to the previous line in Vim, but stays in the same place in Emacs. The cause of that behavior in Vim is the 'whichwrap' option’s value containing “b”. Evil has a rough equivalent to that option in evil-cross-lines (a boolean), but I don’t know if it has an equivalent that lets you selectively enable wrapping only for Backspace and Space. https://bitbucket.org/lyro/evil/issue/247/evil-invert-char-s... implies that there was no exact equivalent as of Febraury 2013.
Re: GitHub's new text editor leaked on Twitter
#235Earlier quoted context omitted.
> it looks like this is a GitHub-aware/integrated text editor that targets both desktop (Mac, at least) and web I can confirm, from looking at the code. It uses CSS / LESS for highlighting, and CoffeeScript for client-side programming (eg, the fuzzy completion[0], or the autocompletion). The surprising part is that the editor doesn't seem to be a fork of either Ace or CodeMirror, the two big guys in the field. The hi…
I hope they won't use this awkward "double-escaped backward-slashes in reglular expressions" environment. YAML[1] is much better for this. [1]: https://github.com/SublimeText/AAAPackageDev/blob/master/Syn...
> I hope they won't use this awkward "double-escaped backward-slashes in reglular expressions"
Yes, they will[0]. YAML is definitely better, but I believe they have a strong opinion against YAML[1].
[0]: https://github.com/atom/language-toml/blob/master/grammars/t...
Re: GitHub's new text editor leaked on Twitter
#236Flattered to see it using marked for the markdown engine. Maybe the world is finally ridding itself of showdown.
And rightly so! Marked indeed is a fine 𝗠⬇ parser! How would you compare your approach to e.g. markdown-js¹, mdown-parse-pegjs², or text.js³ (which are based on PEG parsing)? I would like to elaborate a bit on the specific differences/benefits between the many MD parsers. (I’m maintaining an inventory of Markdown resources in a repo on Github.⁴) [¹] https://github.com/evilstreak/markdown-js [²] https://github.com/sh…
Thanks.
Speed was originally marked's top priority. I would say marked's approach takes advantage of the fact that v8 generates _extremely_ fast machine code for regexes. This is just something I discovered through many endless nights of benchmarking the entire markdown test suite.
Using complex regexes for the lexemes seems like a stupid idea to most people, but it allowed me to optimize marked like crazy, so much so that it beat discount(written in c) in benchmark times (It might be a little bit slower now due to the latest features. I decided to ignore speed for a while to focus on features - will get back to optimization eventually).
The downside of all of this: marked loses some extensibility, however, we implement as much extensibility as possible by exposing the token stream and renderer.
Accuracy and sanity quickly became marked's next top priority. There's a certain threshold of accuracy you want in a markdown engine (you don't want it to be too accurate because markdown.pl had a lot of bizarre behavior). That's a different story.
Re: GitHub's new text editor leaked on Twitter
#237Earlier quoted context omitted.
Atom: http://i.imgur.com/0Qfwkp4.png SublimeText: http://i.imgur.com/frzYwwc.png Case in point.
The UI is undoubtedly similar, but Atom appears to be written in Coffeescript. Isn't Sublime written in C and Python?
Couldn't this effectively be "Sublime Text 4," written from scratch using ST3's proven approaches? I honestly have no clue, I just want to believe.
Re: GitHub's new text editor leaked on Twitter
#238Earlier quoted context omitted.
This looks pretty cool, there seems to be Vim shortcuts [1] and even theming. Judging from your screenshot, Solarized Dark is the default theme? But I'd have to wait until its release (or beta, should I be so lucky!) to consider moving from standard vim editor and Solarized in my Xresources. [1] https://github.com/atom/vim-mode
I always wonder why I learned emacs over vim. There is never support for it.
I learned Emacs because there was nothing that supported Common Lisp editing the way Emacs did.
Re: GitHub's new text editor leaked on Twitter
#239"Atom is free during the beta period." https://github.com/atom/welcome/commit/86790ef7cca263ca0943f...
Seems like they're going the ST route. I'm kinda disappointed Atom won't be open sourced.
It could also mean they are going the Cloud 9 route (unlimited free public editing, limited free private projects) for the web version, which would essentialy be the same as their current subscription model, while still open-sourcing the editor itself.