On Mon, Dec 06, 2010 at 05:44:29PM -0800, George Nachman wrote:
> - I added a %noop unsolicited message.
> - I changed the terminator from ^D to ^D NEWLINE to make it more
> human-friendly.
> - I'll keep ping because I do have a "send something every x seconds to
> keep the connection alive" feature and ping will do the job.
Fine with me.
> 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 :-).
> 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.
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.
Eg:
$ tmux lsk -t asd
unknown key table: asd <-- this is error
$ tmux info|head v-- this stuff is normal output
tmux 1.4, pid 17969, started Tue Oct 12 09:12:34 2010
socket path /tmp//tmux-1125/default, debug level 0
system is Linux 2.6.9-55.ELlargesmp #1 SMP Fri Apr 20 16:46:56 EDT 2007 x86_64
configuration file is /home/nick/.tmux.conf
protocol version is 6
3 clients, 18 sessions
$ tmux set status
set option: status -> off <-- this is info
Easiest thing would just be to send it prefixed with E, I or O (or
ERROR/INFO/OUTPUT or whatever you prefer).
It looks like the hard bit will actually be the tty output. tmux output
is geared for maintaining an entire tty so there are lots of
optimisations for not updating things when not necessary and for drawing
across panes.
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.
If you can parse the data as TERM=screen it'll be easier to just hoke it
straight out, but that is not ideal.
> What is the difference between "info" and "normal ('print')" output?
> On Mon, Dec 6, 2010 at 5:25 PM, Nicholas Marriott
> <[1]nicholas.marri...@gmail.com> wrote:
>
> Do you want to differentiate error, info and normal ("print") output
> from commands? If so, how?
>
> On Tue, Dec 07, 2010 at 01:20:09AM +0000, Nicholas Marriott wrote:
> > I want a %noop from tmux->terminal, I don't really care about a ping
> > command, but if you need it then that's fine.
> >
> >
> > On Mon, Dec 06, 2010 at 04:47:18PM -0800, George Nachman wrote:
> > > Keeping ^D as the terminator. Not in love with the asymmetry, but ^D
> would
> > > be unnecessary in commands, and appears to be necessary in responses
> (with
> > > the alternative being lengths, but that is hard on humans).
> > >
> > > On Mon, Dec 6, 2010 at 4:24 PM, Nicholas Marriott
> > > <[1][2]nicholas.marri...@gmail.com> wrote:
> > >
> > > Two other things:
> > >
> > > - We should have a "noop" command as well.
> > >
> > > I added a "ping" command. Do you want an unsolicited tmux->terminal
> > > emulator noop as well?
> > >
> > > - I think the protocol commands (in both directions) should be
> clearly
> > > different from normal tmux commands. I'd say prefix them with a % or
> > > something or even make them capital letters (tmux commands will
> never
> > > use caps).
> > >
> > > I added a '%' prefix to commands from the terminal emulator to tmux.
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[3]nicholas.marri...@gmail.com
>
> References
>
> Visible links
> 1. mailto:nicholas.marri...@gmail.com
> 2. mailto:nicholas.marri...@gmail.com
> 3. mailto:nicholas.marri...@gmail.com
------------------------------------------------------------------------------
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
