Skip to content
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

Auto display readme`s #8647

Open
NicTanghe opened this issue Dec 24, 2020 · 7 comments
Open

Auto display readme`s #8647

NicTanghe opened this issue Dec 24, 2020 · 7 comments
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Milestone

Comments

@NicTanghe
Copy link

NicTanghe commented Dec 24, 2020

This one is a bit like that fighting type bird pokemon.

Description of the new feature/enhancement

t`would be sort of cool if there was a way to show readme’s in a new vertically split pane.
(preferably with markdown rendered like here (https://github.com/mikaelbr/marked-terminal))

Proposed technical implementation details (optional)

Search current dir level for readme.* and then auto execute split pane vertically and have it ran in marked-terminal or preferably something that is written c++ or rust. And also outputs plain txt

@NicTanghe NicTanghe added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Dec 24, 2020
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 24, 2020
@KalleOlaviNiemitalo
Copy link

Search current dir level

This would need something like #3158 to be implemented first, so that the shell can tell the terminal what the current directory is.

@jack775544
Copy link

This probably wouldn't be a feature of the terminal but instead something that you would implement inside of your shell instead. When #4472 eventually lands you will be able to use the wt command line to control panes from your existing tab. Then in your shell profile script you could check for a readme file after you change directories and if it does exist use the command line to open a new pane in the current terminal using a renderer of your choice.

Doing all this would be outside the scope of the terminal which should be a 'dumb' process isn't going to be scanning directories or rendering markdown in the first place.

@KalleOlaviNiemitalo
Copy link

If you change from one directory to another, and each directory has its own README, then perhaps you want the README of the new directory to display in the same pane as the previous one, instead of opening a third pane. On the other hand, if you detach the README pane from the original tab to a separate tab (#4587), then perhaps you want that to keep displaying the same README regardless of what happens in the shell session afterwards.

This might be implemented by allowing each pane to have a name (in addition to the pane title described in #7290). The shell could then run a command like wt split-pane --profile view-readme --startingDirectory . --paneName readme --replaceInSameTab. This command would search for a pane with the name readme in the tab that it would normally split; if found, it would kill the session of that pane and run the new README viewer session in the same pane, instead of creating a new pane. Pane names would not be required to be unique (unlike the window names described in #8135). Moving a pane to a different tab would preserve the pane name but --replaceInSameTab would not find the pane from there.

Alternatively, Windows Terminal could support named relationships between panes, i.e. know that the README viewer pane has a readme relationship to the shell pane. That would let the user run shells in two panes of the same tab and have a separate README viewer pane for each. Closing the pane at either end of the relationship would break the relationship. There could also be a command to explicitly break relationships while leaving the panes open.

@KalleOlaviNiemitalo
Copy link

If the shell is running on a remote computer behind ssh, then it seems unlikely that wt run by the shell would be able to connect to the Windows Terminal instance and ask it to open a new pane. It would likewise be difficult for Windows Terminal to read a README file from the remote computer. Instead, it seems tmux control mode (#3656) could be used for this. Make the remote computer decide when to start or kill the README viewer, and make Windows Terminal just open or close its pane when requested by tmux.

(Later DEC terminals, like the VT420, support the TD/SMP protocol for multiplexing several sessions over the same serial cable. In theory, I imagine TD/SMP could be used over SSH, instead of tmux control mode. However, it does not seem to be widely implemented on servers nowadays, I cannot find a protocol specification, and it might not support features such as resizable panes. It was also patented, although the patents may have expired by now.)

@zadjii-msft
Copy link
Member

zadjii-msft commented Jan 3, 2021

Alright, from the start, this isn't something we'd build into the Terminal by default. If anything, it'd have to be an extension, so #4000.

Once #4472 lands, this will be a lot easier. Assuming marked-terminal.exe is the exe that outputs a formatted .md file to the console, you could just run

wt -w 0 sp -d . marked-terminal.exe README.md

and that'll open a new split in the current directory, in the current window, running that command.

Heck, slap that into an action, and you could run it from the command palette, or with a keybinding:
EDIT: faulty json snippet removed as to not confuse folks
And that would even work today. (disclaimer: I wrote that json by hand and haven't tested it. The binding is something like that.)

EDIT: Unsurprisingly, the above does not work.

I'll stick this on the backlog for extensions for "trigger some extension behavior when the shell's current directory changes".

@zadjii-msft zadjii-msft added Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Product-Terminal The new Windows Terminal. labels Jan 3, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jan 3, 2021
@zadjii-msft zadjii-msft added this to the Icebox ❄ milestone Jan 3, 2021
@KalleOlaviNiemitalo
Copy link

And that would even work today.

How would "startingDirectory": "." in the key binding find the current directory of the shell?

@zadjii-msft
Copy link
Member

🤦‍♂️

Yea that won't work. I'll edit my comment. That's what I get for triaging on a Sunday 😄

@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Mar 26, 2021
zadjii-msft added a commit that referenced this issue Nov 12, 2024
This adds support to the Terminal for parsing Markdown to XAML. We're
using https://github.com/github/cmark-gfm as our parser, so that we can
support the fullness of github-flavored markdown.

The parser parses the markdown to produce a `RichTextBlock`, which
covers just about all the scenarios we need. Since we're initially just
targeting using this for "Release notes", I didn't implement
_everything_ in markdown[^1]. But headers, bold & italic, unordered
lists, images, links, code spans & blocks - all that works. We can work
on additional elements as we need them. The parser is encapsulated into
`Microsoft.Terminal.UI.Markdown.dll`, so that we won't load it on
startup, only when the pane is actually made the first time.

To test this out, I've added a `MarkdownPaneContent` pane type on
`x-markdown` (the `x-` is "experimental"). Go ahead and add that with:

```json
{ "command": { "action": "splitPane", "type": "x-markdown" } }
```

That's got the ability to load arbitrary MD files and render them. I
wouldn't call that experience finished though[^2][^3](and it probably
won't be in 1.22 timeframe). However, it is an excellent testbed for
validating what we do and do not support.

We'll use the markdown parser Soon<sup>TM</sup> for the What's New
panes.

* Done in pursuit of displaying release notes in the Terminal.
* Doesn't quite close out #16495 
* Should make #8647 possible
* may help with #16484

[^1]: the most notable gap being "block quotes" with `>`. I don't think
I can draw a vertical line in a rich text block easily. Footnotes are
also missing, as well as tables.
[^2]: I say it's not finished because the aforementioned MD gaps. Also
the UX there is not polished at all.
[^3]: I don't believe we'll have time to polish out the pure markdown
pane for 1.22, but what the parser covers now is more than enough for
the release notes pane in time for 1.22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

4 participants