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.
Related
As the title states, I'm relatively new to Emacs. I tried out several starter kits but went with Prelude and changed a lot of things around.
Anyway, I've been getting a good handle on everything...until this morning I was working and I typed double-quotes. Normally Emacs would insert a second double quotes right after ("") due to the auto-completion, but I must have accidentally changed something with a keystroke and now when I type ", I get \"\".
Thoughts?
Thank you.
This seems to be an issue with smartparens which prelude installs by default (see the file prelude-programming.el. This behavior is described in detail on smartparens wiki. To ensure that smartparens is causing problems you can can do C-h k" this would print about the command acutally run when " is pressed, if the command is sp--self-insert-command then the following should work
Paste this (setq sp-autoescape-string-quote nil) to your *scratch* buffer, go to the closing parenthesis and do C-xC-e, this will disable the behavior for current emacs session.
To disable the behavior for all future emacs session, assuming that you are using prelude, you will need to add the following to your personal config (basically some file inside /path/to/prelude/personal/).
(setq sp-autoescape-string-quote nil)
This will disable the auto-escaping of the string quotes, completely. If you like this behavior and do not want to disable it completely you can do what #steckerhalter suggests C-q" will insert just one parenthesis.
If the above does not solve the issue then try providing following info in your question which may help us debug the issue,
1) The list minor modes active (this can be obtained by doing C-hm).
2) Output of C-hk"
Hope that helps
this sounds a lot like smartparens (https://github.com/Fuco1/smartparens) which is included in Prelude. usually when you are inside "" then it will escape the quotes:
"hahah \"\" bah"
if you want to get a normal " inside quotes you have to use C-q " or disable smartparens with M-x smartparens-mode
If, as you say in a comment, " is bound to self-insert-command, then when you type " what happens is that a (single, unescaped) " character is inserted.
However, I suspect you have some mode turned on that does something additional whenever a " char is inserted. You mention automatic insertion of a second ", for example. That kind of behavior comes from a mode such as is provided by library smart-parens or electric-pair.
And you mention Prelude.
To find out what part of your init file (~/.emacs) is causing the behavior you see, bisect your init file recursively (first comment-out half, to see which half is responsible, then 3/4, to see which quarter is responsible,...). Then, if you still have a question about the responsible code, ask here, providing that info.
When you describe your problem here, it is important to be specific: what Emacs version, what mode(s), what libraries have you loaded,... Whatever might be pertinent. But first narrow down the problem by bisecting your init file to find the culprit.
Emacs was working fine, a few days ago some basic functions stopped working.
Alt+Ctrl+>, Alt+Ctrl+>
go to start/end buffer used to work but now I get an undefined error.
Alt+g+g goto line. It was worked, now I get an undefined error
I can't paste into the mini buffer on search with Alt+y, instead it paste the character that my cursor is on.
No one touched my .emacs file.
What is going on? I used emacs for along time and never had a problem with basic functions or pasting to the mini buffer.
Update:
Latest update on my problem is that everything is working when I use the Esc key instead of the Alt key. I don't know why or how it changes but it has nothing to do with my .emacs file or CapsLock or key pressing mistakes. Has anybody a clue why it changes and how to change it back?
Some things to check:
Is your .emacs file loading at all? Are any of the settings in your .emacs file taking effect? Alternately, try running emacs --load /path/to/your/.emacs. This will load the lisp code in your emacs file. If your settings get loaded now, then you need to move your .emacs into the right location so Emacs can pick it up.
Is another mode unbinding your keys? To check this, go to (for example) your *scratch* buffer, which should be in lisp-interaction-mode, and try a shortcut.
Is your .emacs file broken somehow? Try opening it, and commenting everything out but one binding. Then restart emacs and see what happens. If it works, keep uncommenting out sections (binary search is the way to go) to see what line breaks loading.
Are you sure you're pressing the right keys? Hit C-h c M-g g to run describe-key-briefly to see what keys you're pressing, and what they're currently bound to.
Is something wrong with the lisp code to bind the keys? I know this isn't likely, since it used to work, but try it anyway. Open up your .emacs and go to the line binding M-g g. Put your cursor after the closing parenthesis, then press C-x C-e to evaluate the s-expression containing the binding. Then, try the keyboard shortcut again. If it works, then something isn't loading your .emacs file correctly.
You can open your dot emacs and Alt-x eval-buffer. See if your dot emacs file works, or if there are any bugs.
Somehow the emacs I'm using doesn't treat Alt as Meta. It only uses ESC for it. If I press Alt+x it will tell me "A-X" undefined. I tried to figure out how to map it to meta but got no luck on the web because in most of results from my search people take Alt as Meta by default. I guess something like this should work:
global-set-key Alt(?) 'meta
but I'm not sure how to represent Alt in lisp.. any help? Thanks!
Most solutions will tell you to change keymap at the X11 level. The wiki suffers from the problem of too much information. If you just want a solution that works only at the emacs level (quite useful for VNC/remote desktop), then add the below line to your emacs init file
;; Map Alt key to Meta
(setq x-alt-keysym 'meta)
I had the same problem and by putting this in ~/.emacs helped me.
(set-keyboard-coding-system nil)
Refer to this, if you need more help
http://www.emacswiki.org/emacs/MetaKeyProblems#toc15
Entering this command in a shell (even M-x shell) works for me.
xmodmap -e "clear mod4"
This works when the problem is that the output of xmodmap includes a line showing that Meta_L is set to mod4:
mod4 Meta_L (0x73)
Emacs thinks your keyboard has a Meta key, so it's not interpreting Alt as Meta. The above command tells X that you don't have a Meta key, so Emacs will interpret Alt the way that we're used to.
I learned this from https://www.emacswiki.org/emacs/MetaKeyProblems.
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.
I'm using emacs (21.4.1) via PuTTY (0.60) connected to a CentOS5.3 box with a UK keyboard. Whenever I enter the £ symbol emacs locks hard, making the whole putty window unresponsive and loosing all changes.
Edit:
Futher to pajato0's suggestion, I get the following message:
à (translated from £) runs the command self-insert-command
which is an interactive built-in function in `C source code'.
which is an interactive built-in function in `C source code'.
It is bound to many ordinary text characters.
So it looks like I need to rebind the key. How would one do this?
To determine what role, if any, Emacs is playing in your scenario, I would suggest that you try C-h k # where # is your pound key. If it hangs, then Emacs is not getting the key at all and you have a Putty/Windows issue most likely. If Emacs tells you the function binding then you have some hope of fixing it by changing the key binding. My best guess is that Putty is capturing the key and sending it to Windows which is dropping the ball.
You could try another ssh client to see if it is putty-specific. I tend to just run
startxwin.sh # from a MinGW rxvt terminal
after which an xterm pops up in which I do
ssh -X some.unix.box # from the new xterm
after which I fire up a tabbed terminal emulator in which I keep several sessions 'forever'. And my US keyboard has no Pound sign so no way for me to test your issue...
I would look at the character set translation that putty is performing (window->translation in settings). It could be that the character code that is being sent for a pound symbol (don't have a UK keyboard...) locks up the terminal somehow, or that the character that is being returned in response to the keypress is causing some similar behavior (e.g. waiting for the completion of a code point).
You might want to try it with everything set to UTF-8 (charset/locale on linux side, and on Putty translation), to minimize the chances of confusion...
In response to your question "how does one rebind a key": use the define-key function, e.g.
(define-key global-map [S-Home] 'beginning-of-buffer)
The hard part is figuring out how to represent your key and then choosing a suitable function. For example, you might do something like:
(defun make-euro ()
"Euro")
(define-key global-map # 'make-euro)
But I would also suggest that you file a bug since if trying to self-insert your # key causes Emacs to hang, that is clearly Emacs breakage that should get fixed.