Console Multiline mode

[nchevobbe]

In Q1, we want to revive a Firebug Console feature into DevTools: multiline editor.

Basically, the user would switch to a mode where the console input and the console output would be side-by-side, like in this screenshot (but with the input on the left and the output on the right to match known repl https://astexplorer.net/, https://babeljs.io/repl):

Once in multiline mode, there are some things that change from the regular mode:

• new lines are added by simply pressing Enter, like a regular editor
• Ctrl/Ctrl + Enter is used to evaluate what's in the input
• The input does not get cleared when evaluating (the cursor stays at the same place).

This brings quite a lot of questions:

• how do we switch from regular to multiline mode, and back?
• how do we integrate the reverse search?
• how do we integrate the filter bar?
• how do we integrate the sidebar (Cmd+Click on objects pin them to the right side)
• do we want a toolbar in the multiline mode for additional features ? (history panel / snippet management, …)
• should we show the line numbers?
• additional editor-y features?

[DPX-designer]

This also shares overlap with this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1427981 with communicating to the user what pressing enter does in the console.

[fvsch]

how do we switch from regular to multiline mode, and back?

My basic solution for that would be to have a row of icon buttons at the right of the normal input, to give access to multiline mode and reverse search. (And maybe one more feature if we have one to surface there, but beyond three it might take too much space and make the interface too busy.

Oh, and silly question but: do we actually need to remove the normal input when we're showing the multiline input sidebar? It could be that some users want to write down some JS code in that scratchpad-like sidebar, as technical notes, but keep interacting with the normal input. With a process like:

1. Try something in the Console's main input
2. Yep, looks like the code I need to use. Let's copy-paste that in the sidebar.
3. Try a few more things.
4. Edit your code notes in the sidebar.
5. etc.

(Sorry to add diverging ideas if you're in a converging phase. ;))

This also shares overlap with this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1427981 with communicating to the user what pressing enter does in the console.

Indeed, and if we have an alternative input interface where Enter is a new line, we may train users to think Enter is a new line in the regular input as well.

[janodvarko]

It could be that some users want to write down some JS code in that scratchpad-like sidebar, as technical notes, but keep interacting with the normal input. With a process like:

Yes, I support the idea. The current inline-input can be useful all the time and therefore should not be removed/disabled.

Honza

[nchevobbe]

It could be that some users want to write down some JS code in that scratchpad-like sidebar, as technical notes, but keep interacting with the normal input. With a process like:

My initial reaction is that it feels weird as you then have 2 different context to evaluate things, which handle keystrokes differently and might led to confusion (IMO). Also, it might look not polished/professional, but I could be convinced.

Could it be something we do a study on (or kind of a study, a poll, or whatever) to gather some feedback on this.

[violasong]

My basic solution for that would be to have a row of icon buttons at the right of the normal input,

I like this idea - the reverse search button could have selected state when in search mode, and the multi-line could work kind of like the sidebar expand/close button

[digitarald]

Continued in #85