Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!decwrl!hplabs!hp-pcd!hpcvlx!everett
From: everett@hpcvlx.HP.COM (Everett Kaser)
Newsgroups: comp.sys.ibm.pc
Subject: Microsoft Editor: problems
Message-ID: <1180018@hpcvlx.HP.COM>
Date: 16 May 88 16:47:31 GMT
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 115

Dear Microsoft,

Thanks for including your new Microsoft Editor with the new versions of
C and MASM.  It looked very interesting, and I thought I'd give it a try.
Well, after a couple of days of trying to configure it to look and work
something like Emacs, I'm, errr, uhhhh, well-l-l-l, disappointed (to be
polite).

What, exactly, was the reason for rushing this product out the door in
its current state?  Let me describe some of the problems I've had.

I started out trying to adjust the screen colors and size.  I like different
colors than your defaults, and I like to use the 43-line mode of my EGA+
card.  Well, the colors changed just fine, both by command in the editor
and by placing the changes in TOOLS.INI.  However, simply putting the 43-line
mode into TOOLS.INI didn't work (Height:41).  In order to get the editor to
come up in 43-line mode, I had to enter the editor, issue the command to put
it in 43-line mode (arg height:41 assign), then exit the editor.  The editor
then, apparently, updates the file M.TMP, which determines in the future
line mode for the display, completely over-riding the entry in TOOLS.INI.
That was problem (bug) number 1.

Once I got the screen the way I liked it (reasonably), I decided to try
writing an extension program, since I didn't like the way the cursor movement
was handled: left-cursor doesn't wrap from start-of-line to end-of-previous-
line, and vice-versa for right cursor.  (There's additional lesser things
that I don't like about up/down cursor.)  Anyway, in section 8.3 of the
Microsoft Editor User's Guide it says:

   To create a successful C extension, you need to follow these guidelines:
        1. Check the README.DOC file to see what functions you can call
           from the standard C run-time library.

           A technical problem prevents library compatibility: to work with
           the Microsoft Editor, you must compile with SS not equal to DS...

Well, there was no README.DOC file on the editor disk.  I looked on all of 
the disks that came with C 5.1, and found only one README.DOC file, the one
for the main compiler.  It was a large file, but nowhere within was the
Editor mentioned.  Thanks a lot.  Now I can't use ANY of the functions in
the libraries.  Real useful.

I decided to forge ahead anyway.  The next problem I encountered was a more
global problem of general documentation.  Although some of the low-level
functions of the editor that you can call are described in the manual, and
others in the file EXT.DOC, nowhere are we given a good description of the
general internal "working structure" of the editor, ie. what's all this 
stuff about reading lines from files?  Does a "file" correspond to a "buffer"?
How do "files" relate to "windows" (what you see on the screen)? etc, etc.

I'm slowly getting a feel for how the thing works, and what you can do in
extensions, by writing test extension programs and seeing what happens; but
as a programmers manual for a programmers editor, this one sucks the big one.

The last thing is another bug, a big one.  As I said, I wanted to write a
replacement cursor control function.  So, I wrote a function called "test"
(the cmdDesc table entry: {"test", Test,0, NOARG | CURSORFUNC } ) that
looked sort of like this:

unsigned	col;
LINE		row;

flagType pascal EXTERNAL Test( argData, pArg, fMeta)
unsigned int argData;
ARG far *pArg;
flagType fMeta;
{
   row = pArg->arg.nullarg.y;
   col = pArg->arg.nullarg.x;
/* more code here that converts row and col to hex in a char buffer and then
   displays it using the DoMessage function call in the editor */
   return TRUE;
}

Yes, I know it's ugly and all but unreadable, but that's the constraints set
up by the editor folks, and it all seems to work reasonably well.  The code
that converts row and col to hex in the char buffer formats the two variables
row and col into something like     yyyyyyyy xxxx    where yyyyyyyy is the 
row (LINE is typedef'd to a long) and xxxx is the col.  From what I saw, the
internal line/col numbering starts at 0 (fine by me).  Well, when I moved the
cursor to line 4, column 10, and invoked my test function, here is what I got:

         000A0000 0004

The line number showed up in the x/column variable, and the column showed up
in the upper word of the y/row variable.  Now, I know it's not a problem in
my output formatting routine, because of two things:
   1) I wrote the hex output formatting in several totally different ways
      and all came out the same.
   2) I also wrote a different function that used the GetLine and DoMessage
      functions to display (on the dialog line) the text of the line the
      cursor was currently on:

         cfile = FileNameToHandle("", NULL);
         GetLine(pArg->arg.nullarg.y, tbuff, cfile);
         DoMessage(tbuff);

      Regardless of what line the cursor was on, if the cursor was in column 0
      (at the start of the line), then line 0 (the first line in the file) was
      displayed on the dialog line.  If the cursor was on any other line, the
      dialog line was blank (since the nullarg.y variable would have been 
      >64K, which was more lines than my file had).

Now, I don't know if this is just a problem with the definitions in the EXT.H
file, or whether the LINE/COL variables are pushed onto the stack in the
wrong order, or what.  What I do know, is that this is a pretty ugly bug for
people like me who want to adapt the editor to my own tastes (one of the BIG
items in the advance propaganda).

Until microsoft gets some of this stuff cleaned up, I'll have to stick with
my trusty old Emacs.

Everett Kaser
!hplabs!hp-pcd!everett
(503) 750-3569