popup_getoptions without a response (in vim v8.1.2144)

Hi, As a part of the channel-based plugin https://github.com/govim/govim test code I'm using popup_getoptions() to fetch the title of a popup created by the tests. To get the popup id:s I call "getbufinfo()". What I have observed is that when I pass in a valid and existing popup id to

Debugging autocommand help

Hi, I'm having issues with a autocommand not being triggered occasionally and would like some pointers to how I can debug this further. It is in the context of a plugin for Go that is written in Go and uses channels to communicate with vim (https://github.com/govim/govim). The plugin defines

Re: Vim appears to stall channel based requests

Yeah, I don't really understand what triggers it. I've tried to create a small reproducible but I can't seen to make it trigger this. Could be a timing issue. One thing I thought about is the 10ms delay that is added if there is more to read from the channel(?). That might introduce some

Re: Vim appears to stall channel based requests

> Please try if this patch fixes your problem: > > --- prev/src/channel.c2019-06-24 00:43:31.463691826 +0200 > +++ channel.c 2019-06-28 04:41:25.767304149 +0200 > @@ -2850,10 +2850,13 @@ > > if (ch_mode == MODE_JSON || ch_mode == MODE_JS) > { > - jsonq_T *head =

Re: Vim appears to stall channel based requests

Just to summarize: - channel_read() reads 63 bytes and calls channel_save() - channel_save() saves those to a new node->rq_buffer at the end of channel head To convert it to JSON someone must call channel_parse_json(), and it can be either from channel_read_json_block() or may_invoke_callback().

Re: Vim appears to stall channel based requests

> That doesn't look right, because there should not be a complete json message. > If there is, perhaps a call to parse it is missing? > Perhaps a call to channel_parse_json() is needed. Yes, maybe there is a channel_parse_json() missing somewhere. But as the flow log shows it's also a

Re: Vim appears to stall channel based requests

This is a patch that actually fixes the problem, but I have no idea what other side effects it might have. Also note that the line numbers are way off since I've been adding stuff. @@ -2853,7 +2853,7 @@ channel_has_readahead(channel_T *channel, ch_part_T part) jsonq_T *head =

Re: Vim appears to stall channel based requests

In both cases it's called from the end of WaitForCharOrMouse. I'm not entirely sure I get all line numbers right, even when I compile vim with -g -O0, so I had to go with the "Fprintf to stderr"-monkey style :). One further step in the stack trace: ui_wait_for_chars_or_timer(...), the line "if

Vim appears to stall channel based requests

I wrote the previous post yesterday but since it was my first it had to be moderated before showing up. Since then I did some more investigation and it turns out that the channel is indeed read in channel_read(...), but then the blocking select() prevents the incoming message to be processed.

Vim appears to stall channel based requests

Hi everyone, I've been trying to create a smaller reproducible that can demo what happens, but it seems to be a complex combination that isn't trivial to slice down. So I went for another option, debugging vim instead. Since the binary I have can reproduce the behavior consistently I thought