On Fri, Jan 21, 2011 at 2:10 AM, Nicholas Marriott
<nicholas.marri...@gmail.com> wrote:
> I like this idea, DCS or APC with some tmux prefix would seem obvious
> but you'll need a way to escape stuff.
What would such a tmux prefix look like? Is this a standard way of
adding a terminal-specific extension, or do we have to figure out for
ourselves what to do?
>
> Maybe we just parse a string so you actually send the string "\033" and
> so on eg sometihng like
>
> printf "\\033_\\\033[42m\\"
>
> Bit fugly though.
>
> I don't know where I got the APC-sets-title behaviour from, xterm
> doesn't seem to support it.
>
Perhaps from Screen, where it has the same effect as OSC 0, 1 and 2.
> Or maybe we allow \033 during DCS, APC, OSC although we're not really
> supposed to.
>
Yes, there seem to be two obvious approaches.
1. Continue to follow the state diagram from vt100.net that the parser
is based on, using some kind of escaping to allow non-printable
characters.
2. Break from the state diagram and provide a way to send ESC directly.
The second approach would require allowing all characters except ESC
(and possibly the C1 ST character, but it looks like tmux does not
currently support those) to trigger "put" in the dcs passthrough
state. ESC would have to cause a transition to a new state (perhaps
"dcs escape"), where \ triggers the ground state. How other characters
are handled in this state would need to be decided, but one
possibility is to simply allow all other characters to cause a
transition to the dcs passthrough state, with a "put" action.
This is perhaps not as bad as I initially thought it would be.
Breaking the rule that ESC in any state causes a transition to the
escape state seems ugly, but it appears this rule has already been
broken for the UTF-8 support. Adding a new state complicates the state
table slightly, and makes it diverge a bit more from the vt100.net
table.
For the first approach, I think I would suggest using a very simple
scheme, possibly based on quoted-printable encoding. That would make
it fairly easy to deal with both in tmux and in applications using
this feature.
It seems the advantage of the first approach is that it requires no
changes to the structure of the state machine. The advantage of the
second approach is that it places a relatively small burden on
applications to encode strings before sending them through tmux.
Personally I'm on the fence. Either one appears to be workable.
-Kevin
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
