[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 1 18:20:04 1994 
Subject:Re: ved_q (Simplified slightly) 
From:"A.Sloman" 
Volume-ID:940901.04 

Robin suggested using my version of ved_qand to redefine ved_q, thus:

> ;;; ved_q - a new version.  Put together by A.Sloman and R.Popplestone.
>
> ;;; <enter> q to exit from a VED file as usual
> ;;; <enter> q <command> to exit from the file, executing <command>
> ;;; thus <enter> q ved fred is the same as <enter> qved fred
> ;;; but it works systematically.
>
> lconstant ved_q_old = ved_q;
>
> define ved_q();
>     ;;; quit current ved buffer and run the command given as
>     ;;; argument to ved_qand
>     if vedargument /= nullstring then
>       vedqget(veddo(%vedargument%));  ;;; See HELP VEDDO
>     else ved_q_old()
>     endif;
>     ;;; or possibly
>     ;;;     vedqget(vedargument, veddo)
> enddefine;

Even simpler would be the following, which does not require the old
value of ved_q to be saved.

define ved_q();
    ;;; quit current ved buffer and, if appropriate, run the command
	;;; given as argument to ved_q, using old window if necessary.
    if vedargument /= nullstring then
      	vedqget(veddo(%vedargument%));  ;;; See HELP VEDDO
      	;;; or possibly
      	;;;     vedqget(vedargument, veddo)
    else
		vedqget(identfn)
    endif;
enddefine;


It seems to work, perhaps surprisingly.

The only snag with redefining ved_q like this is that it is no longer
safe to call ved_q in arbitrary contexts (e.g. mapped to a key
sequence, or invoked from another VED procedure), because it may pick up
an unintended version of vedargument.

My standard solution to that problem is instead to use veddo with
a string, i.e. veddo('q'), or where appropriate veddo(%'q'%) where a
closure is needed. This ensures that vedargument is set to the empty
string.

The extra overhead of using veddo to interpret a pseudo command line
string normally does not matter, by comparison with everything else that
is going on.

Aaron