bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21536: Texi, Unicode and Emacs interface


From: Ludovic Courtès
Subject: bug#21536: Texi, Unicode and Emacs interface
Date: Thu, 24 Sep 2015 00:02:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Alex Kost <address@hidden> skribis:

> Evaluate there:
>
>   ((@@ (guix ui) texi->plain-text) "foo \u2015 bar.")
>
> So far so good.
>
> 2. Now connect to it, either with:
>
>    - netcat: "netcat localhost 37146"
>
>    - or Geiser: "M-x connect-to-guile"
>
> and evaluate the same expression.  This time you will get the error.

The encoding error comes from the fact that ‘texi->plain-text’ uses a
string port, and string ports internally use the current locale encoding
or ‘%default-port-encoding’.

Consequently, when running in the “C” locale, string ports cannot
represent non-ASCII code points (something widely regarded as a bug in
Guile, and at the very least an annoyance.)

To work around that, you can type this in *Guix Internal REPL*:

  (fluid-set! %default-port-encoding "UTF-8")

I fixed in commit 2cad18a8 of guix-artwork.git, but perhaps a similar
hack is apparently needed elsewhere.

Could you test this patch:

diff --git a/guix/ui.scm b/guix/ui.scm
index 4a3630f..67dd062 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -803,7 +803,10 @@ converted to a space; sequences of more than one line 
break are preserved."
 
 (define (texi->plain-text str)
   "Return a plain-text representation of texinfo fragment STR."
-  (stexi->plain-text (texi-fragment->stexi str)))
+  ;; 'texi-fragment->stexi' uses a string port so make sure it's a
+  ;; Unicode-capable one (see <http://bugs.gnu.org/11197>.)
+  (with-fluids ((%default-port-encoding "UTF-8"))
+    (stexi->plain-text (texi-fragment->stexi str))))
 
 (define (package-description-string package)
   "Return a plain-text representation of PACKAGE description field."
> BTW, since we now use texi for the package descriptions, does it mean
> that our intention is to get rid of using unicode symbols directly?

Not particularly.

Thanks,
Ludo’.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]