-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRAFT Spec for Buffer Exporting and Logging #11090
Conversation
This comment has been minimized.
This comment has been minimized.
on close? on newline? It's unclear exactly when PuTTY flushes with this off. | ||
Need more coffee. --> | ||
|
||
### Future Considerations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideas/Considerations:
- Text formatting
- Does the output file record the formatting of the text (i.e. color, font, etc.)? Or is the output ".log" file just a txt file?
- If we already can output formatted text, we should add this as a possible configuration (later imo, just do plain text for now).
- Maybe we could output to an ".html" file using
TextBuffer::GenHTML
?
- Super logging (no idea what to call this, but it needed a cool name)
- I remember @DHowett created a cool thing one time where you could record and play back a session in Conhost. I don't remember the specifics. But that seems like something that could be a part of this logging discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Nope, it's just text.
- Cool idea, I'll throw it on Future Considerations
- I think you're thinking of
asciicast
/asciinema
which we're tracking in Feature request: Recording #469. I'll link the two up.
- Dustin's thing recorded raw API calls from the driver. It was awesome, but absolutely overkill for this feature 😄
|
||
I'm proposing the following actions and profile settings | ||
|
||
* New Action: `exportBuffer()`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* New Action: `exportBuffer()`. | |
* New Action: `exportBuffer`. |
- `path`: Same as the `path` in the `ExportBufferArgs` above | ||
- `append`: Same as the `append` in the `ExportBufferArgs` above |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- `path`: Same as the `path` in the `ExportBufferArgs` above | |
- `append`: Same as the `append` in the `ExportBufferArgs` above | |
- `path`: Same as the `path` in the `exportBuffer` above | |
- `append`: Same as the `append` in the `exportBuffer` above |
ExportBufferArgs
wasn't introduced... but I guess you also mean to create a mechanism like NewTerminalArgs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yea derp, I just kinda implied that ExportBufferArgs
were the ActionArgs
for the exportBuffer
action.
- `captureAllOutput`: (boolean, defaults to `false`) When true, don't log only | ||
printable characters, also log non-printable escape characters written to | ||
the Terminal. | ||
- `captureInput`: (boolean, defaults to `false`) Additionally log input to the | ||
Terminal to the file. Input will be formatted as the traditional VT | ||
sequences, rather than the full `win32-input` encoding. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea:
- remove
captureAllOutput
andcaptureInput
- (names are still a work in progress, but you get the idea) add
captureHiddenData
: (flag enum{ none, vtKeyboardInput, vtMouseInput, vtOutput, all }
)
- `newFileEveryDay`: (boolean, defaults to `false`) This requires the `day` to | ||
be an element of the path format string. When logging with this setting, | ||
opens a new file at midnight and starts writing that one. | ||
<!-- TODO! - `flushFrequently`: (boolean, defaults to `true`) --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious, why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meh, I found it in the PuTTY docs, thought it was interesting, but commented out because I hadn't investigated it, then forgot to remove the comments before shipping the PR. Will move to future considerations, since it doesn't seem critical to the design.
My worry with logging the backspaces is that conpty is sometimes a bit noisier | ||
than it needs to be with using `^H` as a cursor positioning sequence. Should we | ||
only log lines when the cursor newlines or otherwise moves from the line it is | ||
currently on? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we should only log when we move to another line. Then just get whatever text was at that line and throw it in a file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens in vim
then? Or when performing a cls
? I guess the mechanics of this we'll have to compare with PuTTY a bit closer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I understood the discussion correctly, but we must be able to log everything that happened. Even within the same line, and even if it is noisy. These logs are sometimes required for investigating/debugguing.
Since there might be too much updates we will need to use some async writes with buffering (and ensure everything is flushed when closing).
Probably it should be configured by verbosity level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess my real concern is "does backspace count as a printable character". Yes-ish? By itself it's a non-destructive character. But if we don't treat it as printable, then asdfBkspBksp gets emitted as asdf^h ^h^h ^h
, but then would get logged as asdf
(with two spaces at the end there). So I guess, backspace should count as printable.
The "log everything" option is frankly just way easier to implement than the "printable characters only" one. Maybe we start with that one 😛
should we log the current buffer contents as well? | ||
|
||
I'm inclined to lean towards simply "all future output", and ignore any current | ||
buffer content. If the user rally wants to log the current buffer contents _and_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
buffer content. If the user rally wants to log the current buffer contents _and_ | |
buffer content. If the user really wants to log the current buffer contents _and_ |
started logging with `toggleLogging`, what should we log? All future output? Or | ||
should we log the current buffer contents as well? | ||
|
||
I'm inclined to lean towards simply "all future output", and ignore any current |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100% agree. In my mind, toggleLogging
is intended to be "I want to start writing to the file now. Up until this point, I was setting up the terminal to be in a good state".
`exportBuffer` to a file, then `toggleLogging` to that same file with | ||
`"append":true`. | ||
|
||
## Potential Issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideas/Considerations:
- How will logging work if you resize during a logging session?
<!-- * [ ] `LoggingSettings` property for "Flush log frequently", defaults to | ||
`true`(?). This causes us to flush all output to the file, instead of just... | ||
on close? on newline? It's unclear exactly when PuTTY flushes with this off. | ||
Need more coffee. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you get more ☕? haha
I hope HyperTerminal from XP is also considered as example. I would like to see the same feature is available (for example you can choose when to start and stop the session and the log file is generated in plain text so you can read it in Notepad). |
Yep, that's already in the spec. |
This adds an action for the context menu entry we added in #11062. That PR added support for exporting the buffer, exclusively through the tab item's context menu. This adds an action that can additionally be bound, which also can export the buffer to a file. This action accepts a `path` param. If empty/ommitted, then the Terminal will prompt for the file to export the buffer to. * Does a part of #9700 * Spec in #11090, but I doubt this is contentious * [x] This will satisfy #12052 * [x] I work here * [x] docs added: MicrosoftDocs/terminal#479
…R backlog. We're not making any progress on this immediately.
I'm officially moving this to the |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DRAFT!!
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
⇒ doc link ⇐
Summary of the Pull Request
This is an intentionally brief spec to address the full scope of #642. The
intention of this spec is to quickly build consensus around all the features we
want for logging, and prepare an implementation plan.
Abstract
PR Checklist
Detailed Description of the Pull Request / Additional comments
*** read the spec ***
Open Discussion
${date}
and${time}
, and allow for future variants with something like${date:yyyy-mm-dd}
or${time:hhmm}