Mark H Weaver writes:
> David Kastrup writes:
>
>> In Guile 2.0, at the time a string port is opened, the value of the
>> fluid %default-port-encoding is used for deciding how to encode the
>> string into a byte stream, [...]
>
> I agree that this was a mistake. The issue is fixed on the master
David Kastrup writes:
> In Guile 2.0, at the time a string port is opened, the value of the
> fluid %default-port-encoding is used for deciding how to encode the
> string into a byte stream, [...]
I agree that this was a mistake. The issue is fixed on the master
branch.
> Ports fundamentally d
David Kastrup skribis:
> I stated quite definitely that I am perfectly capable of dealing with
> the mess GUILE made of string ports.
Good to know, this was not my understanding until now.
The intent of the change in 2.2 is to hide the very fact that string
ports “have an encoding.” So from th
l...@gnu.org (Ludovic Courtès) writes:
> Does this help for LilyPond?
I stated quite definitely that I am perfectly capable of dealing with
the mess GUILE made of string ports. The issue is that I should not
have to, nor should anybody else.
This issue _is_ _not_ _about_ _LilyPond_. Working on
David Kastrup skribis:
> They result in code like
>
> // we do our own utf8 encoding and verification in the parser, so we
> // use the no-conversion equivalent of latin1
> SCM str = scm_from_latin1_string (c_str ());
> scm_dynwind_begin ((scm_t_dynwind_flags)0);
> // Why doesn't scm_se
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> David Kastrup skribis:
>>>
> Line/column info remains identical regardless of the encoding, so I tend
> to think it’s more robust to use that.
Column info remains
David Kastrup skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup skribis:
>>
Line/column info remains identical regardless of the encoding, so I tend
to think it’s more robust to use that.
>>>
>>> Column info remains identical regardless of the encoding? Since when?
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>>> Line/column info remains identical regardless of the encoding, so I tend
>>> to think it’s more robust to use that.
>>
>> Column info remains identical regardless of the encoding? Since when?
>
> The character on line L and co
David Kastrup skribis:
>> Line/column info remains identical regardless of the encoding, so I tend
>> to think it’s more robust to use that.
>
> Column info remains identical regardless of the encoding? Since when?
The character on line L and column M is always there, regardless of
whether the
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> David Kastrup skribis:
For error messages, yes. For associating a position in a string with a
previously parsed closure, no.
>>>
>>> But wouldn’t a line/column pair
David Kastrup skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup skribis:
>>>
>>> For error messages, yes. For associating a position in a string with a
>>> previously parsed closure, no.
>>
>> But wouldn’t a line/column pair be as suitable as a unique identifier as
>> the pos
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>>
>> For error messages, yes. For associating a position in a string with a
>> previously parsed closure, no.
>
> But wouldn’t a line/column pair be as suitable as a unique identifier as
> the position in the file?
As long as the
David Kastrup skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup skribis:
>>
>>> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
>>> own UTF-8 verification, error flagging, processing and indexing.
>>
>> Do I understand correctly that LilyPond expects Guil
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
>> own UTF-8 verification, error flagging, processing and indexing.
>
> Do I understand correctly that LilyPond expects Guile strings to be byte
> vectors, wh
David Kastrup skribis:
> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
> own UTF-8 verification, error flagging, processing and indexing.
Do I understand correctly that LilyPond expects Guile strings to be byte
vectors, which it can feed with UTF-8 byte sequences that it
l...@gnu.org (Ludovic Courtès) writes:
> This has been addressed in two ways:
No, it hasn't.
> 1. In 2.0, (srfi srfi-6) uses Unicode-capable string ports (commit
> ecb48dc.)
This issue report is not about adding more optional functionality on
top. It is about _removing_ unwarranted redi
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
>> consistently (I guess, overriding set-port-encoding! will again change
>> that).
>>
>> That still is not satisfactory. For example, using ftell on the input
>>
I see my reply failed to address some of the points raised.
David Kastrup skribis:
> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
> consistently (I guess, overriding set-port-encoding! will again change
> that).
>
> That still is not satisfactory. For example, using ftell on
This has been addressed in two ways:
1. In 2.0, (srfi srfi-6) uses Unicode-capable string ports (commit
ecb48dc.)
2. In 2.2, string ports are always Unicode-capable, and
‘%default-port-encoding’ is ignored (commit 6dce942.)
So for 2.0, the workaround is to either use (srfi srfi-6),
In Guile 2.0, at the time a string port is opened, the value of the
fluid %default-port-encoding is used for deciding how to encode the
string into a byte stream, and set-port-encoding! may then be used for
deciding how to decode that byte stream back into characters.
This does not make sense as
20 matches
Mail list logo
