Skip to content

Latest commit

 

History

History
88 lines (72 loc) · 4.29 KB

TODO.org

File metadata and controls

88 lines (72 loc) · 4.29 KB

Implement firefox protocol

The underlying communication code, opening the socket, writing and messages, work, but the protocol itself still needs to be implemented.

a button to add the current source position (url, line number, column number) to the list of resume points

implement real ‘toggling’ of Network.monitor

the jss-generic-browser object should keep track of the state of the network monitor (assuming it can’t ask the browser about it) and provide a command to enable if it’s curretly disabled or disable if it’s current enabled.

make most of the debugger buffer read-only

currently none of it is read only text. Since most of the momevment commands are single letters, if you type the wrong command you’ll end up just inserting that char and a) it’s looks really ugly and b) it can break some of the ‘find this block’ code.

show the source code of the first frame when the debugger pops up

document the debugger’s resume-points

Implement the DOM inspector

At the very least we want to get an emacs buffer with the dom as the browser sees it. It’d also be very helpful if we could, from this buffer, trigger click, submit or other events, though I’m not sure if this is possible without having to send js to the remote browser (which i’d really rather not do).

visual indiction for sparse arrays.

see if we can use emacs-web instead of implementing our own http client

make the tab’s url stay in sync with the browser

we currently compute the tab’s url at connect time, but if the tab navigates to another page we don’t track that. this is a problem for the auto-resume function jss-is-3rd-party-exception when we start from an empty tab and then go to our site and we think all our own code is 3rd party :(

don’t store tab-ids in text properties, store the tab objects themselves.

We don’t gain anything by having the level of indirection, and it’s more code to implement in the api.

see why it gets so damn slow when there’s a lot of IO logging.

Implement a function which also starts up a browser with the right args

If you’re going to run the browser on the same machine as emacs it’d be pretty easy to check for browsers in a few common locations and, if found, exec them with the required args.

On firefox we’d still have the manual ‘run script’ step, not sure how to work around this.

slime like ‘pop up windows’

instead of using switch-to-buffer-other-window we should have a function which stores the current window configuration, then does switch-to-buffer-other-window. when closing the other buffer if the window configuration is the same (no changes have been made except for what we did) we should restore the previous window configuration.

maybe popwin? https://github.com/m2ym/popwin-el

yes, just make sure popwin integration is working and suggest using that instead of implementing it ourselves.

edit a jss io’s buffer’s request data and submit it again.

  • State “DONE” from “TODO” [2013-03-14 Thu 15:42]
    this has been implemented in the jss-http-repl file.

this would simple present the headers, and post data, sent with the request and allow the user to edit this data and easily resubmit the request.

it may not be possible to do this via the browser, but even just being able to do it locally would be a big help.

Implement mapping from URLs to source code files.

  • State “DONE” from “TODO” [2013-03-14 Thu 15:43]
    see the variable jss-script-source-original-location-functions and friends.

It’s annoying to have to jump from a *JSS Script* buffer to the sourec code (epecially ‘cause they often look exactyl alike). We need a simple list of functions which, given a complete url and line/column numbers, return an emacs buffer we should visit instead of creating a *JSS Script* buffer.

report timing information in the IO buffer

  • State “DONE” from “TODO” [2013-03-16 Sat 14:29]
    This is the ‘Timing Data Log’. Given the amout of text this can generate it’s controlled via the variable jss-console-log-timing-data)

we already get a lot of into about when the requested started, how long we waited, how long it ttok to reiceve, etc. about a specific network IO. might as well display this info in the IO buffer.