Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's new text editor leaked on Twitter

github.com

Post reply on HN
Print view View original

51–60 of 262 posts

Re: GitHub's new text editor leaked on Twitter

#51

Post by roryokane »

benaiah wrote: post #40
jordwalke wrote: post #22

I really can't wait for this to be released. I am a little pessimistic about the Vim mode. There are countless 80 or 90% complete Vim modes in various modern editors. But the absence of a truly native feeling Vim (that last 10%) is a deal breaker for many. I'd rather see more editor developers spend time finding a solution that provides a truly authentic Vim mode instead of spending countless hours merely approaching…

Curious as to your opinion on Evil from Emacs - I've been learning Evil without knowing Vim first, so I don't know what I might be missing.

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 Visual mode) meaning “Quit” instead of “Switch to Select Mode”. Those conflicts aren’t really Evil’s fault – they’re inevitable when combining third-party plugins that don’t explicitly support Evil – but they can be annoying.

I’d say you’re not missing much with Evil that would be in Vim. I suppose you’re mainly missing Vim’s large ecosystem of plugins that are made to work with Vim keybindings and Vim’s editing model – though I see that surround.vim has been ported (https://github.com/timcharper/evil-surround). Plus Vim wouldn’t have Evil’s and Emacs’ keyboard conflicts, of course.

Re: GitHub's new text editor leaked on Twitter

#53

Post by chjj »

benaiah wrote: post #43
chjj wrote: post #36

Flattered to see it using marked for the markdown engine. Maybe the world is finally ridding itself of showdown.

What's wrong with showdown? Legitimate question - I just haven't heard of any complaints about it before.

I'll keep this as short as possible, but that's not easy.

Speed: It's relatively slow (but fortunately faster than markdown.js at the very least).

Quality: It carries with it a bunch of nonsensical quirks. Some of these quirks are inherited from the original markdown, some are unique to showdown. (I feel like I could write a treatise on list behavior alone, and how ridiculously showdown and markdown.pl handle them). It's not what people are accustomed to/find intuitive today. Here's a few problems (with showdown, as well as other engines) presented in a more tangible way: https://github.com/chjj/marked/blob/master/doc/broken.md

Code quality and maintenance: Showdown is a line-for-line port of Markdown.pl. As you can guess, this is not ideal, especially when you consider that the original markdown was written extremely awkwardly - it's essentially a pile of regexes doing global replaces on a single string to produce the output. This is _extremely_ confusing and messy to those who are not familiar with a code, and the original author of showdown, as far as I know, no longer maintains the project.

Re: GitHub's new text editor leaked on Twitter

#57

Post by 1qaz2wsx3edc »

jared314 wrote: post #50
benaiah wrote: post #39

Earlier quoted context omitted.

> An open, compile-less, hot-reloading editor sounds like a dream coming true. You're talking about Emacs, right? This actually seems really exciting, and I'll give it a whirl when and if I can. It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew - modifying your editor in-place is really awesome .

> It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew Since many of the Light Table fans either use or have used Emacs, I would say that it is more of a relief to have something that takes the Emacs concepts and tries to modernize, adapt, or polish them. It might also be good to mention that the Light Table team chose a "usable editor first" strategy to build a user b…

You hit the nail on the head there: "tries to modernize, adapt, or polish them". There's a lot we can do with the stack, we've got websockets (pair programming anyone?), workers, sql, and more baked into browsers. I'm not saying an editor cant do those things, but I think the level of entry and collaboration are totally different outside a web stack.

Re: GitHub's new text editor leaked on Twitter

#58

Post by bsimpson »

netghost wrote: post #14
jitl wrote: post #10

What sets this apart from the other WebKit-based text editors, LightTable and Brackets? In general it seems like there's been an explosion of new text editors with this style since TextMate went into hibernation around 2008. It's great to have options, but there's lots of these TextMate clones now.

TextMate is still alive: https://github.com/textmate/textmate But to your main point, I would assume this has really really really good github integration...

True, but until Sublime started eating his lunch, TM2 was being developed so quiet and slowly that a bunch of people thought it was vaporware. I believe that's what the OP meant by "in hibernation".

Re: GitHub's new text editor leaked on Twitter

#59

Post by shakeel_mohamed »

lelandriordan wrote: post #52
frade33 wrote: post #47

the next big thing for devs. I love sublime and will, but can't figure why is it taking them so long, to launch it on mac appstore.

Apple's 30% cut

Yeah, there's really no incentive for them do it aside from accepting non-Paypal customers.

Re: GitHub's new text editor leaked on Twitter

#60

Post by roryokane »

ChickeNES wrote: post #32
jordwalke wrote: post #22

I really can't wait for this to be released. I am a little pessimistic about the Vim mode. There are countless 80 or 90% complete Vim modes in various modern editors. But the absence of a truly native feeling Vim (that last 10%) is a deal breaker for many. I'd rather see more editor developers spend time finding a solution that provides a truly authentic Vim mode instead of spending countless hours merely approaching…

Why not just use Vim?

Vim does not support graphical user elements, and is built around the unfamiliar language Vimscript. Those drawbacks are pretty baked into Vim and would be hard to change (though someone is trying to: https://www.bountysource.com/fundraisers/539-neovim-first-it...). Many other editors don’t have these drawbacks, allowing them to support features such as these:

• a graphical file tree browser (with icons, not restricted to ASCII art like NERDTree)

• proportional-width fonts

• a zoomed-out-code mini-map scroll bar

• Plugins written in more mainstream, cleaner languages than Vimscript. Vim does have a plugin interface for some other languages such as Python, but some OSs’ provided Vim installations don’t support those languages, and it’s hard to get a version of Vim with support.

Post reply on HN