Re: [h-e-w] Accents in environment variables - HOME

[Jason Rumney]

Benjamin Riefenstahl <address@hidden> writes:

> I did some testing.  The problem seems to be the call to
> GetEnvironmentStrings() in runemacs.c.  For some reason,
> GetEnvironmentStrings() returns an "OEM" encoded memory block, while
> CreateProcess() expects the block to be "ANSI" encoded.  As passing
> GetEnvironmentStrings() directly is equivalent to passing NULL here
> anyway, leaving the call out altogether works and is probably the best
> (see attached one-line patch).

This was the same conclusion I reached, but I had not tested it
yet. Thank you.

> With this change, locale-coding-system == windows-1252 should be the
> right choice.  Actually this should be set from a call to the GetACP()
> API directly or indirectly (I haven't checked the source, so this may
> already be so in CVS).

locale-coding-system is iso-8859-1 in such locales by default, since
windows-1252 is not supported at startup (it requires codepage.el to
be loaded), and there is no generic way to map the results of GetACP()
to Emacs coding-systems.

> > [locale-coding-system]
> 
> It's not clear to me what is covered by locale-coding-system besides
> environment variables?  Documentation for the variable says "system
> messages", what does that mean?

I don't know what it is used for beyond environment variables, and
font names on Windows. But it is used on other platforms, so maybe
"system messages" is relevant elsewhere.

> And why doesn't it mention environment variables there?

It may not be consistent across platforms (I don't know).

> like Michelle, I also would have expected that (getenv) and (setenv)
> do the necessary conversions automatically.

The conversion is done when the environment is read at startup. So if
the conversion fails in the first place, changing
locale-coding-system will not affect it.