[net.emacs] lock.ml

hdj@burdvax.UUCP (02/18/84)

=
lock.ml is an Emacs package that simulates the "lock" program.
lock.ml asks for a password (twice); your Emacs job is "locked" until
the password is repeated.  Any background processes you might be running are
not affected.

lock.ml was written by Karl Puder (decwrl!rhea!logic!puder).
Thanks, Karl.

;------------------ lock.ml ---------------------
; Note that when attempting to escape from LOCK, only a RETURN (13) will end
; lock-tty-string.

(defun
  (lock key
	(progn
	  (setq key (lock-tty-string "Key:"))
	  (if (= key (lock-tty-string "Again:"))
	      (while (!= key (lock-tty-string "LOCK"))
		     (message "Wrong")
		     (sit-for 10))
	      (error-message "Keys differed"))
	  (message "Exited lock.")
	)
  )
  (lock-tty-string chars char
    (setq chars "")
    (message (arg 1))
    (while (!= 13 (setq char (get-tty-character)))
	   (message (arg 1))
	   (setq chars (concat chars (char-to-string char))))
    chars
  )
)

; ----- that's all folks!

dick@tjalk.UUCP (Dick Grune) (02/22/84)

It is a fallacy that one could lock emacs by using get-tty-character. A single
^G will free your terminal. A good (and equally convenient way) is to
return-to-monitor, and then `lock'.

hdj@burdvax.UUCP (Herb Jellinek) (02/23/84)

>It is a fallacy that one could lock emacs by using get-tty-character. A
>single ^G will free your terminal. A good (and equally convenient way) is to
>return-to-monitor, and then `lock'.

Sorry, "Dick," but you are correct only if the Emacs in question is running
in half-baked mode.  Mine is not.  Chris Torek also pointed this problem out
to me, but according to him, if you add an error-occured around the
get-tty-character, and hack up Karl Puder's code a little, the problem you
mentioned will no longer exist.

		Herb Jellinek

chris@umcp-cs.UUCP (02/24/84)

(get-tty-character) will only error out if you have compiled Emacs with
HalfBaked mode defined.  In this case an (error-occur[r]ed) around the
(get-tty-character) invocation will make the abort statistically unlikely.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay