1154359 - Set $1 ... $n to recent expression results

Status: NEW

(DevTools :: Console, enhancement, P5)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Attachment: webkit-last-expr-val.gif

This is a useful feature cribbed from WebKit nightly:

* when I run some JS at the console, if the result of the expression is not falsey it should be assigned to a variable '$n' where n is a number starting at 1.

* when the variable is assigned, we should visually indicate the variable name it assigned the result too

* when the clear() / console.clear() helpers are called, the variable number sequence should be rest back to begin at 1


See attached gif for a quick demo of how webkit works.

Comment 1

[Florent Fayolle]

FWIW, Firebug and Chrome use $1...$4 as for the second-last...fifth-last inspected elements. Same for $n(x). Not sure how useful it is, but maybe we should harmonize with the existing tools and try not to disturb the users coming from Firebug 2.0?

Also Firebug 2.0 implements "use in command line" which introduces a $p variable in the console. To my opinion, that's extremely powerful. You can use it for the purpose mentioned in this bug.

We plan to reimplement it in this issue: https://github.com/firebug/firebug.next/issues/230

Florent

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to fayolle-florent from comment #1)
> FWIW, Firebug and Chrome use $1...$4 as for the second-last...fifth-last
> inspected elements. Same for $n(x). Not sure how useful it is, but maybe we
> should harmonize with the existing tools and try not to disturb the users
> coming from Firebug 2.0?

There is surely value in matching Firebug / Chrome, but the assertion is that $2, $3, $4 is an infrequently used / not useful feature.

> Also Firebug 2.0 implements "use in command line" which introduces a $p
> variable in the console. To my opinion, that's extremely powerful. You can
> use it for the purpose mentioned in this bug.
> 
> We plan to reimplement it in this issue:
> https://github.com/firebug/firebug.next/issues/230

This seems more useful to me than $2-$4, since you can choose the node that you care about.  Personally, I'd like to see this land as a parity feature in the native tools.  Jeff, is there already a bug for this?

Comment 3

[Florent Fayolle]

> There is surely value in matching Firebug / Chrome, but the assertion is that $2, $3, $4 is an infrequently used / not useful feature.

FWIW, I reported that in bug 1163688.

But I don't have much opinion about this. Just cc'ing Honza if he has any thoughts on this.

Florent

Comment 4

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Brian Grinstead [:bgrins] from comment #2)
...
> This seems more useful to me than $2-$4, since you can choose the node that
> you care about.  Personally, I'd like to see this land as a parity feature
> in the native tools.  Jeff, is there already a bug for this?

The thing that I love about webkit's new handling is that they provide instant visual feedback of what happened - it makes the feature very discoverable. I suppose one way to blend this feature with the existing feature is by using $a...$z for recent console results, while preserving $1...$5 for recent DOM nodes. What do you think?

I think Firebug's context menu 'use in command-line' is super useful, we should do that too. I don't think it is either/or. That's logged as bug 1154363.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to Jeff Griffiths (:canuckistani) from comment #4)
> (In reply to Brian Grinstead [:bgrins] from comment #2)
> ...
> > This seems more useful to me than $2-$4, since you can choose the node that
> > you care about.  Personally, I'd like to see this land as a parity feature
> > in the native tools.  Jeff, is there already a bug for this?
> 
> The thing that I love about webkit's new handling is that they provide
> instant visual feedback of what happened - it makes the feature very
> discoverable. I suppose one way to blend this feature with the existing
> feature is by using $a...$z for recent console results, while preserving
> $1...$5 for recent DOM nodes. What do you think?

Maybe.. certainly any change to this effect is going to need to come alongside UX changes to show the assignment in the console output (and I'd like to wait until we have the resources to make said changes or make a decision about what awe will do with $1-$4).

I think having a context menu item to use an object from the console as a variable, along with a context menu item to use a DOM node as a variable would cover a lot of use cases.

Comment 6

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Brian Grinstead [:bgrins] from comment #5)
...
> Maybe.. certainly any change to this effect is going to need to come
> alongside UX changes to show the assignment in the console output (and I'd
> like to wait until we have the resources to make said changes or make a
> decision about what awe will do with $1-$4).

Agreed - the key aspect of this feature for me is the visual feedback of what's been assigned to what.

> I think having a context menu item to use an object from the console as a
> variable, along with a context menu item to use a DOM node as a variable
> would cover a lot of use cases.

That sounds like a reasonable thing to do - sooner than this bug? I don't think we need UX input, we can just copy firebug UX.

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to Jeff Griffiths (:canuckistani) from comment #6)
> > I think having a context menu item to use an object from the console as a
> > variable, along with a context menu item to use a DOM node as a variable
> > would cover a lot of use cases.
> 
> That sounds like a reasonable thing to do - sooner than this bug? I don't
> think we need UX input, we can just copy firebug UX.

I agree Bug 1154363 could be implemented without waiting for anything here.  In that case we can copy firebug UX and it shouldn't be blocked by anything here.