On Dec 30, 9:46 pm, John J Barton <[email protected]> wrote:
> I think close coupling of debug and edit are a fantastic direction to
> work. But of course if it was as easy as bolting Scintilla on to
> Firebug it would already be done. (I've heard rumors of work on a new
> JS-based editor from Mozilla Labs that is supposed to be out in
> January).
This would be awesome!
>
> As I point out below, I don't think you can get both live edits and
> source edits easily. In my own work I am concentrating on a much
> deeper integration between editor and debugger, an integration that
> does not allow the use of normal source files. This would make all
> edits 'live' much like the Smalltalk or Self environments work. But
> will developers agree to use something that does not use standard
> source files?
[snip]
> I don't see how this makes sense. Either you are live editing or you
> are editing local files. Which is it? If you save the live contents
> to a file then its not source. That is the direction I want to try,
> but you have to be prepared for people rejecting the idea.
>
Sorry for the confusion here. I was confused between "live" and
"source" edits. From live edit I meant editing the actual source file
in a running app (=> live!). From now on I will differentiate between
live and source edits!
After going through other discussions and already logged enhancements,
I realize it is not an easy and straight forward thing to do. From
what I can gather, Firebug reads resources from the loaded page using
Firefox APIs. Here, we get the live content used and possibly modified
by the browser rather than the resource downloaded (actual resource).
This is how we see actual DOM rather than the original HTML source!
Same for CSS. Since the Firebug uses live content, technically it
would be cleaner and easier to operate on the live content. Using
actual downloaded resource to edit contents could lead to possible
contradictions.
Nevertheless, originally goal of having a source editor was to reduce
the development time by cutting down duplicate edit operations. Still
a live edit can be used to save changed contents (which is better than
nothing) but leaves a lot to be done. Perhaps it can be extended to
map the changes to the actual source file!
>
> > * Reduces development time by cutting down editing time with in-place
> > editing. We dont loose data. We dont have to switch tabs to edit
> > relevant source files.
>
> I don't get the switch tabs part here. But in general the organization
> of screen real estate is critical.
Meant switching windows, Firebug/Firefox and the actual text editor!
>
> > * A speculation: Possibly faster load times of text in an editor
> > buffer for large JS library files.
>
> Hmmm, you said you were going to save the files (I guess to local
> storage?) So you have to load them again correct?
I may not be aware of the actual problem, but I thought that we could
load the downloaded resource instead of loading the physical file.
This was based on assumption that a text editor is more efficient with
loading and editing content.
>
>
>
> > Does this make sense to you? What is the best choice for embedding
> > one? Scintilla looks like a very solid candidate. It is being used in
> > Notepad++ and Komodo Edit.
>
> Give it a go and let us know. Anything you learn will be helpful.
>
>
>
> > Ajit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en
-~----------~----~----~----~------~----~------~--~---
