-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replying to an edited message causes "This event could not be displayed" in Element #227
Comments
@phil-s Thanks. Seems that we follow Postel's Law a bit more than Element does. BTW, I didn't intend that experienced users would have to fill out the whole bug template when reporting issues that are plainly, actually bugs that simply need to be fixed, so feel free to skip the template and file a free-form report if you like. |
Use in (ement-room-edit-message). Fixes #227. Reported-by: Phil Sainty <[email protected]>
I'll try again this evening when I have more time in case I messed up the update (testing with
Element still shows me |
Use in (ement-room-edit-message). See #226, #227, #228. Reported-by: Phil Sainty <[email protected]>
@phil-s Ok, I pushed another commit to this branch: https:/alphapapa/ement.el/compare/wip/original-id-of I tested it according to your instructions, and it seems to work correctly now. |
See #226, #227, #228. Reported-by: Phil Sainty <[email protected]>
See #226, #227, #228. Reported-by: Phil Sainty <[email protected]>
Yep, that's done the trick! Cheers for getting a new release out with all those fixes. I'm only seeing one other related point of difference between the two clients, which is that Element seems to dynamically update the quoted text in a reply when the message being quoted is edited (or deleted), whereas in Ement.el the quote remains unmodified. I'm not fussed about this myself -- it doesn't seem very important (certainly not the same class of inconsistency which these recent issues were resolving), and it's not clear to me that Element's behaviour is better. I'll leave it to you to log an issue for that if you think it's worth changing. |
That issue should be handled by #150, which will fetch the content of referenced events rather than using the embedded, quoted content. However, as you said, I'm not convinced it's necessarily better, so we might have an option to disable that. Thanks. |
As a footnote, I was just looking in the spec again trying to verify that replies need to target the original message ID, and I simply don't see that stated anywhere, so my impression is that this issue was on account of an Element bug (or if not that it's an accidental omission from the spec). I believe the revised behaviour is perfectly valid though, and still think that it's the right thing for Ement.el to do for the sake of Element compatibility. |
Yeah, a bit ambiguous, but this is probably best. Thanks. |
Seems similar to #226.
OS/platform
Ubuntu GNU/Linux 22.04
Emacs version and provenance
Emacs 29.1 compiled from source.
Emacs command
emacs
Emacs frame type
GUI
Ement package version and provenance
Tested with current HEAD:
Actions taken
test
. Both clients showtest
.test2
. Both clients showtest2 [edited]
Observed results
Ement.el displays something like this for both replies:
While Element shows something like this for the reply sent by Ement.el:
Expected results
Element displays
test2
as the quote.Backtrace
No response
Etc.
This looks like much the same issue as #226. Looking at the events...
test
has ID$ox7euKl9PzczuoJbGwHpTcn2AOV3GatwlcdWwCu2rOA
test2
has ID$hSiAg7wawUv6d-LbQgzEcHmoLXxCTu167kjMEUoOR4g
test2
from Ement.el has:test2
from Element hasThe text was updated successfully, but these errors were encountered: