more about build-index+cl-ppcre branch & encodings

On 3/5/11, Leo Butler <l.butler at ed.ac.uk> wrote:

> I've patched that, and a few things Ray mentioned in this
> thread. I now see what appears to be the correct characters
> for both encodings and all languages and lisps in clisp, cmucl
> and sbcl and on both an xterm and gnome-terminal (debian testing
> & ubuntu 10.04 less cmucl).
>
> To be clear, with revision b5805315e8 in a freshly cloned
> repo, I execute:
>
>  ./bootstrap && \
>  ./configure --enable-sbcl --enable-clisp --with-default-lisp=sbcl \
>  --program-suffix=-post-5.23 --enable-all-lang && \
>  make && \
>  cd tests && \
>  perl ./rtest-build-index.pl -verbose=1 -run_rtest_build_index=true \
>  -lisps=sbcl:clisp #:cmucl

Works for me, but I had to update makeinfo (texinfo package)
to 4.13, which generates UTF-8 characters when the
documentencoding is UTF-8. (Makeinfo from texinfo 4.11
generates ASCII approximations such as c, for cedilla.)

I'm not too crazy about updating makeinfo. I suspect the
existing Makefile machinery in doc/info/* which calls recode or
iconv after generating ISO-8859 maxima.info files is a
workaround for the inability of pre-4.13 makeinfo versions to
actually generate UTF-8. Maybe instead of fudging the
documentencoding in maxima.texi, we could
s/coding: iso-8859-1/coding: utf-8/ in maxima.info* instead.
That would make the declared encoding match the actual
without requiring an update for makeinfo.

I like the idea of using a Lisp-based system to generate the
help index, although I'm not convinced that the extra gyrations
to explicitly track the encoding for an ordinary Maxima
session are an improvement. (It is necessary to track the
encoding when generating the indices since the maxima.info
files have different encodings.)

FWIW

Robert Dodier