On Tue, Dec 7, 2010 at 2:08 AM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> On Mon, Dec 06, 2010 at 06:24:29PM -0800, George Nachman wrote:
> > > 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?
>
> Sure, but don't send UTF-8 to tmux as part of command arguments and
> expect it to work at the moment :-).
>
>
I updated the spec to call for 7-bit ascii except for pty i/o. We can always
change to UTF-8 when ready.
> >
> > > 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.
>
> Yes that is fine.
>
> >
> > 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.
>
> At the moment commands do not respond with >1 type of output AFAIK but I
> wouldn't like to guarantee they won't in future.
>
>
I've only specified one kind of output for now. If we find a case where we
need two, the spec can be updated without breaking the existing code.
> >
> > 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.
>
> Sure that'd be fine.
>
>
I added a prefix to tmux's output and defined E, I, and P in the spec.
I'd like to add a new tmux command that allows the client to store and
retrieve an arbitrary dictionary of string->string. I want to store window
positions, font names, etc., so that when you attach to an existing tmux
session we can recover all details of the old state. Does that sound ok?
------------------------------------------------------------------------------
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
