Thanks for the report!

I have pushed a fix for this and an other issue to the "work" branch.
LLama now handle dotted lists properly (not just cons-cells), and it
skips quoted lists.  (I.e., both of these fixes would have addressed
the test-case you provided, but they are really to separate issues.)

I've also dropped the dependency on seq and the and-let* macro.

I'll have to test these changes a bit before merging into "main".
Who knows, I might even find the time to write some proper tests.
Meanwhile, please give it a try too.

Joseph Turner <joseph@ushin.org> writes:

> Thanks for this branch, Jonas!
>
> I merged

That was slightly premature.  No harm done, probably, but I would have
read through the commits again, to make sure I didn't mess anything up.

(I guess I should have used the "wip/" prefix.  Will do that next time,
but I didn't expect you to act this quickly.)

> How much of this work were you able to automate?

Joseph Turner <joseph@ushin.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> Sounds like you prefer the colon separators, and Joseph and I are both
>>> fine with that.  So if it helps, let that be the decision (for now,
>>> anyway).  :)
>>
>> Uhm, I really don't want to impose my preference here.  It's two to one
>> (with one abstain).  I am totally fine with whatever Joseph chooses,
>> it's not like I think using "/" is wrong or anything.

Joseph Turner <joseph@ushin.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
> [...]
>
>> Looks good.
>>
>> And I learned something new; I was unaware of `format-message'.
>>
>> I wish `yes-or-no-p' and `y-or-n-p' took a format string (and passed
>> it through `format-message' internally).
>
> Yes, that would be nice.

Joseph Turner <joseph@ushin.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> While we are on the subject of format strings, I though I would bring up
>> the following points:
>>
>> (a)
>> As a Swiss, I have noticed the use of «guillemets» [1] with some
>> amusement.  However, this is problematic because they cannot be
>> displayed in all terminals.  Some users might also find them noisy
>> and thus distracting.
>>
>> Emacs makes the used quotation marks customizable through

While we are on the subject of format strings, I though I would bring up
the following points:

(a)
As a Swiss, I have noticed the use of «guillemets» [1] with some
amusement.  However, this is problematic because they cannot be
displayed in all terminals.  Some users might also find them noisy
and thus distracting.

Emacs makes the used quotation marks customizable through
`text-quoting-style'.  Unfortunately the available options are
very anglocentric, so we cannot actually use «guillemets».

Joseph, since you like these enough to hard-code them in your own

> [use] the Emacs 29 format-spec lambda specification feature
> to allow format-spec to recurse without falling into an infinite loop.

Wouldn't this kludge achieve the same thing?:

       (format-spec format
-                   `((?H . ,(lambda ()
-                              (hyperdrive--preferred-format hyperdrive)))
+                   `((?H . ,(and (string-match-p "%H" format)
+                                 (hyperdrive--preferred-format hyperdrive)))

Of course "%H" would have to extended to support all of
"%<flags><width><precision>character".

> I don't know if
> that clarity is worth deprecating Emacs 28 just yet. :)

I haven't studied the change in detail yet but it would have to be the
best thing since sliced bread to justify dropping support for Emacs 28
this soon after the release of Emacs 29.

Luckily we have some other options.

- It seems unlikely that the updated format-spec would be added to the
  Compat package.  Its documentation already contains a note that some
  additional modifiers added in Emacs 27 *not* being supported.  I think
  it also is against its policy to backport this kind of change.

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

> Hi Jonas!
>
> On 9/19/23 17:38, Jonas Bernoulli wrote:
>> I was surprised to learn that `pcase-setq' isn't implemented.
>> The manual mentions that it is not implemented, but not why.
>> 
>> Please (re-)consider adding it.
>
> Additional pcase features and pcase-setq are too complicated to port
> back via Compat. I made a quick attempt a while back in the
> feature/pcase branch, which resulted in a lot of code and which didn't
> work. I've asked Stefan Monnier if making pcase available as a :core

Hello

I was surprised to learn that `pcase-setq' isn't implemented.
The manual mentions that it is not implemented, but not why.

Please (re-)consider adding it.

     Thanks!
     Jonas