"Conveniently" append newline when autoresponding?

[bitprophet]

From #289. See also #369 which might obviate this (by making "respond to prompts" just one of many potential callbacks hooked into the autoresponse system).

Background

Many autoresponse use cases are responding to prompts, wherein a newline is required to submit; it's very easy to forget the newline and wonder why things didn't work right / the program is still hanging. Automatically appending \n (probably in a "only if not explicitly newline-terminated already" manner) solves this.

Unfortunately despite prompts being arguably the main use case, there's doubtless non-prompt uses for this feature, and a "helpful" newline insertion would make those frustrating / impossible.

Unlike most run features, this would be hard to add with a simple "advanced users can turn it off" toggle, because it wants to be per-response, not per-run-invocation. (Otherwise executing run with a nontrivial responses dict would be ambiguous - some might have been inserted assuming auto-newline, some might not.)

Ways forward

• Close the ticket: it's not really THAT hard to add a newline and that leaves the implementation as something relatively clean/pure.
  • At least add a warning or info block to the docstring and/or conceptual doc, making it obvious that newlines must be manually added. Hope that this heads off most footgun potential.
  • Arguably, my own foot-shooting during testing isn't realistically something most users will encounter, they're likely to only add a single thing to responses at a time, not dozens of times like in the suite.
• Just implement the naive version, see if anyone actually does ever use it for things which aren't prompts. Revisit if so.
  • Not a big fan of this one...
• Make the responses dict a real object structure (or, possibly, nested dicts) with more, well, structure. Allows non-prompt response entries to specify e.g. no-autonewline or something.
  • "Best" solution but arguably over-engineered.
  • Also runs into the "do we offer the shorthand of just-a-dict and also this more complex structure, at the same time?" problem where the API gets really mushy.
  • However, may dovetail well with another "responses feature needs to be more powerful" ticket (to be linked).