Skip to content
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

Incorrect message selection due to non-message separators #316

Open
hrdl-github opened this issue Sep 28, 2024 · 3 comments
Open

Incorrect message selection due to non-message separators #316

hrdl-github opened this issue Sep 28, 2024 · 3 comments

Comments

@hrdl-github
Copy link
Contributor

Separator's in a channel's message view such as date separators or the new messages separator each increase an unwanted message offset by one, causing the wrong message to be returned. Example:

Message 1 (selection can return a message before this that is not being displayed)
Message 2 (selection can return a message before this that is not being displayed)
==== Some date ==== (selection returns Message 1)
Message 3 (selection returns Message 2)
---- new messages ---- (selection returns Message 3)
Message 4 (selection returns Message 4)

There might be some other issues, e.g. messages not being displayed.

@boxdot
Copy link
Owner

boxdot commented Sep 28, 2024

This created also a problems previously when answering to messages. Maybe, for now it is a good idea to disable this feature and rethink the design.

@hrdl-github
Copy link
Contributor Author

I can try to implement something that is consistent and a bit more flexible. I want to implement a marking mechanism (in addition to cursor selection) of multiple messages to implement actions like copy_message marked and delete_message marked.

@hrdl-github
Copy link
Contributor Author

I think iamb's approach in https://github.com/ulyssa/iamb/blob/9a9bdb4862646da3b03490ab250feb62df7ea468/src/windows/mod.rs and https://github.com/ulyssa/iamb/blob/9a9bdb4862646da3b03490ab250feb62df7ea468/src/windows/room/scrollback.rs would be suitable for gurk, too. It avoids the brittle index-based logic and is should be flexible to accommodate e.g. multiple selection or handling of list items of different types (e.g. messages, date separators, error messages, unread indicators).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants