Meta key, Alt key & ESC

Meta key, Alt key & ESC

[Bertram Scharpf]

Hi,

sorry, I could not find a documentation about this problem.

Under Debian/GNU Linux my Emacs Meta key is the one
between `Control_L' and `Alt_L'. But from SuSE
Linux I am used `Alt_L' to be the Meta key. Now I don't
want to change my Debian `.Xmodmap'; rather I want Emacs
to accept the `Alt_L' in one of the following manners:


A.

I examine my keystrokes using the command "C-h k"
(`descibe-key'). Typing

    C-h k <Alt>-a

      yields in                            under
      ---------                            -----
      "M-a runs the command ...."          SuSE
      "A-a is undefined"                   Debian/GNU

But I get

    $ xmodmap -pm | grep mod1
    mod1        Alt_L (0x40)
    $

in both cases!

So there must be a way to tell Emacs which modifier is the
Meta Key. How do I tell?


B.

My `/usr/X11R6/lib/X11/app-defaults/XTerm' contains
something like

--------------------------------------
XTerm*VT100.Translations: #override \
   Alt<KeyPress>Shift_L,Alt<KeyPress>: string(0x01B) insert() \n\
   Alt<KeyPress>Shift_R,Alt<KeyPress>: string(0x01B) insert() \n\
   Alt Ctrl <KeyPress>: string(0x01B) insert() \n\
   Alt      <KeyPress>: string(0x01B) insert()
--------------------------------------

(I didn't find a documentation about that either.)

Running Emacs in an XTerm as "emacs -nw" I get the following
results:

    Typing                           yields in
    C-h k <Meta>-a                   "M-a runs the command ...."
    C-h k ESC a                      "ESC a runs the command ...."
    C-h k <Alt>-a                    "ESC a runs the command ...."

but in the X-windowed Emacs still:

    C-h k <Alt>-a                    "A-a is undefined"

Is there a way letting Emacs take an <Alt> as an ESC-prefix
as XTerm does?

Thank you very much in advance for your answers.

Bertram

-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany

Re: Meta key, Alt key & ESC

[Kai Großjohann]

Bertram Scharpf <b.scharpf@tesionmail.de> writes:

> Under Debian/GNU Linux my Emacs Meta key is the one
> between `Control_L' and `Alt_L'. But from SuSE
> Linux I am used `Alt_L' to be the Meta key. Now I don't
> want to change my Debian `.Xmodmap'; rather I want Emacs
> to accept the `Alt_L' in one of the following manners:

Metaphorically speaking Emacs looks for Meta_L and/or Meta_R in the
output of "xmodmap -pm" and considers the modifier it finds there as
the meta modifier.  If there is no Meta_{L,R} in the output of
"xmodmap -pm" (metaphorically speaking), then Emacs looks for Alt_L
and Alt_R instead.

You say that you don't want to frob .Xmodmap.  Why not?  Maybe it's
because you don't want the key next to the spacebar to change (that
generates Alt_L I think).  So you could frob .Xmodmap to assign
another keysym (other than Meta_L), say Super_L or Hyper_L to the key
with a flag on it.  Then there will be no Meta_{L,R} in the output of
"xmodmap -pm", and so Emacs will use Alt_{L,R}.

If you really really REALLY do not want to change .Xmodmap, you can
consider installing Emacs from CVS.  It contains a patch that defines
variables x-meta-keysym and x-alt-keysym which allow to swap the meta
and alt modifiers:

(setq x-meta-keysym 'alt
      x-alt-keysym  'meta)

That's what I do, but I want to change it to use another mechanism
instead: I will just remove Meta_{L,R} from the keymap.
-- 
Ambibibentists unite!

Re: Meta key, Alt key & ESC

[Bijan Soleymani]

Bertram Scharpf <b.scharpf@tesionmail.de> writes:

> Hi,
> 
> sorry, I could not find a documentation about this problem.
> 
> Under Debian/GNU Linux my Emacs Meta key is the one
> between `Control_L' and `Alt_L'. But from SuSE
> Linux I am used `Alt_L' to be the Meta key. Now I don't
> want to change my Debian `.Xmodmap'; rather I want Emacs
> to accept the `Alt_L' in one of the following manners:
I had the same problem. I just switched to standard pc101 keyboard in
X config file and Alt became Meta again.

Re: Meta key, Alt key & ESC

[Tim X]

Bertram Scharpf <b.scharpf@tesionmail.de> writes:

> Hi,
> 
> sorry, I could not find a documentation about this problem.
> 
> Under Debian/GNU Linux my Emacs Meta key is the one
> between `Control_L' and `Alt_L'. But from SuSE
> Linux I am used `Alt_L' to be the Meta key. Now I don't
> want to change my Debian `.Xmodmap'; rather I want Emacs
> to accept the `Alt_L' in one of the following manners:
> 
> 
> A.
> 
> I examine my keystrokes using the command "C-h k"
> (`descibe-key'). Typing
> 
>     C-h k <Alt>-a
> 
>       yields in                            under
>       ---------                            -----
>       "M-a runs the command ...."          SuSE
>       "A-a is undefined"                   Debian/GNU
> 
> But I get
> 
>     $ xmodmap -pm | grep mod1
>     mod1        Alt_L (0x40)
>     $
> 
> in both cases!
> 
> So there must be a way to tell Emacs which modifier is the
> Meta Key. How do I tell?
> 
> 
> B.
> 
> My `/usr/X11R6/lib/X11/app-defaults/XTerm' contains
> something like
> 
> --------------------------------------
> XTerm*VT100.Translations: #override \
>    Alt<KeyPress>Shift_L,Alt<KeyPress>: string(0x01B) insert() \n\
>    Alt<KeyPress>Shift_R,Alt<KeyPress>: string(0x01B) insert() \n\
>    Alt Ctrl <KeyPress>: string(0x01B) insert() \n\
>    Alt      <KeyPress>: string(0x01B) insert()
> --------------------------------------
> 
> (I didn't find a documentation about that either.)
> 
> Running Emacs in an XTerm as "emacs -nw" I get the following
> results:
> 
>     Typing                           yields in
>     C-h k <Meta>-a                   "M-a runs the command ...."
>     C-h k ESC a                      "ESC a runs the command ...."
>     C-h k <Alt>-a                    "ESC a runs the command ...."
> 
> but in the X-windowed Emacs still:
> 
>     C-h k <Alt>-a                    "A-a is undefined"
> 
> Is there a way letting Emacs take an <Alt> as an ESC-prefix
> as XTerm does?
> 
> Thank you very much in advance for your answers.
> 
I had the same problem with my Debian system, when I upgraded from
potato to testing (pre-release woody), but decided to just get use to
it. I was just about accustomed to it when I did a dist upgrade to the
new testing when woody was released and the old behavior is now back.

Personally, I'd just use xmodmap and I suspect it is the default
xmodmap debian is using which is causing the differences anyway. There
is some info on this in the emacs PROBLEMS or NEWS file (sorry, can't
remember which).

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!

X-Windows cut&paste problems (Japanese characters)

[Janusz S. Bień]

I have recently observed several problems concerning cut&paste between
Emacs and some applications (Debian unstable, IceWM and GNOME).

The most obvious one is that when I paste from some applications
(e.g. Mozilla) some Japanese characters, I get something like this:

        \x{65E5}\x{672C}

My semi-random experiments included setting
`x-select-enable-clipboard' and using `compound-text-with-extensions',
but the problem was unaffected.

