27 replies to this topic

[Ralph]

Randy, on Mar 11 2007, 05:33 PM, said:

Ok...I've not been plagued by any of these things. If we're talking about the same lag (javascript loading), it takes less than a second for me. The JS file is ~20K that is downloaded and then run in order to render the code highlighting. Perhaps my broadband connection and quick computer makes this appear better to me than to most. AFAIK this is the best of breed.

I was hoping I wouldn't have to put these hacks into every deployment independently. I'll understand and respect your decision if you want to rollback the mod.

I've never had a problem with any of the code editors "loading", it's the functionality that lags... Slow scrolling, getting tossed around in the snippet code to places I never was - things like that... Very sluggish performance on any PC or browser I test them with... Other than determining which line of code is at fault, they just don't seem to perform fast enough for me to get any work done... Which causes me to go back to using my editor and using cut & paste... Doesn't anyone else have problems with the speed of overall operation within these things...??? It surely has to be related to how the code calculates line numbers on the fly because WYSIWYG editors don't display this same characteristic...

[Randy]

Ah....I may understand now. Perhaps this is what you mean by getting tossed around...

With cursor on line 17, you save the snippet and select Keep Editing, after the snippet saves, the cursor is dumped to the bottom of the page instead of staying on line 17. Yes, this happens.

Honestly, scrolling is in no way slow for me.

Just punch the paint brush button at the top and try it without highlighting. Also, you can punch the little highlighter pen to turn off the 'current line' highlight. So you get the line numbers but no syntax highlights. I'm curious to see if there is a performance gain for you.

I'll tell you absolutely, and without doubt, this thing has never munged code on me. The line numbers, cntr-f and cntr-r, search/replace, and goto line are just killer core stuff for editing code. I dig all that. I suppose the question is whether its worth the burden imposed.

[Ralph]

@Randy

Turning off syntax highlighting and disabling the extra display features vastly enhances performance to an acceptable level... If they can be set to disabled by default I'd almost be a happy camper... The only thing that might possibly make me happier would to actually be camping... Thanks for the tips...

Oh, any chance that the Dynamically Resize textarea feature can be incorporated into this...???

Ralph...

[Randy]

Yes and Yes.

I'll make it an option on the settings panel to turn on highlighting. It will be off by default.

Ref. resize. If you click on the resize button on the lower right. Then let go and drag, you can resize that way currently.

I'll turn that off and incorporate the dynamic resize since dynamic is good. It may be slower, but I doubt by very much.

[Dean]

i downloaded from the svn, and like the syntax editor

[Randy]

This mod has [temtatively] been added to the 0614 base. Dean is testing with Safari and Ralph needs to validate and approve the modification. We went with editarea as it is more of a seemless integration than other solutions. There options to turn the highlighter off altogether, leave it on for line numbering and just turn off the syntax coloring, and eitherway, the toggle still works while inside the editor window so you can override your default settings for the session.

CU

[Cris D.]

Thanks for persevering with this one Randy. I'm loving the line numbers.

I don't know if anyone else is having this problem, but when I save, if I open another window without waiting for the page to save, then the edit area cuts off at the last line viewable. You can't scroll down or even run the cursor down with arrow keys or use go to line... The only way to get back the rest of the code is to re-save it and wait for the edit area to re-load with the window open. The obvious solution is to wait for it to save and re-load before checking the output, but it does slow the process... If it is the dynamically resized text area causing this, is it possible to turn it off?

This happens in IE7 & FF, with syntax "highlingting" & "other features" on or off.

[Randy]

Hi Cris,

This has been a problem using EditArea from the beginning. It is not the dynamic resize. I really, really thought the problem was specifically with FF, you surprised me with the IE7 thing. I cannot reproduce this problem with IE7 no matter how hard I try. I can reproduce this with FF routinely.

Bottom line:
1. I stopped troubleshooting this and went on to other things because I thought it was a FF rendering problem and not EditArea
2. This is not a problem with dynamic resizing (this was happening before we added that code)

So I really don't have a fix for you at this time Cris, and I'm not sure there is one. For me personally, the occasional trade off of working with a better code editor is worth the small bump in the road. I would prefer this be a perfect solution, but it isn't. Besides, for long complex scripts I defer to my IDE anyway.