I suggest you ...

Remove hard-coded processing of blank lines from the Keyboard.i6t

If authors want to do something with a blank line (such as run a different command, like LOOK), they currently must hack the Keyboard routine to comment out the hard-coded bailout of the parsing beginning after the comment "If the line was blank, get a fresh line". If this was moved to a rule, or could be deactivated via a use option, authors could adjust behavior in more I7-y ways instead of needing to replace a long I6 routine in ways that render it incompatible with other code or extensions that also might want to adjust this routine.

6 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AaronReedAdminAaronReed (Admin, Inform 7) shared this idea  ·   ·  Admin →
    under review  ·  emshortAdminemshort (Admin, Inform 7) responded  · 

    I am in favor of this, and think it fits well with other items on the agenda of the present build, to do with allowing much greater output customization overall. We’ll see.

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Andrew PlotkinAndrew Plotkin commented  · 

        I'd say the cleanest solution is to remove the blank-line check from Keyboard(), and instead perform that check right after the "reading a command" activity. (Before the ".ReParse" label in Parser__parse().) It can still invoke a parser error rather than an activity. But then an "after reading a command" rule can do something else, remunge the blank line to something more useful. I think that's the most natural tool for the job.

        You'd have to be careful to handle blank lines correctly in the other places that call Keyboard() -- two disambiguation points in the parser.

      • Victor GijsbersVictor Gijsbers commented  · 

        I support this feature request, and would like to point out that a "Rule for printing a parser error when the latest parser error is the I beg your pardon error" is not a valid alternative: parser errors go back to parsing immediately, skipping the turn sequence rules, which is presumably not what the author wants.

      Feedback and Knowledge Base