This command allows the user to open and control the scratchpad
Would benefit from bug 659268
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.
Moving GCLI bugs to Developer Tools: Console. Filter on 'baked beans are off'.
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.
Bug triage, filter on PEGASUS.
Another potentially useful feature: scratchpad --gist <url> scratchpad --pastebin <url> Populates a scratchpad with the contents of the specified gist or pastebin.
5 years ago
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
(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.
5 years ago
Triage: Filter on the TRIAGE keyword.
New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"
why am I still assigned to this?
4 years ago