GCLI needs a 'scratchpad' command

RESOLVED FIXED in Future

Status

()

Firefox
Developer Tools: Graphic Commandline and Toolbar
P2
normal
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: jwalker, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gclicommands])

Attachments

(1 attachment)

This command allows the user to open and control the scratchpad
Would benefit from bug 659268
Duplicate of this bug: 636731
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.
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?
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?
(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.
OK - idea noted. Thanks.
Blocks: 689605
No longer blocks: 671406
OS: Windows 7 → All
Hardware: x86_64 → All
Created attachment 573483 [details]
A prototype scratchpad command
Assignee: nobody → fayearthur
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
Moving GCLI bugs to Developer Tools: Console. Filter on 'baked beans are off'.
Component: Developer Tools → Developer Tools: Console
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.
(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.
Blocks: 711051
No longer blocks: 689605
Assignee: fayearthur → rcampbell
Status: NEW → ASSIGNED
Priority: -- → P1
Bug triage, filter on PEGASUS.
Target Milestone: --- → Firefox 12
No longer blocks: 711051
Target Milestone: Firefox 12 → Firefox 13
Target Milestone: Firefox 13 → Firefox 14
Blocks: 739261
Target Milestone: Firefox 14 → Firefox 15
Blocks: 745773
No longer blocks: 745773
Target Milestone: Firefox 15 → Firefox 16
Another potentially useful feature:

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

Populates a scratchpad with the contents of the specified gist or pastebin.
Blocks: 768998
Additional progress:
  https://gist.github.com/2995780

Rob - what are the chances of you getting time to finish this off for 16?
Filter on teabags
Whiteboard: [gclicommands]
(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.
still hoping...
Target Milestone: Firefox 16 → Firefox 17
Triage: Filter on the TRIAGE keyword.
Priority: P1 → P2
Target Milestone: Firefox 17 → Future
New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"
Component: Developer Tools: Console → Developer Tools: Graphic Commandline and Toolbar
why am I still assigned to this?
Assignee: rcampbell → nobody
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.