Edit like an Ace | Hacker News Reader

Edit like an Ace

github.com

415 pointssant0sk154 comments

For those following Canvas projects it is worth noting the history here, that Mozilla Bespin became Mozilla Skywriter and then ditched HTML5 Canvas altogether for divs only, finally merging with Ace.

Have you got any links/pointers as to why they switched? I remember their use of canvas being a strategic design choice early on (with IIRC, a list of reasons why just using the DOM wouldn't work so well)

I think the main issues were accessibility, IE support without a canvas stand-in which could be very slow, and accessibility. Also, general rendering is pretty speedy on all browsers, whereas canvas rendering was pretty variable until recently (and still is for fast redraws).

Also makes theming changes quite a lot easier using css.

(http://groups.google.com/group/ace-internals/browse_thread/t..., http://groups.google.com/group/ace-internals/browse_thread/t...)

Implementing good text controls in Canvas is a fool's errand. The spec itself warns against it:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

They wanted to be ambitious and to their credit they got very far. They gave a few talks on the hurdles they had to overcome. Measuring the height of text, making their own custom scrollbars, resizing woes, etc. They did a good job with a lot of it.

They admitted it was fun but too hard to get everything right. They ran into most of the problems in the spec: "Unlike Skywriter, Ace uses the DOM to render instead of the <canvas> element making it compatible with a wider range of browsers and potentially giving it a leg up in accessibility."

http://mozillalabs.com/skywriter/2011/01/18/mozilla-skywrite...

The code for Skywriter was actually really good. I used a lot of it to make my in-canvas scrollbars before moving on to my own code.

They would have preferred to go this route in the beginning. I think the main reason at the time for avoiding DOM was actually performance -- probably all the various improvements in browsers since then have changed the situation.

I happen to know the story, since I was there for much of it.

IIRC, Ben and Dion originally went the canvas route for:

1. fun 2. performance 3. total control over rendering

I was never personally involved in the rendering part of Bespin. I do remember talking with Dion one day and he was telling me that he thought it would be possible to make a DOM-based renderer that performed well. We had lots of other stuff to do, though.

Time passed... We rejiggered Bespin a good deal before it became Skywriter.

Then, last September, I was in Berlin with Joe Walker and Patrick Walton. We were walking from the hotel to JSConf.eu and talking about accessibility and DOM-based rendering. Coincidentally, that very day Fabian Jakobs of Ajax.org showed off Cloud9 and Ace (which used DOM-based rendering and was, indeed, quite fast).

I'll just note that accessibility and full internationalization are *hard, if not actually impossible, to do with pure JS in the browser alone. I recently started a feature page to start gathering information about exposing more APIs to browser content to enable the creation of fully a10y- and i18n-ready editors:

https://wiki.mozilla.org/Features/Desktop/EditorAPI

Anybody can shed some light on how Ace works?

By having this tied into github I'm beginning to see how use Ace (or similar) instead of vim/emacs as a day-to-day code edit workflow...

Just fork a project to your account on github, edit in Ace, and then make a pull request when you are done.

Would people do this? If not, is Ace just going to be for minor edits, etc?

I'm curious how other people will use this.

EDIT: people the child comments are telling me the fork is done automatically for you - cool. I need to play around with this on other projects!

Imho, if i'm going to download the code to run and test it anyway, i might as well use an editor on my computer (vim/e/sublime) and skip Ace.

Ace is gradually gaining full IDE features like syntax checking, split views, and responsive behaviours such as auto-brace/bracket/parens insertion.

If you want an online-only workflow, Cloud9 already offers github as a backend for an Ace powered IDE. I think Ajax.org have hired someone to work on IntelliSense style auto-complete for Cloud9, not sure if those will be suitable to be put into Ace itself.

how is split views an ide feature?

Well, I just did a fork -> edit with Ace -> pull request for two little documentation fixes in a library I use. It was quite convenient. But I don't see using it for a project I frequently contribute to, unless I'm stuck away from my usual dev environment (which would be strange, since it's my laptop).

Just wanted to note that a fork is automatically created and a pull request created when you edit a file in a repository you don't have push access to. So the workflow is even simpler: 1.) see file, 2.) edit file and save, 3.) land on send pull request page.

great. But perhaps a fork is still needed for editing multiple files and submitting as one pull request?

or the pull request would accumulate changes?

I cannot reproduce but I noticed a situation when I was issuing multiple pull requests and the previous pull request somehow got commits that weren't intended to end up there; so I begin to think that it was intentional.

(just asking because I would like to avoid creating a tmp github account just to try that out, otherwise I wouldn't bother you with silly questions)

Pull requests do seem to accumulate changes if you push to your fork while there's one open.

> Just fork a project to your account on github, edit in Ace, and then making a pull request when you are done.

Github's edit feature does all that: if you're trying to edit a file in a third party's project, it creates a fork and opens the file for editing, and creates a pull request when you commit your edit.

> If not, is Ace just going to be for minor edits, etc?

Well yeah, since you can't really test the code (for now at least, maybe they'll build some sort of testrunner via VMs later on) it's not like you can perform significant code editions with it. But for docfixes, typos or minor stuff it's very handy.

Well, you can't run tests on code you edit this way; I'd say its intended usage is just minor edits such as typoes.

Well this sounds like a problem that could be fixed quite easily, albeit it would cost some money to do so. But for people willing to pay for this kind of workflow it would be no issue to provide them with a testing machine. Since you only run tests every few minutes or so it wouldn't even be too resource intensive for most people.

Travis-ci is already doing something to that effect. Check them out. https://github.com/travis-ci/travis-ci

I wonder if joint support with somebody like heroku is coming. Being able to develop and deploy all from your web browser would be a very cool feature.

Of note, this was the core feature of Heroku when they first started out (no need to know git/command line).

I hope that someday you can work like that. But I doubt that people can work like that when they are not able to test their code. At least adding unit test capabilities is absolutely nessesary for that.

    Just fork a project to your account on github, edit in Ace, and then make a pull request when you are done.

I'm not sure that would be plausible for anything other than documentation or maybe typo fixes in string literals. I would ask contributors to my projects to make sure they've run tests (and made new ones, if need be) before sending a pull request.

I'm really happy to see this feature. Sometimes I see a small problem in somebody else's code or documentation and out of sheer laziness I don't go though the trouble of forking, cloning, editing, pushing and sending a pull request. I think this will be wonderful for exactly those situations and should help encourage more people to participate in open source.

The edit feature has been there for a long time. They have added an improved editor.

Ha, can't believe I completely missed that.

Is github is speeding up even internet time? The edit button was only added to unowned repositories at the end of April. https://github.com/blog/844-forking-with-the-edit-button

That blog post is about automatically forking with edit. The edit button was discovered by our users nearly 3 years ago: https://github.com/blog/143-inline-file-editing

forking with edit is what the parent comment was talking about.

I can see how this might silently make Github into one of the best blogging platform on the planet.

I run my blog (pepijndevos.nl) on Github, using its Jekyll feature, so my blog just got a much better online editor with preview functionality.

I've checked Ace live demo[1], turned on "Emacs" keybindings and failed to see what do they have in common with Emacs, apart from the old, carpal-tunnel-syndrome-powered C-p/n/b/f movement keys.

They could use an Emacs hacker to fix it up, but Emacs hackers already have perfectly fine editor, so I do not predict any great success in this field.

[1] - http://ajaxorg.github.com/ace/build/kitchen-sink.html

Agreed. If it just implemented killing and yanking (and selecting regions, which goes along with these), it would be semi-viable.

Also missing C-a/C-e. All the meta bindings are noops as far as I can tell. C-<space> doesn't work to anchor the selection. Just generally worthless.

The Vim bindings have the same issue. Sure, it's modal, and you have to hit `i` before you can insert text... but there's nearly no features when you're not in insert mode. The only one I was able to trigger off the top of my head was using `dd` to delete a line... and it didn't even yank it, so p wouldn't paste it back in. No searching, no undoing, no applying commands to multiple lines, no `.` to repeat the last action...

Like the emacs mode, it feels like it was implemented to check a feature off on a list, not because someone wanted to take advantage of the things that vi/emacs do well.

Well, I went in and submitted a pull request that'll at least give it undo as a binding and [count] args on the existing commands that it's appropriate for.

https://github.com/ajaxorg/ace/pull/381

Julian Viereck created Skywriter/Ace's keybinding system with the requirement that it had to be able to handle Emacs and vi style keybindings. Those of us working the most on Skywriter were actually fine with the default bindings, but we looked up the different keybinding patterns used by Emacs and vi and made it possible to do those.

There's a bit of effort to go from that capability to a full set of bindings. I know that Gozala (on GitHub) worked a bit on vi bindings. For a motivated hacker, it's possible and likely not too much work to fit Ace with some slick bindings.

This is neat editor and it's cool to see how Github could eventually bill itself as your one stop shop for code editing and collaboration. My only concern is that of feature creep hurting the user experience by creating a cluttered and confusing UI. I personally feel that Github's web UI is very cluttered as it is. They possibly have one of the best user experiences that I have seen, given the large amount of data and information that they have to present and I do not think that this feature necessarily hurts it at all, but it's getting close, in my opinion.

Just my two cents.

It would be great if it gets collaborative real time editting.

Check out ShareJS:

https://github.com/josephg/ShareJS

I've contributed some changes and documentation to Ace, really awesome project, great to see it hitting Github!

Support for IE<9 older browsers is a little sketchy at the moment, but hopefully greater exposure through github will see more fixes and features contributed. (Fabian Jakobs seems quite open to new features as long as they fit in with the projects goals)

Wow, I'm in love with the idea of a "preview" tab showing you a git diff!

Would love to see this feature given 1st class attention in other editors!

Agree. Why in this day and age I need to fire up an external tool to look at diffs is beyond me. I appreciate the external tool exists (for times when I'm NOT in my editor/IDE to begin with) but I'd rather it was all baked in.

Even if it git or another scm wasn't available - just a diff of changes since the file was opened in the editor...

If you use emacs, this is a good reason to use Magit. Your diff is just a "C-x g" away.

http://www.emacswiki.org/emacs/Magit

I was already a huge fan of the Bespin / Cloud9ide / ace projects so this is great news!

This is great! I'm currently working on a small web editor called anyfnwhere. In development at the moment.

check https://github.com/keyle/anyfnwhere

From TFA: "If you're using a recent version of Safari, Chrome, or Firefox here's how it works.."

Is there a reason they miss out Internet Explorer? Makes it sound like it's not supported or something. Is it?

Apparently IE and Opera use the old editor.

I wonder why they have chosen Ace over CodeMirror. CodeMirror has very similar set of features, is less bloated and works on more browsers.

This is a brilliant feature, and as close an example of cloud editing that I would consider using as any on the internet.

Does anyone know is there anything to give this a modular editor feel like vim?

If someone can deliver me an online experience with a fully functioning vim, I would be browser bound almost exclusively.

I use cloud9, and love it.

Finally there is support for this! I'm excited.

No.

C-x k

Just learn vim.

Reply on news.ycombinator.com