Significant delay of 5 seconds between stdin and stdout - serving locally

Well, not so significant after all (5 seconds), but enough to worry me when a given file consists of more than twenty lines or so. In all honesty, I didn’t count the characters but I don’t think there’s a need for that at this point.

Under both vim and neovim the feedback is immediate. I’m serving a site locally.

This is happening with static site generators. I haven’t tried to test it with jekyll yet, but if the delay experienced occurs with one of the fastest ones such as hugo (which returns no lag under vim with a write operation), what gives?

I normally run terminal emulators such as urxvt and xterm. There was a lag issue I remember reading about and I believe is under tmux, but I don’t use it.

My question is: why is there a lag with write and write! operations?

This is one outstanding issue (for me at least.)

Addendum: i did tried different browsers, and also by opening the file directly. Also, by cd ing into the directory and editing it afterwards. Made no difference.

You may be encountering issue 2036.

It’s not so much a delay between stdin and stdout, as a delay between Kakoune writing the file, and hugo (or whatever) noticing that it’s been updated. Apparently hugo checks before Kakoune has had a chance to change anything, and doesn’t check again until long after Kakoune’s write operation has completed.

It’s not so much a delay between stdin and stdout

Correct. I wasn’t clear enough.

Thanks for the link. I’ll check it out.

But what’s odd is that no delay is experienced with a file of only a few lines, only when some markdown/html is added, the lag is thus amplified

After revisiting the issue 2036 today, it seems as if https://github.com/dmerejkowsky suggested having

 BufferCoord start { 0, 0 };
auto end = buffer.end_coord();
String contents = buffer.string(start, end);
write(fd, contents);

on file.cc

It does work in my end with the above code.

Change detected rebuilding site which is the message from hugo, occurs immediately regardless of the file size.

Was his suggestion ever considered? I don’t think the merge even happened

edit sigh
there’re unresolved conflicts with file.cc (his fork overall is 150 commits behind and 8 ahead)
on my end this would be 1 ahead