Make on eshell , the chinese prompt will make the split line broken.
Like this, How to fix this problem ? thanks. Emacs version 24.4
Related
Recently, my Dired listing in Emacs starting appearing with 015 at the end of each line:
I'm not sure what brought it on. I had been making some changes with my Spacemacs layers but since then I've gone to a completely out-of-the-box Spacemacs configuration and the 015s are still there. It makes Dired pretty much useless because if I try to select a file or drill into a directory it doesn't recognize it. Any ideas or suggestions would be greatly appreciated!
Those are Control M characters. Emacs writes them as either ^M (one char, not two) or \015 (again, one char, not 4).
This Emacs Wiki page tells you about this: EndOfLineTips.
This is some of what it says:
If you see ^M in your file, you may have opened a file with DOS-style line endings (carriage return + line feed) while Emacs assumes it has Unix-style line endings (line feed only). (The carriage-return character, sometimes abbreviated as CR, is ^M. The line-feed character, sometimes abbreviated as LF, is ^J.)
You can reopen the file with the correct line ending with a command like C-x C-m r dos.
C-x C-m r is bound to revert-buffer-with-coding-system. Use C-h k or C-h f to see more about it.
See also (C-h v) variable buffer-file-coding-system.
Also: use i line endings in the Emacs manual, to go to node Coding Systems. That tells all you need to know about this.
This question and its answers might also help. And see the UNIX/Linux command dos2unix.
When opening emacs with two files $ emacs a.txt b.txt, the window splits vertically.
I need to have a horizontal split instead. Is there a variable that controls this behavior or is there a hook where I can override the one behavior without changing other behaviors as well?
I've looked at related questions on StackOverflow but they had a different focus and their answers weren't directly applicable:
OP wants to delete the other windows when opening files: How do I prevent emacs from horizontally splitting the screen when opening multiple files?
OP wants to globally affect all functions that split windows and the answer involves tricking the split algorithm into thinking there is not enough space fo a vertical split: Setting Emacs Split to Horizontal and the same applies for:
Open new Emacs buffer using vertical splitting
I would like to find the specific code runs when emacs is opened and change just the one call to (split-window-vertically).
In case it matters, I'm using GNU Emacs 24.3.1.
The specific code to open files from the command line is in startup.el. The function is command-line-1 and it calls find-file-other-window (in two different places).
You should be able to do something like this in your .emacs, but I'm not sure about the details:
(defadvice find-file-other-window (before split (file &optional wildcards))
(if <during command line processing>
(split-window-horizontally)))
(ad-activate 'find-file-other-window)
emacs -Q a.txt -eval "(split-window-horizontally)" -eval "(find-file \"b.txt\")"
Maybe set some font too, for example Liberation Mono-18:
emacs -Q a.txt -eval "(split-window-horizontally)" -eval "(find-file \"b.txt\")" --font 'Liberation Mono-18'
Without option -Q load your init-file also.
Well, just for completeness, when at a file already: C-x 3
There's an option to transpose
vertical/horizontal split. Very convenient and fun.
When I have Greek characters in emacs the line spacing before the next line is increased, which is pretty annoying and weird. Strangely any other unicode characters seem to be fine.
What is going on here and how can I make the line spacing consistent with other characters?
The version of emacs is:
GNU Emacs 24.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on batsu, modified by Debian
on linux mint (and using xmonad as a window manager but I doubt that has anything to do with it).
The example above is using "emacs -q" launched from a urxvt terminal with no .Xdefaults file (I then enabled linum-mode so that the line spacings are more visible).
Edit: The same thing happens if using the "-Q" options (I only just found out the difference between -q and -Q).
It seems that the Greek letters are from a completely different font. In addition to stylistic difference, this may cause different line height. So check out whether you can change the font to one that contains all the characters needed.
I have to use windows to write some shell scripts. I decided to use emacs, but I get a weird error when running the script:
/bin/bash^M: bad interpreter: No such file or directory
Correct me if I'm wrong, but that looks like the shebang ends in \r\n instead of just \n. How can I tell emacs to only write \n? I'm in Shell-script major mode. It's quite surprising this isn't fixed by default.
As Jürgen mentioned, you need to use the set-buffer-file-coding-system. You can say
(set-buffer-file-coding-system 'unix)
and stick that into a function inside the find-file-hook so that it will set it for all the buffers you open. Alternatively, you can put it inside the write-file-hook list so that the file-coding-system is set properly before you dump the file to disk.
For a simpler way out, if you're using the GUI version of Emacs, you can click on the 3rd character in the modeline from the left. It's to toggle between eol formats.
Use:
set-buffer-file-coding-system
(should be bound to a key-sequence) before saving the file.
Update: This only occurs when I access the particular server from a Windows machine
With emacs tramp (plink) I'm logging on to 2 different servers, and am experiencing a problem in one of them with find-file.
If I do tab completion in a directory, all file names have ^M appended to them, e.g.:
Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
-name^M ../^M
./^M .bash_history^M
.git/^M .gitconfig^M
.gitignore^M .lesshst^M
.ssh/^M .subversion/^M
and when I tab-complete the file name, it completes with the ^M suffix, which is the filename of a nonexistent file:
/plink:user#myserver.com:/home/me/.gitignore^M
Anyone experience a similar problem? ^M is ungoogleable!
^M really is the carriage return part of a carriage return/line feed (hex 0x0d, oct 015). You probably need to configure your server to use linefeeds as line endings. There might be a way to fix this in emacs, but I don't know offhand.
In a way, it's MS Windows (carriage return/line feed) vs. Linux (line feed) issue. However, it's not really that simple and boths types of line endings are there for a historically good reason.
As mentioned elsewhere, ^M is the CR character, which makes up the first half of a CR LF pair used as a line terminator in DOS. Unix/Linux just uses the LF, so the ^M is displayed as an extra character.
When I see this in vim, I remove it by searching for ^M and replacing it with nothing. To specify ^M I press ctrl-V then M
I'm sure emacs has some way to do the same thing.
Try
(add-hook 'comint-output-filter-functions
'shell-strip-ctrl-m nil t)
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt nil t)
or maybe even
'(ansi-color-for-comint-mode-on)
'(ansi-color-for-comint-mode-filter)
^M is Enter.
It could has to do with DOS vs. Unix line break.
DOS: (13, 10)
Unix: (10)
So when you want to write lines using DOS style, a Unix style renderer will say:
your like(char13)
another line
Check your terminal and stuff like that...
And... if you are writing a batch file for Unix in DOS happens the same. You have to convert it using dos2unix filename to remove the extra 13's in your file.