home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / editors / 2112 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  3.0 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!ucsbcsl!network.ucsd.edu!swrinde!gatech!bloom-beacon!eru.mt.luth.se!lunic!sunic!mcsun!uknet!mucs!m1!bevan
  2. From: bevan@cs.man.ac.uk (Stephen J Bevan)
  3. Newsgroups: comp.editors
  4. Subject: Re: sam (was Re: Why I love VI)
  5. Message-ID: <BEVAN.92Aug29151734@tiger.cs.man.ac.uk>
  6. Date: 29 Aug 92 14:17:34 GMT
  7. References: <BEVAN.92Aug27202655@tiger.cs.man.ac.uk> <715009315.21223@minster.york.ac.uk>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Department of Computer Science, University of Manchester
  10. Lines: 56
  11. In-reply-to: pete@minster.york.ac.uk's message of 28 Aug 92 13:41:55 GMT
  12.  
  13. In article <715009315.21223@minster.york.ac.uk> pete@minster.york.ac.uk writes:
  14.    Stephen J Bevan (bevan@cs.man.ac.uk) wrote:
  15.    : Seriously, something that bugs me about sam is that it duplicates some
  16.    : of mux's functions to allow it to be a multi-file editor.  
  17.  
  18.    Yes -- but consider people who _aren't_ running mux. For example, I run sam
  19.    under X about half of the time and mux the rest;
  20.  
  21. I'm sure the duplication of features is handy if your not running mux,
  22. but that still doesn't alter that point that sam was designed for Plan
  23. 9, where mux would be running.  Under those circumstances I think the
  24. design is wrong.  (big IMHO here of course :-)
  25.  
  26.  
  27.    : This is reasonably simple if you use a decent language to control
  28.    : your applications 
  29.  
  30.    Hmmm, I would have thought it was a lower-level feature than that. Just
  31.    because dired in gnuemacs is a lisp package doesn't mean that corresponding
  32.    functions in other editors have to be -- it would be more efficient if it
  33.    was a builtin primitive...
  34.  
  35. But almost anything will be quicker as a builtin, but that way lies
  36. editor bloat.  It is a tough job deciding what should and shouldn't be
  37. built in to an editor, and I think Pike has done better than most, but
  38. IMHO it still has too many things in it.
  39.  
  40.  
  41.    : but it seems that developers either shy completely
  42.    : away from using a language (Pike - sam, Joy - vi) or use one but
  43.    : through a combination of things, screw it up.  
  44.  
  45.    I'd rather use no language in an editor than a botched or inefficient one.
  46.  
  47. True, but there is no law saying "thou shalt botch up the language in
  48. your editor" :-)
  49.  
  50.  
  51.    Agree with you about scheme - it should be possible to embed a tiny scheme
  52.    such as Carrette's ``siod'' into an editor as a macro language.
  53.  
  54. Not quick enought IMHO.  Interpreters are great for prototyping, but I 
  55. I want something I can download native code into and have it running
  56. at full speed.  I'd like to be proven wrong, but I think that there is
  57. a better chance of producing a fast native code FORTH than Scheme.
  58.  
  59.  
  60.    What are your thoughts on editors like point, which is very heavily based
  61.    around use of Tcl? My impression is that the language is nice, but the user
  62.    interface which has been grafted on to it is tacky to say the least...
  63.  
  64. Never used "point".  I have used TCL though, but not for long.  It
  65. just didn't give me anything _I_ wanted that I didn't feel was better
  66. served by Scheme or FORTH.
  67.  
  68. bevan
  69.