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
Related
I have a Python program which uses rlcompleter to provide custom Tab-completion. The completion works when it is run under a bash terminal. However, it does not work under emacs, in shell mode, nor in eshell mode.
I noticed that Tab is really bound to completion-at-point, eshell-pcomplete, and so on, so I tried an (insert "\t"), supposing that this would trigger the completion, which I understand happens when the child process reads a "\t" character. But this does not work either. Perhaps input is buffered until a "RET"?
Completion for commands like service, which define their own candidates, does not work as expected either.
How can I access these candidates within Emacs?
Try using M-x ansi-term. I find it behaves a bit more like what I have come to expect from a *nix terminal.
I've been fooling around with comint-mode lately and I'm noticing some weird behaviors. Its very poorly documented, so I'm wondering if anyone has any insight on this.
In some modes, comint-send-string causes whatever is sent to be inserted into the comint buffer and then sent to the associated process, whereas in others, the input is send directly to the process without being placed into the buffer. For example, do run-python with the new (24.3) python.el and then do (comint-send-string "*Python*" "x=3\n"), the string x=3 is inserted into the buffer and then executed. If you do M-x shell, however, and then (comint-send-string "*shell*" "x=3\n"), no text is inserted into the buffer, the input is simply sent to the shell process directly to be executed.
Does anyone know why this difference in behavior exists or how I can change it?
I observe identical behavior on linux (emacs-version == "24.3.50.7", both GUI and emacs -Q -nw): neither
(comint-send-string "*Python*" "x=3\n")
nor
(comint-send-string "*shell*" "x=3\n")
insert anything in the comint buffer (i.e., the next prompt appears
right after the previous prompt - without even a newline between them).
I eventually figured it out. For some reason the system python on OSX causes this behavior, installing python from homebrew fixed it.
I am using emacs and the auto-newline feature is not working as expected. I have a pretty large number of customizations done to my emacs. So it would be no wonder if one of the other customizations is not what auto-line is expecting. I would like to know if there is a way to know the list of commands (list of emacs commands) executed by emacs at a particular point, for e.g. when ctrl-s ctrl-c or in my case when auto-line feature is called.
edit : I think you have misunderstood the question. I would like to know what command emacs calls 'internally'.
I believe view-lossage is what you're looking for -- M-x view-lossage, or C-h l.
If you want to know what a keystroke is bound to, consider using describe-key, which is usually bound to C-h k.
Basically at this point, you need to bite the bullet and learn some Emacs-lisp. The debugger is what you are looking for to dig further into your problem (I use edebug). It's not just about seeing what functions get called, you also need to see the values of the relevant variables when those functions are called.
If you feel you're not up to it, then you can bi-sect your init file until you find the culprit, but at that point you still need some Emacs-lisp to investigate further.
To add to what #event_jr said --
What you seem to be asking is the history of the functions called by the command you last invoked. (You speak of Emacs "internal commands", but it seems you just mean functions.)
To get that history for any given command you invoke (e.g., by a key), use M-x debug-on-entry and then enter the command name. The next time you use that command, you can walk through its execution in the Emacs debugger (hit d to step, c to continue past a step).
I'm studing lisp and I found this: (zoom in)^C ^C , but the text don't explain it, and I searched "^C ^C" in other places but didn't found anything. Can someone here help-me?
(I'm studying english yet, sorry if I wrote anything wrong)
"^C^C" is not AutoLisp; that would be for/is the macro language for menus and such.
Caret-C does "mean" CTRL-C.
What it does in the macro language:
^c means: cancel
^c^c means: cancel twice.
In AutoCAD we hit the ESC key (twice to cancel a command). The ^C^C is "good practice". -i.e. Before we issue or start a new command we cancel any current command.
The equivalent in AutoLisp would be:
(command) (command)
or
(repeat 2 (command))
I think they refer to the control-character ctrl-c you enter after entering (zoom in) in the REPL.
As others have said, most likely it means Ctrl+C, especially if you're using emacs, where two Ctrl+C presses (usually written "C-c C-c" in the emacs convention, though) means "run this using the default interpreter" in some language modes.
If I'm not mistaken, ^C usually represents the "Ctrl+C" modified keypress.
It won't work in a console on Windows, as Ctrl+C also means "break (execution)", but if you press Ctrl+V, Ctrl+P, etc., you'll see what I mean.
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.