Re: v4/v3 CMline (was Re: survey on XW use)

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to note from "..."  04/09/96 1:13pm -0400

> Hi, Robert: I haven't thought this through, but the way the xyDos 4
> CMline handles input does seem to be at the heart of my reservations
> about v4. Three examples come quickly to mind, but if I used 4 an hour or
> so I could come up with others.

> 1. *Many* of my *.kb3 entries enter guillemet'd code--v3 doesn't care
> whether in text or on CMline. That is fundamental to my xpl programming
> practices... To get an identical effect
> in xyDos 4 requires convoluted U2 entries.

I know you're not looking for solutions, but: some reactions. The
inability of v4 to accept real guillemets on the CMline absolutely
infuriated me. It still does. My bile rises as I write! How dare these
arrogant SOBs compel us to change our entire working style in order to
impose a simply cosmetic "improvement"!

That said, I adapted, and I'm glad. No thanks to XyQuest, I hasten to add-
- but I'm glad. I had a KBD file just chocked with XPL. There were real
line length limits; I recall something on the order of 440 characters per
key assignment, and I was incessantly seeking small programming economies
in order to squeeze my stuff into a "fit". The biggest economy you can
seize in v3 is to delete all the commas between functions. In other words,
 nn=NI,DX,NF,MD,MD,DO,FF,BC,d,i,r,XC
becomes
 nn=NIDXNFMDMDDOFFBC,d,i,r,XC
You end up increasing your available space for programming by 30-40%. But,
it was all a bit silly. U2 is a far more sensible place for programming.
For one thing, it's faster. Routines interoperate. You can be as prolix
as you want. It's a helluva lot easier to write the stuff, than formatting
it for the KBD file! And there's nothing "convoluted" about it at all,
just straight XPL.

> 2. In some cases v4 CMline treats whitespace as not present, and I forget
> now in what context...

I don't think there's any difference at all. The only white space that's
ignored is the space after the last user-entered character on the line.
Even that, if you want it, can be picked up with VA$CL (I think it is --
undocumented).

> :  [M]ercifully there haven't been any changes since Signature
> :  was introduced, it's been stable for the last few years,
> :  a rare instance of no news is good news).
>
> Here we must agree to disagree. The v4 CMline is altogether too
> sensitive, tries to do too much text processing, for my taste.

All I was saying is, that if they change the handler, there's nothing much
we can do about it, we simply have to adapt, like it or not. But when you
have to adapt twice a year, it's a serious imposition. I'm happy that
there haven't been any changes since Sig, i.e. for about four years. That's
a record. I don't really understand what PERS.SPL "conversions" are, if
that's what you mean by "text processing". I happen to think the v4 line
is dumber, not the v3. In v3 I could actually run little XPL routines on
the CMline, treating it as a kind of special environment & workspace for PV
operations -- PV being the transformational XPL operator, whereas GT is the
dumb dumb dumb one. GT is all we've got now.

Funny how easy it is to send Public when you intend Private. No taking it
back either! One of many unlikeable things about this forum. The
inability to publicly, openly, easily distribute binary material to
everyone is also just awful. Anyway... Be good


-----------
Robert Holmgren
holmgren@xxxxxxxx
-----------