Create inactive timestamp keyboard shortcut not working - emacs

So, according to the Emacs manual, you can create inactive timestamps of the form [1970-01-01 Thu] by hitting C-c !.
However, doing so will result in my minibuffer displaying C-c !- waiting for further input. Hitting space or return doesn't work and just results in an error saying C-c !-RET isn't a valid command.
What exactly happened here? Is the command simply not defined by default? I'm fairly certain I don't have anything defined that globally overrides this, but I could be wrong.

If you type C-c ! <f1> you'll see a list of all keybindings that start with C-c !. Does that help?
I don't think there's a timestamp function bound to C-c ! by default, but there are plenty of results if you Google "Emacs timestamp".

Related

RET does not select the default in Command selection

When I use the Command in Auctex C-c C-c, it brings up a list of possible commands. It will usually select a reasonable default (e.g. Command: (default View)), however, when I press RET, it selects whatever is selected in the list below. I suspect this behavior is caused by one of the following packages I have installed
flx-ido
ido-ubiquitous
ido-vertical-mode
smex
To be honest, I used pieces from others' .emacs, so I'm not sure which of the customizations are causing this.
You do not have to deactivate it. You can type C-j to accept the current entry. If the current entry is empty, it will select the default.
It was ido-ubiquitous. Deactivating fixed it

Any way to silence Emacs keyboard shortcut advice?

Emacs sometimes can be rather annoying, it emits too much information in minibuffer. For instance, when I run M-x gnus, it tells me that
You can run `gnus' with <menu-bar><tools><gnus>
It also occurs when there is a keymap for certain command. I don't need them, But I don't know how to remove.
Any ideas?
Thanks.
Customize the variable suggest-key-bindings: a value of nil will disable key binding suggestion.

Why do all keys start being interpreted as "." in Emacs?

I am running Emacs on a unix server, which I access using PuTTY. Occasionally, I accidentally type some combination of keystrokes that causes all future input to be interpreted as a period. I'm pretty sure this always starts when I'm in Emacs, but it continues after exiting (ctrl-xc still works), so if I exit and try to enter something at the prompt it just looks like "....".
I have no idea what I'm doing that causes this. Any ideas?
I agree with phils comment to the question. But In emacs whenever you like to see what you have just pressed, There is a C-h l which gives you the history of keystrokes

Emacs C-c } command and parentheses-match checking

I am working in Emacs 23, editing LaTeX via AUCTeX. I noticed in emacs that when I press C-c }, I receive the minibuffer message
Scan error: "Unbalanced parentheses", 16026, 16440
Question 1. What exactly is this command doing?
Question(s) 2. More generally, how can I determine what I a given macro is doing? Is there, for example, a universal command that request the keyboard shortcut as an input and outputs a description of the command to which that shortcut is bound? Is there a list of all active keyboard shortcuts?
Question 3. How can I find my unmatched parentheses? The post here recommends the command M-x check-parens, but it availed me nothing, not even a minibuffer message.
The answer to 1 and 2 is to do C-h k C-c } and see what the help buffer tells you. This is one of the features that allows us to call Emacs a self-documenting editor. Don't forget that you can follow the links in the help buffer to both the source code where this function is implemented and to other documentation.
You may also want to use C-h m to see all the key bindings added by the major and minor modes that are currently enabled and C-h ? to see what other interesting help functions there are.
I've never used check-parens specifically, but it does work in my current buffer, which is javascript. I see from its documentation (C-h f check-parens) that it relies on the current syntax table, so perhaps for TeX the syntax table doesn't contain enough information for check-syntax to find the error.

Emacs How to redefine Shift-R for expected use

I've checked my elisp files to make sure that I do not have any bindings that contain Shift+R (and I have not found any). I expect SHIFT+R to print an uppercase character, but instead I get R R undefined inside of the Emacs command line. This is only in C/C++ major modes.
Any suggestions?
Update: Describing the key shows that it is undefined. How would I define it for the normal, expected use (capitalizing the letter R)?
I assume by the 'expected use' you mean to insert the 'R' character. For this, you'd need to bind the key to 'self-insert-command':
M-x global-set-key R self-insert-command
Or, in your .emacs or .emacs.d/init.el file:
(global-set-key "R" 'self-insert-command)
Of course, this should be the default....
I'm getting a little deja-vu here and if memory serves the behavior I encountered some years ago was that (on Windows) certain accessibility settings unset or changed the keycode for the right shift key. Sorry I cannot be more specific but maybe this will stimulate someone else to come up with the real answer. A test you can make: does the behavior work with both shift keys or just one? If the answer is just one shows the bad behavior, is that bad behavior shown with all keys?
Try C-h k (describe-key), then press Shift-R. describe-key will then tell you what is bound to that key. At least that will give you a hint as to whether or not there is an active binding. If there's a binding, perhaps it will give you a hint of something else to search for in your startup files.
You sound like you're having the same problem I had. Typing Re... in any html buffer would try to execute an R- command, when every single R-* command was undefined. Turned out that I had a typo in my .emacs file. I had a global-key-map set to (kbd "REF") instead of (kbd "RET"), and fixing it made the problem immediately vanish. So I'd recommend checking for anything similar in your .emacs file.