GNOME Bugzilla – Bug 31316
[PATCH] Meta functionality would be nice
Last modified: 2021-06-10 12:33:47 UTC
Package: gnome-core Version: 1.2.3.1 Severity: wishlist >Originator: Christian Marillat >Organization: net >Synopsis: >Class: >Gnome-Libs-Release: gnome-libs-1.2.8 >Environment: System: Linux falcon.wanadoo.fr 2.2.17 #1 dim oct 1 16:10:29 CEST 2000 i686 unknown Architecture: i686 Distribution: Debian Version: woody >Description: Hi, It would be really nice if gnome-terminal supported the functionality of a "Meta" key, i.e. Meta-q would insert q with the high bit set. Currently only "Alt-q" is supported, and it inserts ESC q rather than M-q. Also, there's no way to have the terminal respond to Meta. (I have both an Alt key and a Meta key, and I'm relatively sure I've set things up correctly, because ICCCM-compliant programs like XEmacs and FSF Emacs get them right.) ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 15:08 ------- This bug was previously known as bug 31316 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=31316 Originally filed under the gnome-core product and general component. Unknown version 1.2.x in product gnome-core. Setting version to the default, "unspecified". The original reporter (marillat.christian@wanadoo.fr) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, gnome-core-maint@bugzilla.gnome.org.
Excuse me for being dumb here. What do you mean by 'q' with the high bit set?
This bug has been forwarded by the previous Debian maintainer and can be closed.
Closing as requested.
I've more info and patchs. For X, every time a key is pressed (or released), the app receives an event giving the name of the key, and wether it has been pressed or released. The event also contains some informations on the state of all the modifiers (Shift, Meta, Alt, etc). For console applications, there is no such thing as events, only characters read from stdin. When "converting" from events to stdin, gnome-terminal (actually libzvt) translates (most) meta-<key> to ESC+<key>, as opposed to Xterm which sets the high bit to 1 (iff eightBitInput is true) Example: in xterm: % od -x a^AM-A^D^D 0000000 0161 00e1 (typed in key a, CTRL-a, META-a) 0x61 0x01 0xe1 = 0x61|0x80 in gnome-terminal % od -x a^AM-A^D^D 0000000 0161 611b (typed in key a, CTRL-a, META-a) 0x61 0x01 0x1b 0x61
Created attachment 5720 [details] [review] gnome-libs patch
Created attachment 5721 [details] [review] gnome-core patch
The patches look somewhat mangled. Is it possible for you to resubmit them? Thanks in advance.
Created attachment 6382 [details] [review] acconfig.h.dpatch
Created attachment 6383 [details] [review] gnome-terminal.c.dpatch
Created attachment 6384 [details] [review] gnome-terminal.glade.dpatch
Created attachment 6385 [details] [review] gnome-terminal.glade.h.dpatch
Created attachment 6386 [details] [review] zvtterm.c.dpatch
Created attachment 6387 [details] [review] zvtterm.h.dpatch
Some comments about the latest patches. I forgot to remove the Debian header in the files, can you do that ? The zvtterm.c.dpatch and vt.c.dpatch include patche from vivek who add dtterm in gnome-terminal. Sorry I don't remember the bug number in bugzilla
Created attachment 6388 [details] [review] vt.c.dpatch
Forwarded for closer inspection :)
How is this working out with gnome-core-1.4.0.6 and gnome-libs-1.4.1.4? I think these went in.
No.
Christian, why was this bug moved to gnome-terminal? Shouldn't it still belong in gnome-core, since it's against 1.4 gnome-terminal?
Because I want to see this feature in 2.0 Otherwise this bug will be changed to wontfix like my others Debian bugs.
I've tried Alt as a modifier, and I don't see ESC as mentioned in the initial bug description. Many shells, such as zsh, use the Meta modifier to do line-edit functions. For example, Meta-b tells zsh to back up a word on the command line. ESC b as two separate characters achieves the same result but is less convenient, particularly when issuing multiple commands. For example going back three words - you can hold down Meta and press b three times, or else type ESC b ESC b ESC b. I have never used a terminal window that did not have this functionality, it is very unfortunate if gnome-terminal becomes the first. It was supported by xterm, dtterm, shelltool, cmdtool, etc etc etc. This bug has been idle for quite some time. Is there any change it might get fixed?
See attached patches and the BTS http://bugs.debian.org/50427
As Bob mentioned, Meta functionality (i.e. substitution of Escape sequence for Alt key) is broken on libzvt. In the zvt_term_key_press() the call to gtk_im_context_filter_keypress ()steals the keypress event (meta + b) thus it ignores meta modifiers and prints "b". The proposed solution for the same is, before calling gtk_im_context_filter_keypress() check if the GdkEvent contains meta modifiers and if modifier is present then steal the call and proceed with normal key press routine.
Created attachment 16897 [details] [review] proposed patch for Escape sequence
gnome-terminal doesn't use zvt for some months now. I think this bug should reassigned to vte
Reassigning to VTE to see if it's a problem there. If not feel free to close this.
I think there are actually two things being discussed here -- meta-sends-escape and eight-bit-input. I believe that meta-sends-escape works in as you would expect in VTE. I don't see how eight-bit-input (or the related eight-bit-output option) can make any sense when you're supporting encodings other than iso-8859-1, so I have no plans to implement these options. I remain open to the possibility should someone propose a reasonable way to go about it.
I have verified that zsh works as expected with the Meta key with gnome-terminal on Linux, using libvte. The man page for zsh talks about meta not as the 8th bit, but as the "highest bit". Does this mean that for 16-bit character sets meta should set the 16th bit? Somebody should probably confer with a zsh expert to get a strict definition of "metacharacters" and how they are affected by 16-bit character sets before determining that ZVT and VTE are sufficiently fixed.
Cleaning up version and keyword.
Adding the PATCH keyword.
Pasu, Bob, Nalin: is pasu's patch ( http://bugzilla.gnome.org/attachment.cgi?id=16897&action=view ) still relevant?
Also lowering priority given Nalin's comments. Alexander, PATCH != high if the maintainer explicitly says the bug is low priority to him, unless there is a really, really good reason :)
Luis: the patch wouldn't apply. If I'm reading it right, the current patch's function attempts to make libzvt avoid filtering keys through the input method if Alt, Meta, Super, or Hyper is also pressed (assuming the system has the same keymap as I have). Bug #128099 lists a similar problem with NumLock, so the bug itself is likely still valid.
Can we forget libzvt and focus on determining what this bug really is about in the vte context? If I try the first example in the report under g-t and xterm on a recent vte/g-t build I see the same result in both cases. Is there still a problem here?
Has there been any progress on this? It affects anyone using vim and trying to use Meta- or Alt- key combinations. Downstream, this termite issue is also waiting for this bug's resolution: https://github.com/thestinger/termite/issues/168
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/577.