Open bramadams opened 2 months ago
Respecting
auto-revert-remote-files
inforge-bug-reference-setup
auto-revert-remote-files
purpose is to control an unrelated feature, and should not be repurposed here.
when using tramp, forge would do substantial unnecessary work
What part is expensive? Did you do some benchmarking?
I don't think it is "unnecessary" in the same way as was the case for magit/magit#5222. This does cause bug-references to be by "linkified", doesn't it? Doing that might be too expensive to be worth it, but "unnecessary" doesn't seem like the appropriate term, unless I am missing something.
Can you say more about the hanging? Why does that happen? Does that actually happen, or is the process just so slow, that you always abort before it completes?
Thanks for checking this PR!
For a given remote file, it basically hangs for at least a minute, before I manually abort. Then, if I try to open the same file again, it opens immediately. When trying a different file, the second try would work again.
Neither of these files are inside a git repository, just a regular folder where I have read/write access. When invoking tramp to access those files, I'm also not inside any local git repository. As such, it seems unnecessary for forge to jump in.
Earlier today, I made a screenshot of the stack trace after sending a SIGUSR2 to emacs while it was hanging, see attached. That's where I noticed forge-bug-reference-setup
. Also, if I toggle the new variable forge-bug-reference-remote-files
to nil
, the hanging disappears.
Fixes a similar issue as https://github.com/magit/magit/issues/5222, where, when using tramp, forge would do substantial unnecessary work inside
forge-bug-reference-setup
, slowing down the connection or even hanging.To fix this issue, changes similar to the original magit commit (see https://github.com/magit/magit/commit/61c051ea1cda5fe6c9404cb5ae228088d2e254f0) could easily be repeated, basically shortening out the
unless
withinforge-bug-reference-setup
.