> Personally, I find missing newlines much more annoying than blank
> lines, so, frankly, if we are in a hurry for the release, I'd suggest
> to revert Viktor's patch in the release branch.
Well, you have a point. The patch was meant to be applied with the
understanding that a fix is needed in many places to add newlines that are
not present (I fixed several of these myself.) In the absence of those
fixes, I can see that an extra newline can be less annoying than missing
newlines. Having said that, the extra newlines can be very annoying, too,
especially when a Maxima program attempts to print multiple lines of text
that comes out double-spaced. I personally find the current CVS behavior
less annoying (I also prefer to move forward, completing a partial fix as
opposed to rolling it back), but I guess it's a matter of taste, choosing
the lesser of two evils... In the long run, we ought to properly fix this
issue.
Regarding the use of ~&, the problem (which my patch was intended to
address) is that ~& does not properly recognize it when the cursor is at the
beginning of the line as a result of input, not output. So in an interactive
situation, we may have a prompt with no newline at the end:
(%i1) _
Then, the user enters a command and hits the Enter key, so the cursor is now
positioned at the beginning of the next line:
(%i1) 2*2;
_
But the ~& mechanism is confused; it still thinks that we're somewhere in
the middle of a line, since no newline appeared in the OUTPUT stream. Now,
when Maxima sends an output starting with a ~&, an extra newline is
inserted, resulting in this:
(%i1) 2*2;
4
(%o2) _
In other words, ~& seems useless in an interactive environment, since it
does not take into account changes in cursor position due to input.
By removing the ~&, I eliminated this problem, but we now have a new problem
when outputs from Maxima run together on the same line, with no newline in
between. These can be fixed by addressing each case individually, but that's
a fair bit of work.
Viktor