insert umlaut

insert umlaut

[Stefan Vollmar]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Hi,

I am using an elisp insert statement to put text into a newly generated buffer, this text contains a German Umlaut. The text is displayed correctly in my .emacs-file, I also have a (prefer-coding-system 'utf-8) statement.

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?

Many thanks in advance.
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







[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4409 bytes --]

Re: insert umlaut

[Stefan Vollmar]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Hi,

if I use 

(insert (string-make-multibyte "Umlaut: ü"))

it now works with Emacs 23.2 (Windows). However, the question remains why "string-make-multibyte" is apparently not required when using Aquamacs 2.0 (Emacs 23.2) and with Emacs 23.1 (Ubuntu). The Windows version assumes a different encoding for the insert text?

Warm regards,
 Stefan


On 07.06.2010, at 10:30, Stefan Vollmar wrote:

> Hi,
> 
> I am using an elisp insert statement to put text into a newly generated buffer, this text contains a German Umlaut. The text is displayed correctly in my .emacs-file, I also have a (prefer-coding-system 'utf-8) statement.
> 
> 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?
> 
> Many thanks in advance.
> 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







[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4409 bytes --]

Re: insert umlaut

[Kevin Rodgers]

Stefan Vollmar wrote:
 > I am using an elisp insert statement to put text into a newly
 > generated buffer, this text contains a German Umlaut. The text is
 > displayed correctly in my .emacs-file, I also have a
 > (prefer-coding-system 'utf-8) statement.

Please show us the insert statement.

When visiting ~/.emacs, what does `C-h C RET' display?

When point is before the umlaut character in the insert statement,
what does `C-u C-x =' display?

 > 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.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: insert umlaut

[Stefan Vollmar]

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

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







[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4409 bytes --]

Re: insert umlaut

[Kevin Rodgers]

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")

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: insert umlaut

[Stefan Vollmar]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

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.

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.

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







[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4409 bytes --]

Re: insert umlaut

[tomas]

-----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)?

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFMFGOABcgs9XrR2kYRAjBOAJ4zFLNJCzlWms7erzw6pTubNUkqYwCfWG5j
FymGZhOLT3FutmuawzLIA94=
=Wj0i
-----END PGP SIGNATURE-----

Re: insert umlaut

[Stefan Vollmar]

[-- Attachment #1: Type: text/plain, Size: 5422 bytes --]

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







[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4409 bytes --]