NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/os/vms/17628

Internet Message Format | 1992-11-08 | 5.5 KB

Path: sparky!uunet!spool.mu.edu!agate!ucbvax!BARRA.COM!louis
From: [e-mail] (Louis Dunne)
Newsgroups: comp.os.vms
Subject: Re: EMACS as default mail editor?
Message-ID: <[e-mail]>
Date: 7 Nov 92 22:50:40 GMT
Sender: [e-mail]
Distribution: world
Organization: BARRA Inc., Berkeley, California.
Lines: 115

On Nov 6, 12:12pm, Harvey Brydon [phone] wrote:
> Subject: Re: EMACS as default mail editor?
>In article <[e-mail]>, [e-mail] writes:
>>Does anyone know if it's possile to specify EMACS as as the default
>>editor in MAIL?
>>
>>The documentation for SET EDITOR in MAIL says to specify any callable
>>editor.  I don't beleive that EMACS is callable, but I'm not sure about
>>that.
>>
>>I'm running EMACS v18.58.1 on VMS 5.4-2.
>
>If it has an executable in sys$share of the form xxxSHR.EXE with some required
>entry points, it can be considered callable by mail and other applications.
>Do:
>
>$ dir sys$share:*shr.exe
>
>If Emacs shows up in the list, you're in business.  If not, you're not.  There
>are a legion of other files matching this filespec that are not editors, by
>the way.  UISSHR.EXE is not an editor...

    If your editor isin't callable, then use the MAIL$EDIT logical.
    Point this a command procedure to be invoked. When MAIL needs to
    invoke an editor (e.g. via a SEND/EDIT) it will create a sub-process
    to execute this command procedure. You can then do anything you
    like in this command procedure, as long as you leave behind a file
    of the name that MAIL expects (which you can see from the example
    below).

    NOTE:    You are not limited to just editors; you can do ANYTHING
        as long as the file exists when the command procedure exits.
        If the file does not exist no message will be sent.

    For example:
        $ sh log mail$edit
           "MAIL$EDIT" = "VI$DIR:VI_MAIL.COM" (LNM$PROCESS_TABLE)

        $ type mail$edit
        $ assign/nolog sys$command sys$input
        $ vi home:[000000]mail_'f$getjpi("","master_pid")'_send.tmp
        $ deass sys$input

    One downside is that it takes a while (on most systems) to create the
    sub-process, which is not nearly as fast (or efficient) as using a
    callable interface to the editor.


    BUT, in reality most editors you will use will have been written using
    TPU, your version of EMACS included. Usually you will have (or you can
    make) a section file which contains the TPU routines that constitute
    your editor. If you define the logical TPU$SECTION to point to this
    section file, then it will be read and executed every time TPU starts
    up unless you tell it otherwise using command line qualifiers.
    TPU$SECTION by default point to EVE$SECTION, which is not normally
    defined. So, you can point TPU$SECTION or EVE$SECTION to the section
    file containing your editor. But you should really re-define TPU$SECTION,
    because you're not using EVE!
    For example:

        $ sh log tpu$section
           "TPU$SECTION" = "EVE$SECTION" (LNM$SYSTEM_TABLE)
        $ sh log eve$section
        %SHOW-S-NOTRAN, no translation for logical name EVE$SECTION
        $ edit/tpu
            [invokes EVE]

        $ assign/nolog vi$dir:vi.gbl tpu$section
        $ edit/tpu
            [invokes VI]    (or whatever)

    The same goes for MAIL too. Set your editor to TPU and have
    TPU$SECTION pointing at your editor's section file. MAIL will then
    start TPU which will read and execute that section file and hence
    your editor.

    There is one annoying caveat I've found in doing this. Often your
    editor (within it's TPU code) will issue CALL_USER calls to invoke
    code written in other languages. This "other" code by default should
    reside in SYS$SHARE:TPUSHR.EXE. The usuall way to get TPU to look
    at routines you've written is to define the TPU$CALLUSER logical
    to point to a sharable image that you've writen which contains
    the given routines (to be called from the TPU code). Anyhow, the
    annoying caveat is this: when invoked from MAIL the image pointed
    to by TPU$CALLUSER seems to be ignored. I'm not entirely sure why
    this happens (I don't have sources), and I would have thought that
    this has little to do with MAIL and more to do with the TPU side
    of things. So the result is when your editor uses CALL_USER, the
    routine can't be found, and TPU issues error messages.

    I suspect that if the TPU$CALLUSER is defined in a higher access
    mode it would work. MAIL is probably guarding against users
    intercepting the CALL_USER calls that EVE would make with code in
    their own image, thus producing a loophole if that account where
    captive. As I have said, I don't don't have the sources so I can't
    verify that these are MAIL's motives. Perhaps a TPU developer or
    someone with sources could verify this.

    So, the bottom line is:
        1) If you don't mind the overhead, use the MAIL$EDIT
           approach.
        2) Try the TPU$SECTION approach, and if your editor
           has problems locating it's code on calls to CALL_USER
           then try defining TPU$CALLUSER in a higher access mode.

Louis
       -------------------------------------------------------------------------
      / Louis Dunne                          /                                /
     /  VMS/UNIX Systems                    /  Internet:   [e-mail]   /
    /                                      /   Phone:      [phone]  /
   /    BARRA, Inc.                       /    Fax:        [phone] /
  /     1995 University Ave., Suite 400  /                                /
 /      Berkeley, CA 94704              /                                /
-------------------------------------------------------------------------