The latest Emacs versions removed some (private) functions that telega
depends on, and this is fixed in HEAD of telega.el.
However, without these fixes, the unstable version of telega doesn't
build because the patch Nix tries to apply doesn't match the source
anymore.
The patch itself doesn't seem to do anything relevant for me.
Change-Id: Ib9a042c636cb438b2b15d231a07afd5c02be72ee
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3294
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
* 3p/buzz: bump to latest master (1.6.0)
* 3p/emacs/explain-pause-mode: adjust to package-build update
MELPA's package build now cares about git revisions, but calling VC
commands in a nix build is usually a bad idea. Thus upstream nixpkgs
passes `$commit` to the `buildPhase` and otherwise fails with an
error message that doesn't really point to the issue. Upstream change:
9140d4b06f
* 3p/overlays/emacs: udpate to 2021-07-25 to support the package-build
update. Without this emacsPackages.xelb (for tazjin's exwm) would fail.
Change-Id: I7cd782fe7d66ed4ea78c529b79fe761d921f46a8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3253
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
We don't need these in the depot anymore as the Emacs overlay now
provides newer versions of them, or because they are not used anymore.
Change-Id: I393e1580b66450d0bb128213bc79668172dadacc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3005
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Adds a new internal builder that makes it possible to override the
`emacsPackages` passed to our Emacs packages, which in turn makes it
possible to inject them into the emacsPackages fixpoint and use them
with features like Emacs native compilation.
Change-Id: I80dad57115c83cf5693ae6ba4e4cf3105d103d5e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3003
Tested-by: BuildkiteCI
Reviewed-by: adisbladis <adisbladis@gmail.com>
Reviewed-by: grfn <grfn@gws.fyi>
In recent Chrome versions, EXWM has some issue around handing focus
back to the application. There is a Github issue about this and this
commit implements the suggested workaround, which I've verified
locally.
Change-Id: Ib451e8d8b34921665c3015853850d12e04612929
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2342
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
... this should also update my system EXWM.
Change-Id: Idfbbda67613ac678dc2d5f82533e1c6176ab4a28
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2072
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
This adds very basic capability[0] and message tag[1] support to rcirc
which is used to implement support for the IRCv3 server-time[2] spec.
During connection setup, the server is asked to list its capabilities
and the `server-time` capability is then blindly requested from
it (the CAP handler code does not check whether server-time is
actually part of the listed capabilities). rcirc does not need to know
whether this negotiation succeeded, because server time tags will
either be sent or not.
By default rcirc prints all timestamps at current-time. A new variable
`rcirc-last-message-time` has been added which, if set, overrides this
timestamp. It is set by the message handler after parsing IRCv3 tags.
Thanks to William Cummings for nudging me in the direction of his post
about adding ZNC playback support to rcirc[4], from which some parts
of this code were taken.
This has been tested with IRCCloud's bouncers.
[0]: https://ircv3.net/specs/core/capability-negotiation
[1]: https://ircv3.net/specs/extensions/message-tags
[2]: https://ircv3.net/specs/extensions/server-time-3.2.html
