Re: Nota Bene

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to message from Dorothy Day  on Sat, 1 Jun 2002
21:40:09 -0500 (EST)

Dorothy:

> On Sat, 1 Jun 2002, Robert Holmgren wrote:

>> Here's my take: [blah blah blah disparaging of timid NBers]

> Robert, that's just a tad unfair, though largely true. The Customization
> & Programming Guide supplied back starting with version 2 had the basics
> on using XPL, and XyWrite Revealed provided a fuller. more coherent
> guide to what all those codes meant and how to use them.

That CPG booklet was *very* rudimentary -- and that was thirteen years ago;
compare Xy4's customization guide, or better, "Making the Transition", and,
well, there's no comparison.

> Steve Seibert's licensing of the Xywrite engine, TextBase (which evolved
> into Orbis) and the bibliography-generating program (and the programmers
> hired to create Ibid from that), and the tight integration of those
> three modules makes the package ideal for research as well as
> writing.

May be. Ideal, if you're willing to "take it as it comes" and are uninterested
in adding personalized features (or subtracting all the overlays). But it is
precisely that "tight integration" that makes NB much more impervious to
modification and, conversely, makes modification more likely to upset the apple
cart. It has *always* been that way with NB, since I've owned it (v3). Unlike
XyWrite, NB has always had binary overlays and *essential* files that no user
can modify. Moreover there is scant acknowledgment that you have any
alternative! For example, there are built-in mechanisms in NB (such as the
"VA_" variable) that would allow the Help file to accurately reference the exact
key in your KBD file that performs a particular function; but instead Help just
assumes that the pre-programmed keys are used, which is not real helpful.

> Seibert also customized the default keyboard to produce (mostly
> European) accented characters and run the three main program modules,
> but it's still yours to modify just as in XyWrite (along with printer
> drivers and help files and frames,etc.)

I'm not talking about the *keyboard file*! What can you do with a Windows
printer file? Or a KBD file, except introduce a few silly keystroke macros,
which by their rigid nature canNOT have any built-in intelligence? Accented
characters are a piece of cake, with or without KBD support. That's basically
fluff and nonsense (and the KBD is the wrong place for most of it *anyway*).
I'm talking about getting complex XPL to work reliably. And it often doesn't, in
NBWin. Many times I've started to notate the bugs in NB; but to describe them
with convincing thoroughness, and to dictate (as one must) the specific steps
required to reproduce the error, takes so much time, and has so little hope of
being remedied (with NB's small staff and *fundamental disinterest* in the whole
subject of customization), that I just give out & up before I get going. The
bugs are absolutely innumerable. But I guarantee that an ordinary NBer will
never encounter 99% of the ones I see.

Plus I simply cannot abide NB's keyboard handler. Until they disable ALL the
reserved keys, i.e. give users access to them, for someone like me there is
little incentive to push on -- it means that much to me. As of v5.5-3c (my
latest), they have taken only a few steps in that direction, without introducing
the basic mechanism (a VAriable, obviously) to allow a user to voluntarily
disable all the keys. Although they easily could do that.

> The magnificent Green manual
> and then the Big Black Book include clear instructions for all three
> integrated programs

What are you referring to? Certainly there was NOTHING accompanying v5.
On-line NB website reference material is miserable. With NB v4, you couldn't
even DL an updated PRiNter file from them! Loads of dead links, and marginal
content -- it's really little more than a big advertisement. No list of VAs (I
mean, what is VA "C#" anyway? who knows? NB would certainly add "who cares?",
because clearly, if anyone did care, that list, so UTTERLY INDISPENSABLE to
manipulating the machine with XPL, would be front and center. Ergo I conclude,
with considerable logic on my side, that nobody's doing any serious programming
over there). Or they'll say things like "Can I download information from
on-line sources directly into NB for Windows? Yes. This feature is facilitated
by Bookwhere for NB which is also available now." But when you look at the
specifics of their Bookwhere info, there's no mention of anything except MARC
data. Hell, I can DL http web pages directly into Xy4-DOS anytime, using it
like a browser.

> The emphasis is on churning out the books and (increasingly camera-
> ready) copy. NBWin has made that far more possible (and more fun).

NB *user* emphasis, doubtless; but I want a malleable all-purpose engine not
pegged to producing particular kinds of documents. Xy4-DOS hews much closer to
that philosophy than NBWin.

>> In short, NB is waiting for some talented programmer with a XyWrite
>> background to really study it...

> Will Dave Erikson do for one such programmer? He's contributing now...

Theoretically and obviously, there's nothing he couldn't do if he wanted to
(and I think he's more than "contributing", I think he's maintaining the core
code). But I also think he's now working in service of NB's above-mentioned
philosophy. Look, that's great, I'm sure it serves the NB user base very
nicely. I'm only saying that, coming from my perspective, and perhaps the
perspective of other XyWriters, NB doesn't measure up (yet), and is not yet
capable of replacing XyWrite as an all-purpose engine, where you toss all the
canned stuff -- the menus, the overlays, everything! -- go back to the basic
building blocks (functions, commands, variables), and roll your own personal
word processor. Not to mention, that it's very discouraging to open a 70-page
columnar file (akin to a spreadsheet), and have NB constantly crash and burn
after just two or three operations -- or even just paging down more than 10-12
pages into the file and you get a GPF! A file that Xy4 and XyWin can handle
with aplomb. How do you debug a GPF, for heaven's sake? Merely to cite one
example; there are plenty.

> The SmartWords engine and other
> limitations of 32-bit WinGate are the main hurdles, and they've been
> hacking away at the inevitable bugs resulting from those.

Well, good. Maybe I should send in a brief bug list, and see what happens.
Nothing to lose (except hours and hours of time), maybe something to gain. But
my fear (amply borne out at XyQuest and TTG) is this: You document a bug, they
can't reproduce it. OK, you amplify the instructions so that it *is*
reproducible, supplying a sample document or whatever; and then they say (if
they respond at all), right, we understand now, but frankly it isn't a
"priority", or we don't use it that way in any of our default configurations, so
clearly nobody else will ever encounter it... And this covers up the reality,
most often, that the problem is so deeply embedded in the core code that there's
only one person competent to fix it.

Which brings us back, inexorably, to David Erickson. He *is* really the only
hope here. If he doesn't do it, it won't happen. Getting his attention is the
problem.

> Cheers,
> Dorothy

Bottoms up! (Er, well... you know what I mean.)

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