Devtools: [WIP] Implement enhanced devtools extension language APIs

Source/devtools/front_end/sdk/ConsoleModel.js

Index: Source/devtools/front_end/sdk/ConsoleModel.js
diff --git a/Source/devtools/front_end/sdk/ConsoleModel.js b/Source/devtools/front_end/sdk/ConsoleModel.js
index 66dec2279101e10e41486cbbebaedaf41671f608..f7244e4345c6ab7282b54fe7da2387bf3d47765e 100644
--- a/Source/devtools/front_end/sdk/ConsoleModel.js
+++ b/Source/devtools/front_end/sdk/ConsoleModel.js
@@ -194,8 +194,24 @@ WebInspector.ConsoleModel.evaluateCommandInConsole = function(executionContext,
             target.consoleModel.dispatchEventToListeners(WebInspector.ConsoleModel.Events.CommandEvaluated, {result: result, wasThrown: wasThrown, text: text, commandMessage: commandMessage, exceptionDetails: exceptionDetails});
         }
     }
-
-    executionContext.evaluate(text, "console", useCommandLineAPI, false, false, true, printResult);
+    
+    var mime = WebInspector.ResourceType.fromActivePanel();

[pfeldman, 2015/08/13 21:15:46]

Use DI for that. We should teach language support to respect runtime
extension-provided transpilers as well as API-added transpilers.

[wes, 2015/08/14 00:55:05]

So, I would declare an 'ActiveMimeExtensionDelegate' interface in the language
service module,
which has an implementation in the 'sources' module, which the language service
module can 
attempt to load each time this function is called (once it's moved into the
language service module)?

Is that the correct place for each of the parts to go?

[pfeldman, 2015/08/17 21:15:51]

As discussed during our meeting, we should take this out of SDK and place it on
the level higher. I'd take this entire
WebInspector.ConsoleModel.evaluateCommandInConsole method and move it into your
language module. Call sites are UI and can depend on your module just fine.

[wes, 2015/08/25 18:13:18]

By the time you had commented this I had actually already uploaded a changeset
which did just that. :D

+    if (WebInspector.languageService.handles.transpile(mime)) {
+        var location = executionContext.pauseLocation();
+        var prom = WebInspector.ConsoleModel._pendingTranspileResult = WebInspector.languageService.transpile(mime, text, location);
+        prom.then(result => {
+            if (WebInspector.ConsoleModel._pendingTranspileResult !== prom) {
+                return; //preempted by a following entry - drop ths one.

[wes, 2015/08/14 00:55:05]

I don't know if this behavior is desirable, but I figure it's better than
getting results in a random order. Would like feedback.

+            }
+            executionContext.evaluate(result, "console", !!useCommandLineAPI, false, false, true, printResult);
+        })
+        .catch(err => {
+            //TODO: decide how to handle errors?

[wes, 2015/08/14 00:55:05]

I would like some feedback on how to fulfill this TODO - errors from the
transpiler should probably be reported like a 'ReferenceError' in the js context
would (ie, immediately reported in the console). Right now it's just swallowed.

[pfeldman, 2015/08/17 21:15:52]

- please don't use arrow functions just yet
- that depends on the kind of error this is. When does the code above throw?

[wes, 2015/08/25 18:13:18]

If the transpile call throws on the user's end (and by user, I mean 'person who
registers a language', not necessarily an extension author) throws, it throws. I
could change to manager to have the .catch call... but the correct behavior on
error is really callsite-specific (try again? ignore the registered language and
fall back to callsite's default?), I'd think, so it's probably just worth
handling here. In this case, I don't know if it's better to fallback to
evaluation as JS or reporting the error to the user somehow (or both).

+            throw err;
+        });
+    } else {
+        executionContext.evaluate(text, "console", useCommandLineAPI, false, false, true, printResult);
+    }
 
     WebInspector.userMetrics.ConsoleEvaluated.record();
 }