Here is what I use:
- MacOS X 10.6.7
- GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
- Mercurial Distributed SCM (version 1.7.2+20101201)
- GNU Emacs 24.0.50 (build from git repo with --cocoa flag)
- aHg v0.99
Here is my emacs settings:
(set-default-coding-systems 'utf-8)
(prefer-coding-system 'utf-8)
(setq locale-coding-system 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-8)
(set-language-environment 'UTF-8)
And here if what i got after C-c h g s:
parent: 2512:6252abcd7368 tip
JavaScript: ???????? ???????????? ????? ? ???????.
branch: default
commit: 3 modified, 6 unknown
update: (current)
Running hg log under M-x term gives me a correct result I can read (? is a russian chars...). So... How can I fix this in Emacs in aHg output?
First thing, that should be checked here - which LANG is set when Emacs was started)? (what is returned when you execute M-: (getenv "LANG")? As I remember, Mac OS X set LANG to "C" on the start of launchpad... setting of language environment don't modify LANG...
You can explicitly set the LANG environment from Emacs using (setenv "LANG" "ru_RU.UTF-8") or use "en_EN.UTF-8" if it preferable.
P.S. I just checked ahg with different LANG settings, and see question marks when I set LANG to "C", and see Russian letters when I run ahg-log in repository
It could be that the default font that is being used for output when you do C-c h g s doesn't support Cyrillic characters. You can see what font is being used by placing the point on one of the Russian characters that isn't being displayed properly and pressing C-u C-x =. To ensure that Russian is always displayed properly in Emacs, you can specify that all Russian characters will be displayed in a particular font. Since the Cyrillic characters are in the Unicode range U+0400 – U+04FF and the Arial font seems to display these characters ok, you could try the following in your Emacs init file:
(set-fontset-font "fontset-default"
'(#x400 . #x4ff)
"Arial")
Related
When I evaluate ruby code blocks inside org-mode I encounter utf-8 errors.
and indeed If i do
#+BEGIN_SRC ruby :exports both :results output
puts RUBY_VERSION
puts __ENCODING__
#+END_SRC
#+RESULTS:
: 2.1.1
: US-ASCII
and when i try to evaluate
#+BEGIN_SRC ruby
'Aurélien'
#+END_SRC
I get this error in Org-Babel Error Output
-:3: invalid multibyte char (US-ASCII)
-:3: invalid multibyte char (US-ASCII)
-:3: syntax error, unexpected end-of-input, expecting keyword_end
'Aurélien'
If I start an inf-ruby buffer I can use utf-8, there is no problem. I think it is a problem with org-babel.
my configuration:
M-x emacs-version 24.4.1
M-x org-version 8.2.10
M-! ruby --version 2.1.1p76
from package list: inf-ruby 20141005.550 installed
In my init file I have
(prefer-coding-system 'utf-8)
(set-default-coding-systems 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-8)
(set-terminal-coding-system 'utf-8)
(setq buffer-file-coding-system 'utf-8)
(setq erc-server-coding-system '(utf-8 . utf-8))
(setq locale-coding-system 'utf-8)
;; Treat clipboard input as UTF-8 string first; compound text next, etc.
(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING))
Is there a setting to change to have utf-8 by default for ruby code blocks and org-babel?
I found the problem.
On my mac, Emacs with a GUI default environment encoding is C.
In my init file, I specified an environment encoding with
(setenv "LANG" "fr_FR.UTF-8")
(setenv "LC_ALL" "fr_FR.UTF-8")
and org-babel picks it up correctly
I notice this problem recently, whenever I use emacsclient to start a new client, font color of the mode line becomes black.
I can produce this problem with following step :
emacs -q --daemon # start the server
emacsclient # bring up the client
use customze-theme to load "wombat" theme
C-x c leave client, then bring up client again
Dose anyone know what's the problem ?
Emacs version :
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4) of 2013-10-03 on louvi, modified by Debian
Here is my workaround based on #DanAloni's comment:
(defun rangi/reload-theme ()
(when window-system
(load-theme 'afternoon)))
(defadvice server-create-window-system-frame
(after reload-theme-on-frame-created ())
"Reload theme when a frame is created"
(rangi/reload-theme))
(ad-activate 'server-create-window-system-frame)
(add-hook 'after-make-frame-functions 'rangi/reload-theme t)
I simply load theme again when frame is created, although it required you to hard code theme name.
Not sure whether this bug will be fixed in 24.4 or not
In windows, I set the variable inferior-lisp-program to be (shell-quote-argument "D:/Program Files/ccl/wx86cl.exe").
But when I run inferior lisp with the command run-lisp, emacs responds:
Searching for program: no such file or directory, "D:/Program
It seemed that emacs treats "D:/Program Files/ccl/wx86cl.exe" as two arguments "D:/Program and Files/ccl/wx86cl.exe" separated by a space character.
How can I make emacs treat "D:/Program Files/ccl/wx86cl.exe" as a whole?
Try using the old "Progra~1" compatibility name for "Program Files". So,
(setq inferior-lisp-program "D:/Progra~1/ccl/wx86cl.exe")
How can change this behaviour:
C-s — start incremental search
type word — misprint the last character
Backspace — Oops! incremental search disappears, and I actually delete 1 character from the buffer.
to that one:
C-s — start incremental search
word — misprint the last character
Backspace — delete the last d character
type k — work — correct, and continue the search
I run Emacs in text terminal via SSH in PuTTY.
Operating system version: 2.6.16.60-0.58.1.1882.3.PTF.638363-smp #1 SMP Wed Dec 2 12:27:56 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
Emacs version: GNU Emacs 23.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.14.6) of 2010-07-16
With the -q option, Backspace sent by PuTTY is just C-h, and it acts like C-h, but in my .emacsfile I it bind to delete-backward-char:
(global-set-key [(control h)] 'delete-backward-char)
Try this:
(define-key isearch-mode-map [(control h)] 'isearch-delete-char)
What you should do is configure PuTTY to send C-? (byte 127) for Backspace instead of C-h (byte 8). This is the setting that works best in most circumstances. See the
PuTTY manual.
If you changed the PuTTY setting to send C-h because some other application didn't work, check that your terminal settings are correct on the server. The setting is often correctly autodetected, but sometimes you may need to add stty erase '^?' to your shell configuration file (.bashrc or similar) on the server.
If you really absolutely have to have Backspace send C-h, then globally rebinding C-h isn't sufficient. Instead, add (normal-erase-is-backspace-mode 1) to your .emacs. See the Emacs manual.
How you should use Emacs:
C-s - start incremental search
type word - misprint the last character
M-e - goes into edit-search-word-thing-mode-in-minibuffer :-)
correct the typo
C-s - continue incremental search
I encountered strange behaviour of expand-file-name function on windows during installation of last cedet using el-get. The issue is related to generation of autoloads.
The autoload.el on last emacs 24.1.50 contains the following function:
(defun autoload-generated-file ()
(expand-file-name generated-autoload-file
;; File-local settings of generated-autoload-file should
;; be interpreted relative to the file's location,
;; of course.
(if (not (local-variable-p 'generated-autoload-file))
(expand-file-name "lisp" source-directory))))
In my case generated-autoload-file is:
"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
as I have $HOME$ environment variable pointed to C:/home/ngulyamov. In this case above function returns:
"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
due to source-directory contains:
"d:/devel/emacs/emacs-bzr/trunk_jenkins/".
As you can see it changes drive letter from C: to D:.
At the same time on emacs 23.3 this function returns semi-correct value as source-directory contains value:
"c:/Users/Sean/Downloads/emacs-23.3/".
According to expand-file-name function description:
(expand-file-name NAME &optional DEFAULT-DIRECTORY)
Convert filename NAME to absolute, and canonicalize it.
Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative
(does not start with slash or tilde); if DEFAULT-DIRECTORY is nil or missing,
the current buffer's value of `default-directory' is used.
The paths on Windows never start from slash or tilde.
Now my questions:
1. Does expand-file-name function behaviour correct on Windows?
2. Why source-directory contains value of developers paths?
Could we consider expand-file-name as buggy on windows? Or it is just wrongly used in autoload.el?
Thank you in advance.
Finally I figured out the reason. The issue is coming from Makefile of cedet which uses $(abspath) functionality of make 3.8. The cygwin version of make in this case returns UNIX way of path, i.e. /home/ngulyamov/... which then replaces by source-directory root in autoload by d:/home/ngulyamov/.... The GnuWin32 version of make works correctly but by strange reason I have the following issue:
C:\home\ngulyamov\.emacs.d\el-get\cedet>\gnuwin32\bin\make all
Removing loaddefs.el files from subprojects.
Generating autoloads.
make[1]: Entering directory `C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet'
> autoloads
Wrote C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/loaddefs.el
Loading vc-bzr...
Generating autoloads for C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/cedet-android.el...
Memory exhausted--use C-x s then exit and restart Emacs
make[1]: *** [autoloads] Error 127
So dirty fix is specifying source-directory in autoload.el itself like:
(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")
Anyway, why source-directory is pointing to developer's computer path is remaining open.