683513 - GCLI needs a 'scratchpad' command

Status: RESOLVED FIXED

(DevTools Graveyard :: Graphic Commandline and Toolbar, defect, P2)

Description

[Joe Walker [:jwalker]]

This command allows the user to open and control the scratchpad

Comment 1

[Joe Walker [:jwalker]]

Would benefit from bug 659268

Comment 3

[Joe Walker [:jwalker]]

From https://bugzilla.mozilla.org/show_bug.cgi?id=636731#c0

We should be able to control Workspaces via Cockpit. Initial set of commands I can think of (feel free to add/remove/adjust as makes sense):

* open workspace
* load file into workspace
* select range of lines
* object view for that range of lines ("inspect?" overloaded word?)
* evaluate that range of lines
* close the workspace (what if there are multiple?)

Note also that I think in addition to a selected DOM node notion, I think we also want a selected object. it would be good to evaluate code in the workspace and then be able to do another operation on that same object.

Comment 4

[Mihai Sucan [:msucan]]

To properly handle the notion of multiple Scratchpads, we need "handles". Something like:

open scratchpad into handle1
load file into handle1
select 10,40 in handle1
close handle1

... where handle1 or whatever the user picks refers to the scratchpad instance he opened. One can have multiple handles/Scratchpad instances. The GCLI commands need to be made easy to use with the notion of "handles".

Thoughts?

Comment 5

[Joe Walker [:jwalker]]

We're not trying to be a scripting language - that's what JS is for, so GCLI is almost a write-only language :) - ease of typing trumps readability every time.

So rather than:
> open scratchpad into handle1

We can do:
> scratchpad --name handle1

The difference isn't really in characters typed, but in predictability. In effect we're doing most-significant-word-first to make subsequent words more predictable. You're right that the former is more readable, but the latter is more typable.

Makes sense?

Comment 6

[Mihai Sucan [:msucan]]

(In reply to Joe Walker from comment #5)
> We're not trying to be a scripting language - that's what JS is for, so GCLI
> is almost a write-only language :) - ease of typing trumps readability every
> time.
> 
> So rather than:
> > open scratchpad into handle1
> 
> We can do:
> > scratchpad --name handle1
> 
> The difference isn't really in characters typed, but in predictability. In
> effect we're doing most-significant-word-first to make subsequent words more
> predictable. You're right that the former is more readable, but the latter
> is more typable.
> 
> Makes sense?

Sure, it does. My idea wasn't specifically about the syntax of the commands themselves, I was more aiming at the idea of having "handles" for every Scratchpad instance created from GCLI.

Comment 7

[Joe Walker [:jwalker]]

OK - idea noted. Thanks.

Comment 8

[Joe Walker [:jwalker]]

Attachment: A prototype scratchpad command

Comment 9

[Joe Walker [:jwalker]]

For what it's worth these are the strings to go with the example, which would live in /devtools/browser/locales/en-US/chrome/browser/devtools/gclicommands.properties

scratchpadDesc=Open a scratchpad
scratchpadManual=Scratchpad allows editing JavaScript in a smalltalk-like environment
scratchpadFileDesc=Initial file
scratchpadScriptDesc=Initial script
scratchpadChromeDesc=Chrome privilages
scratchpadOnesource=Only one of --file and --script should be used
scratchpadFilepretend=Pretend this is a scratchpad with the contents of %S
scratchpadScriptpretend=Pretend this is a scratchpad containing this text
scratchpadEmptypretend=Pretend this is an empty scratchpad

Comment 10

[Joe Walker [:jwalker]]

Moving GCLI bugs to Developer Tools: Console. Filter on 'baked beans are off'.

Comment 11

[Joe Walker [:jwalker]]

Consider adding a --template XXX to pre-fill the scratchpad with a custom template - for example to create a new GCLI command.
Add a separate bug to do this, if you don't do it in this bug.

Comment 12

[Joe Walker [:jwalker]]

(In reply to Joe Walker from comment #11)
> Add a separate bug to do this, if you don't do it in this bug.

Sorry - that came across really didactic. If this feature doesn't fit, we can do it in another bug.

Comment 13

[Joe Walker [:jwalker]]

Bug triage, filter on PEGASUS.

Comment 14

[Panos Astithas (he/him) [:past] (please ni?)]

Another potentially useful feature:

scratchpad --gist <url>
scratchpad --pastebin <url>

Populates a scratchpad with the contents of the specified gist or pastebin.

Comment 15

[Joe Walker [:jwalker]]

Additional progress:
  https://gist.github.com/2995780

Rob - what are the chances of you getting time to finish this off for 16?

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Filter on teabags

Comment 17

[Rob Campbell [:rc] (:robcee)]

(In reply to Joe Walker from comment #15)
> Additional progress:
>   https://gist.github.com/2995780
> 
> Rob - what are the chances of you getting time to finish this off for 16?

I should have a chance to work on it next week. Doesn't give us a lot of time for review and fixups though so feel free to steal it if anyone has the cycles.

Comment 18

[Rob Campbell [:rc] (:robcee)]

still hoping...

Comment 19

[Joe Walker [:jwalker]]

Triage: Filter on the TRIAGE keyword.

Comment 20

[Joe Walker [:jwalker]]

New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"

Comment 21

[Rob Campbell [:rc] (:robcee)]

why am I still assigned to this?