Re: [Maxima-discuss] Issue with input line for macintosh

[Joseph O'L. <jos...@gm...>]

Hello there guys,
Just an update on this issue. I also found that if I type a greater than >
it comes up as an upside question mark. I'm not sure if this helps at all
but another piece to the puzzle.
Cheers,
J.

On Thu, Dec 29, 2016 at 4:55 PM, Gunter Königsmann <gu...@pe...>
wrote:

> Character encoding issues do ring a bell for me:
>  - Mac computers traditionally use LF (ASCII code 10) as line endings
>  - Windows computers use CR LF (13 10)
>  - Linux uses CR only (ASCII 13)
> ...and by default for any non-standard-american characters Windows by
> default uses a codepage (which means it assigns all commonly used
> characters in the current language an 8-bit-numer) while the rest of the
> operating systems uses unicode (which mean that non-standard-ASCII
> characters will need more bytes which is bad for SMS, but at least allows
> to express greek, cyrillic and latin characters in the same document).
>
> If you use your own .mac or .wxm files as libraries for maxima's load()
> type of commands that means it is safer not to use any non-ASCII characters
> in them. Even comments might cause character encoding errors even if the
> contents of a comment are otherwise  being ignored by maxima. And I assume
> the same to be true for files created with save(). There might be no easy
> way out oof this: The lisps maxima run with allow to set any character
> encoding that might commonly be in use - but any of them might be a bad
> solution for your specific case;
> If you use a recent version of wxMaxima and .wxmx files instead I have
> spent considerable time for making everything being Unicode-compatible. If
> you found an error there please report it at https://github.com/andrejv/
> wxmaxima/issues.
> The only known issue that remains curently is that on windows non-unicode
> characters in the directory the current file lies in will cause maxima to
> output an error message as it cannot change the current working directory
> to the current dir. Unfortunately on windows the default home directory
> location contains non-ascii characters in many languages and the same is
> true if the user name of the current user contains non-ascii characters. In
> theory setting the default character encoding to UTF-8 should be a remedy
> for this. But at least with current SBCL this doesn't seem to be the
> case... ...again I have no idea what to do in this case. But at least the
> reading from .wxmx files from network shares or unicode paths should have
> started working by now.
>
> Kind regards,
>
>       Gunter.
>