Re: The `zle' command and traps

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mar 9,  1:21pm, Sven Wischnowsky wrote:
} Subject: Re: The `zle' command and traps
}
} Bart Schaefer wrote:
} 
} > 	TMOUT=2 ; TRAPALRM() { zle -R "Hi there, I'm a trap." }
} > 
} > Of course if the signal arrives when ZLE is not active, this generates an
} > ugly warning message.
} 
} I was about to add a/some test(s) for sfcontext in bin_zle()
} but... this is quite cool, isn't it? ;-)

Yes, I confess I thought so too ... but some things don't work so well.
For example, try using "zle -M ..." instead of -R in that trap.

Or try

	TRAPINT() { zle push-input }

and then type ctrl-C.  Note that the line gets pushed onto the buffer
stack, but the display is not refreshed so you can't tell.  You need an
explicit refresh:

	TRAPINT() { zle push-input ; zle -R }

(An explicit refresh makes the "zle -M" trap work as well.)

I'm also concerned about what happens if a zle widget is invoked from a
trap in the middle of some interactive thing like menu-selection.  That
could get messy quickly, especially if it's something that alters the
buffer.
 
} So, should we disallow it completely?

I can't decide.  The message modes and refresh seem harmless enough, but
perhaps we should refuse to execute widgets from within traps?

} Or make the zle builtin be quiet if zle isn't active?

That isn't strictly necessary as one can redirect stdout to hide the
warning.  However, it'd be nice if zle returned a non-zero status when
it fails; try typing

	zle -R "not echoed" || echo zle failed

and you'll get

	zle: can only be called from widget function

but not "zle failed".

} Make the zle special parameters accessible (read-only) in traps if zle
} is active?

If we allow widgets to be called, you can cause the special parameters
to become available by using "zle widgetname".  So instead of writing

	TRAPINT() { .... something with $BUFFER .... }

One writes

	widgetname() { .... something with $BUFFER .... }
	zle -N widgetname
	TRAPINT() { zle widgetname }

Can you extend read-only-ness of the parameters to the point that widgets
are restricted as well?  I.e., if you call from a trap a builtin widget
that moves the cursor or inserts/deletes characters, it would fail?

If we can restrict widgets to those that do "safe" things, then we can
allow "zle widgetname" and there's no need for the special parameters to
be visible directly to the trap function.  If instead we must prohibit
widget-calling entirely, then perhaps the parameters should be available
to the trap function.

} Add a way to detect if zle is active?

That would be nice.  "zle" with no arguments silently returning 0 or 1
would be sufficient (it now says "zle: widgets can only be called ...").

While we're on the subject ... CURSOR is almost equivalent to emacs'
(point).  Why is there no MARK variable?  I find myself wanting to play
with the region and therefore doing things like

	local -i point=$CURSOR
	zle exchange-point-and-mark
	local -i mark=$CURSOR
	zle exchange-point-and-mark

} Add a way to detect if (the shell thinks that) there is a
} completion list displayed below the prompt? Etc, etc?

Hrm.  That may be getting too esoteric.  Hard to say.

While we're on the subject of zle behavior:

	zle -U frob

This results in "brof" being inserted onto the command line.  The docs
refer to the "input queue" not the "input stack" -- why is it LIFO?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com