Issue with indirect buffers

[dvzubarev]

Hi, thank you for this package.
I've recently started using this package and noticed occasional freezes for 10 seconds when working with indirect buffers.
I've tracked it down to an imenu update that is launched in the idle timer from bc--ipath-alist.
My setup: Emacs-30.0.50, imenu is powered by lsp-mode, lsp-server: pyright 1.1.325

So, when you have two windows B (base buffer), I (indirect buffer), and idle for a second after the change, the following will happen.

1. Buffer I: timer launches imenu--make-index-alist
2. Buffer I: lsp-mode sends the request with method="textDocument/documentSymbol" and with textDocument.uri = <path/to/base/file>
3. Buffer B: timer launches imenu--make-index-alist
4. Buffer B: lsp-mode sends the request with method="textDocument/documentSymbol" and with textDocument.uri = <path/to/base/file>
5. Buffer B: lsp-mode receives a response.
6. Buffer B: imenu--make-index-alist returns imenu alist.
7. Buffer I: imenu--make-index-alist prints error after 10 seconds
   "Timeout while waiting for response. Method: textDocument/documentSymbol"
   This error is not visible by default, because of ignore-errors.

I'm not expert of lsp-mode or lsp protocol, but I guess that lsp server cancel? the first request after it receives the identical second request and never sends anything back for the first request.
I'm not sure whether it is correct behavior or not, but the consequences, while using it with breadcrumb, are pretty harsh.
I've come up with this fix.
It checks whether the base buffer is visible and if it is then returns imenu--index-alist from the base buffer.
It seems that it is a good idea in general, since there is no point to update imenu index two times for the same buffer.
But I understand that the actual problem has nothing to do with breadcrumb, so you may feel free to reject this fix.

[joaotavora]

I'm not expert of lsp-mode or lsp protocol, but I guess that lsp server cancel? the first request after it receives the identical second request and never sends anything back for the first request.

It's a server-specific behaviour, but yes that's probably what's happening.

I'm not sure whether it is correct behavior or not, but the consequences, while using it with breadcrumb, are pretty harsh.

Understood.

I've come up with this fix.

I think it's a start, can you make it a PR? I don't understand why you have to check "base visible". What's visibility got to do with anything? Are you trying to use "base visible" as a proxy for something else, like "base recently request computed imenu-buffer-alist itself"?

[dvzubarev]

I think it's a start, can you make it a PR?

Sure.

Are you trying to use "base visible" as a proxy for something else, like "base recently request computed imenu-buffer-alist itself"?

Yes. If a base buffer is visible then it will compute imenu-buffer-alist, that can be reused in an indirect buffer. On the other hand, if the base buffer is hidden, then the indirect buffer should request an update of imenu-buffer-alist by itself. Otherwise it won't be updated. But it occurred to me now that it won't help, if there are two indirect buffers and the base buffer is hidden.
Both indirect buffers will request an update and one of them will hang.