german umlauts vs. meta key

german umlauts vs. meta key

[Andreas Goesele]

Hi,

I'm in the process of moving from XEmacs to Emacs, but I encountered a
problem:

To be able to input german umlauts directly I have in my init.el:

 (progn
 (apply 'set-input-mode t (list (nth 1 (current-input-mode)))
 0 (list (nth 3 (current-input-mode))))
 )
 )

This worked fine under XEmacs.

Under Emacs it enables me to indeed directly input the umlauts, but it
disables all key combinations which use C-s or C-q. (I use emacs -nw
in an xterminal, namely KDE konsole.)

http://user.cs.tu-berlin.de/~eserte/FreeBSD/doc/umlaute/umlaute.txt
explains the problem as a conflict between umlauts and the meta key:
Supposedly the code above disables the meta key and thus enables the
input of umlauts. What I don't understand though, is that in my case
with this code the meta key (alt-left) is working, and only C-s and
C-q don't work.

An alternative to the code above would be (again according to the
website above) the following code:

     (global-set-key "\M-d"  'my-insert-ae)
     (global-set-key "\M-D"  'my-insert-Ae)
     (global-set-key "\M-v"  'my-insert-oe)
     (global-set-key "\M-V"  'my-insert-Oe)
     (global-set-key "\M-|"  'my-insert-ue)
     (global-set-key "\M-\\" 'my-insert-Ue)
     (global-set-key "\M-_"  'my-insert-ss)
     (defun my-insert-ae () (interactive) (insert "a:"))
     (defun my-insert-Ae () (interactive) (insert "A:"))
     (defun my-insert-oe () (interactive) (insert "o:"))
     (defun my-insert-Oe () (interactive) (insert "O:"))
     (defun my-insert-ue () (interactive) (insert "u:"))
     (defun my-insert-Ue () (interactive) (insert "U:"))
     (defun my-insert-ss () (interactive) (insert "ss"))

This code again indeed allows me to input the defined umlauts, but
disables M-v and M-d (which are of rather common use - I don't mind
the loss of M-\\ and such).

Another explanation of the problem I found is that under the console
C-s disables input and C-q reenables it - which indeed is the case,
but doesn't make much sense under a xterminal, does it? (XEmacs does
not interpret C-s and C-q this way.)

Is it possible to make umlauts work in emacs under a xterminal
(konsole) and using C-s, C-q, M-d, M-v etc. in the "normal" emacs way?

Thanks a lot in advance!

Andreas

Re: german umlauts vs. meta key

[Peter Dyballa]

Am 29.02.2008 um 08:46 schrieb Andreas Goesele:

> I'm in the process of moving from XEmacs to Emacs, but I encountered a
> problem:


Which prehistoric version of GNU Emacs are you trying to use? Up-to- 
date version 22.1 accepts German umlauts directly from the keyboard,  
it even can handle Unicode. No particular input method is needed. And  
the URL you gave is out of time, part of a museum.

You could try this behaviour by launching GNU Emacs with the -Q  
argument. Then no init will be loaded and you could insert whatever  
you want directly into the *scratch* buffer, for example. You might  
also think of customising X11 such that your keyboard emits  
particular characters (€ for example) when holding the alt key. So in  
case you're using a keyboard with an US layout, alt-# or such could  
produce ä.

Modern Emacsen read the environment variable LC_CTYPE and try to  
setup a preference for a particular encoding default, for example ISO  
8859-15 or UTF-8.


> Another explanation of the problem I found is that under the console
> C-s disables input and C-q reenables it - which indeed is the case,
> but doesn't make much sense under a xterminal, does it? (XEmacs does
> not interpret C-s and C-q this way.)


How can it? It's the terminal that steals the input event which was  
passed to it via X11. If the terminal emulation has no use for a  
certain input it passes it further to some shell interpreter or  
programme running in it.

^S/^Q are part of the software handshake. Just switch it off with stty!


With Gnu Emacs from CVS (version 23.0.60) you can make use of the  
multi-tty patch: one GNU Emacs client is running in X11, Emacs server  
started, and in every terminal window you can have access to GNU  
Emacs by invoking 'emacsclient -t'. In Mac OS X (partly FreeBSD  
based) this give *me* a problem when I isearch for a German umlaut in  
a file's name: HFS+ saves it decomposed, i.e. I would need to search  
for o¨ instead of ö, or such ...

--
Mit friedvollen Grüßen

   Pete

Got Mole problems?
Call Avogadro 6.02 x 10^23

Re: german umlauts vs. meta key

[kl811af]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1894 bytes --]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Which prehistoric version of GNU Emacs are you trying to use?

21.4.1 (released 2005!)

> Up-to- date version 22.1 accepts German umlauts directly from the
> keyboard, it even can handle Unicode. No particular input method is
> needed.

At the moment unfortunately I can't move to that version.

> And the URL you gave is out of time, part of a museum.

But still valid for 21.4.1, isn't it.
 
> You could try this behaviour by launching GNU Emacs with the -Q
> argument. Then no init will be loaded and you could insert whatever
> you want directly into the *scratch* buffer, for example.

Under 21.4.1 this doesn't allow to input umlauts.

> You might also think of customising X11 such that your keyboard
> emits particular characters (ž  for example) when holding the alt
> key. So in case you're using a keyboard with an US layout, alt-# or
> such could produce ä.

Except for emacs in an xterminal I don't have problems to input
umlauts.

> > Another explanation of the problem I found is that under the console
> > C-s disables input and C-q reenables it - which indeed is the case,
> > but doesn't make much sense under a xterminal, does it? (XEmacs does
> > not interpret C-s and C-q this way.)
>  
> How can it? It's the terminal that steals the input event which was
> passed to it via X11. If the terminal emulation has no use for a
> certain input it passes it further to some shell interpreter or
> programme running in it.
> 
> ^S/^Q are part of the software handshake. Just switch it off with stty!

But in XEmacs and Emacs without the code snippet I need to input the
umlauts ^S/^Q work without problem the emacs way.

Thanks for you help and suggestions, but as I'm stuck with 21.4 I
still would like to have emacs to accept umlauts *and* all basic emacs
commands. Any suggestion?

Thanks again

Andreas

-- 
Andreas Goesele

Re: german umlauts vs. meta key

[Peter Dyballa]

Am 09.03.2008 um 02:52 schrieb kl811af:

>> You might also think of customising X11 such that your keyboard
>> emits particular characters (ž  for example) when holding the alt
>> key. So in case you're using a keyboard with an US layout, alt-# or
>> such could produce ä.
>
> Except for emacs in an xterminal I don't have problems to input
> umlauts.


So it's only a problem when you use GNU Emacs without X11 running in  
an XTerm on some Sun OS version?

What keeps you from using cmdtool? Another work-around would be to  
use emacsclient.


^S/^Q are a setting of your terminal emulation. Check its man page,  
check also stty and its man page.

--
Mit friedvollen Grüßen

   Pete

Build a man a fire and he'll be warm for a night, but set a man on  
fire and he'll be warm for the rest of his life.

Re: german umlauts vs. meta key

[Johan Bockgård]

Andreas Goesele <goesele@hfph.mwn.de> writes:

> Hi,
>
> I'm in the process of moving from XEmacs to Emacs, but I encountered a
> problem:
>
> To be able to input german umlauts directly I have in my init.el:
>
>  (progn
>  (apply 'set-input-mode t (list (nth 1 (current-input-mode)))
>  0 (list (nth 3 (current-input-mode))))
>  )

That's ugly and broken (there's one `list' call too many).

    ;; poor man's destructuring-bind
    (apply (lambda (interrupt flow meta quit)
             (set-input-mode interrupt flow 0 quit))
     (current-input-mode))

-- 
Johan Bockgård

Re: german umlauts vs. meta key

[goesele]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Andreas Goesele <goesele@hfph.mwn.de> writes:
> 
> > To be able to input german umlauts directly I have in my init.el:
> >
> >  (progn
> >  (apply 'set-input-mode t (list (nth 1 (current-input-mode)))
> >  0 (list (nth 3 (current-input-mode))))
> >  )
> 
> That's ugly and broken (there's one `list' call too many).
> 
>     ;; poor man's destructuring-bind
>     (apply (lambda (interrupt flow meta quit)
>              (set-input-mode interrupt flow 0 quit))
>      (current-input-mode))

Many thanks. That code solved my problem!

Andreas

-- 
Andreas Goesele