zulip/zulip-terminal

Distinguish EDITED vs MOVED in UI

Open

#1,253 opened on Sep 6, 2022

 (18 comments) (0 reactions) (0 assignees)Python (352 forks)github user discovery
area: UIfeature parity: 05good first issuehelp wantedmissing feature: user

Repository metrics

Stars
 (853 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

When messages have been edited in any way (content, topic, stream) then we should be already showing an EDITED label to the left of the content, under the sender name.

At some point the web app added a MOVED label to distinguish the case where the content has not been modified, and it would be useful to also have this behavior.

Mobile is also adding/adjusting this feature, possibly with a redesign, which motivated this issue. (eg. https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/UI.20redesign.3A.20edited.20and.20moved.20marks)

It would be worth investigating the approach taken in the other apps, but my take is that we likely want EDITED to take priority over MOVED if more is done to the message, but track both. Please read how we track and show EDITED first, and then think of how to implement MOVED. This would likely be good split into implementing the data-tracking first in the model, and adding tests for that, then extending to include the changes necessary to the UI.


UPDATES:

In feature level 365 (Zulip 10.0), the server introduced a last_moved_timestamp field on message objects, as well as narrowing the meaning of last_edit_timestamp. Together these are intended to let the client skip scanning through the edit_history object to determine whether a message has been edited or moved.

Therefore, implementing this feature should interpret the new fields, instead of doing that scanning. This will be more efficient, and also a step toward the server being able to stop sending the full edit history in the future.

References

Contributor guide