From grtcdr to ~leon_plickat/public-inbox
--- iwd.el | 1 + 1 file changed, 1 insertion(+) diff --git a/iwd.el b/iwd.el index c5d8fc4..f61afc9 100644 --- a/iwd.el +++ b/iwd.el @@ -219,6 +219,7 @@ (let ((map (make-sparse-keymap))) (set-keymap-parent map tabulated-list-mode-map) (define-key map (kbd "c") #'iwd-connect) (define-key map (kbd "s") #'iwd-scan) map) [message trimmed]
From grtcdr to ~leon_plickat/public-inbox
--- iwd.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/iwd.el b/iwd.el index 75622e7..c5d8fc4 100644 --- a/iwd.el +++ b/iwd.el @@ -211,7 +211,9 @@ (interactive) (dolist (device (iwd--get-devices (iwd--get-obj-alist))) (dbus-call-method :system iwd--dbus-service (car device) "net.connman.iwd.Station" "Scan"))) (car device) "net.connman.iwd.Station" "Scan"))[message trimmed]
From Taha Aziz Ben Ali to ~leon_plickat/public-inbox
Thanks! I was able to get the warning by simply running `byte-compile-file' on iwd.el (inspect the *Compile Log* for confirmation). I should mention that these minor warnings always manage to creep in, Borg (an alternative package manager) likes to report every little warning that other package managers like package.el don't necessarily emit.
From grtcdr to ~leon_plickat/public-inbox
This fixes the following error: package/iwd/iwd.el:12:11: Warning: defgroup for ‘iwd’ fails to specify containing group --- iwd.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/iwd.el b/iwd.el index d25dc4e..75622e7 100644 --- a/iwd.el +++ b/iwd.el @@ -9,7 +9,9 @@ ;; Add dwim command, which on enter connects/disconnects from network in list [message trimmed]
From grtcdr to ~grtcdr/pub
--- early-init.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/early-init.el b/early-init.el index 6394f7e..17c3ecb 100644 --- a/early-init.el +++ b/early-init.el @@ -12,7 +12,7 @@ :prefix "my/") ;; Raise the garbage collection threshold and percentage (setopt gc-cons-percentage 0.6 (setopt gc-cons-percentage 0.8[message trimmed]
From Taha Aziz Ben Ali to ~sircmpwn/sr.ht-discuss
Hi, I spoke with the current maintainer of hut, Thorben, about adding support for modifying specific files in *existing* subdirectories <https://todo.sr.ht/~xenrox/hut/55>. I was told that the API must first add support for this use case. Background: I'm attempting, as mentioned in the aforementioned issue, to deploy a file (a curriculum vitae to be precise) created within a pipeline that is completely different from the one that builds the website. I'd like to do this because it means that I can make changes to one file and have them reflected without requiring an entire rebuild of the website.
From Taha Aziz Ben Ali to ~grtcdr/pub
Looks good, I just have one minor nitpick about the wording here: > +most probable cause is a not well known Emacs default. It would flow/read much better if we instead say "most probable cause is a subtle and unexpected default setting", what do you think?
From Taha Aziz Ben Ali to ~grtcdr/pub
> In my situation (as an intermediate emacs user), I didn't realize that > this is what the docs where referencing when skimming them for the first > time. Not having worked much with themes before, it didn't occur to me > that the inconsistencies I was seeing were related to the other themes > not getting disabled first. It was only after finding out what `modus- > themes-toggle` does differently that I learned about this quirk. This behavior may be a relic of time, because there's no reason that comes to mind where someone would want to load two themes as they will most definitely clash one way or another. > I do think that the vast majority of users would prefer disabling other > themes as a default (I have no data and might be completely off). > However, I think changing the docs to more accurately point out this
From Taha Aziz Ben Ali to ~grtcdr/pub
Hello Dominik, We already have a section in the manual (darkman.org) for this specific problem, it's under Tips > Disabling existing themes. I don't know if we should ship it as part of the package because if users wish to disable other themes through darkman, they are likely to want the same feature applied when they invoke `load-theme' independently. In that case, advising `load-theme' to disable all themes before applying the new one is arguably the better solution, as we point out in the manual.
From Taha Aziz Ben Ali to ~filiplajszczak/patches
> Applied, thanks!
And thank you :)
Best regards,
--
Aziz