home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / editors / 2102 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  4.7 KB
  1. Path: sparky!uunet!mcsun!uknet!yorkohm!minster!pete
  2. From: pete@minster.york.ac.uk
  3. Newsgroups: comp.editors
  4. Subject: Re: sam (was Re: Why I love VI)
  5. Message-ID: <715009315.21223@minster.york.ac.uk>
  6. Date: 28 Aug 92 13:41:55 GMT
  7. References: <BEVAN.92Aug27202655@tiger.cs.man.ac.uk>
  8. Organization: Department of Computer Science, University of York, England
  9. Lines: 102
  10. X-Newsreader: Tin 1.1 PL5
  11.  
  12. Stephen J Bevan (bevan@cs.man.ac.uk) wrote:
  13. : In article <714828990.22356@minster.york.ac.uk> pete@minster.york.ac.uk writes:
  14. :    An excellent text editor indeed -- sam concentrates on _getting the job
  15. :    done_ rather than piddling about with customisation and fancy/useless
  16. :    macros.
  17. : 
  18. : However isn't the "job" here defined as "writing C or *roff"?
  19. : For example, sam will nicely match {} pairs which is great for C, but
  20. : is completely useless if you're writing in a language that doesn't use
  21. : single character block delimiters e.g. Ada, Pascal, Algol 60, TeX ...
  22. : etc. 
  23.  
  24. Well, for my purposes "the job" involves writing C/C++, troff or straight ASCII
  25. files so I have to agree that my needs match the features of the editor. As
  26. they say in the US ``your mileage may vary''.
  27.  
  28. :    -- regular expressions across multiple files? No problem!
  29. : 
  30. : Sounds like editor bloat to me :-)
  31.  
  32. Hmmm, I wouldn't say it was bloat - it fits seamlessly into the Sam view of
  33. things. Having multiple files open logically implies that you should have
  34. operations which work across them.
  35.  
  36. : Seriously, something that bugs me about sam is that it duplicates some
  37. : of mux's functions to allow it to be a multi-file editor.  
  38.  
  39. Yes -- but consider people who _aren't_ running mux. For example, I run sam
  40. under X about half of the time and mux the rest; the X implementation of
  41. samterm makes sam infinitely better than any other X editor.
  42. Duplicating the functionality in some cases may mean you're actually
  43. improving it for others. 
  44.  
  45. : By all
  46. : means allow the editor to edit more than one file at a time, but if
  47. : you have a window system that is as fast as 8 1/2, why not have
  48. : window per file.  
  49.  
  50. See above, repeating the words ``X is slow on low-end machines'' to
  51. yourself as you do! I agree that this would be the ideal situation --
  52. sending a message to a running sam to open a new file in a new ``real''
  53. window rather than in its own. (Crowley's Xwindows editor ``point'' does
  54. something like this).
  55.  
  56. If you're that fussy though you might find that running sam in
  57. non-downloaded mode in an ordinary muxterm and using the editing
  58. facilities provided by the muxterm is an acceptable lightweight
  59. solution -- since the muxterm has cut/paste/mouse editing it is
  60. perfectly usable on its own, provided you remember to hit ESC (or F5 here)
  61. to get into and out of edit mode...
  62.  
  63. : Also, the buffer list is just a poor man's
  64. : directory, why not use the directory directly?
  65.  
  66. Granted. Not a bad idea at all.
  67.  
  68. : This is reasonably simple if you use a decent language to control
  69. : your applications 
  70.  
  71. Hmmm, I would have thought it was a lower-level feature than that. Just
  72. because dired in gnuemacs is a lisp package doesn't mean that corresponding
  73. functions in other editors have to be -- it would be more efficient if it
  74. was a builtin primitive...
  75.  
  76. : but it seems that developers either shy completely
  77. : away from using a language (Pike - sam, Joy - vi) or use one but
  78. : through a combination of things, screw it up.  
  79.  
  80. I'd rather use no language in an editor than a botched or inefficient one.
  81. I'm sorry, but a 1.6Mb gnuemacs is overkill on my Sun. 
  82.  
  83. : For example, GNU Emacs
  84. : uses Lisp but embeds it in the editor instead of keeping it separate*.
  85.  
  86. : XEDIT keeps its language separate but the language is REXX!  I don't
  87. : want to start a flame war about REXX as I realise that lots of people 
  88. : think REXX is an excellent language.  It just isn't what I want in a
  89. : language, I'd much prefer to use a system based around Scheme or
  90. : FORTH.  
  91.  
  92. Agree with you about scheme - it should be possible to embed a tiny scheme
  93. such as Carrette's ``siod'' into an editor as a macro language.
  94.  
  95. What are your thoughts on editors like point, which is very heavily based
  96. around use of Tcl? My impression is that the language is nice, but the user
  97. interface which has been grafted on to it is tacky to say the least...
  98.  
  99. : As I refuse to "waste" my time writing YAE I'll just carry on
  100. : using GNU Emacs and suffer the bloat :-< 
  101.  
  102. Think I'll stick to sam and/or vi.
  103. : 
  104. : bevan
  105. : 
  106. : * This works fine if you're working on a LispM where the whole system
  107. :   is Lisp based but it doesn't fit into the UNIX way of things.
  108.  
  109. pete
  110. --
  111. *Peter Fenelon -- Research Associate -- Software Safety Assessment Procedures*
  112. Dept. of Computer Science, University of York, York, Y01 5DD (+44/0)904 433388
  113. EMAIL: pete@minster.york.ac.uk `There's no room for enigmas in built up areas'
  114.