search

rokucommunity / vscode-brightscript-language

A Visual Studio Code extension for Roku's BrightScript language
MIT License
110 stars 41 forks source link

Add ability to mark log output #63

Closed georgejecook closed 5 years ago

georgejecook commented 5 years ago

It should be possible to add a mark to log output with a keypress (Suggestion ctrl+l) The logoutput should append 

---------------------- MARK 1 ----------------------
logstuf
logstuf
---------------------- MARK 2 ----------------------

with an incrementing mark count also keypress to clear the output (suggested default is ctrl+k) - this will reset marks as well

georgejecook commented 5 years ago

yo @TwitchBronBron can you assign me please? I've got it in progress. Hope you concur with the approach - if not let me know - keys are easy enough to redefine.

TwitchBronBron commented 5 years ago

I'm not opposed to this, but could you explain some of the common use cases?

georgejecook commented 5 years ago

use case is you get tons of logoutput - and something happens that you are interested in - like showing a screen, playback start - a glitchy bit of UI a spinner appearing

you can press a key - I no longer have to scan tons of log code - I've a very good idea of where it occurred..

TwitchBronBron commented 5 years ago

I've given this some thought, and I hate to say it, but I don't think this concept belongs in vscode-brightscript-language. There's nothing BrightScript-specific about it. It just adds text to a vscode "output" channel. You could easily write a standalone extension that allows you to do this same thing...by adding the line to the active channel, or adding a setting to specify which output channel the mark should be added to.

TwitchBronBron commented 5 years ago

@georgejecook I just wanted to summarize out slack conversation for tracking purposes. Thanks for the clarifications.

For the upcoming log-filtering feature, you are moving all of the log statements into an array (so you can recreate the log based on filters). That would make this mark log output feature impossible to implement in a separate extension because that new extension wouldn't have access to that log entry array, and so every filter change would cause these mark statements to get lost. That's good enough reason for me to be ok with this arriving in the extension.