aboutsummaryrefslogtreecommitdiff
path: root/lisp/mastodon-notifications.el
Commit message (Collapse)AuthorAgeFilesLines
* wholly remove parent-toot; use base-toot/-id onlymarty hiatt2022-11-121-3/+3
| | | | | | | | | | | | | | the confusion came from the three different types of statuses we often encounter: - toot - boost/fave - notification (of boost/fave/mention) in notifications, we can't just use -tl--toot-id. it will return the notif's id, not the base toot's. so we do still fetch base-toot JSON (formerly 'parent-toot prop), and get base-toot-id from there, else from toot JSON.
* use seq-empty-p and string-empty-p callsmarty hiatt2022-09-051-1/+1
|
* autoloadmarty hiatt2022-08-301-0/+1
|
* clear notification(s) functionsmarty hiatt2022-08-301-0/+28
|
* bump version in boilerplatemarty hiatt2022-08-271-1/+1
|
* autoloads, flycheckmarty hiatt2022-08-271-1/+4
|
* flychecks and docstringsmousebot2022-04-051-1/+3
|
* attach parent JSON to fave/boost notifs to fix repliesmousebot2022-03-191-3/+6
| | | | | | | because we switched to using boost/fave JSON rather than parent, as 'toot-json, replies to these toots were broken (mentions, etc.) so now we attach both bits of data and selectively pull from each.
* favourite not favoritemousebot2022-03-111-2/+2
|
* improve empty notifications json messagemousebot2022-03-111-1/+1
|
* make follow etc work on boost/fave notifsmousebot2022-03-111-6/+12
| | | | | | | to achieve this, in notifications--format-note, we run notifications--insert-status on 'note' rather than 'status' handle mentions/reblogs when following from a notif
* test and message for foll reqs processmousebot2022-02-181-1/+2
| | | | just feedback for when we call it when not on anything
* add mini docs for foll reqs viewmousebot2022-02-151-1/+2
| | | | reload foll reqs view on accept/reject
* message when notificiations--timeline returns nothing.mousebot2022-02-051-2/+4
|
* update homepage and copyright boilerplatemousebot2022-02-051-1/+1
|
* handle a buggy empty notificationmousebot2022-01-151-1/+2
| | | | | | i received an notification (also in other clients/web interface) attached to no toot. these checks should allow notifications view to display without tripping up on any such vacant notifs from the server.
* autoloadsmousebot2022-01-151-0/+2
|
* byte compile warningsmousebot2022-01-111-2/+3
|
* add support for poll notificationsmousebot2022-01-101-4/+12
| | | | finally we now display all types of notifications! it's about bloody time.
* refactor notification functionsmousebot2022-01-031-75/+48
|
* fix follow-request-process: change "accept" to "authorize"mousebot2021-12-291-7/+8
|
* Merge branch 'insert-status-refactor' into developmousebot2021-12-241-14/+2
|\
| * refactor mastodon-notifications--insert-statusmousebot2021-12-241-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | which was a copy of mastodon-tl--insert-status. we revert to having just the latter as main function with optional argument. mastodon-notifications--insert-status just calls it with the arg ID. the reason we need the difference is to ensure notifications have their own ID, and not that of the toot the notif refers to, attached as property "toot-id". then we have all functionality working on notifications, such as boosting mentions and so on.
* | refactor follow request accept/reject functions.mousebot2021-12-241-32/+29
|/ | | | | | | | | | previously we had duplication of functions depending on whether we were in follow requests view or notificaitons view. now we just check which kind of f-req we have and act accordingly. main function being `mastodon-notifications--follow-request-process'. also updates keybindings for both views. we no longer need them included separately in profile-mode.
* tiny ediff clean up 2.mousebot2021-12-231-2/+1
|
* bump version to a round numbermousebot2021-12-171-1/+1
|
* boilerplate maintainer contactmousebot2021-12-171-0/+1
|
* depend on emacs 27.1, flychecks, docstrings, etc.mousebot2021-12-171-1/+1
| | | | strictly, the 27.1 dependency is only for proper-list-p in -http.el.
* bump version, change homepage link, readmemousebot2021-12-171-2/+2
|
* Merge branch 'develop' into notify-when-postmousebot2021-12-161-49/+49
|\
| * Convert most uses of `(cdr (assoc <some-symbol> <a-list>))` to `(alist-get ↵Holger Dürer2021-11-061-15/+15
| | | | | | | | | | | | | | <some-symbol> <a-list>)` This is more readable and actually more efficient (maybe) since it uses `eq` rather than `equal` as a test.
| * Reformat all code.Holger Dürer2021-11-061-34/+34
| | | | | | | | | | | | | | | | | | | | | | Basically, in Emacs for each file: select all text and `indent-region`. - This also removes one redundant comment, and - fixes an error with json decoding where the `json-read-from-string` was actually not within the intended `unless` clause (which explains the warning about "result of (string-equal "" json-string) will be ignored" which I never understood.
| * tiny cleanupmousebot2021-11-061-1/+0
| |
| * Fix compilation warnings.Holger Dürer2021-11-011-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | This is mostly reflowing / reworkding docstrings to keep within 80 characters limit and adding autoloads. There are two warning remaining that I don't understand: - mastodon-async.el:359:16: Warning: reference to free variable ‘url-http-end-of-headers’ - mastodon-http.el:139:8: Warning: value returned from (string-equal json-string "") is unused When adding autoloads this sorts them for better readability.
* | add support for receiving notifications when a user postsmousebot2021-11-021-2/+24
|/ | | | | | | - mastodon-tl--notify-user-posts - mastodon-tl--no-notify-user-posts - + some schtick in notifications.el to make sure the notifs display ok.
* restore original tl--init as tl--init-sync.mousebot2021-10-251-1/+1
| | | | | | | | | - use it for eg notifications - this because i suspect sync is sometimes faster. - with async init*, i often have to press a key to trigger the request - perhaps good to have both in the code, and choose which to use when - cd also poss make this a customize.
* flycheck: docstrings, autoloads, etcmousebot2021-10-031-5/+17
|
* package-lint: bump to emacs 26.1, disable stream keybindingsmousebot2021-09-221-1/+1
|
* follow requests accept/reject from notifications +mousebot2021-08-091-13/+64
| | | | | | | - new bindings for f-req accept/reject (in both notifs and in f-req views) - check if we are at an f-req before accept/rejecting - flycheck / docstrings - fix notifs byline formatting for f-reqs
* include follow-requests in notificationsmousebot2021-08-081-2/+21
|
* feed notfication ID to mastodon-notifications--insert-statusmousebot2021-06-191-9/+38
| | | | | | | | which is a copy of mastodon-tl--insert-status. this makes the 'toot-id of notifications that of the favoriting/boosting item, rather than the item boosted/favorited. this ID is needed in order to make loading more older notifications work correctly. beforehand, the call would be incorrect and the same latest 20 notifications would load.
* typos and readmemousebot2021-06-141-1/+1
|
* enable async stream for user notifications.mousebot2021-06-031-3/+3
| | | | creates a notifications filter for the 'user' stream, then handles display of notifications, which have their own timeline funs.
* bump masto version, bump emacs version to 25.1, dependency in readmemousebot2021-05-311-2/+2
|
* make the boosts/favorite byline text in notifications less ambiguousmousebot2021-05-211-2/+2
|
* message for notifs load, tiny search.el cleanupmousebot2021-05-171-1/+2
|
* Update copyright and bump versionJohnson Denen2019-03-041-1/+1
|
* Fix boosting and faving in the notifications buffer.Holger Dürer2018-08-101-4/+6
| | | | Now that we calculate the base toot id, we can ensure that it is unset in notifications that do not represent a toot.
* Remove compiler warnings in mastodon-notifications.el (#190)H Durer2018-08-101-0/+12
|
* Give mastodon-media--inline-images a saner interface. (#191)H Durer2018-08-101-5/+7
| | | | | | | | Instead of making it search the whole buffer every time to find images to load, give it a range where this work should be done. We then call this immediately after inserting a single status, notification, ... There should be no big noticible difference - images might load a tiny bit sooner although I doubt you can see that. This should be more efficient on large buffers although Alex didn't notice any problems when testing streamed buffers. We should still do it as it make things easier to understand. I was always worried about these global operations.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 04:23:00 +0000