Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: in-browser code editor

69 views
Skip to first unread message

Kevin Dangoor

unread,
Apr 29, 2011, 12:18:03 AM4/29/11
to Ehsan Akhgari, dev-pl...@lists.mozilla.org, Rob Campbell
(subject changed to reflect a different topic - Joe's original thread was
not just about Ace and I don't want to see questions about Ace get in the
way of the unrelated feature that Joe was asking about as well)

On Thu, Apr 28, 2011 at 4:07 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> But I think we're approaching the problem in a strange way. I think
> it's best for the devtools team to come up with a set of requirements on
> what they want from an editor, and then we can move from there to decide
> whether we should just extend the HTML editor in Gecko, use a Javascript
> wrapper on top of it (like Orion) or just roll our own from scratch
> (like Ace).
>
> What do you think?
>
>
I think this is a fine idea, and I've started a feature page for this:

https://wiki.mozilla.org/DevTools/Features/CodeEditor

Please forgive any glaring omissions or typos on that page, because I just
created it and it's late on an already long day.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

Ehsan Akhgari

unread,
Apr 29, 2011, 2:05:31 PM4/29/11
to Kevin Dangoor, dev-pl...@lists.mozilla.org, Rob Campbell
On 11-04-29 12:18 AM, Kevin Dangoor wrote:
> (subject changed to reflect a different topic - Joe's original thread was
> not just about Ace and I don't want to see questions about Ace get in the
> way of the unrelated feature that Joe was asking about as well)
>
> On Thu, Apr 28, 2011 at 4:07 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:
>
>> But I think we're approaching the problem in a strange way. I think
>> it's best for the devtools team to come up with a set of requirements on
>> what they want from an editor, and then we can move from there to decide
>> whether we should just extend the HTML editor in Gecko, use a Javascript
>> wrapper on top of it (like Orion) or just roll our own from scratch
>> (like Ace).
>>
>> What do you think?
>>
>>
> I think this is a fine idea, and I've started a feature page for this:
>
> https://wiki.mozilla.org/DevTools/Features/CodeEditor
>
> Please forgive any glaring omissions or typos on that page, because I just
> created it and it's late on an already long day.

I took a look at the page. I'm happy to see that we're gathering a list
of requirements for this project. But I want to clarify something when
we want to compare "built-in" with the "off-the-shelf" editors.

I think we need to remember that the built-in Gecko editor
implementation is an API for web applications to build on top of. So, I
think for filling the requirements grid, we should ask ourselves:
"whether feature X can be implemented on top of the built-in editor, and
if no, what can we do to fix that?"

Looking at the list, I don't immediately see anything which is too
difficult to support in the built-in editor.

How do we feel about building a code editor which is built on top of
interoperable web technologies, with no dirty hacks? We can borrow code
from the existing projects for things that we can use whole-sale (such
as syntax highlighting) and we can build the pieces that we need on top
of web editing APIs...

Cheers,
Ehsan

Robert O'Callahan

unread,
Apr 29, 2011, 7:40:24 PM4/29/11
to Ehsan Akhgari, dev-pl...@lists.mozilla.org, Kevin Dangoor, Rob Campbell
On Sat, Apr 30, 2011 at 6:05 AM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> How do we feel about building a code editor which is built on top of
> interoperable web technologies, with no dirty hacks? We can borrow code
> from the existing projects for things that we can use whole-sale (such
> as syntax highlighting) and we can build the pieces that we need on top
> of web editing APIs...
>

I think the reason people like Bespin took the canvas route in the first
place was performance --- probably the item "Responsive editing, even for
large files (20,000 lines)" on that requirements page. If you do syntax
highlighting on a large text file in a naive way then you're likely to build
a huge DOM; building that DOM and reflowing it is likely to be a performance
problem.

This is one of those cases where you really want to have an internal
document model that's not the DOM (e.g., one string per line and a tokenizer
state for the start of each line for syntax highlighting), and lazily build
a representation of the visible parts of your model. It's possible to
represent the visible parts of the document with the DOM instead of a canvas
--- Orion does this, for example. If you make the DOM representation
contenteditable, this can get a lot of of the benefits of using browser
built-in text editing --- IMEs, most accessibility features, spellcheck,
most bidi layout, text shaping, etc should all work. But a few things will
not work, e.g. FAYT won't see the whole document, nor will you be able to
cut-and-paste the entire document. I think that's probably a good tradeoff
for now, though.

But I think we should also be thinking about ways to make "lazy
representation" approaches work better on the Web. It's similar to the
requirements around tree widgets.

Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Ehsan Akhgari

unread,
Apr 30, 2011, 11:06:24 AM4/30/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org, Kevin Dangoor, Rob Campbell
On 11-04-29 7:40 PM, Robert O'Callahan wrote:
> On Sat, Apr 30, 2011 at 6:05 AM, Ehsan Akhgari <ehsan....@gmail.com>wrote:
>
>> How do we feel about building a code editor which is built on top of
>> interoperable web technologies, with no dirty hacks? We can borrow code
>> from the existing projects for things that we can use whole-sale (such
>> as syntax highlighting) and we can build the pieces that we need on top
>> of web editing APIs...
>>
>
> I think the reason people like Bespin took the canvas route in the first
> place was performance --- probably the item "Responsive editing, even for
> large files (20,000 lines)" on that requirements page. If you do syntax
> highlighting on a large text file in a naive way then you're likely to build
> a huge DOM; building that DOM and reflowing it is likely to be a performance
> problem.

Are there any ways in which we can improve the performance on the Gecko
side?

> This is one of those cases where you really want to have an internal
> document model that's not the DOM (e.g., one string per line and a tokenizer
> state for the start of each line for syntax highlighting), and lazily build
> a representation of the visible parts of your model. It's possible to
> represent the visible parts of the document with the DOM instead of a canvas
> --- Orion does this, for example. If you make the DOM representation
> contenteditable, this can get a lot of of the benefits of using browser
> built-in text editing --- IMEs, most accessibility features, spellcheck,
> most bidi layout, text shaping, etc should all work. But a few things will
> not work, e.g. FAYT won't see the whole document, nor will you be able to
> cut-and-paste the entire document. I think that's probably a good tradeoff
> for now, though.

What about the performance of scrolling for example? This model would
mean that new DOM should be built and reflowed when scrolling, which
sounds way more expensive than what we do for scrolling now.

> But I think we should also be thinking about ways to make "lazy
> representation" approaches work better on the Web. It's similar to the
> requirements around tree widgets.

Yeah, this is a very interesting point, thanks for bringing it up.

Do you have any broad directions to go in mind? I haven't had time to
think about it much yet, but a non-DOM based content model for the web
seems rather scary...

Ehsan

johnjbarton

unread,
Apr 30, 2011, 12:16:27 PM4/30/11
to
On 4/30/2011 8:06 AM, Ehsan Akhgari wrote:
> On 11-04-29 7:40 PM, Robert O'Callahan wrote:
>> On Sat, Apr 30, 2011 at 6:05 AM, Ehsan Akhgari<ehsan....@gmail.com>wrote:
...

>> This is one of those cases where you really want to have an internal
>> document model that's not the DOM (e.g., one string per line and a tokenizer
>> state for the start of each line for syntax highlighting), and lazily build
>> a representation of the visible parts of your model. It's possible to
>> represent the visible parts of the document with the DOM instead of a canvas
>> --- Orion does this, for example. If you make the DOM representation
>> contenteditable, this can get a lot of of the benefits of using browser
>> built-in text editing --- IMEs, most accessibility features, spellcheck,
>> most bidi layout, text shaping, etc should all work. But a few things will
>> not work, e.g. FAYT won't see the whole document, nor will you be able to
>> cut-and-paste the entire document. I think that's probably a good tradeoff
>> for now, though.
>
> What about the performance of scrolling for example? This model would
> mean that new DOM should be built and reflowed when scrolling, which
> sounds way more expensive than what we do for scrolling now.

Firebug's Script panel has used this 'viewport' approach ever since we
started seeing 70kloc JS files a couple of years ago. Scrolling is
fine, even using my unoptimized amateur code.

jjb

Robert O'Callahan

unread,
May 1, 2011, 2:09:44 AM5/1/11
to Ehsan Akhgari, dev-pl...@lists.mozilla.org, Kevin Dangoor, Rob Campbell
On Sun, May 1, 2011 at 3:06 AM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> On 11-04-29 7:40 PM, Robert O'Callahan wrote:

> > I think the reason people like Bespin took the canvas route in the first
> > place was performance --- probably the item "Responsive editing, even for
> > large files (20,000 lines)" on that requirements page. If you do syntax
> > highlighting on a large text file in a naive way then you're likely to
> build
> > a huge DOM; building that DOM and reflowing it is likely to be a
> performance
> > problem.
>
> Are there any ways in which we can improve the performance on the Gecko
> side?
>

Yes but not an order of magnitude improvement.

What about the performance of scrolling for example? This model would
> mean that new DOM should be built and reflowed when scrolling, which
> sounds way more expensive than what we do for scrolling now.
>

Yes but the work you do is only proportional to the size of what's visible
--- which is roughly a constant --- vs the size of the document, which can
be arbitrarily large.

Do you have any broad directions to go in mind? I haven't had time to
> think about it much yet, but a non-DOM based content model for the web
> seems rather scary...
>

I don't like the XUL tree model or what was proposed for HTML5 datagrid,
where you have a hardcoded set of features you can display in "rows" or
"cells". A hardcoded set of features is never enough.

I also don't like the canvas approach where the developer writes everything
from scratch, for the reasons we've been discussing here.

If we had a beforepaint event that fired before each paint that would make
some things easier. I haven't figured out what the ultimate answer is though
:-).

Kevin Dangoor

unread,
May 12, 2011, 2:53:02 PM5/12/11
to Ehsan Akhgari, dev-pl...@lists.mozilla.org, Rob Campbell
I have just updated the Code Editor feature page based on the discussions
we've had. In particular, it seems that we have narrowed down the options
(all contentEditable+JS behavior on top) so that we can run a fairly quick
evaluation and make a decision:

https://wiki.mozilla.org/DevTools/Features/CodeEditor#Evaluating_the_Options

Axel Hecht

unread,
May 13, 2011, 3:32:49 AM5/13/11
to
On 12.05.11 20:53, Kevin Dangoor wrote:
> I have just updated the Code Editor feature page based on the discussions
> we've had. In particular, it seems that we have narrowed down the options
> (all contentEditable+JS behavior on top) so that we can run a fairly quick
> evaluation and make a decision:
>
> https://wiki.mozilla.org/DevTools/Features/CodeEditor#Evaluating_the_Options
>
> Kevin
>

Thanks for that page, that's really helpful.

Reading through it, I tripped over the line

> work through differences between running in content and chrome

Reminds me that you should probably put a security review on your action
items.

Axel

Kevin Dangoor

unread,
May 13, 2011, 7:45:22 AM5/13/11
to Axel Hecht, dev-pl...@lists.mozilla.org
On Fri, May 13, 2011 at 3:32 AM, Axel Hecht <l1...@mozilla.com> wrote:

> Thanks for that page, that's really helpful.
>
> Reading through it, I tripped over the line
>
> work through differences between running in content and chrome
>>
>
> Reminds me that you should probably put a security review on your action
> items.
>

Indeed. When I wrote that, I was actually thinking of the fact that certain
things that work in content don't work at all in chrome.

I've added a "next step" for security review of the proposed choice.

0 new messages