I've been using gdb (in Ubuntu 18.04 for Windows subsystem for Linux if that makes any difference) recently and for some reason the arrow keys do not seem to work. I get the characters left = 'K', right = 'M', up = 'H' and down = 'P'. Arrow keys seem to work normally in bash or zsh. I have tried different TERM modes (ansi, xterm, linux and my normal xterm-256color) but they do not seem to have any effect on the behavior. I can cycle through the command history in gdb with ctrl+p/n so that is working (and enabling the command history is the only thing I do in my ~/.gdbinit). What do I need to do to get the arrow keys working in gdb?
Related
I have a simple set of emacs lisp lines that I use to insert my initials and a time/datestamp, but this has stopped working in some modes (e.g., python-mode). In these modes it throws the error comint-send-string: Buffer *spam* has no process, where 'spam' is the buffer I'm trying to add my timestamp to.
The lisp lines are:
(defun msl-insert-datetime () (interactive) (insert (format-time-string "%Y-%m-%d %H:%M ABC: ")))
(global-set-key [(control c)(control d)] 'msl-insert-datetime)
This works fine in buffers of various modes (text mode, lisp mode, etc.), inserting something like 2020-05-20 21:44 ABC:. But in Python mode (where I do much of my programming) I get the message above instead.
Any suggestions would be most welcome! I'm running Emacs 26.3 (build 2) on Ubuntu 20.04.
C-cC-d is probably bound in python-mode (presumably to something which wants to talk to an inferior process).
(global-set-key [(control c)(control d)] 'msl-insert-datetime)
This binds the sequence in the global key map -- which is the lowest-priority keymap -- and you've chosen a sequence which is reserved for major modes.
Sequences consisting of ‘C-c’ followed by a control character or a digit are reserved for major modes.
-- C-hig (elisp)Key Binding Conventions
As such, it's not surprising that some major modes are binding that in their (higher-priority) major mode keymaps.
There are certain other sequences you can more safely use in the global map, without worrying about them being used by other keymaps:
Sequences consisting of ‘C-c’ and a letter (either upper or lower
case) are reserved for users. Function keys <F5> through <F9>
without modifier keys are also reserved for users to define.
Note that you can use such sequences as prefix bindings, so lots of custom commands might hang off of C-cd (for example).
If you have Super and/or Hyper modifier keys on your keyboard, they are typically also unused by Emacs (at least by default).
I also remove the default C-z binding and use it as another prefix for custom bindings.
Lastly, I highly recommend reading https://www.masteringemacs.org/article/mastering-key-bindings-emacs to gain an understanding of keymaps and their priorities.
I'm basically trying to figure this out because I want to use my iMac as an external monitor for my macbook air. I also want to use the iMac keyboard for my macbook air however for some reason, Apple has decided that once you press and hold Command F2 to activate Target Display Mode (meaning it is now an external monitor) that the keyboard paired with the iMac cannot be unpaired with the iMac.
To work around this I thought I would just pair the keyboard with the macbook air initially (leaving the iMac without a keyboard) and create an Applescript macro that would simulate the keyboard pressing and holding the Command F2 for five seconds eliminating the need to go buy another Apple keyboard.
Here's what I have so far and it doesn't work. It's telling me F2 is not right. I'm pretty sure F2's key code is 120.
tell application "System Events"
key down Command
key down F2
delay 5
key up Command
key up F2
end tell
Does anyone know how I might accomplish this?
Observations as of OS X 10.9.1:
There's a problem with the way you're sending F2 (you need to use (key code 120) instead of just 120), but the larger problem is that key up/down only works as expected with modifier keys.
While NON-modifier keys can be sent (using (key code <n>) syntax), the up / down aspect is ignored, making both key down (key code <n>) and key up (key code <n>) statements effectively the same as key code <n> (i.e., a Key Down event immediately followed by a Key Up event is sent).
There's a suggested workaround here, based on repeatedly sending keystrokes in short sequence - it's worth a try, but from a technical perspective it's not the same as keeping a key [combination] held down, so I'm not sure it'll work.
Adapted to your situation (and replacing key down with key code), we get:
tell application "System Events"
set now to the seconds of the (current date)
set later to now + 5
if later > 60 then set later to later - 60
key down command
# Workaround: send F2 repeatedly.
repeat while the seconds of the (current date) is not later
key code 120
end repeat
key up command
end tell
As I said: this may not work; also note that the loop is "tight" meaning that it'll make your machine pretty busy (if sending keys repeatedly, but not necessarily as fast as possible is an option, you could insert a short delay).
Some optional background info:
The key up and key down commands, while also requiring the System Events context, are NOT exposed in the System Events.sdef, the app's dictionary (only key code and keystroke are listed) - this may indicate that Apple doesn't officially support them.
On OS X 10.9.1 (unlike on OS X 10.8 - don't know about earlier versions) there is a bizarre bug where an extra "a" keypress is sent whenever you use key down with a (keycode <n>) specifier.
Ways of determining key-code values (gleaned from various other SO answers, mostly here):
Key Codes, a free GUI app for interactive use - very handy.
The following header file on your system (list of codes in hex format):
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/Events.h
List of decimal codes (incomplete):
I've started a project to do something similar, namely monitor the iMac and automatically trigger target display mode and toggle off bluetooth when a Macbook is connected. You can download it from https://github.com/duanefields/VirtualKVM.
I wanted to program some of the Fnn and shift-Fnn keys, and clear the rest of them from what windows had assigned them. Just long enough to run a telnet or putty session, then I want to let them revert back to win std. I used a script in AutoHotkey, and it works mostly, but I assigned the many unused keys to be SHIFT keys, and now the shift-F4 often burps out the unshifted F4 string {over half the time I hit it.} Is there some better way to nuke the windows presets than just slapping SHIFT on all those keys, or is there some obscure tweak I can make to the script to lighten the load on the SHIFT kbd hook?
Script follows; note there's lotsa trailing spaces on most lines, if it matters...
Tested on a win8 laptop and an XP tabletop, same results.
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
;SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
SetWorkingDir C:\bin ; Ensures a consistent starting directory.
F1::send, EX`r
F2::Shift
F3::Shift
F4::send, FI`r
F5::Shift
F6::Shift
F7::Shift
F8::Shift
F9::send, OFF`r
F10::send, PROD
F11::send, `r
F12::send, END`r
+F1::send, FD
+F2::Shift
+F3::Shift
+F4::send, EM5
+F5::Shift
+F6::Shift
+F7::Shift
+F8::Shift
+F9::send, `r
+F10::send, PYR`r
+F11::send, SYSP
+F12::Shift
^F12::ExitApp ; control-F12 will remove all these
$~CapsLock Up::SetCapsLockState Off ; regress capslock to a SHIFT
Having tried a similar thing to "disable" Windows hold on the WIN key, I found that there wasn't a way to disable all of them - only a few.
However, Autohotkey can override windows hotkeys, as you've found.
If you just want to disable Windows' use of those keys (if I'm understanding you correctly), you could try something like this:
F11::
F12::
return
That would effectively disable the use of F11 and F12 anywhere as long as the script was running.
(no, trailing spaces don't make any difference)
When I type any key, normally, it is immediately echoed back to the std output i.e.my screen.
If I have to enter a password, that says that it will not echo back, I cannot see the keys that I type.
How does this work.
Does each key press go to the kernel immediately(without me pressing ENTER), and then the kernel decides to echo them or not?
Like , I press 'A', it goes to the kernel; kernel echoes it; I get it on my screen. Now I hit 'B'...same sequence again...; Now I have 'AB' on my screen (my command) and hit ENTER; My command goes to the kernel and is finally executed.
Is there any other explanation? What happens in the background during the key presses?
The terminal driver in the kernel can be put in several modes (there are actually many more flags than this, and these days "cbreak" is actually the opposite of a different flag, so this is simplified).
The "cbreak" mode means that the process that is attempting to read from the terminal will receive keyboard input as soon as it is available. When cbreak mode is off, the data is stored by the kernel in a buffer until enter is pressed, and certain keys like backspace are handled by the kernel (when you press backspace, it removes the character from the buffer and - if echo mode is on - writes "backspace-space-backspace" to the terminal to overwrite the character with a blank space).
Echo mode means that whenever the user presses a key, the kernel will immediately echo it back to the screen. When it is off, nothing will be echoed to the screen, and the program will need to write it to the terminal if it wants you to see it.
There are several typical situations:
In programs that do advanced input handling (like most shells, or something like a full screen program), cbreak is on and echo is off; the program will write the character to the terminal itself if it is not part of a special key escape sequence.
In most situations [the default with a simple program that reads stdin and writes stdout], echo is on and cbreak is off. When you type, it behaves as I described above, all of this is handled by the kernel until you hit enter and it sends it to the application. Input editing is limited to backspace [and ctrl-u, ctrl-w], trying to use the arrow keys will just put escape sequences like ^[[D in the input line.
When reading a password, echo is off and cbreak is off. Input works just like the default case, except the kernel does not copy input to the screen.
The program that is running tells the kernel what mode to have it in with the termios functions. You can use the stty command to do the same in a shell environment, but be aware that this may interfere with the shell's own input handling or with what programs you run expect the default state to be.
Your keyboard generates electrical signals that are eventually interpreted as keycodes that correspond to letters - 'A', 'B', function keys F1, F2 etc. This all happen in the keyboard driver that is handled by the kernel. That keyboard driver has a buffer to receive all the keypresses from the keyboard and sends that to the kernel that in turn direct them to processes that is currently having the focus. What to do with the sequence of keys are totally decided by the individual application, such as whether to display the keys or not.
echo program is part of coreutils. You can download its sources here. Look at src/echo.c it's quite small. You can see that echo uses fputc or putchar calls. Those calls deal with standard stream called stdout. The architecture of standard streams is quite complicated and it's beyond of this post. You can found it using for example google.
Is it possible in any way to send the key "C-(" to Emacs over a VT100/xterm terminal (Mac OS X Terminal)? Is there an escape sequence that could be sent to achieve the equivalent?
I suspect the fundamental problem is that the concept of combining control with the character "(" (and other such characters that are produced using shift) does not exist.
Note: Using Cocoa Emacs is not an option. And the reason for needing "C-(" is that paredit.el uses it amongst other key combinations, and it would be preferable to not remap it (because it makes sense to have it on "C-(").
A VT100 terminal couldn't do that, because there is no ^( control character corresponding to (. However, xterm has the so-called "modifyOtherKeys" mode, which does allow to send unique keycodes for combinations like that.
To enable it, set the modifyOtherKeys resource, e.g. in ~/.Xdefaults:
XTerm*vt100.modifyOtherKeys: 1
With that, Ctrl+( will send the following keycode:
^[[27;6;40~
That's rather long though, so another format for keycodes like that was introduced, which can be enabled by setting the formatOtherKeys resource:
XTerm*vt100.formatOtherKeys: 1
With that, Ctrl+( sends:
^[[40;6u
In both of these keycodes, the 40 is the decimal ASCII code for (, and the 6 represents the Ctrl.
See man xterm and http://invisible-island.net/xterm/ctlseqs/ctlseqs.html for further details. No idea whether Terminal.app supports any of it.