🚀 go-pugleaf

I have been listening carefully to the discussion concerning 
Emacs and its problems *8-) compared with other editors.  I would
just like to add a few thoughts, but first, a little framing is 
necessary.

Xedit/REXX was the first real editor I learned.  I had used and
pretty well understood some PC editors, but they should not be
added to this discussion, as their designers need not concern
themselves with portability; a something most other programmer's
*do* care about.

Using what I call ReXedit (Rexx/Xedit), I was able to write a full
screen mail agent.  It has many if not most of the options available
to RMAIL emacs; this is what inspired me to write the mail program.
I have written many other packages in ReXedit as well.  I have not
done anything serious in Elisp, for two reasons: first, it is harder
to learn, and second, I don't have much documentation on it.  Now, 
one could say that the first is due to the second, but this is not
true.  I have looked at and studying many of the examples of Elisp 
and that should be enough to understand it.  But, it is not.  Rexx
IS easier to learn; it is hardly debateable.  The syntax is much 
closer to english; similar to pascal or basic. 

Ok, now to go on:

There is no doubt in my mind, after using emacs for the past year and
half, that it is the best thing around.  Granted, I have not used
all the editors which exist, and I am sure there are some which
cater to a specific need and fulfill it well, but for overall use 
Emacs is certainly the way to go.  It is simply the most adaptable
editor around. 

As I am not entirely familiar with the regexp routines, I won't
get into that discussion.

>joshi@m.cs.uiuc.edu (Anil Joshi) writes:
>>jbw@bigbird.bu.edu (Joe Wells) writes:
>>>joshi@m.cs.uiuc.edu (Anil Joshi) writes:


>>> I don't see any advantage of using LISP syntax over say REXX for editor
>>>  macros. I can do better in REXX than LISP.

>>You are confusing macros with functions.  The word "macro" does not have
>>the meaning in this forum that you seem to think it does.

>I know what a macro means in LISP. What I mean is editor programming.
>Some people do use the term macro in this context.
  
I have to agree again.  For using what is also commonly called macros 
(functions for emacs) it is much easier to do it in ReXedit.  The reason
for this, is due to the fact that you can do more in emacs.  So, with 
more to choose from, you have to better specify what you want done.  If
the Elisp syntax was made to be used by novices, then its strongest 
point (adaptability) would be lost.  

>>>UNIX utilities don't hang together well due to their origins

>>What?!?!?!?!?!?  Who told you this???????  If you came to this conclusion
>>on your own, I pity you.

>I pity you for your ignorance and ostrich like mentality. Look around
>you especially look at some IBM mainframe stuff.

You are wrong here.  Unix is MUCH more flexible as it deals with standard
ins and outs.  STANDARD is the key word.  You can have buffers as the
standard in, files, output of programs and more.  So, for example, let's
take the unix program 'wc' (word count).  It can count the words of a file,
have a program pipe its output to it for counting purposes, or you can
have a region in emacs piped to it.  It does NOT need to have a FILE or
one type of input.  Let's see that done ReXedit.  Let's see the sort command
on many IBM Mainframe's use an Xedit buffer as input.  No, you have to 
write a macro do that.  

>>> But GNU emacs is in my opinion is a step backwards in terms of bringing
>>>   computing closer to the users.

>>What?!?!?  How long have you been using Emacs???

>Not for long. But I have read the manuals (both GNU Emacs and ELISP).
>I don't about you but I read the manuals end-to-end first before I try
>to do anything.

First of all, if you by "bringing computing closer to users" you mean 
allowing novices to quickly learn and utilize the full power of an 
editor, send them over to a Mac and let them go.  However, if you want
an environment which you can create, and adapt, and change, then 
use Emacs.  If all you care about is producing papers for class, then
Emacs is NOT the editor you want.  But, if you are going to be programming,
using email, connecting to the Usenet, batch operations on many files, 
etc, then you DO NOT want to use something like a Mac.  It is for the 
end user only...It allows little customization.  


>>> 3. Shell language and the editor macro language are completely
>>>  integrated. They are the same. (REXX for VM and TSO/E Clist for ISPF).

>>Emacs runs on multiple operating systems each of which has a different
>>shell language.  Working with only one shell language would cripple Emacs.
>>Instead, it transcends the operating system.  I think making the shell
>>language and editor extension language the same is a severe
>>*disadvantage*.
>No. If you have one shell language that is actually a great advantage.
>You win.
>
>Imagine saying something like 
>
>'Get next file in this directory'
>'if it is a c program file then 
>  ... Some ISPF editor program having the same control constructs as
>  the above..
>'
>
>There is only one language. Where as in UNIX/Emacs, 
>
>'for all i in *.c'
> do
>   emacs -batch -l xyz -u whatever
> endfor
>'
>where xyz has to be written in ELISP. Why not make ELISP the standard
>shell language? That will address all the objections I have raised re.
>emacs/UNIX.

No, this is not a good idea at all.  This does not allow for portability.
I think that perhaps what you want is a PC.  A binary on one PC should be
able to run on any other.  In a distributed environment, that is NOT
possible.  It is NOT acceptable. 

>>>   I can go on..but the point is that there are some user interfaces that
>>>   should have been incorporated into emacs to make it more user-friendly
>>>   and they can be found in editors from non-UNIX world.

>>I think the point is that you don't know what you're talking about.
  
Umm, again, you want a PC in an environment where it is not possible.  One
of the best editors for PAPERS and such is FrameMaker, and it is VERY 
powerful.  But, with its power, it is also not the easiest. 

Anil Joshi gives a few examples where Xedit can do something which
is not easily done in Emacs.  I say that it is not fair to choose one
or two things which one editor can do that another can't.  Each editor
has its one or two things which no other editors can replicate the same
way.  So what.  There are SO many more examples of what Emacs can do that
ReXedit can't...there is simply no comparison.  

So, if you want to write papers, use your PC.  Oh, but then you take a
CS course in which you have to write C.  Ok, you go by Turbo C and have
to learn a new editor.  Oh, then you have to do some Math calculations...
gotta find that calculator.  Oh, darn, the paper needs to be between 
500 and 600 words.  Humm, gotta count those words....But, wait, what about
this area...how many words does it contain....darn, gotta count them again.

To summarize, Emacs is NOT a word processor, it is a TEXT EDITOR.  ANY
KIND of text, and it is possible to create different environments for
different "types" of text.  That is its strength.

jc

--
					-- James Cameron  (jc@raven.bu.edu)

Signal Processing and Interpretation Lab.  Boston, Mass  (617) 353-2879
------------------------------------------------------------------------------
"But to risk we must, for the greatest hazard in life is to risk nothing.  For
the man or woman who risks nothing, has nothing, does nothing, is nothing."
	(Quote from the eulogy for the late Christa McAuliffe.)