From: pete@minster.york.ac.uk
Newsgroups: comp.editors
Subject: Re: sam (was Re: Why I love VI)
Date: 28 Aug 92 13:41:55 GMT
Organization: Department of Computer Science, University of York, England
X-Newsreader: Tin 1.1 PL5

Stephen J Bevan (bevan@cs.man.ac.uk) wrote:
: In article <714828990.22356@minster.york.ac.uk> pete@minster.york.ac.uk writes:
:    An excellent text editor indeed -- sam concentrates on _getting the job
:    done_ rather than piddling about with customisation and fancy/useless
:    macros.
: 
: However isn't the "job" here defined as "writing C or *roff"?
: For example, sam will nicely match {} pairs which is great for C, but
: is completely useless if you're writing in a language that doesn't use
: single character block delimiters e.g. Ada, Pascal, Algol 60, TeX ...
: etc. 

Well, for my purposes "the job" involves writing C/C++, troff or straight ASCII
files so I have to agree that my needs match the features of the editor. As
they say in the US ``your mileage may vary''.

:    -- regular expressions across multiple files? No problem!
: 
: Sounds like editor bloat to me :-)

Hmmm, I wouldn't say it was bloat - it fits seamlessly into the Sam view of
things. Having multiple files open logically implies that you should have
operations which work across them.

: Seriously, something that bugs me about sam is that it duplicates some
: of mux's functions to allow it to be a multi-file editor.  

Yes -- but consider people who _aren't_ running mux. For example, I run sam
under X about half of the time and mux the rest; the X implementation of
samterm makes sam infinitely better than any other X editor.
Duplicating the functionality in some cases may mean you're actually
improving it for others. 

: By all
: means allow the editor to edit more than one file at a time, but if
: you have a window system that is as fast as 8 1/2, why not have
: window per file.  

See above, repeating the words ``X is slow on low-end machines'' to
yourself as you do! I agree that this would be the ideal situation --
sending a message to a running sam to open a new file in a new ``real''
window rather than in its own. (Crowley's Xwindows editor ``point'' does
something like this).

If you're that fussy though you might find that running sam in
non-downloaded mode in an ordinary muxterm and using the editing
facilities provided by the muxterm is an acceptable lightweight
solution -- since the muxterm has cut/paste/mouse editing it is
perfectly usable on its own, provided you remember to hit ESC (or F5 here)
to get into and out of edit mode...

: Also, the buffer list is just a poor man's
: directory, why not use the directory directly?

Granted. Not a bad idea at all.

: This is reasonably simple if you use a decent language to control
: your applications 

Hmmm, I would have thought it was a lower-level feature than that. Just
because dired in gnuemacs is a lisp package doesn't mean that corresponding
functions in other editors have to be -- it would be more efficient if it
was a builtin primitive...

: but it seems that developers either shy completely
: away from using a language (Pike - sam, Joy - vi) or use one but
: through a combination of things, screw it up.  

I'd rather use no language in an editor than a botched or inefficient one.
I'm sorry, but a 1.6Mb gnuemacs is overkill on my Sun. 

: For example, GNU Emacs
: uses Lisp but embeds it in the editor instead of keeping it separate*.

: XEDIT keeps its language separate but the language is REXX!  I don't
: want to start a flame war about REXX as I realise that lots of people 
: think REXX is an excellent language.  It just isn't what I want in a
: language, I'd much prefer to use a system based around Scheme or
: FORTH.  

Agree with you about scheme - it should be possible to embed a tiny scheme
such as Carrette's ``siod'' into an editor as a macro language.

What are your thoughts on editors like point, which is very heavily based
around use of Tcl? My impression is that the language is nice, but the user
interface which has been grafted on to it is tacky to say the least...

: As I refuse to "waste" my time writing YAE I'll just carry on
: using GNU Emacs and suffer the bloat :-< 

Think I'll stick to sam and/or vi.
: 
: bevan
: 
: * This works fine if you're working on a LispM where the whole system
:   is Lisp based but it doesn't fit into the UNIX way of things.

pete
--
*Peter Fenelon -- Research Associate -- Software Safety Assessment Procedures*
Dept. of Computer Science, University of York, York, Y01 5DD (+44/0)904 433388
EMAIL: pete@minster.york.ac.uk `There's no room for enigmas in built up areas'
Newsgroups: comp.editors