Elijah Gabe Pérez <eg642616@gmail.com> writes:

> From 18ca5c6423a2c4e62ccb0073afec0de5e53bb091 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?El=C3=ADas=20Gabriel=20P=C3=A9rez?= <eg642616@gmail.com>
> Date: Sat, 29 Mar 2025 17:51:49 -0600
> Subject: [PATCH] Add color.el oklab functions
>
> * compat-30.el (color-oklab-to-xyz, color-xyz-to-oklab)
> (color-oklab-to-srgb, color-srgb-to-oklab): New functions.
>
> * compat-tests.el (compat-color-tests-oklab-to-xyz)
> (compat-color-tests-xyz-to-oklab, compat-color-tests-srgb-to-oklab)
> (compat-color-tests-oklab-to-srgb): New tests.
> ---

Daniel Mendler <mail@daniel-mendler.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I have recently been working on a older system with an older Emacs
>> (well, Emacs 27) and it is easy to get annoyed by the absence of certain
>> commands, first and foremost in my case `duplicate-dwim'.
>>
>> This made me wonder if a user-facing extension of Compat would be a
>> worthwhile project, of course as a separate package.  It wouldn't be
>> developed as a library and the user would have to install it on their
>> own.  This means we could also be more aggressive and bind commands
>> using a global minor mode.  From scraping a few NEWS files, I could at
>> least come up with a few ideas that might be/seem feasible to implement:

I have recently been working on a older system with an older Emacs
(well, Emacs 27) and it is easy to get annoyed by the absence of certain
commands, first and foremost in my case `duplicate-dwim'.

This made me wonder if a user-facing extension of Compat would be a
worthwhile project, of course as a separate package.  It wouldn't be
developed as a library and the user would have to install it on their
own.  This means we could also be more aggressive and bind commands
using a global minor mode.  From scraping a few NEWS files, I could at
least come up with a few ideas that might be/seem feasible to implement:

** New commands 'unix-word-rubout' and 'unix-filename-rubout'.
*** New command 'diff-kill-ring-save'.

Mario Liguori <mario.liguori.056@gmail.com> writes:

> Hi Philip,
>
> Apologies for resurrecting this thread. 

Nothing wrong with that :)

>                                         I started from
> https://www.emacswiki.org/emacs/SetupEl#h5o-25, and also tried
> https://www.emacswiki.org/emacs/SetupEl#h5o-26. Essentially, I explored
> both approaches: adding a wrapper function to setup-modifier-list (though
> I’m appending the function to the list) and defining a custom macro. I’ve
> encountered a few caveats with the wrapper function from EmacsWiki that I’d

Ralf Schmitt <ralf@systemexit.de> writes:

> Hi,
>
> I did run into a problem with compiling emacs from git with an included
> setup.el using a nix flake.
>
> The build bails out with the following error:
>
> ,----
> |  Extracting...done
> |   INFO     Scraping 2 files for loaddefs...
> |   INFO     Scraping 2 files for loaddefs...done
> |   GEN      setup-autoloads.el

Okamsn <okamsn@protonmail.com> writes:

> Philip Kaludercic wrote:
>>>  From 45c5ad4e4ad251256eb70f8f6b5a18285512a737 Mon Sep 17 00:00:00 2001
>>> From: Earl Hyatt <okamsn@protonmail.com>
>>> Date: Fri, 6 Sep 2024 19:50:38 -0400
>>> Subject: [PATCH] Add primitive type checking to `:option`.
>>>
>>> The new `setopt` macro in Emacs 29 can perform a basic check to see whether
>>> the value being used matches the variable's customization type.  Use that logic
>>> for the `:option` Setup macro if `setopt` is not defined, otherwise use `setopt`
>>> directly.
>>> ---
>>>   setup.el | 19 +++++++++++++++----

Okamsn <okamsn@protonmail.com> writes:

> Philip Kaludercic wrote:
>>> Hello,
>>>
>>> Would you be open to adding the primitive type checking that `setopt`
>>> does to `:option`?  I added it in a local version, and it and `setopt`
>>> have been helpful in finding errors and mistakes in my config. It is
>>> convenient to have the type checking while keeping the convenience of
>>> Setup's setters, such as `append*`.
>>>
>>> I can provide a patch file, if you are interested.
>> 
>> Sure!  But couldn't we just re-use setup on newer versions?

Okamsn <okamsn@protonmail.com> writes:

> Philip Kaluderic <philipk@posteo.net> writes:
>  > Zachary D'Anthony <zdm@disroot.org> writes:
>  >
>  > > Greetings,
>  >
>  > Hi,
>  >
>  > > I was looking over your emacs init file and noticed you never use the
>  > > local macro `:option' for setting custom variables, but rather use
>  > >
>  > >   (setopt ...)
>  > >

First of all, sorry for the delay in responding to your message.  My
inbox has been overflowing for a while, and I am trying to remedy that.

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> ---
> This works and is tested on Emacs 28. Only difference from V2 is the
> derived-mode-p stuff in autocrypt.el. And I'm writing 100 times on the
> blackboard tonight: "Test before send, not test after send".
>
>  README.md            |  1 +
>  autocrypt-notmuch.el | 93 ++++++++++++++++++++++++++++++++++++++++++++
>  autocrypt.el         |  1 +
>  3 files changed, 95 insertions(+)

Visuwesh <visuweshm@gmail.com> writes:

> [புதன் ஜூலை 17, 2024] Philip Kaludercic wrote:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>>> Good day, Philip!
>>
>> Hi,
>>
>>> The regexp used in shell-command+-expand-% seems to falsely replace all
>>> "\ " with the filename.  To reproduce,
>>>
>>>     1. M-! touch "/tmp/file with space" RET