> > > On reflection, it seems fairly improbable to me that people would use > \if and friends interactively. They're certainly useful for scripting, > but would you really type commands that you know are going to be ignored? >
I'm thinking the one use-case is where a person is debugging a non-interactive script, cuts and pastes it into an interactive script, and then scrolls through command history to fix the bits that didn't work. So, no, you wouldn't *type* them per se, but you'd want the session as if you had. The if-then barking might really be useful in that context. > > Therefore, I don't think we should stress out about fitting branching > activity into the prompts. That's just not the use-case. (Note: we > might well have to reconsider that if we get looping, but for now it's > not a problem.) Moreover, if someone is confused because they don't > realize they're inside a failed \if, it's unlikely that a subtle change in > the prompt would help them. So your more in-the-face approach of printing > messages seems good to me. > Glad you like the barking. I'm happy to let the prompt issue rest for now, we can always add it later. If we DID want it, however, I don't think it'll be hard to add a special prompt (Thinking %T or %Y because they both look like branches, heh), and it could print the if-state stack, maybe something like: \if true \if true \if false \if true With a prompt1 of '%T> ' Would then resolve to ttfi> for true, true, false, ignored. This is just idle musing, I'm perfectly happy to leave it out entirely. > This seems more or less reasonable, although: > > > # \endif > > active \endif, executing commands > > looks a bit weird. Maybe instead say "exited \if, executing commands"? > +1 > > BTW, what is your policy about nesting these things in include files? > My immediate inclination is that if we hit EOF with open \if state, > we should drop it and revert to the state in the surrounding file. > Otherwise things will be way too confusing. > That's how it works now if you have ON_ERROR_STOP off, plus an error message telling you about the imbalance. If you have ON_ERROR_STOP on, it's fatal. All \if-\endif pairs must be balanced within a file (well, within a MainLoop, but to the user it looks like a file). Every new file opened via \i or \ir starts a new if-stack. Because commands in an inactive branch are never executed, we don't have to worry about the state of the parent stack when we do a \i, because we know it's trues all the way down. We chose this not so much because if-endif needed it (we could have thrown it into the pset struct just as easily), but because of the issues that might come up with a \while loop: needing to remember previous GOTO points in a file (if the input even *is* a file...) is going to be hard enough, remembering them across files would be harder, and further complicated by the possibility that a file \included on one iteration might not be included on the next (or vice versa)...and like you said, way too confusing.