Christian J. Robinson wrote: > I spent some time playing with this, and one thing I noticed is that > there's no way to get the status of a channel "out of band". For example, > when I was writing my little Perl server for Vim to communicate with > occasionally it would die on me, but my Vim script didn't know that until > one of the ch_* commands threw an error, which I currently handle using > either :silent or :try/:catch/:endtry. A ch_status() or something like it > that returns a dictionary of info about the channel would be useful. For > example, it could indicate the mode, callback, waittime, last message > number sent/received, etc. and if the channel is dead it could just return > an empty dictionary.
That's a good point. I suppose that when Vim uses select() on the channel it will notice that it closed. I would think that in most cases a simple string would be sufficient. Like we have job_status(). We can have other functions to get the mode and timeout, although in most cases you would already know. Not sure why you would want statistics. For debugging? I plan to add a log file for that. Also, the channel callback can be invoked when the channel closes. Currently it's only called when nothing else handles the received message. Perhaps it's more useful to have a separate "close callback" or "error callback". > The other thing I noticed is that even though it says in the documentation > that you can specify a callback in ch_open, it doesn't actually call the > callback--I still have to specify the callback on every call to > ch_sendexpr. I'm assuming it's just not implemented yet and I should be > patient. It is implemented, but it is only invoked when the sequence number is zero. > A feature I wouldn't mind seeing added, but would understand if it wasn't > due to possible drawbacks is a flag to ch_open to make it automatically try > reconnecting a specified number of times if the channel dies without > ch_close being called. Or perhaps it would be better to allow a handler to > be defined for when the channel dies without ch_close being called. As mentioned above, a callback for when the channel closes is planned. I'm not sure how useful it is to retry opening the channel in the background. If the channel closes unexpectedly, I would think Vim needs to do something (e.g., restart the server). I was just looking at the old netbeans code to retry connecting. It would keep trying 36 times 3 seconds, and block Vim during that time. Not really useful. This is from before when we had a timeout on the connection. I believe PyClewn is the main user of netbeans these days, perhaps the developer has an opinion. Anyway, a blocking wait can be annoying. Retrying the connection (with zero timeout) in the main loop might be usefel. -- hundred-and-one symptoms of being an internet addict: 176. You lie, even to user-friends, about how long you were online yesterday. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
