From: louis@BARRA.COM (Louis Dunne)
Newsgroups: comp.os.vms
Subject: Re: EMACS as default mail editor?
Date: 7 Nov 92 22:50:40 GMT
Distribution: world
Organization: BARRA Inc., Berkeley, California.

On Nov 6, 12:12pm, Harvey Brydon (918)250-4312 wrote:
> Subject: Re: EMACS as default mail editor?
>In article <1992Nov4.162506.13620@synapse.bms.com>, kaz@bms.com 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:   louis@barra.com   /
    /                                      /   Phone:      +1 510 649-4229  / 
   /    BARRA, Inc.                       /    Fax:        +1 510 548-4374 /
  /     1995 University Ave., Suite 400  /                                /
 /      Berkeley, CA 94704              /                                /
-------------------------------------------------------------------------