Erlangen, Bavaria
From Philip Kaludercic to ~pkal/elpa-zine
Yuan Fu <casouri@gmail.com> writes: >> 1. How should the zine published (website, news feed, round-mail, video, >> some other format or service) >> > I think a static website plus feed should be more than enough. That would be my feeling as well. >> 2. Is it necessary to automate the announcement of new packages and >> updates, or would be sufficient to do so manually on a regular basis? >> (It would be conceivable to get upstream support for this). >> > IMO the major characteristic/contribution of such a zine would be
From Philip Kaludercic to ~pkal/elpa-zine
To anyone interested in participating, all questions are open to discussion, e.g: 1. How should the zine published (website, news feed, round-mail, video, some other format or service) 2. Is it necessary to automate the announcement of new packages and updates, or would be sufficient to do so manually on a regular basis? (It would be conceivable to get upstream support for this). 3. What should the goals and the theme of the project be? My proposal has been to more extensively highlight new packages and mention what
From Philip Kaludercic to ~pkal/public-inbox
ping? Philip Kaludercic <philipk@posteo.net> writes: > Trey Peacock <git@treypeacock.com> writes: > >> "Philip Kaludercic" <philipk@posteo.net> writes: >> >>> I get the impression that cl-defmacro is too great of an overhead here >>> -- especially when we consider loading the necessary files during >>> initialisation. `Setup' is relatively fast, and if there is a more >>> efficient/lightweight way then I think it would be preferable. >>> Dispatching ensure-specs could also be done using an alist mapping >>> symbols to functions.
From Philip Kaludercic to ~pkal/public-inbox
Trey Peacock <git@treypeacock.com> writes: > "Philip Kaludercic" <philipk@posteo.net> writes: > >> I get the impression that cl-defmacro is too great of an overhead here >> -- especially when we consider loading the necessary files during >> initialisation. `Setup' is relatively fast, and if there is a more >> efficient/lightweight way then I think it would be preferable. >> Dispatching ensure-specs could also be done using an alist mapping >> symbols to functions. > > That makes sense. There should be a new patch attached below. I'm not > extremely familiar with the email patch workflow, so I hope that is okay
From Philip Kaludercic to ~pkal/public-inbox
Trey Peacock <git@treypeacock.com> writes: > "Philip Kaludercic" <philipk@posteo.net> writes: > >> Hi, >> >> Trey Peacock <git@treypeacock.com> writes: >> >>> I currently use a modified versions of the keybinding macros that use >>> `keymap-set` and other functions found in `keymap.el`. This resulted in >>> an error thrown when trying to use the new `kbd` ensure keyword. "C-=" >>> can be set with `keymap-set`, but it will result an error in >>> `setup--ensure` with `(kbd "C-=")`. >>>
From Philip Kaludercic to ~pkal/public-inbox
Hi, Trey Peacock <git@treypeacock.com> writes: > I currently use a modified versions of the keybinding macros that use > `keymap-set` and other functions found in `keymap.el`. This resulted in > an error thrown when trying to use the new `kbd` ensure keyword. "C-=" > can be set with `keymap-set`, but it will result an error in > `setup--ensure` with `(kbd "C-=")`. > > So, I figured it may be useful to allow for custom ENSURE-SPECs. The > implementation below uses `cl-defgeneric` to allow for custom methods; > however, if you do not want to rely on the `cl-lib` library, I have a
From Philip Kaludercic to ~pkal/public-inbox
Okamsn <okamsn@protonmail.com> writes: > Hello, > > I noticed that I failed to mention the setters `append*`, `prepend*`, > and `remove*` in the documentation string of the `:local-set` macro. > They were correctly added to the documentation string of the `:option` > macro. > > I have attached a patch to add them. Thanks! Will push the change. > I apologize for missing this the first time.
From Philip Kaludercic to ~pkal/public-inbox
Thanks, I pushed the patch! ~hilde <hilde@git.sr.ht> writes: > From: Hilde <hilde.rhyne@disroot.org> > > Fix typo in :with-feature definition, as per > https://lists.sr.ht/~pkal/public-inbox/%3Cm0edq8dqj7.fsf%40disroot.org%3E > --- > setup.el | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/setup.el b/setup.el > index d5e49be..229f324 100644
From Philip Kaludercic to ~pkal/public-inbox
Hilde Rhyne <hilde.rhyne@disroot.org> writes: > Hi Philip, Hi, > currently, :with-feature keyword doesn’t accept list argument, which > conflicts against its docstring, "If FEATURE is a list, apply BODY to all > elements of FEATURE." > > For example: > (setup foo > (:with-feature (prog-mode conf-mode) > (:bind "C-c u" #'bar)))
From Philip Kaludercic to ~pkal/public-inbox
Visuwesh <visuweshm@gmail.com> writes: >> The change makes sense, but this would raise the minimum version to >> 26.1. We could add Compat as a dependency to fix this, or just copy the >> compatibility version which isn't that complicated itself: >> >> (or (file-remote-p file 'localname) file) >> >> What do you think? > > Makes sense to me. Here's an updated patch with that change in place, Thanks, I applied it and also marked a new patch release.