Incorrect line prefix and duplicate prompt when using --tag-lines option

[morganwillcock]

I was looking at using the --tag-lines option to more reliably detect the game and debugger prompts, but when trying it, I appear to be getting a prefix of " " on a prompt line as well as a duplicate prompt.

Here is the normal output:

$ dgdebug cloak.dg stdlib.dg 
Dialog Interactive Debugger (dgdebug) version 1c/02.
Type @help at the game prompt for a brief introduction.


Hurrying through the rainswept November night, you're glad to see the bright
lights of the Opera House. It's surprising that there aren't more people about
but, hey, what do you expect in a cheap demo game...?

Cloak of Darkness
A port of Roger Firth's reference game by Linus Åkesson.
Release 1. Serial number DEBUG.
Dialog Interactive Debugger (dgdebug) version 1c/02. Library version 1.2.3.

Foyer of the Opera House
You are standing in a spacious hall, splendidly decorated in red and gold, with
glittering chandeliers overhead. The entrance from the street is to the north,
and there are doorways south and west.

> 

Here is the output with --tag-lines:

$ dgdebug --tag-lines cloak.dg stdlib.dg 
  Dialog Interactive Debugger (dgdebug) version 1c/02.
  Type @help at the game prompt for a brief introduction.
  
  
  Hurrying through the rainswept November night, you're glad to see the bright
  lights of the Opera House. It's surprising that there aren't more people
  about but, hey, what do you expect in a cheap demo game...?
  
  Cloak of Darkness
  A port of Roger Firth's reference game by Linus Åkesson.
  Release 1. Serial number DEBUG.
  Dialog Interactive Debugger (dgdebug) version 1c/02. Library version 1.2.3.
  
  Foyer of the Opera House
  You are standing in a spacious hall, splendidly decorated in red and gold,
  with glittering chandeliers overhead. The entrance from the street is to the
  north, and there are doorways south and west.
  
  > 
> 

I am testing in the XFCE terminal emulator.

[dstelzer]

That's intended—the first > is printed by the game, so it's a line of game output (prefix ). Then the game requests line input, so the next line has prefix > .

It would be nicer if the debugger could buffer each line, so the game's prompt would end up on the > line, not a line. (I believe that's what dfrotz does.) Unfortunately, the current system doesn't support that kind of buffering.

[morganwillcock]

the first > is printed by the game

Where is that in the first version that doesn't use --tag-lines?

It seems a bit counter-intuitive to display an extra prompt when trying to differentiate the prompt from game output that looks like a prompt.

[dstelzer]

Without --tag-lines, there's only one >, which is the one printed by the game.

If the game started like this instead:

This is the opening text, which spans as many lines as is necessary. An
introduction, a room description, and so on, everything that a work of parser
interactive fiction needs to get started. Blah blah blah.

What will you do next?

(With "What will you do next?" as its prompt.) Then with --tag-lines, it would look like:

  This is the opening text, which spans as many lines as is necessary. An
  introduction, a room description, and so on, everything that a work of parser
  interactive fiction needs to get started. Blah blah blah.
  
  What will you do next? 
> 

The first lines start with to show that they're output from the game; the last line ends with > to indicate that the game is waiting for input. Both of those are totally independent of whatever prompt the game might print for itself.

This feature was added to make it easier to wire dgdebug into automated tests, which need to know when the game is waiting for input.

[morganwillcock]

I can see how it makes sense for testing, but duplicating the prompt rules out using it for interactive use that also needs to determine the prompt, unless the output has additional buffering to try and remove the additional prompt.

From the description of the option:

$ dgdebug --help 2>&1 | grep -- --tag-lines
--tag-lines       -T    Prepend output with "  ", input with "> " or ") ".

...I was expecting this, where * is the cursor position:

  This is the opening text, which spans as many lines as is necessary. An
  introduction, a room description, and so on, everything that a work of parser
  interactive fiction needs to get started. Blah blah blah.
  
> What will you do next? *

For my purposes, I'll see if I can work around it, so feel free to close the issue.

[dstelzer]

Yeah, that would definitely be better—that's what dumbfrotz does, which --tag-lines is trying to emulate. Unfortunately, I haven't found a way to make that work with Dialog's built-in buffering system.

[morganwillcock]

Is this current output format going to be stable in the long term?

(I think I have the line parsing working, but it is a significant change to accommodate the debugger potentially being started with or without the --tag-lines option.)

[dstelzer]

The use of for output, > for line input, and ) for character input should be stable, because those are taken from dumbfrotz. If we figure out a way to put the prompt on the > line instead of a separate line, that bit may change. (And dumbfrotz supports some additional codes, for timed input and such, which could possibly be added in the future. But there are no current plans to add timed input to Dialog.)