> This sprinkles the sources with code snippets reflecting
> certain constraints on the underlying streams instead
> of keeping such assumptions in one place
I respectfully disagree. Arguably, the present version is also sprinkled
with code snippets... Code snippets that assumed that the prompt, for
instance, is preceded by ~&, instead of explicitly controlling newline
behavior.
> What if somebody wants *standard-input* and
> *standard-output* to go to different terminals, for instance?
This is why the fixes need to be tested in all contexts. When I made my
initial fix, I tested it using three different LISPs, using both command
line mode and graphical clients, and also batch mode and redirects. Though I
did not fix all occurrences where extra messages appear without a necessary
newline, the ones I did fix convinced me that this approach is eminently
doable, and the effort is reasonable, hence I offered my fix to Jim for
evaluation.
> I don't think so, and we have already discussed this point.
> In particular, Clisp's (and ECL's) *terminal-io* behave as
> you want it to
Well, the fact is that it does NOT work that way with the copies of GCL,
CMUCL, and CLISP installed on my system.
> Why do we care about these issues at all? We should just
> use FRESH-LINE and not worry about what any old lisp might
> do about it.
I worry about it because I not only write code, I also USE Maxima. The extra
newlines are very inconvenient, and I don't care whose fault it is... What I
do know is that whereas it is not within our power to fix all LISPs out
there, it IS within our power to devise a solution that works around the
problem and provides consistent behavior with all supported versions of
LISP.
Or, to put it another way, we can make a choice: write code against an
idealized, flawless, perfect compiler or write code against the actual
environments in which Maxima will be compiled and run. I advocate the
latter, even though I realize that it is messier.
Viktor