I see my reply failed to address some of the points raised. David Kastrup <d...@gnu.org> 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 > port will not report the string index of the string connected to the > string port but rather a byte index into a UTF-8 encoded version of the > string. This is a number that has nothing to do with the original > string and cannot be used for correlating string and port. Right. > Ports fundamentally deliver characters, and so reading and writing from > a string source/sink should not involve _any_ coding system. > > Files fundamentally deliver bytes, a conversion is required. The same > would be the case when opening a port on a _bytevector_. Here an > encoding would make equally make sense, and ftell/fseek offsets would > naturally be in bytes. But a port on a string delivers and consumes > characters. Any conversion, even a fixed UTF-8 conversion, will destroy > the predictable nature of with-output-to-string and > with-input-from-string and the respective uses of string ports. Guile ports can be mixed textual/binary (unlike R6 ports, which are either textual or binary.) Thus, they fundamentally deliver bytes, possibly with a textual conversion. Although the manual isn’t clear about it, ‘ftell’, when available, returns a position in bytes. The situation for string ports here is comparable to that of other ports used for textual I/O. Do you have a situation where you were relying on 1.8’s behavior in that regard? Could we see whether this can be solved differently? Thanks, Ludo’.
