>
>
> > As far as parsing command output, I'll need your help on that. I don't
> > think I'll be able to tell from the man page which commands generate
> which
> > errors. I will need to know if a command's output is normal or an
> error.
> > If the result is an error then I need two things:
> > 1) To notify the user that something went wrong. The error should
> include
> > (ideally localized) text that's appropriate to show to the user.
>
> All messages are 7-bit ASCII and English and are meant to be shown
> directly to the user, that's what happens to them now :-).
>
>
That works. Can we call it UTF-8 for the purposes of the protocol?
> > 2) To handle certain errors internally. I don't know what cases this
> > covers, or even if there will be any, but I expect to need a reliable
> way
> > to identify particular errors to handle them in some special way. This
> > would require a unique error code.
> > Here's an initial stab at it:
> > COMMAND_RESPONSE := SUCCESS | ERROR
> > SUCCESS := "OK" NEWLINE (any character except EOF)* EOM
> > ERROR := "ERROR" ERROR_CODE NEWLINE (any character except EOF)* EOM
> > ERROR_CODE := [A-Za-z0-9_]+
>
> All we have is the text, I don't want to add error codes for everything
> now. There are too many errors and it'll be too much churn. At least
> initially you'll have to match on the text itself.
>
> All we know is whether the output came from command parsing or execution
> and whether it is an error, info or normal.
>
>
This is an important distinction. A command parsing error indicates a bug in
the terminal emulator that originated the command, while an error could
happen due to unfortunate circumstances. I'd like to call out parsing errors
if possible so I can tell the user to report a bug.
> Error is (obviously) an error condition. Normal is command output. These
> can be thought of as what would go to stderr and stdout.
>
> Info are informational, such as confirmation messages, they are turned
> off if you set the "quiet" option. There aren't many of these.
>
>
Can a command respond with more than one kind of output? I don't think I'll
ever need info, but I can't say for sure until I've looked at every command.
Quite possibly I'll turn them off. I can't (yet) see a reason to distinguish
them from normal output.
Easiest thing would just be to send it prefixed with E, I or O (or
> ERROR/INFO/OUTPUT or whatever you prefer).
>
>
Sure, that's fine. I and O could be grouped together, most likely.
I would like to have a separate prefix for parse errors (P?) that indicate a
bug if that's feasible.
> Since you want the pane data separately and I guess you will want all
> the state changes it may be a bit of a fiddle, I need to play around and
> see what can be done.
>
>
Definitely - split pane support is almost working:
http://twitpic.com/3degmg/full
> If you can parse the data as TERM=screen it'll be easier to just hoke it
> straight out, but that is not ideal.
>
>
I inherited my parser, and it's an understatement to say I prefer not to
change it :). To a first approximation, it speaks xterm.
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
