Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!bellcore!texbell!merch!cpe!hal6000!trsvax!johnm
From: johnm@trsvax.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Compiling mEmacs under Turbo C 2.0
Message-ID: <216100071@trsvax>
Date: 21 Nov 88 15:34:00 GMT
References: <41280@aero.ARPA>
Lines: 123
Nf-ID: #R:aero.ARPA:41280:trsvax:216100071:000:5508
Nf-From: trsvax.UUCP!johnm    Nov 21 09:34:00 1988


Before I get started, it seems that Mr. Lawrence took some offence at what I
had meant to be constructive criticism.  I am very sorry if you mistook my tone
to be ungrateful or unfairly critical, it was not meant to be.  I appreciate
your work and was merely discussing changes I would like to make or see made
that would make it the best possible editor for my purposes (i.e. editing C
files on a Vax, Amiga, and PC clones.

>>I would really love it if the size of a displayed tab was an adjustable thing
>>and also if the tab implementation (spaces or tab) was selectable.
>>
>	in version 3.10 $hardtab is the number of columns between hard
>tab stops, and $softab is the number of spaces used in soft tabs. (If
>$softab is zero, hard tabs are used. $hardtab defaults to 8).

Hurray!

>>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.
>
>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.

As somebody else pointed out, you have to be on a PC to notice it.  I'll look
for it in the new version.  Thanks for telling me where to look.

>>	c) temporary windows that go away once you press a key (excellent for
>>	functions like apropos)
>
>	I though very seriously about this, but  I really don't know
>what would be a good implementation of this.  Too many of these
>"Temporary output" commands fill up the window and require the user to
>page throught them.

How about splitting the current window and then deleting the temporary window
when a ^G is pressed?

>>	d) a function that creates a file with a unique name
>
>	Macro Function?  For temporary files? explain.

It has to do with my firing off makes.  Don't let it worry you, it was just
a little rambling.

>>	e) functions to return the size of files and delete files
>
>	directory listers and OS remove or delete commands seem to work
>real well for this.  ^X$ and ^X! call them up very easily...  I don't
>understand why yet another machine dependant function is needed for this.

There is a problem with that, there is no way to react to the outcome of the
execution.  Suppose the file isn't there?  If not then there is no variable set
to the exit value of the command because it is not an internal one.

>>	f) file name completion
>
>	Again, machine incompatability.  I don't have to write these
>once, but 12 times.  Not having access to a lot of the more unusual
>machines I am very hesitant to make uEMACS at all machine dependant. I
>really wrote it because I was VERY angry about learning loads of
>different editors everytime I switched hardware.

This is kind of a strange reply considering the video use that you have in there
now (very machine specific), and also the fact that filename completion is only
machine dependant WITHIN the code.  Filename completion as far as the user is
concerned will probably stay the same across all machines.

I'm not saying that you should be forced to write this or anything else that you
don't want to.  But I or someone else can take a stab at it, give you the code,
and it can just be an #ifdef in the code.  People who don't want it don't have
to have it.

>>Which brings me to my final point.  I could probably do a couple of these myself
>>if I had the latest uEmacs source or knew where to get it (or even what version
>>it is).  Can anybody tell me where to get it?
>
>	Did you try the docs? Every README file or EMACS.MSS file from
>version 3.3 and up (4 years ago) has had my address/phone and BBS phone
>numbers in it.  My apologies if you somehow got uEMACS without these
>files, but I have been on the net a lot and available through the ibm
>and emacs groups for 3 years as well.

You know, I never thought of looking in the docs :-).  That was pretty dumb of
me.

>>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 saved this for last even though it came first because macros are really
important to me.

How about taking David Betz's ExTalk language (described in this months Byte
magazine) and imbedding the ExTalk virtual machine in uEmacs?  How would that
help macros, glad you asked...

	a) Macros would become a compiled entity and the slow startups that
	PC users with large emacsrc files have would go away.

	b) The macro language would be more robust in many ways (even to the
	extent of being object oriented).

	c) If other applications begin using ExTalk then it could provide
	users with a common macro language across applications.

	d) It seems to me (from having written a 25 opcode 68000 emulator in C
	a long time ago) that the amount of code devoted to the macro language
	in the editor might even shrink.

	e) It is written in C and thus would be immediately portable to all the
	machines uEmacs is now on.

John Munsch