I have a skeleton defined like this:
(define-skeleton hello-skeleton
"Write a greeting"
"Name: "
"Hello " str "!")
When I run it with M-x all is well. The minibuffer displays "Name: ", and if I type in "abc" I end up with "Hello abc!". Awesome.
Then I evaluate this:
(define-abbrev text-mode-abbrev-table "hello" "" 'hello-skeleton)
Now, in a buffer with text-mode and abbrev-mode activated, typing "hello" [ENTER] does cause the minibuffer to come alive and display "Name: " again, but this time everything I type in is reversed. Every character I type in the minibuffer pushes the previous character one step to the right and the caret doesn't move.
So if I type "abc" I get "cba" in the minbuffer, and if I press [ENTER] I get "Hello cba!" in the buffer.
I suspected I had some junk in my init-file but I see this behavior even if I start emacs with -q.
What's going on here, why is it doing that?
Using: GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN. Windows 7 Home Prem.
Update 2014-08-23:
I can reproduce the bug with version 24.1.1 of the Emacs Windows binaries (http://ftp.gnu.org/pub/gnu/emacs/windows/), but not with 23.4.1.
I tried replacing the abbrev-mode and skeleton .el and .elc files in the buggy version (24.1.1) with the ones in the bug-free version (23.4.1) but the problem did not go away. I guess something else changed between those releases that the abbrev-mode/skeleton combo does not take into account..?
Suggestions?
I found a way that gets the job done:
If I press [SPACE] instead of [ENTER] after the trigger-word ("hello" in my example) then I no longer see the strange reversed minibuffer input behavior.
It's confusing because [ENTER] worked just fine in 23.4.1. Then in 24.1.1 there's this weird behavior. My guess is that the Windows line break characters (CR and LF) confuses Emacs 24.
I realise I haven't found an answer to my question, technically speaking, but this is good enough for me.
Related
Environment is Konsole + xterm-256color + tmux.
I like bind-key [Prefix] Alt+Backspace to next-window, so I wrote the following line in ~/.tmux.conf
bind-key M-BSpace next-window
It worked well. But now, it suddenly stop working after maybe the system upgrade or something whatever. I need to know how to get the correct expression for bind-key. (I mean, M-BSpace may be an invalid expression)
Is there any way to get the exact expression of the pressed key in tmux? For example, just like Emacs's C-h k, which can display the exact expression of a pressed key-binding.
This method is very useful because I can know whether Emacs accepted a correct key-binding, or the key-binding cannot interpreted/interpreted as something else by Konsole, xterm-256color, or tmux. (e.g. C-2 will be interpreted as C-#, C-i as TAB)
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.
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
Everytime I insert a snippet (with yasnippet) in a .tex document, I obtain a newline after the snippet. This is quite annoying for small snippets that are typically used in text style. How can I avoid that?
I read a bit about the problem (http://code.google.com/p/yasnippet/issues/detail?id=115 or http://yasnippet.googlecode.com/svn/trunk/doc/faq.html) but couldn't find a solution. Reproduce it as follows (I work with Aquamacs 2.3a on Mac OS X 10.6.8 with yasnippet version 0.6.1c):
Define ~/Library/Preferences/Aquamacs Emacs/Preferences.el to be:
(require 'yasnippet)
(yas/initialize)
(yas/load-directory "~/Library/Preferences/Aquamacs Emacs/plugins/yasnippet-0.6.1c/snippets")
define the following snippet (call it "bm.yasnippet" [bm = boldmath]; the star * symbolizes where the cursor ends -- note that there is no newline after the snippet)
# name: \bm{}{}
# key: bm
# --
\bm{$1}*
restart Aquamacs and open a .tex file and type in bm + Tab [this should insert the snippet]
A newline is added after the snippet. This is quite inconvenient since \bm{foo} is typically used in text style, so for example in "The vector \bm{x} is not the null vector". A typical cause of this is that the snippet ends with a newline which is then inserted, too. However, I specifically obtain this behavior even the snippet does not end with a newline.
I can't repro it with plain Emacs. In fact, I had this exact issue, but my problem is I had require-final-newline set to t. So Emacs was adding a newline at the end of my template.
My setup is a little more complicated but the solution for you is probably to set mode-require-final-newline to nil and restart Emacs.
To verify this is the problem, open up the template and check for the final newline.
Thanks to the answers in Temporarly disable adding of newlines in Emacs, I'm using a function to only temporarily disable the adding of final newlines in the current buffer:
(defun disable-final-newline ()
(interactive)
(set (make-local-variable 'require-final-newline) nil))
the reason why u got a new line is that your snippet has space or tab at the end.
Ctrl+e and Ctrl+k to kill them will make it works, nearly 1 hour to figure it out...
I had a similar issue with a few snippets, one of that was \frac{}{} which I use quite often.
The snippet version of frac that I use is not the one bundled with yasnippets.
The issue was that I edited some of the snippets in VIM and when you save the file, VIM automatically appends a newline to it.
To resolve it I had to remove the newline in a different editor e.g. emacs.
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.