[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Problems
- Subject: Problems
- From: Robert Holmgren
- Date: 20 Apr 1993 12:15:49
Dear SysOp: Some questions:
1) In v4.011, if I Define a Column (func DC) and try to MoVe it (func MV),
the operation fails, cursor jumps to row 0 column 0 of the DefinedColumn (as if
func DB had been issued, or a JMP to VA$DS made), and define is cancelled. Is
something broken here? Note that if I CoPy and then RuboutDefined text
(DC...DC...CP,RD), I get the equivalent of a MoVe.
2) In eXPanded mode ($DT=0), screen behavior seems much different than in Sig
or Xy3. The nominal RM still appears to be 78 (at least, to judge by the
Ruler's visual indicator); but in practice every line wraps before column 73.
This means that a text with hard carriage returns at the end of every line (a
text designed primarily for console display, with line lengths of 78) often
wraps further to the left than expected -- earlier than it used to -- leaving a
very short particle (usually one single word) on a next line by itself,
followed by the hard carriage return. Thus what used to look like this
(pretend that 38 is really 78):
Here's a sample of wrapping under Xy3+[hard CR]
And here's line 2[hard CR]
now looks like this:
Here's a sample of wrapping under[soft CR]
Xy4[hard CR]
Here's old line 2, now become line 3[hard CR]
That's a drag. Note that this behavior is limited to XP mode; in WG ("draft")
mode, the first type of wrap prevails. VA$WF=0. Doesn't make any difference
if I change WF=1. Extremely irritating when you're trying to read imported
Ascii documents, where every line ends with a hard return! What has changed,
and how do I restore the old XP wrapping behavior?
3) I'm dubious about your explanation on 3/24 (#8488) of the difference
between VA$CM and (undocumented) VA$CL. You imply that VA$CM stores function
calls whereas VA$CL doesn't. VA$CM stores the text string that's current on
the CMline, whatever it is. It may well store 3-byte chars (if part of the
CMline text string), but that's incidental. It certainly does _not_ store the
"BC commandXC " string that yielded the last-executed command, as stated in yr
msg. VA$CL appears to store the text of the last command executed on the
CMline (sans functions), regardless of the current text on the CMline. VA$CL
seems buggy, and often stores corrupt forms of the last command. BTW, how
about documenting this stuff? $CL $FR $OO too!
4) How about a DF that records the cursor state (insert or overstrike)? Long
overdue.
5) Do you have any reports that the command is working erratically?
Sometimes, for no good reason, stores a value that adds about 80 bytes to
the correct CharPosition. Very irritating when it happens. Intermittent.