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)
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."
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:
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.
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.
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)
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.
> 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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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)
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.
