Add support for @stdin on <program>.

[jdeisenberg]

Add @stdin attribute to element. Outputs a data-stdin attribute in the resulting HTML.

[rbeezer]

Thanks for noticing that this is not implemented.

Runestone Author Guide says:

stdin

String. Define a virtual ‘standard input’ for an active code block.

If present, :stdin: creates a text area and allows a string to be 
passed to the program for processing. An optional value after 
the argument defines the default value.

• What do you think of @stdin being yes or no, resulting in an empty text area when yes? And then @stdin-default for supplying a value? As is, the common use case of an empty text area would require stdin="''" (or maybe just stdin="")?

• There should be an example in Chapter 5 of the Sample Book. For testing as part of the PR, and long-term testing of other work. And documentation in The Guide:
  Subsection 4.15.3: Interactive Programs, ActiveCode
  https://pretextbook.org/doc/guide/html/topic-program-console.html#interactive-program-activecode

• Does this make sense for every language? Like HTML? Should we be more careful about that distinction?

• Looks like your PR has tabs in it? Did not fetch it, so can't be certain.
  Section 52.4: Tabs
  https://pretextbook.org/doc/guide/html/git-tabs.html

[jdeisenberg]

Fixed the tabs. I think having only one @stdin instead of an additional @stdin-default makes processing easier; otherwise we have to take care of the case where someone specifies @stdin-default without @stdin -- do we provide the @stdin automatically, or raise an error, ignore it, or what?

[jdeisenberg]

If you set data-stdin="", the data entry area does not show up at all. If you set it to data-stdin="''", you get two single quotes in the data area. It would seem that whatever JavaScript handles that attribute requires a non-empty value.

[DavidCooperWCU]

I'm just curious about the timeline on this request. We're about to start the semester in a little under three weeks, and it would be great to have this feature available by then. Thanks!

[rbeezer]

the timeline on this request

The fact that we need a non-empty value makes this a bit nebulous. Two attributes - a mandatory switch and an optional value feels better to me. We don't worry about erro-handling so much; the schema can express correct formulations precisely, so that is not at issue.

Once that is settled, this needs documentation to move forward. I'll be off-duty for the final two weeks of your three-week window.

[rbeezer]

Just replied to a -support thread on all three std* streams.

Myabe this should be an element. progam has input, plus output, stdin etc. That could be presentational outside of ActiveCode (and in static formats), while being an active participant in an ActiveCode. Pinging @bnmnetp who might have thoughts.

[bnmnetp]

I guess the thought process of the guy who wrote the javascript was why would you go to the trouble of adding a stdin and then leave it blank?

        if (this.stdin) {
            this.createInputElement();
        }

Yep, an empty string is "falsey" in Javascript.

It would be easy enough for me to check if this.stdin is undefined which is the case when the @data-stdin is not there.

So easy in fact that I've already made the change, which I think actually counts as fixing a bug (given the documentation)

[adam-a-smith]

A related idea that I've been wrestling with is how to make a stderr in outputs. I'm not sure that this is quite what you all are talking about above. But it would be useful in my book to distinguish stdout from stderr in my tags, since they really are different channels.

[DavidCooperWCU]

It looks like Brad's bug fix makes it so there would only need to be one @stdin attribute/element and not a default value attribute/element. I'm not sure whether an attribute or element is better for this particular feature. It may be theoretically easier to make newlines if it's in an element, but I'm not sure.