Google 網路論壇不再支援新的 Usenet 貼文或訂閱項目,但過往內容仍可供查看。

Any way to make Alt key like X-windows in UTF-8 terminal?

瀏覽次數:60 次
跳到第一則未讀訊息

David Mazieres expires 2013-11-25 PST

未讀,
2013年8月27日 下午5:57:352013/8/27
收件者:help-gn...@gnu.org
I've been trying to find a way to get the Alt key to work the same in
UTF-8 terminals as it does in X windows. By UTF-8 terminal, I mean
one in which the alt key works, adds 128 to the value of whatever key
was typed, and then translates the corresponding unicode code point
(which lies between 128 and 255) into a two byte UTF-8 sequence. In
particular, this behavior is what you get from xterm if you set the
following X resources:

XTerm*eightBitInput: true
XTerm*utf8: true

Now the behavior I get in X windows, which I like, is that Alt behaves
like meta. In other words, when I type Alt-x, it gets interpreted as
M-x, which is bound to execute-extended-command. On the other hand,
if I type Control-q followed by Alt-x, I get unicode code point 0xf8,
"LATIN SMALL LETTER O WITH STROKE".

Unfortunately, I can't figure out any easy way to make this happen in
"emacs -nw". Basically unicode character 0xf8 is always interpreted
as LATIN SMALL LETTER O WITH STROKE, and never as M-x.

In the particular case of xterm, I can set the xterm resource
altSendsEscape to true, but this does not work very well with viper,
which interprets the ESC character differently. Moreover, for other
applications I run in the terminal, I don't want Alt sending the
escape key. Hence, I would very much like to make Alt work with the
exact X resources that I listed above in this message.

The best I've been able to come up with so far is:

XTerm*eightBitInput: true
XTerm*utf8: false

Then if I run emacs -nw with LC_TYPE=C, I get the appropriate
behavior. However, now xterm and emacs don't display unicode
characters properly, which I live with okay for years, but now other
applications in my xterm really want to send unicode. Effectively
what I want is to use different locales for input and output, which is
not possible. However, I could get something equivalent if emacs
compensated by mapping code points 128-255 to meta keys.

It's also possible that I'm thinking about the problem in entirely the
wrong way, so higher-level advice would be welcome, too. At a high
level, the problem is just getting viper in "emacs -nw" to work the
way it does in X windows. Oh, and I guess I have one more constraint,
which is that if I don't hard-code:

(defun viper-translate-all-ESC-keysequences () nil)

then I get horrible behavior over slow ssh connections and the like or
when I type commands quickly after ESC. Given my typing, there just
doesn't seem to be any timing heuristic that reliably differentiates
ESC from Meta, and this drove me nuts for years until I enabled a
proper meta key.

Thanks for any help.

fells...@gmail.com

未讀,
2014年1月25日 下午5:08:092014/1/25
收件者:
David,

It's a horrible hack, but at http://pastebin.com/NU6En97C I have put some code which binds ?\M-C to a function that looks up the appropriate key and executes its command. Let me know how it works for you.

Norman

fells...@gmail.com

未讀,
2014年1月27日 下午1:12:542014/1/27
收件者:
Code at http://pastebin.com/3q9Qn2qG also deals with M-\, M-space, M-:, others.

Emanuel Berg

未讀,
2014年1月27日 下午1:38:222014/1/27
收件者:
fells...@gmail.com writes:

> Code at http://pastebin.com/3q9Qn2qG also deals with
> M-\, M-space, M-:, others.

Here [1], it says:

> The Linux kernel maintainers do not accept patches
> for better Unicode support on the console because the
> console is to be used as an emergency interface.

The Linux people are almost always right (monolithic
kernel, in C, in all essence Unix, "people want
features", open source, etc.) so I suspect the Unicode
chars can screw things up, so you can't use the console
as a fallback, and that is why they don't want it.

Check out: 'unicode-data', 'console-data', and 'fbterm'

[1] http://askubuntu.com/questions/23610/tty-unicode-problem

--
underground experts united:
http://user.it.uu.se/~embe8573

Emanuel Berg

未讀,
2014年1月27日 下午1:56:582014/1/27
收件者:
fells...@gmail.com writes:

> Code at http://pastebin.com/3q9Qn2qG also deals with
> M-\, M-space, M-:, others.

Now, wait. What problem are you trying to solve?

Those keys work in Emacs in an "UTF-8 terminal" what I
can see (?).

'kbd_mode' tells me "The keyboard is in Unicode (UTF-8)
mode". And 'kbdinfo gkbmode' "unicode".

In Emacs:

M-\ runs the command delete-horizontal-space
M-SPC runs the command just-one-space
M-: runs the command eval-expression

But I don't remember ever using those keys, so I don't
want to swallow poison that they are safe...
0 則新訊息