Felix Lechner via "Developers list for Guile, the GNU extensibility
library" writes:
> Hi Tomas,
>
> On Tue, Feb 04 2025, Tomas Volf wrote:
>
>> automatically decoding now would lead to double decoding.
>
> Will a second decoding step for HTML entities, which is the most likely
> workaround, mess
"Dr. Arne Babenhauserheide" writes:
>> I see few ways forward:
>>
>> 1. Document the current behavior and keep it as it is.
>> 2. Add argument #:decode-attributes, defaulting to #f, to the relevant
>>procedures, so that people can opt into the fixed behavior.
>> 3. Introduce parameter %decode
Hi Felix,
Felix Lechner via "Developers list for Guile, the GNU extensibility library"
writes:
> On Tue, Feb 04 2025, Tomas Volf wrote:
>> automatically decoding now would lead to double decoding.
>
> Will a second decoding step for HTML entities, which is the most likely
> workaround, mess up s
Tomas Volf <~@wolfsden.cz> writes:
> I think I found a bug in the htmlprag module in guile-lib. When parsing
> attributes, the values are not properly decoded:
Thank you for the report!
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use (htmlprag)
> s
Hi Tomas,
On Tue, Feb 04 2025, Tomas Volf wrote:
> automatically decoding now would lead to double decoding.
Will a second decoding step for HTML entities, which is the most likely
workaround, mess up strings like "a&b" or "bbb\"ccc'ddd" ?
Kind regards
Felix
Hello,
I think I found a bug in the htmlprag module in guile-lib. When parsing
attributes, the values are not properly decoded:
--8<---cut here---start->8---
scheme@(guile-user)> ,use (htmlprag)
scheme@(guile-user)> (html->sxml "")
$1 = (*TOP* (hr (@ (aaa "bb
