Path: utzoo!utgpu!watmath!clyde!att!rutgers!cmcl2!rocky8!rocky2.rockefeller.edu!edf
From: edf@rocky2.rockefeller.edu (David MacKenzie)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Compiling mEmacs under Turbo C 2.0
Keywords: uEMACS
Message-ID: <227@rocky8.rockefeller.edu>
Date: 20 Nov 88 04:07:17 GMT
References: <41280@aero.ARPA> <216100068@trsvax> <8308@j.cc.purdue.edu>
Sender: notes@rocky8.rockefeller.edu
Reply-To: edf@rocky2.rockefeller.edu (David MacKenzie)
Organization: Environmental Defense Fund
Lines: 74

In article <8308@j.cc.purdue.edu> nwd@j.cc.purdue.edu (Daniel Lawrence) writes:
>In article <216100068@trsvax> johnm@trsvax.UUCP writes:
>>Yes, I too would like to make this change and one other.  Have you ever noticed
>>that splitting the screen slows you down massively when you start editing.  I
>>think this is because uEmacs wants to keep the upper screen display coordinated
>>with the lower if they both contain the same file.  This isn't strictly
>>necessary though unless the line you are editing also appears in the other
>>window.  That is one fix I would love to make.
>>
>
>Maybe I am not running on a slow enough machine, but with two or three
>windows, I don't notice the difference.  The code for this is in the
>linsert() function in line.c. Just don't update the change flags for the
>other windows.

Under System V Unix, adding multiple windows doesn't slow things down at
all, but under MS-DOS (using MicroEMACS 3.8l compiled with MSC 3.0), it
goes from very fast to almost unusably slow when you go from one window
to two.  I've never understood that, either, nor have I explored that
part of the code, but it sure is annoying.

>>While I'm on a wish list kick, how about:
>>	a) a tags function (NOT a convoluted macro)
>
>	So that everyone pays the price in size so that a few can have
>tags?  Yes I know there are a lot of programmers who would like this
>built in, but if I put everything like this in we would end up with
>something the size of GNU emacs, and that just doesn't seem to be the
>point behind all this.  Instead of saying this, why don't you explore
>writting a non-convoluted macro, or help point out to me what I can do
>with the macro language that would keep such a thing from working the
>way you would like.

I think that the tags macro I have works pretty well, except that
MicroEMACS's regular expresions treat '*' as magic, so it doesn't work
with definitions like "char *foo() { ..."; but if you search in
non-MAGIC mode, then you might get bogus matches because you have to
ignore the '^' and '$' characters in the pattern.  Otherwise, I think it
just shows how powerful MicroEMACS's macro language already is.

Here are a few things *I* am hoping are in 3.10:
1.  A way to bind named macros to keys directly, rather than needing the
    execute-macro-n kluge.

2.  A way for macros to access the repeat count given to them (unless
    they already can and I just missed it).

3.  Undo.  With all of those control key combinations, I *often* find
    myself accidentally pressing the wrong key and wondering what in the
    world I did to mung my file.  I usually have to kill the buffer,
    losing the changes, and reload the file.  This is an incentive to
    save frequently, to be sure.  Even limited undo like vi has would be
    wonderful.

4.  More efficient screen redraw in the termcap driver, particularly use
    of the insert-line and delete-line capabilities.  It's just
    intolerable at 1200 baud currently.

5.  Entab- and detab- line functions that only affect leading spaces, so
    they don't screw up strings in code.  Using these, it would be
    possible to write good shift macros like vi's << and >>; you would
    detab the lines, add or delete the appropriate number of leading
    spaces, and then re-entab the lines.

I know, I ought to just hack on the beta and do it myself.  Wish I had
the time!

For many purposes, particularly editing multi-file sources, though,
MicroEMACS is great.  The programmability is wonderful for a non-huge
editor.
-----
David MacKenzie
Environmental Defense Fund
edf@rocky2.rockefeller.edu (...rutgers!cmcl2!rocky2!edf)