Closed pekeler closed 5 years ago
I've had this behavior with 0.0.10. Just upgraded to 0.0.14 and seeing the same. These new tabs are taking the focus, so it's quite disruptive.
I did 2 things before this started:
I downgraded VSCode back to 1.39.0 and now the problem is gone. Perhaps something related to https://github.com/Microsoft/vscode/issues?q=is%3Aissue+milestone%3A%22September+2019+Recovery%22+is%3Aclosed
Hmmm, I'm using 1.39.1 and I've been working on a different project in VSCode all weekend and haven't seen that issue.
Basically, the extension thinks fossil is asking for user input. The only time this happens is if any fossil command output has a line ending with :
or ?
(note the spaces as well) Edit: It will check for endings with zero or one space. I don't believe this would be influenced by the version of VSCode unless they are piping other data through the fossil stdout stream, which would be weird.
I suppose this could happen if you files that contain those endings. Is that the case?
I have lines that end with :
and it doesn't throw on those. Can you try to find out specifically what cases is causing the issue? Or perhaps you can share a file that is causing the issue so I can investigate?
OK, I upgraded VSCode to 1.39.1 and the problem is back.
The editor tab that is popping up is displaying the content of one of my JS files, the first 301 lines of it. The last line isn't complete - it ends on the colon that's in the original.
The displayed content is 8220 bytes long. (the original file is about 20Kb)
Looking through the extension's log, it seems the problem happens when it logs fossil cat <myfile>
.
I deleted everything else in my project except for this one file. The problem goes away and I also don't see it doing the fossil cat
in the log anymore. Copying files back and editing the offending file and also other files, it now does fossil cat
on any file except for the offending file. This is weird. How can I trigger fossil cat
for my file again?
What happens if you type fossil cat <myfile>
on the command line? Does fossil correctly cat the file contents?
I believe the extension will cat the contents of any file that you have open and in focus. You can force a fossil cat
by viewing the file diff from the scm explorer.
Just so I understand, your original problem went away but now you have the problem that it will not cat the file was causing issues before?
Yes, doing a fossil cat
from the cmd-line correctly cats the full file.
Even opening the diff doesn't do the cat any more. It does show the correct diff, though. Could it be cached somewhere?
I just restarted VSCode, and now it does the cat again and the problem is back.
OK, so I added some characters to the top of this file, committed it, and now the problem is gone. So it smells like a buffer size issue for processing the result of fossil cat
to me - if a colon is right at the end of that buffer, it's triggering the issue.
Yes I was leading in that direction, but I can't find anything that states what the limit is. It's definitely not a limit placed by the extension, my guess is that has to do with how Node handles the stdout pipe for a child process.
Getting this deep into VSCode\Node implementation is well over my head, this is my first and only project working with it.
If you have any insights or clever ways to prevent this from happening to other people, please let me know.
By chance, you mentioned earlier that made two changes to fossil global settings, what were those changes?
I set the binary-glob and updated the ignore-glob. Neither of which would include my problematic file.
Create a new file test.txt whose entire content is 8,200 colons. Check it in. Then make an edit to that file to reproduce the problem.
Instead of just checking the output for :
and ?
, would it make sense to only look for those if the child process didn't terminate, i.e. is waiting for input?
Its easier to reproduce than that. Any file that ends with :
or ?
would throw the error.
Looking for stdout ending with :
or ?
is my way of checking to see if the process is waiting for input. I suppose it must be possible to check if the exit
event has been thrown. I'm already grabbing the exit code at that time so I could set some other flag that could be checked in conjunction with the :
or ?
.
But I think doing that will not fix the problem you are seeing, because the fossil cat
command was in the middle of streaming the file contents, hence the process would still be open when the :
came through.
Create a new file test.txt whose entire content is 8,200 colons. Check it in. Then make an edit to that file to reproduce the problem.
Its easier to reproduce than that. Any file that ends with : or ? would throw the error.
The file has 8,200 colons and then ends on something else, such as "abc". To reproduce the buffer-like error.
I just published v0.0.15 that will not perform the input checking for the fossil cat command
I'm suddenly seeing "Fossil Request" editor tabs popping up in VSCode after saving changes to any file. What's going on here?