Re: insert umlaut

[Stefan Vollmar]

Dear Tomas,

On 13.06.2010, at 06:50, tomas@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, Jun 12, 2010 at 11:55:49AM +0200, Stefan Vollmar wrote:
>> Dear Kevin,
>> 
>> On 12.06.2010, at 08:10, Kevin Rodgers wrote:
>> 
>>> Stefan Vollmar wrote:
>>>> Dear Kevin,
>>>> On 09.06.2010, at 05:43, Kevin Rodgers wrote:
>>>>> Please show us the insert statement.
>>>> (insert "Umlaut: ü")
>>> 
>>> What happens if you use a coding-system independent representation
>>> in your ~/.emacs:
>>> 
>>> (insert "Umlaut: \u00FC")
>> 
>> 
>> It works with the \u00FC representation, so this is another solution in 
>> addition to using (string-make-multibyte "ü"), probably very similar in 
>> effect.
> 
> What is the coding system of the elisp file itself (i.e. where the source of 
> this
> statement lives)?


I think that question has already been answered, see below. Also take into 
account that this appears to be dependent on whether the insert takes place in 
site-lisp/site-start.el (while starting) or whether Emacs has already started 
completely:

> From: Stefan Vollmar <vollmar@nf.mpg.de>
> Date: 12. Juni 2010 11:55:49 MESZ
> To: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: insert umlaut
[...]
> However, here is an interesting observation: that insert statement is used in 
> a site-lisp/site-start.el file. It produces the mentioned problem when Emacs 
> is started. If, in contrast, Emacs is running and I do a load-file of 
> site-start.el then, 
> 
> (insert "Umlaut: ü")
> 
> will work exactly as observed on recent versions of Emacs on MacOS and Linux.

The other Email I was referring to:

> From: Stefan Vollmar <vollmar@nf.mpg.de>
> Date: 9. Juni 2010 08:01:48 MESZ
> To: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: insert umlaut
> 
> Dear Kevin,
> 
> On 09.06.2010, at 05:43, Kevin Rodgers wrote:
> 
>> Please show us the insert statement.
> 
> (insert "Umlaut: ü")
> 
>> When visiting ~/.emacs, what does `C-h C RET' display?
> 
> * Emacs 23.2.1 Windows Server Enterprise 2007 (German)
> 
> Coding system for saving this buffer:
>  - -- undecided-dos (alias: dos)
> [...]
> Coding system for terminal output:
>  nil
> Coding system for inter-client cut and paste:
>  U -- utf-16le-dos
> Defaults for subprocess I/O:
>  decoding: U -- utf-8-dos (alias: mule-utf-8-dos)
> [...]
>  Process I/O  "[pP][lL][iI][nN][kK]"  (undecided-dos . undecided-dos)
>                               "[cC][mM][dD][pP][rR][oO][xX][yY]"
>               (undecided-dos . undecided-dos)
> 
> 
> * Aquamacs 2.0 Mac (English)
> 
> Coding system for saving this buffer:
>  - -- undecided-unix (alias: unix)
> [...]
> Coding system for terminal output:
>  U -- utf-8-unix (alias: mule-utf-8-unix)
> Coding system for inter-client cut and paste:
>  nil
> Defaults for subprocess I/O:
>  decoding: U -- utf-8-unix (alias: mule-utf-8-unix)
> [...]
>  Process I/O  nothing specified
> 
>> When point is before the umlaut character in the insert statement,
>> what does `C-u C-x =' display?
> 
> * Emacs 23.2.1 Windows Server Enterprise 2007 (German)
> 
>        character: ü (252, #o374, #xfc)
> preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1))
>       code point: 0xFC
>           syntax: w   which means: word
>         category: .:Base, c:Chinese, j:Japanese, l:Latin
>      buffer code: #xC3 #xBC
>        file code: #xC3 #xBC (encoded by coding system utf-8-unix)
>          display: by this font (glyph code)
>    uniscribe:-outline-Courier 
> New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x81)
> 
> Character code properties: customize what to show
>  name: LATIN SMALL LETTER U WITH DIAERESIS
>  old-name: LATIN SMALL LETTER U DIAERESIS
>  general-category: Ll (Letter, Lowercase)
>  decomposition: (117 776) ('u' '̈')
> 
> There are text properties here:
>  face                 font-lock-string-face
>  fontified            t
> 
> 
> The Aquamacs output is identical, except for the line that says "uniscribe" 
> on Windows, it says:
> 
>    nil:-apple-Monaco-medium-normal-normal-*-12-*-*-*-m-0-iso10646-1 (#x81)
> 
>>> With Emacs 23.2 (Windows) the Umlaut is not displayed correctly (in
>>> the newly generated buffer), with Aquamacs 2.0 it works just
>>> fine. With both Emacsen, the .emacs-file yields "utf-8-unix" in the
>>> modeline and "utf-8" for the newly created buffer.
>>> 
>>> Is this a bug or is it a coincidence that this works in Aquamacs?
>> 
>> There are a lot of variables to account for between the 2 platforms and
>> the 2 Emacs versions.
> 
> And so it seems. The problem can probably be explained by the above the 
> differences in the default coding systems, interesting.
> 
> Warm regards,
> Stefan

-- 
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleuelerstr. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213  FAX +49-221-4726-298
Tel.: +49-221-478-5713  Mobile: 0160-93874279
Email: vollmar@nf.mpg.de   http://www.nf.mpg.de







-- 
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleuelerstr. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213  FAX +49-221-4726-298
Tel.: +49-221-478-5713  Mobile: 0160-93874279
Email: vollmar@nf.mpg.de   http://www.nf.mpg.de

smime.p7s
Description: S/MIME cryptographic signature