mirror of
https://github.com/vale981/ement.el
synced 2025-03-04 17:01:39 -05:00
Update
This commit is contained in:
Adam Porter
parent
faf97385bd
commit
2a449ae14a
1 changed files with 164 additions and 164 deletions
328
NOTES.org
328
NOTES.org
|
|
@ -2,6 +2,170 @@
|
|||
|
||||
* Tasks
|
||||
|
||||
** TODO Make bookmark handler put point at end of room buffers
|
||||
|
||||
When restoring a room buffer bookmark, having point at the top of the buffer isn't very useful, because I almost always want it to be at the bottom so I can follow new messages.
|
||||
|
||||
[2022-09-01 Thu 04:04] Or maybe go to the fully-read marker instead.
|
||||
|
||||
** TODO Membership events in which nothing seems to change :bug:
|
||||
|
||||
e.g. this one from an event in =#matrix:matrix.org= formats as "Unrecognized", because nothing is changed, so I don't even know what this event is supposed to mean.
|
||||
|
||||
#+begin_example elisp
|
||||
((:id . "$5tsYDxTf8SkJ1J8MLZfV4TtNMdXl3pKkU8T1T6oDszY")
|
||||
(:sender . "@key823:setada.de")
|
||||
(:content
|
||||
(avatar_url . "mxc://setada.de/fGrtYfbbtrvhzPwfdKeCharl")
|
||||
(displayname . "key823")
|
||||
(membership . "join"))
|
||||
(:origin-server-ts . 1657024512875)
|
||||
(:type . "m.room.member")
|
||||
(:state-key . "@key823:setada.de")
|
||||
(:unsigned
|
||||
(age . 2297)
|
||||
(replaces_state . "$-J4JTEu_WIheqWQUe_1S4oP_D9zgxDS41XsaoKuvLVM")
|
||||
(prev_content
|
||||
(avatar_url . "mxc://setada.de/fGrtYfbbtrvhzPwfdKeCharl")
|
||||
(displayname . "key823")
|
||||
(membership . "join"))
|
||||
(prev_sender . "@key823:setada.de"))
|
||||
(:receipts)
|
||||
(:local))
|
||||
#+end_example
|
||||
|
||||
** TODO Render server ACL events
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2022-06-13 Mon 17:39]
|
||||
:END:
|
||||
|
||||
e.g.
|
||||
|
||||
#+begin_src js
|
||||
{
|
||||
"content": {
|
||||
"allow": [
|
||||
"*"
|
||||
],
|
||||
"deny": [
|
||||
"foo.bar",
|
||||
"*.foo.bar"
|
||||
]
|
||||
},
|
||||
"origin_server_ts": 1655159830066,
|
||||
"sender": "@user:server",
|
||||
"state_key": "",
|
||||
"type": "m.room.server_acl",
|
||||
"unsigned": {},
|
||||
"event_id": "$foobarbaz",
|
||||
"room_id": "!foobar:baz"
|
||||
}
|
||||
#+end_src
|
||||
|
||||
** TODO Notifications for "@room" messages
|
||||
|
||||
** UNDERWAY User avatars
|
||||
:PROPERTIES:
|
||||
:ID: db3393af-6195-419b-aaaa-508cafc07589
|
||||
:END:
|
||||
|
||||
In the =wip/user-avatars= branch, which should be rebased on the =wip/queue-avatars= branch, which should be rebased on =master= and depends on the =plz= queue feature, which is not yet released. But these pieces already basically work, and it shouldn't take much to polish them up.
|
||||
|
||||
** MAYBE Use line-prefix and/or wrap-prefix
|
||||
:LOGBOOK:
|
||||
- State "MAYBE" from [2020-12-03 Thu 15:28]
|
||||
:END:
|
||||
|
||||
These could be alternatives to using margins. See [[info:elisp#Truncation][info:elisp#Truncation]].
|
||||
|
||||
** MAYBE Use =persist.el= for saving session data
|
||||
|
||||
It's in ELPA, and its code looks good. Is there any reason not to use it?
|
||||
|
||||
** PROJECT Backfilling paged events after interrupted sync
|
||||
|
||||
e.g. when a system has been asleep for hours and syncs again, there may be more new events in a room than the server is willing to send in a single sync response, causing the response to be paged. The old events need to be fetched in pages up to the old sync token.
|
||||
|
||||
+ [[file:worktrees/spec/matrix-spec-r0.6.1.org::*\[\[#id256\]\[9.4 Syncing\]\]][SPEC: 9.4 Syncing]]
|
||||
|
||||
This note from the spec is important:
|
||||
|
||||
#+begin_quote
|
||||
Events are ordered in this API according to the arrival time of the event on the homeserver. This can conflict with other APIs which order events based on their partial ordering in the event graph. This can result in duplicate events being received (once per distinct API called). Clients SHOULD de-duplicate events based on the event ID when this happens.
|
||||
#+end_quote
|
||||
|
||||
[2021-09-24 Fri] This is done (in =6d772ec=) to a useful extent: after an interrupted sync, rooms are backfilled up to 1,000 events (and that number could be configurable). Beyond that, a gap would remain, and it would remain unfilled within that Ement session. (Disconnecting and reconnecting would cause the room history to be cleared and re-fetched from scratch.)
|
||||
|
||||
In the long run, a more flexible solution is needed, e.g. something like Element does, where it seems that an event can be fetched, displayed, and then gaps on either side of it are filled on-demand. Doing that in Emacs with EWOC will probably require some thoughtful design.
|
||||
|
||||
** PROJECT Invited rooms
|
||||
:PROPERTIES:
|
||||
:ID: bad4dbe4-4f86-479a-a346-e7d89bf39f92
|
||||
:END:
|
||||
:LOGBOOK:
|
||||
- State "PROJECT" from [2021-08-23 Mon 16:32]
|
||||
:END:
|
||||
|
||||
i.e. showing invitations, not sending them (a separate issue)
|
||||
|
||||
*** TODO Make join-room command default to current room in invited-room buffers
|
||||
|
||||
*** MAYBE Show room preview for invited rooms
|
||||
:PROPERTIES:
|
||||
:ID: acf07f25-3425-466b-83f6-81fb192f8e17
|
||||
:END:
|
||||
|
||||
Not sure how this is intended to work, e.g. in Element sometimes rooms seem to show a preview in direct rooms, so you can see what someone said before you accept the invitation to the room. But other times, it seems necessary to join the room first (maybe that's onl for encrypted rooms, which seem to be the default for direct rooms in Element).
|
||||
|
||||
*** TODO Notification for invitations
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2021-09-30 Thu 20:52]
|
||||
:END:
|
||||
|
||||
*** TODO Sort invited rooms to the top of room list by default
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2021-09-30 Thu 20:52]
|
||||
:END:
|
||||
|
||||
*** CANCELED Column in room list for room type
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
:PROPERTIES:
|
||||
:ID: a1078833-9637-488c-8fb9-cf989b35e970
|
||||
:END:
|
||||
|
||||
i.e. =j= for joined, =i= for invited, =l= for left, and maybe some others for archived or forgotten, depending on what the spec calls for.
|
||||
|
||||
[2021-08-23 Mon 19:22] Decided that the extra column didn't look nice, and isn't that useful. Better to just use a different face and topic message for invited rooms.
|
||||
|
||||
*** DONE Save room type in struct
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
I don't see a straightforward way to know what a room's type is, other than saving it to a struct slot when processing a sync response, depending on which set of rooms it appears in.
|
||||
|
||||
*** DONE Set footer of invited rooms to a clickable link to join the room
|
||||
CLOSED: [2021-08-23 Mon 19:21]
|
||||
|
||||
*** DONE Show invited rooms in rooms list
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
*** DONE Store =invite_state= for invited rooms
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
According to the [[file:worktrees/spec/matrix-spec-r0.6.1.org::#get-_matrixclientr0sync][spec]]:
|
||||
|
||||
#+BEGIN_QUOTE
|
||||
The state of a room that the user has been invited to. These state events may only have the =sender=, =type=, =state_key= and =content= keys present. These events do not replace any state that the client already has for the room, for example if the client has archived the room. Instead the client should keep two separate copies of the state: the one from the =invite_state= and one from the archived =state=. If the client joins the room then the current state will be given as a delta against the archived =state= not the =invite_state=.
|
||||
#+END_QUOTE
|
||||
|
||||
** PROJECT [#B] Multi-room buffer
|
||||
:LOGBOOK:
|
||||
- State "PROJECT" from "TODO" [2020-12-02 Wed 14:46]
|
||||
:END:
|
||||
|
||||
Like the "notifications" buffer in ~matrix-client~.
|
||||
|
||||
[2021-09-26 Sun 19:56] Mostly done, but I had some issues with margin text and displaying the room avatar, which I'd like to fix sometime.
|
||||
|
||||
** DONE [#A] Submit to ELPA
|
||||
:LOGBOOK:
|
||||
- State "DONE" from "PROJECT" [2022-09-15 Thu 13:06] \\
|
||||
|
|
@ -262,45 +426,6 @@ And it still happens: after connecting and the auto-view-rooms are shown, Emacs
|
|||
So I think the only solution now is to use a global idle timer that iterates over visible windows. We won't use window-scroll-functions at all, even though that's obviously the more correct solution.
|
||||
|
||||
[2022-09-19 Mon 15:08] I ended up using the iterating global idle timer, and it seems to work fine.
|
||||
** TODO Make bookmark handler put point at end of room buffers
|
||||
|
||||
When restoring a room buffer bookmark, having point at the top of the buffer isn't very useful, because I almost always want it to be at the bottom so I can follow new messages.
|
||||
|
||||
[2022-09-01 Thu 04:04] Or maybe go to the fully-read marker instead.
|
||||
|
||||
** TODO Membership events in which nothing seems to change :bug:
|
||||
|
||||
e.g. this one from an event in =#matrix:matrix.org= formats as "Unrecognized", because nothing is changed, so I don't even know what this event is supposed to mean.
|
||||
|
||||
#+begin_example elisp
|
||||
((:id . "$5tsYDxTf8SkJ1J8MLZfV4TtNMdXl3pKkU8T1T6oDszY")
|
||||
(:sender . "@key823:setada.de")
|
||||
(:content
|
||||
(avatar_url . "mxc://setada.de/fGrtYfbbtrvhzPwfdKeCharl")
|
||||
(displayname . "key823")
|
||||
(membership . "join"))
|
||||
(:origin-server-ts . 1657024512875)
|
||||
(:type . "m.room.member")
|
||||
(:state-key . "@key823:setada.de")
|
||||
(:unsigned
|
||||
(age . 2297)
|
||||
(replaces_state . "$-J4JTEu_WIheqWQUe_1S4oP_D9zgxDS41XsaoKuvLVM")
|
||||
(prev_content
|
||||
(avatar_url . "mxc://setada.de/fGrtYfbbtrvhzPwfdKeCharl")
|
||||
(displayname . "key823")
|
||||
(membership . "join"))
|
||||
(prev_sender . "@key823:setada.de"))
|
||||
(:receipts)
|
||||
(:local))
|
||||
#+end_example
|
||||
|
||||
** UNDERWAY User avatars
|
||||
:PROPERTIES:
|
||||
:ID: db3393af-6195-419b-aaaa-508cafc07589
|
||||
:END:
|
||||
|
||||
In the =wip/user-avatars= branch, which should be rebased on the =wip/queue-avatars= branch, which should be rebased on =master= and depends on the =plz= queue feature, which is not yet released. But these pieces already basically work, and it shouldn't take much to polish them up.
|
||||
|
||||
** DONE [#B] Fix membership messages for empty displaynames :bug:
|
||||
:PROPERTIES:
|
||||
:ID: 412d352f-6e66-44dc-9f6f-4c92cc71b176
|
||||
|
|
@ -350,131 +475,6 @@ Is displayed as:
|
|||
Membership: 1 joined (); 1 changed name ().
|
||||
#+end_example
|
||||
|
||||
** TODO Render server ACL events
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2022-06-13 Mon 17:39]
|
||||
:END:
|
||||
|
||||
e.g.
|
||||
|
||||
#+begin_src js
|
||||
{
|
||||
"content": {
|
||||
"allow": [
|
||||
"*"
|
||||
],
|
||||
"deny": [
|
||||
"foo.bar",
|
||||
"*.foo.bar"
|
||||
]
|
||||
},
|
||||
"origin_server_ts": 1655159830066,
|
||||
"sender": "@user:server",
|
||||
"state_key": "",
|
||||
"type": "m.room.server_acl",
|
||||
"unsigned": {},
|
||||
"event_id": "$foobarbaz",
|
||||
"room_id": "!foobar:baz"
|
||||
}
|
||||
#+end_src
|
||||
|
||||
** MAYBE Use line-prefix and/or wrap-prefix
|
||||
:LOGBOOK:
|
||||
- State "MAYBE" from [2020-12-03 Thu 15:28]
|
||||
:END:
|
||||
|
||||
These could be alternatives to using margins. See [[info:elisp#Truncation][info:elisp#Truncation]].
|
||||
|
||||
** MAYBE Use =persist.el= for saving session data
|
||||
|
||||
It's in ELPA, and its code looks good. Is there any reason not to use it?
|
||||
|
||||
** PROJECT Backfilling paged events after interrupted sync
|
||||
|
||||
e.g. when a system has been asleep for hours and syncs again, there may be more new events in a room than the server is willing to send in a single sync response, causing the response to be paged. The old events need to be fetched in pages up to the old sync token.
|
||||
|
||||
+ [[file:worktrees/spec/matrix-spec-r0.6.1.org::*\[\[#id256\]\[9.4 Syncing\]\]][SPEC: 9.4 Syncing]]
|
||||
|
||||
This note from the spec is important:
|
||||
|
||||
#+begin_quote
|
||||
Events are ordered in this API according to the arrival time of the event on the homeserver. This can conflict with other APIs which order events based on their partial ordering in the event graph. This can result in duplicate events being received (once per distinct API called). Clients SHOULD de-duplicate events based on the event ID when this happens.
|
||||
#+end_quote
|
||||
|
||||
[2021-09-24 Fri] This is done (in =6d772ec=) to a useful extent: after an interrupted sync, rooms are backfilled up to 1,000 events (and that number could be configurable). Beyond that, a gap would remain, and it would remain unfilled within that Ement session. (Disconnecting and reconnecting would cause the room history to be cleared and re-fetched from scratch.)
|
||||
|
||||
In the long run, a more flexible solution is needed, e.g. something like Element does, where it seems that an event can be fetched, displayed, and then gaps on either side of it are filled on-demand. Doing that in Emacs with EWOC will probably require some thoughtful design.
|
||||
|
||||
** PROJECT Invited rooms
|
||||
:PROPERTIES:
|
||||
:ID: bad4dbe4-4f86-479a-a346-e7d89bf39f92
|
||||
:END:
|
||||
:LOGBOOK:
|
||||
- State "PROJECT" from [2021-08-23 Mon 16:32]
|
||||
:END:
|
||||
|
||||
i.e. showing invitations, not sending them (a separate issue)
|
||||
|
||||
*** TODO Make join-room command default to current room in invited-room buffers
|
||||
|
||||
*** MAYBE Show room preview for invited rooms
|
||||
:PROPERTIES:
|
||||
:ID: acf07f25-3425-466b-83f6-81fb192f8e17
|
||||
:END:
|
||||
|
||||
Not sure how this is intended to work, e.g. in Element sometimes rooms seem to show a preview in direct rooms, so you can see what someone said before you accept the invitation to the room. But other times, it seems necessary to join the room first (maybe that's onl for encrypted rooms, which seem to be the default for direct rooms in Element).
|
||||
|
||||
*** TODO Notification for invitations
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2021-09-30 Thu 20:52]
|
||||
:END:
|
||||
|
||||
*** TODO Sort invited rooms to the top of room list by default
|
||||
:LOGBOOK:
|
||||
- State "TODO" from [2021-09-30 Thu 20:52]
|
||||
:END:
|
||||
|
||||
*** CANCELED Column in room list for room type
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
:PROPERTIES:
|
||||
:ID: a1078833-9637-488c-8fb9-cf989b35e970
|
||||
:END:
|
||||
|
||||
i.e. =j= for joined, =i= for invited, =l= for left, and maybe some others for archived or forgotten, depending on what the spec calls for.
|
||||
|
||||
[2021-08-23 Mon 19:22] Decided that the extra column didn't look nice, and isn't that useful. Better to just use a different face and topic message for invited rooms.
|
||||
|
||||
*** DONE Save room type in struct
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
I don't see a straightforward way to know what a room's type is, other than saving it to a struct slot when processing a sync response, depending on which set of rooms it appears in.
|
||||
|
||||
*** DONE Set footer of invited rooms to a clickable link to join the room
|
||||
CLOSED: [2021-08-23 Mon 19:21]
|
||||
|
||||
*** DONE Show invited rooms in rooms list
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
*** DONE Store =invite_state= for invited rooms
|
||||
CLOSED: [2021-08-23 Mon 19:22]
|
||||
|
||||
According to the [[file:worktrees/spec/matrix-spec-r0.6.1.org::#get-_matrixclientr0sync][spec]]:
|
||||
|
||||
#+BEGIN_QUOTE
|
||||
The state of a room that the user has been invited to. These state events may only have the =sender=, =type=, =state_key= and =content= keys present. These events do not replace any state that the client already has for the room, for example if the client has archived the room. Instead the client should keep two separate copies of the state: the one from the =invite_state= and one from the archived =state=. If the client joins the room then the current state will be given as a delta against the archived =state= not the =invite_state=.
|
||||
#+END_QUOTE
|
||||
|
||||
** PROJECT [#B] Multi-room buffer
|
||||
:LOGBOOK:
|
||||
- State "PROJECT" from "TODO" [2020-12-02 Wed 14:46]
|
||||
:END:
|
||||
|
||||
Like the "notifications" buffer in ~matrix-client~.
|
||||
|
||||
[2021-09-26 Sun 19:56] Mostly done, but I had some issues with margin text and displaying the room avatar, which I'd like to fix sometime.
|
||||
|
||||
** TODO Notifications for "@room" messages
|
||||
|
||||
** DONE Sending direct messages
|
||||
:LOGBOOK:
|
||||
- State "DONE" from "PROJECT" [2022-03-25 Fri 23:14]
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue