Using Emacs on my linux box (wheezy, awesome,gnome and kde) I run into big trouble using clipboard even from one emacs instance to another.
Everything I put into the clipboard is converted into chinese looking characters in emacs. Only solution is to copy paste into some other editor (e.g. nano, vi) save it and open it in emacs.
I use the same .emacs on my other (ubuntu) computer and on windows 7 with out any trouble. I erased all my previous encoding settings I had without any success.
http://stackoverflow.com/questions/ask
after copy paste gets
栊瑴㩰⼯瑳捡潫敶晲潬潣⽭畱獥楴湯⽳獡k
I run into the same problem today, with a little different environment tho. I've been using Emacs 24.3.1 on Windows 7, then switched to the same version running under Cygwin+XWin with the same .emacs.d config. While clipboard under Windows worked fine, with the config I had under Cygwin/XWin I had the same problem as in the question.
Under terminal it worked fine, with XWin the -Q worked too, so after a little digging, it turned out to be:
;; MS Windows clipboard is UTF-16LE
(set-clipboard-coding-system 'utf-16le-dos)
I don't remember why I added this. I must have copied it from some Emacs Wiki in early days. When I googled it now, it seems like a popular setting in people configs. It turns out, under Windows I don't need this line for clipboard to work properly with Emacs (quick check with some polish diacritical characters), and under Cygwin/XWin it finally started to work.
(sorry, I haven't the reputation to comment, so I leave a clarification request here)
Are you using emacs in a terminal ? if so, which one (konsole, lxterm, xterm...) ?
Are you cut'n'pasting with mouse (middle click) or keyboard ?
Have you any clipboard manager running (eg glipper) ?
Do you get the same behavior if you start without an init file (~/.emacs), that is, using emacs -Q?
If you can come up with a reproducible recipe starting from emacs -Q then, unless you get some solution proposed here, consider filing an Emacs bug report: M-x report-emacs-bug.
Related
i have a few keys that i prefer to force-bind to keys i'm familiar with, and so i have used this SO Solution .
but i have found recently that it breaks for me.
the circumstances: it works fine when running 24.2.1 in window mode as build 2012-08-27 on bob.parkland.org (i.e. the pre-build emacs-for-mac solution found at http://emacsformacosx.com/).
but then it will not work when run in terminal on lion, which is 22.1.1 (mac-apple-darwin) of 2012-01-12 on b1006.apple.com .
if i comment out the call to add the hook, it works fine.
the problem is partly that i byte-compiled the code found at the other link above into a separate loadable .elc file … and did so with the newer version of emacs.
when i go back to the 22.1.1 version of emacs and byte-compile it with that version, it works in both versions of emacs without problems.
What do I have to write in my .emacs file in order to associate the <S-dead-grave> command with inserting the character ` (backtick).
I run GNU Emacs 23.1.1 on Unix.
Background: I run Unix via a shell that runs in Java (Oracle SGD) on a Windows terminal server. I do not have admin access on either system. My keyboard is set to Norwegian. There is apparently some bug in Java causing this to act weird with "dead" characters (like ` is on the Norwegian keyboard) and I have not succeeded in getting my administrator to fix this.
When I click ` followed by a space (as is the way to insert that character with my keyboard layout) in Emacs, I get the error message <S-dead-grave> is undefined. Hence, I believe that if I could define this, I would be able to work around this error.
Within this setup, I am also happy with alternative workarounds.
It's not completely clear to me whether you run Emacs in GUI mode or in text mode (in a terminal emulator), but based on your description of Emacs's behavior I guess it runs in GUI mode (maybe via some X server on your Windows machine?).
It's strange that you'd get S-dead-grave events, so it might be a bug in your GUI environment (your X server's config?).
But in any case
(global-set-key [S-dead-grave] "`")
might let you work around the problem.
I had the same problem and this bug report discussion reports a solution :
XMODIFIERS= emacs
I did put it into my .bashrc after testing that it works (with XMODIFIERS= emacs && emacs)
This is apparently not needed with emacs 24.4, but I use emacs 24.3.1 and still need it.
If XMODIFIERS= emacs works for you (don't forget space after equal sign), check ~/.xinputrc and /etc/X11/xinit/xinputrc or run im-config and select none. For more info consult debian reference chapter I18N and L10N
My Emacs editor can't work with ibus chinese input method, ibus shows "No input window" when cursor is on Emacs.
I run Emacs with alias like LC_CTYPE="zh_CN.UTF-8" emacs, It actually works before, but I have no idea why it doesn't work now, maybe some system update I think.
About my system: Gentoo Linux with Gnome3, I installed Emacs23 and Emacs24, and both of them can't work with ibus now.
PS: Ibus works on other programs, Emacs can display chinese characters well.
It seems the problem only happen on Gentoo. Because system update clear up some fonts. The solution is to install the missing fonts:
emerge media-fonts/font-adobe-75dpi x11-apps/bdftopcf media-fonts/font-alias media-fonts/font-util
Then after logout and re-login, I can use input method again.
I solve this problem via installing ibus.el and this seems like emacs GTK UI's problem.
make sure that ibus is configured correctly by opening the default text editor for your distribution (Mousepad, Leafpad...?), typing control-space and seeing if you can enter Chinese. If you cant you may have to install a Chinese input method or add an input method in the ibus settings.
next make sure you have the emacs, ibus mode installed. If you are using a Debian based distribution, the package you want to install will be listed as 'ibus-el'.
After installing ibus-el usually control-space will activate and allow you to cycle through your input methods; however, on some of my machines I have to help emacs to get ibus mode started by typing M-x ibus-mode.
I am using shell in my emacs version 22.2.1 (debian stable repos) and it has some kind of broken coding. For example, if I run `ls' command, output is
[0m[01;34margouml-0.30.2[0m
not "argouml-0.30.2" as normal. I have tried commands C-x RET p utf-8 and so others but without any effect. I have properly generated utf-8 locales and everywhere else in emacs coding works perfect. Does anybody knows what may be wrong with it?
Your terminal type in the shell is set incorrectly; those escapes are for colors, but the emacs shell doesn't support them. Try M-x term instead for better support.
You can also try M-x ansi-term, or even download Multi term and try that too.
Links:
Ansi Term
Multi Term
I recently had to reimage my windows laptop, and emacs is now giving me a strange error:
"Starting new Ispell process [default]
Enabling flyspell mode gave an error"
I have aspell installed, and it is accessible via emacs. I have attached a picture to show this. I also have (setq-default ispell-program-name "aspell") in my emacs configuration. This same configuration works properly on my other windows machines. What might be the problem here? Image: Aspell in emacs-shell http://img145.imageshack.us/img145/4497/emacsaspell.jpg
You can add the line:
(setq flyspell-issue-welcome-flag nil) ;; fix flyspell problem
to your personal emacs initialization file (~/.emacs.d/init.el, ~/.emacs, ~/.emacs.el, whatever...) and that should bypass the problem for you.
EDIT: This it seems is not the best solution: see the comment below and see Dennis' answer for a better alternative.
EDIT2: As the comment below indicates, deleting the files recommended in this post causes problems when upgrading. If you followed the advice on this post and now regret it (sorry), then to reinstall the deleted files you want to type:
sudo apt-get --reinstall dictionaries-common
You should now be able to upgrade and follow Dennis' solution.
Google sent me here first so I thought I would add another common reason for this error message (at least on Ubuntu systems)
My ubuntu 10.10 fresh install had the following bug:
https://bugs.launchpad.net/ubuntu/+source/dictionaries-common/+bug/619015
which is fixed (as indicated in the link) by deleting
/usr/share/emacs/site-lisp/dictionaries-common/debian-ispell.el
/usr/share/emacs/site-lisp/dictionaries-common/flyspell.el
/usr/share/emacs/site-lisp/dictionaries-common/ispell.el
and all the .el .elc files in
/usr/share/emacs23/site-lisp/dictionaries-common
The reason it seems is the above files are already installed in the emacs23-common,
and the .el and .elc files retain the conflict on live systems (from reading the bug report).
I think there are other problems that can cause this error message, but this solved it for me, and I felt ubuntu is common enough for this to mensioned as another answer.
EDIT: There seems to be a less intrusive solution - see Dennis Sheil's answer
Blessings,
Tom
Writing an answer in order to mark this as accepted:
paprika's comment helped me track the problem -
"Did you check if aspell works outside of Emacs, i.e. something like cat foobar.txt |aspell -a -l en?"
Turns out aspell-en had not been installed. my bad.
I ran into this problem as well when upgrading to emacs24. My aspell was working fine. I tried some of the techniques here with dictinaries-common and settting flyspell-issue-welcome-flag to nil as above but running emacs24 kept hanging on ispell.
I ended up purging my previous emacs23 install (making sure all their .el/.elc files were deleted in the uninstall), making sure there were no emacs processes in the background, and removing my cruft collecting ~/.emacs.d directory (taking care to save code in there I still needed).
I then freshly installed emacs24 (24.1.50.1 as it happens) and ran it and flyspell worked flawlessly.