🚀 go-pugleaf

	Since we get postings a good few days after everyone in the US,
     some of this may seem dated, but I'm sorry, I'm not going to get
     flamed by someone who asks for help in gnu.emacs.help & then slags
     off GNU & Emacs because of ignorance.  I have seen a demolishment by
     Joe Wells (jbw@bigbird.bu.edu), so I'll try not to repeat his points.

Joshi@m.cs.uiuc.edu (Anil Joshi) writes: 

| >| 2. In the emacs syntax to represent the period, I need to escape it but
| >|    that is not enough. I need to escape the escape (\\). This is
| >|    totally counter-intuitive (as many things in emacs are). Why o why?
| >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| >       Don't say things are "totally counter-intuitive" just because you
| >     don't understand them!!!  If you don't like it, you can always use vi
| >     or ed!!!
| I understand reg.exp. as much as any CS student does. I don't like
| ed ed or vi either. Their reg.exp are any good. I am using
		      ^^^^^^^^^^^^^^^^^^^^^^^^^^ I presumed "aren't"
| "counter-intuitive" as an euphemism.

	Euphemism for what?  What on earth do you mean?

| I don't see any ambiguity if one leaves out the escaping the escape.  Could
| you please emlighten me as to the rationale behind forcing the \\.  Syntax?

	As I said to you, the regexp is being parsed/processed/interpreted
     before the directory-files function sees it.  This is Lisp, it is a
     functional language.

| Is it advantageous over the other syntax or is it because one is forced to
| use elisp(GNU emacs coming from MIT and MIT being the bastion of Functional
| Programming Langs. esp. LISP) and the designers have chosen elisp as the
| language for emacs editor.

	Again, you're not "forced" to do anything.  Emacs is not a
     conspiracy on behalf of MIT & GNU, it's a good editor which is very
     easily extended by users in a language which, while not quick, is
     easy to write in *when you understand it*.

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

	Use it then.  (1) How long have you known REXX?  (2) How long have
     you known Emacs & Emacs Lisp?  My guess is (1) >> (2).

| Unix utilities don't hang together well due to their origins ...

	I don't think you understand Unix either.

| ... Emacs has gone one step further in widening the gap by introducing an
| entirely new set of utilities/interfaces/langauges/tools. I don't have
| anything against changes as long as they are progressive.  But GNU emacs is
| in my opinion is a step backwards in terms of bringing computing closer to
| the users.

	So there should be only one tool for any given job?  Emacs is an
     editor/environment.  A user can extend Emacs, if s/he wants to.
     There are a multitude of existing environments to make make editing
     easy.

| There is definitely a point or two that can be incorporated into emacs from
| the IBM mainframe world.

	Ahhh!  Now we have it!  An IBM user!

| 1. Exclusion (different from emacs' narrow-region). This allows for multiple
| regions.

	I'm not sure what you mean, are you aware of outline-mode?

| 2. Rulers lines, margins, tabs and profiles.

	Surely you know these within Emacs?

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

	They are also inappropriate for an editor extension language.
     Have a look at some *.el files, to see what I mean - try re-writing
     them in sh syntax.

| 4. Standard interface for calling utilities from editor macros. They get
| passed onto the underlying login process. emacs call-process creates a new
| shell and runs the command there. Why o why? Just pass the command to the
| shell process that is running emacs.

	You understand neither Emacs nor Unix here.  Emacs does not create
     a shell (it's called call-process, for god's sake).  In Unix, each
     process has only 1 process attributed to it (obvious, isn't it?),
     remember we're multiprocessing here, we have no need to pass the
     command to the shell process running Emacs.  The whole point of Unix
     is that it runs on many platforms, this trick is not available on
     most.

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

	Like what?  People would be interested to here these.

| If GNU acronym puports a new idealogy, then they should have looked at some
| other editors from non-UNIX world and tried to learn a few lessons in
| user-interface from there. Looks like they have not done their homework.

	Pile of rubbish.

| >       Hope things are a little clearer!  Si.
| Same here.

	Well, are they?

| "Whatever we wish ourselves to be, we have the power to make ourselves. If
| what we are now has been the result of our own past actions,then it certainly
| follows that whatever we wish to be in the future, can be produced by our own
| present actions."

	In other words, "we are what we do".  Leave out pretentious
     rubbish, just read Zippy.  Yow!