In another application the paste worked correctly, in another one the
effect was the same as in Emacs.

I browsed the list archive but it seems that nobody reported an
identical problem.

I am looking forward to your advice.

Best regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: X-Windows cut&paste problems (Japanese characters)

[Eli Zaretskii]

> From: jsbien@mimuw.edu.pl (=?iso-8859-2?q?Janusz_S._Bie=F1?=)
> Date: 25 Sep 2003 18:00:10 +0200
> 
> I have recently observed several problems concerning cut&paste between
> Emacs and some applications (Debian unstable, IceWM and GNOME).

The version of your Emacs will be of help, of course ;-)

Re: X-Windows cut&paste problems (Japanese characters)

[Janusz S. Bień]

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

On Sat, 27 Sep 2003  "Eli Zaretskii" <eliz@elta.co.il> wrote:

> > From: jsbien@mimuw.edu.pl (=?iso-8859-2?q?Janusz_S._Bie=F1?=)
> > Date: 25 Sep 2003 18:00:10 +0200
> > 
> > I have recently observed several problems concerning cut&paste between
> > Emacs and some applications (Debian unstable, IceWM and GNOME).
> 
> The version of your Emacs will be of help, of course ;-)

I've just tested that the problem occurs also in CVS Emacs, so I
cross-post to emacs-devel.

