Re: PARI/GP for Windows doesn't support umlauts and diacritical signs but it's possible

[Jens Schmidt <crashdump@meine-dateien.info>]

Bill Allombert schrieb:
> On Fri, Apr 21, 2017 at 11:39:00AM +0200, Jens Schmidt wrote:
>> There is another related? effect with readline and colors in Windows
>> (not only in Wine).
>>
>> To test this start clean PARI/GP without any preloaded defaults in a
>> windows console:
>>
>>   gp -f
>>   default(prompt, "gp >")
>>   default(colors, brightfg)
>>   default(readline, 0)
>>
>> The white prompt switches to yellow color and brightness on. Now type:
>>
>>   default(readline, 4)
>>
>> The prompt switches back to white color and brightness off. This
>> should'nt happen.
> 
> This is a know issue. The default Windows terminal does not handle
> ANSI color sequences, so we use a function win32_ansi_fputs()
> in src/systems/mingw/mingw.c that parses the color code and sets the
> terminal color using SetConsoleTextAttribute.
> 
> Unfortunately the prompt is printed directly by readline and we did
> not find a way to have readline use win32_ansi_fputs() or set the
> color correctly.
> 
> If you have a solution for this, please tell us.
> 
> Cheers,
> Bill.
> 

At least I found a workaround for all versions of Windows incl. Wine. No
code changes are required. Every user can do this to make special chars
working:

1. Create a file inputrc.txt in home directory with following contents:

  set convert-meta off
  set input-meta on
  set output-meta on

2. Set environment variable INPUTRC to the absolute path of inputrc.txt

Readline now functions (hopefully) as expected.

Nevertheless readlines "double call" to setlocale() in nls.c should be
fixed. 'man 3 setlocale' writes clearly

 "A program may be made portable to all locales by calling:
setlocale(LC_ALL, "");   after program initialization..."

A second call isn't required. An own setlocale() to circumvent possible
errors is kluge.

LG - Jens