Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!esl.esl.com!lrs
From: lrs@esl.esl.com (Lynn Slater)
Newsgroups: gnu.emacs
Subject: GNU and the NeXT.
Message-ID: <8902131937.AA02607@esl.ESL.COM>
Date: 13 Feb 89 19:37:41 GMT
References: <508@gonzo.UUCP>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 97


> Poking around a friend's NeXT machine, I couldn't find the source for
> the emacs, gcc and gdb that were present. 

You are not any more blind than I am.

I expect to ask Next for all these sources and to send them the media
on which to copy them.   This will be a good test of their respect for
the gnu copylefts.

				 -*-
On supporting gnu better on the next:  Wish list/call for suggestions

Emacs:
  Objective C minor mode of C mode
  Next error regular expression to recognize Objective C errors
  The gnu emacs/gdb interface seems to work well; Next seemed surprized
    May want to try a speaker/listener between independent gdb and
    emacs processes so that emacs will scroll and display whatever gdb
    is doing, even if gdb is in another window.
  PSwrap mode
  Postscript mode
    (A really nice mode would know the number of operands needed for
     every postscript operator and would match beginning and end of
     expressions like lisp matches parens.)
  Better auto-mode-alists for all these new standard file suffixes.
  Lookup (ala the "man" command) of next document libraries.
  Search/lookup of method names and declarations/implimentions.
    Maybe enhance "tags" for objective C declarations.
    Slight change to find-tag command for objective C syntax.

  NextStep Application features:
    Allow gnu to be the target of a command cell (MMI item) action.
      Have gnu ask the cell for some sort of textual tag and use that
      tag as a lisp expression to execute.  This would allow people to
      use the interface builder to make menus for emacs.
    Have gnu lisp types that hold or translate into nextstep object id's
    Allow gnu to have "outlets" that issue commands to other next
      objects.
  
  Running gnu emacs not from a terminal emulator:
    Would require efficient postscript paint/scroll code.
      The text object may be unacceptable because it keeps its own text
       store; gnu emacs does this very well already.  Also, text objects
       would not allow for two windows editing a common buffer and
       updateing each other.
    Would be easiest to impliment if Next made available certain
      portions of the text object or terminal emulator paint/scroll code.
      There seems to be many implicite requirements of being a good
      textual object in Next; I would hate to have to find them one by
      one by trail and error.
    Features that could result:
      scrollbars
      resizing
      mouse support
      Next menus for completions;
        replace try-completion code so that the next menus are used
        for file names, M-x commands, and all other completions.
        Next does this for file names, maybe they can make this
         capability generalized and available to all.
  
  I suspect that the multi-window changes being inserted by R. Stallman
  for X11 in release 19 will help make a multi-window next support
  package. Attempt to make gnu emacs "run native" on the next window
  system should probably await release 19.


Make:
  I wish that next would switch to gnu make rather than the old and
  painfull unix make.  Maybe they can do this before the 1.0 release.

GDB:
  Would be nice to make gdb a nextstep application with menus, windows,
   pictures of the stack, etc.
  Interface to independent emacs via speaker/listener.
    This would let folks use their favorate editor to change the code
    on the fly rather than just seeing the code on the GDB screen.

				 -*-
The above was a quick and dirty core dump of immediate ideas for gnu
and the next.  I am hoping that somebody will just send code for all
the above but realize that this hope is not realistic at this time.
Alternatively, I am looking for comments/suggestions, code fragments,
developer reviews, and volunteers/interested parties.

I may be doing some of the above but have limited time and limited
access to a Next machine.  I hope that others will join this effort
with the goal that Emacs and other gnu products will become good and
friendly citizens of the Next environment and be viable alternatives
even for those new users who will be accustomed to standard NextStep
applications.

===============================================================
Lynn Slater -- lrs@esl.com
ESL/TRW 495 Java Drive, Box 3510, Sunnyvale, Ca 94088-3510
Office (408) 738-2888 x 4482; Home (415) 796-4149 
===============================================================