When I paste two kanji characters from Mozilla (Debian package 1.4-4)
to Emacs 21.3.1. from the Debian package or to the CVS version
compiled by myself (21.3.50.1), I get

\x{65E5}\x{672C}

The numbers in braces are the correct Unicode code points of the
characters in question.

I repeated the experiment in a different Debian installation. When I
paste from Galeon 1.2.5 to Emacs 21.2.1 from the Debian package, I get
just 2 question marks. However, when I paste them into exactly the
same CVS version as above, I get two strange characters (displayed as
question signs in reverse video), the first one being reported as "c
with acute":

------------------------------------------------------------------------
  character: ć (0346, 230, 0xe6, U+65E5)
    charset: eight-bit-graphic (8-bit graphic char (0xA0..0xFF))
 code point: 230
     syntax:   	which means: whitespace
buffer code: 0xE6
  file code: not encodable by coding system iso-8859-2
       font: -ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1

Composed with the following character(s) `—¥' to form `æ—¥'.

There are text properties here:
  fontified            t
  untranslated-utf-8   26085
  composition          (0 3
   [326333])
-----------------------------------------------------------------------

The Unicode code point is correct, but the rest seems a complete mess
:-(.

Las but not least, a good news: the characters are pasted correctly in
unicode-emacs.

Best regards

Janusz


-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: X-Windows cut&paste problems (Japanese characters)

[Miles Bader]

On Sun, Sep 28, 2003 at 07:12:22PM +0200, Janusz S. Bie? wrote:
> On Sat, 27 Sep 2003  "Eli Zaretskii" <eliz@elta.co.il> wrote:
> I've just tested that the problem occurs also in CVS Emacs, so I
> cross-post to emacs-devel.
> 
> When I paste two kanji characters from Mozilla (Debian package 1.4-4)
> to Emacs 21.3.1. from the Debian package or to the CVS version
> compiled by myself (21.3.50.1), I get
> 
> \x{65E5}\x{672C}
...
> The Unicode code point is correct, but the rest seems a complete mess

Did you have `utf-translate-cjk-mode' turned on?  (do M-x ...)

Cut-n-past of japanese characters between Mozilla and (CVS) emacs works
perfectly for me if I do that.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: X-Windows cut&paste problems (Japanese characters)

[Janusz S. Bień]

On Sun, 28 Sep 2003  Miles Bader <miles@gnu.org> wrote:

> On Sun, Sep 28, 2003 at 07:12:22PM +0200, Janusz S. Bie? wrote:

[...]

> > The Unicode code point is correct, but the rest seems a complete mess

[...]

> 
> Did you have `utf-translate-cjk-mode' turned on?  (do M-x ...)
> 
> Cut-n-past of japanese characters between Mozilla and (CVS) emacs works
> perfectly for me if I do that.

Thanks, cut and paste works OK with `utf-translate-cjk-mode' on.

However, with its default value Emacs should behave in a more
reasonable way than that described in my previous posting.

Best regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: X-Windows cut&paste problems (Japanese characters)

[Jason Rumney]

Janusz S. Bien' wrote:

> Thanks, cut and paste works OK with `utf-translate-cjk-mode' on.
> 
> However, with its default value Emacs should behave in a more
> reasonable way than that described in my previous posting.

I believe it is a TODO item to automatically load the CJK-UTF 
translation tables when they are needed. If you have time, you could 
have a go at implementing that. Otherwise I find it hard to see what 
Emacs could do that is more reasonable than it does now (refuse to paste?).