Disabling this because of some weird behavior. It seems like a race
condition exists in which the window-scroll-functions are called,
causing the read receipt to get sent, followed by the read-receipt
being updated, causing the window-scroll-functions to be called again
before the updated receipt is displayed in the buffer, which can cause
an infinite loop, which can even exhaust the Lisp stack and cause
Emacs to freeze (without 100% CPU usage). At least, that's the best
explanation I have so far--it's very weird. Until it's solved, we'll
have to do without sending read receipts. Maybe
window-scroll-functions isn't suitable for this, even though it seems
ideal in theory. Maybe instead we should use a simple idle timer that
iterates over windows, or something like that.
A bug was introduced in the previous fixes that can cause excessive
read receipts to be sent in rapid succession. A more thoughtful fix
will be necessary to properly send only one receipt per room event and
per scroll event. In the meantime, this must be disabled to prevent
the excessive network requests.
This may fix a weird bug introduced in the last commit or
two (involving variable-binding-depth errors, timers running
repeatedly and making Emacs unresponsive, etc--I have no idea how the
changes could have caused such a thing, but they apparently did).
- Move function called by timer to a named function.
- Send read receipt even if its position is outside the range of
retrieved events. Otherwise, it could be so far back that it never
gets updated, which doesn't seem useful. The fully-read marker
remains unmoved until the user gets to the end of the room's events
and marks them all as read, which seems right and useful.
And use it in ement-notify, etc. This seems to strike a nice balance
between readability and efficient use of space, especially in the
notifications buffer.
I'm not sure what can cause this. While I've heard a couple of
reports from users, this is the first time it's happened to me. It
might be caused by an earlier error interrupting sync processing,
leaving a room data or buffer in an inconsistent state. Anyway, this
should prevent it from being a problem, while still leaving a way to
potentially learn the cause so it can be truly solved.
...since ts is not (yet?) in ELPA, which would prevent Ement from
going into it. Also, this should be slightly more efficient, since we
won't allocate ts structs for these calculations.
This avoids circular data structures (I think this is the only case of
it), which should prevent the infinite-loop/out-of-memory situations
when Emacs prints one in an error or backtrace and print-circle is
nil.
Fixes#41.
