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.
Related
Struggling to get using xtermjs, and have some questions which aren't covered in the official documentation, at least I didn't find.
I understand that when I use some app within the terminal, for example, Vim terminal need to be switched to alternate buffer, after I quit from the app, terminal switched back to the normal buffer. Is this right?
To switch between buffers (and overall to control terminal behavior) I need to use a control sequence. It isn't something unique to xterm.js, but the common pattern and control sequence is unified between terminals?
Control sequence to switch to the alternate buffer is CSI ? Pm h with parameter 47 according to documentation:
DECSET DEC Private Set Mode CSI ? Pm h Set various terminal attributes.
Where
paramAction 47 - Use Alternate Screen Buffer.
How to use this control sequence with xterm.js, for example, I want to switch to alternate buffer. What string should be used in terminal.write(...)?
Yes, see description here in this question Using the “alternate screen” in a bash script
The alternate screen is used by many "user-interactive" terminal applications like vim, htop, screen, alsamixer, less, ... It is like a different buffer of the terminal content, which disappears when the application exits, so the whole terminal gets restored and it looks like the application hasn't output anything
Yes, ANSI escape code
ANSI escape sequences are a standard for in-band signaling to control the cursor location, color, and other options on video text terminals and terminal emulators. Certain sequences of bytes, most starting with Esc (ASCII character 27) and '[', are embedded into the text, which the terminal looks for and interprets as commands, not as character codes.
Control sequence to switch to alternate buffer: CSI ? 47 h
Control sequence to switch to regular buffer: CSI ? 47 l
Code to apply control sequence to switch to alternate buffer:
terminal.write("\x9B?47h"); //CSI ? 47 h
I have a very weird issue when my application is run under "Windows Vista Compatibility mode" (right-click the EXE, enable compatibility mode and select windows vista).
The issue is the return buffer length value from the "RegEnumValue" function returns a different value.
For example, with a registry value of "Zoom Player MAX" (15 characters):
With compatibility mode diabled, RegEnumValue's "lpcbData" field return a value of 16 (including the trailing null termination).
With compatibility mode enabled, RegEnumValue's "lpcbData" field return a value of 15 (doesn't include the trailing null termination).
Is there a work-around/patch for this that doesn't require changing my string conversion code?
It should not matter. When reading from the Registry using low-level classic functions, you must be able to handle strings with and without null-terminators:
Beware of non-null-terminated registry strings
The easy way to do this is to secretly allocate one extra character that you don't tell the API about when reading, and then append the '\0' character to the end of however many characters it returns.
Newer functions like RegGetValue() handle this for you.
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.