| 2012-03-29 22:53:26 |
Jo Vermeulen |
bug |
|
|
added bug |
| 2012-03-29 22:55:48 |
Jo Vermeulen |
description |
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the file menu here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in an GUI version of Emacs (without invoking the HUD), but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in other programs.
|
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the menubar here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in an GUI version of Emacs (without invoking the HUD), but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in other programs. |
|
| 2012-03-29 22:55:57 |
Jo Vermeulen |
description |
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the menubar here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in an GUI version of Emacs (without invoking the HUD), but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in other programs. |
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the menubar here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in a GUI version of Emacs (without invoking the HUD), but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in other programs. |
|
| 2012-03-29 22:56:41 |
Jo Vermeulen |
description |
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the menubar here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in a GUI version of Emacs (without invoking the HUD), but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in other programs. |
When I'm using Bash in gnome-terminal, I'm currently unable to use the GNU Readline shortcuts to move forward a word, because pressing Left Alt + a key tries to open a menu option. For example, Alt+f opens the file menu. For some reason, the Alt key is bound to the menubar here.
Expected behavior: Alt+f moves the cursor forward one word
Current behavior: Alt+f opens the file menu.
The strange thing is that it does work in a GUI version of Emacs, but not when Emacs is run directly in the terminal (emacs23-nox). It also works correctly in xterm (after Ctrl + left-click > select "Meta Sends Escape"). So I'm not sure if it's a bug in gnome-terminal or in unity.
When you hold the Alt key in Emacs or xterm, nothing happens, the HUD is only displayed when you release the key again. Of course, when you're using it as a meta key, you're never doing that, you're holding it and combining it with another key. So that's the correct behaviour. In gnome-terminal, however, holding the Alt key doesn't do anything. It seems to be the case that combinations using the Alt key are interpreted as shortcuts for the menubar in gnome-terminal.
On a related note, I'm wondering whether binding Alt to the HUD won't conflict with the usage of Alt as a meta key? While Alt is the obvious choice (and I like the concept of the HUD), it would be very annoying to be unable to use the meta key in certain programs. |
|
| 2012-04-26 14:28:10 |
obeliksz |
bug |
|
|
added subscriber obeliksz |
| 2012-04-26 14:28:46 |
Launchpad Janitor |
unity (Ubuntu): status |
New |
Confirmed |
|
| 2012-08-19 07:43:14 |
Jussi Brunberg |
bug |
|
|
added subscriber Jussi Brunberg |
| 2012-08-24 02:34:53 |
Edward Donovan |
unity (Ubuntu): status |
Confirmed |
Invalid |
|
| 2012-08-24 04:08:55 |
Edward Donovan |
affects |
unity (Ubuntu) |
gnome-terminal (Ubuntu) |
|
| 2012-08-24 04:09:26 |
Edward Donovan |
bug |
|
|
added subscriber Edward Donovan |
| 2013-07-04 17:34:46 |
v17al |
gnome-terminal (Ubuntu): status |
Invalid |
New |
|
| 2013-08-07 22:05:30 |
Duncan Mac-Vicar P. |
bug |
|
|
added subscriber Duncan Mac-Vicar P. |
| 2013-08-07 22:05:48 |
Launchpad Janitor |
gnome-terminal (Ubuntu): status |
New |
Confirmed |
|
