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.
Related
I am trying to figure out why VSCode sometimes decides to randomly insert "non-breaking spaces" U+00A0 instead of regular spaces, and how to stop this from happening?
This is a different type of space character which is causing issues, as seen in my previous question GitHub markdown not rendering and git detecting changes when no changes
This is happening to me on both Mac OS and Windows, and others have experienced this issue too. Although this question is about VSCode, this also happens on the online GitHub markdown editor.
How do I solve this problem?
Steps to reproduce
Edit a markdown .md file in VSCode for a while.
Put in lots of headings such as # my heading or ## my sub-heading.
If you have the markdown extension you can CTRL/CMD + SHIFT + P and Open preview to the side.
You should eventually notice that one of the headings doesn't render, and if you open the file in a hex editor such as HxD you'll notice that there is a non-breaking space instead of a regular space after the # character.
Possible causes
The backtick ` character on Windows can be combined with a letter on your keyboard for example a which results in à. Maybe the use of backticks is causing the space character to turn into a non-breaking space? However this wouldn't explain the problem on Mac OS, because backticks can't be combined with other characters.
I have this a lot too on Mac OS, but it turns out I am still holding the option key slightly (or perhaps shift on your keyboard) when typing the space after just having used the modifier key to type #
I've installed https://marketplace.visualstudio.com/items?itemName=viktorzetterstrom.non-breaking-space-highlighter&ssr=false#overview to spot my mistakes early.
I just spent quite a lot of time trying to figure out why a "mv foo bar" command I copy and pasted from VScode was returning command not found. Turned out the space in between mv and foo was a non-breaking space which I only determined by pasting it into a unicode text converter. I would really like to know why this is happening and if it's a setting I can disable. I am using Windows 10 so I don't think it's just a Mac issue.
I have faced this trouble several times when copy/pasting code from Microsoft Skype or Microsoft OneNote. Both programs convert regular spaces into special Unicode spaces when pasting into it.
By the way, since version 1.63, Visual Studio Code automatically highlights these special spaces.
I ran into this too, but I'm sure I unwittingly inserted the non-breaking spaces using the spacebar alone. I found the hexdump plugin useful for diagnosing the problem. I still don't know how to avoid it.
By default, Emacs 24 can handle Arabic, Hebrew, and other right-to-left (RTL) languages. I have multilingual term emulators that handle this in X, but I would like to use eshell inside emacs to see the non-English character filenames (and boy do I have many). When I use eshell, the characters are not in the correct order and it spells out gibberish. (setq-default bidi-display-reordering t) (which is default) makes no difference obviously.
Is this possible?
I believe you're getting double reordering by emacs + mlterm, and need to disable one.
Your screenshot shows in upper half mlterm successfully detects line-by-line base direction and reorders characters.
And Emacs 24 by default reorders bidi in the terminal, assuming a non-bidi LTR termianl.
Combining both results in double reordering ABC -> CBA -> ABC.
You have 2 options:
Disable bidi in mlterm (at least while running emacs, not sure how to automate that).
Disable bidi in emacs (at least when running under mlterm).
I.e. set bidi-display-reordering to nil, not t.
I expect the first will work better. mlterm can only give you a dumb "bidi display" layer, which may be confusing on top of an editor; emacs gives you "bidi editing" where someone thought of how the whole interaction should work.
Specifically, side-by-side "windows" within emacs should work well when emacs is doing the bidi and break horribly when mlterm is.
OTOH, mouse copy-paste probably works better when mlterm is doing the bidi.
If emacs sends reordered chars, that's what mlterm mouse selection will copy.
Emacs can mostly take over mouse with xterm-mouse-mode but (untested speculation) it works on terminal coordinates and would need extra work to match them to logical-order text.
P.S. I'm not sure why the end result is right-aligned, as it seems there is a blank line before so Emacs should consider it a new paragraph, decide it's RTL and send right-aligned text to mlterm, and I'd expect mlterm to then reverse the line resulting in it left-aligned. I'm probably missing something.
Make on eshell , the chinese prompt will make the split line broken.
Like this, How to fix this problem ? thanks. Emacs version 24.4
This is odd. I have defined the following prompt in zsh:
local user_host='%{$terminfo[bold]$fg[green]%}%n # %m%{$reset_color%}'
local current_dir='%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}'
local git_branch='$(git_prompt_info)%{$reset_color%}'
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"
It works great on gnome-terminal as well as in an ansi-term terminal in Emacs (M-x ansi-term) - see the example below:
However, it does not work well under multi-term in Emacs as you can see below:
I thought multi-term would be capable of interpreting the same set of escape characters that a terminal like gnome-terminal or ansi-term does. Why is it not interpreting the escape characters returned by git-prompt_info and others correctly?
I have also tried:
M-x set-terminal-coding-system and setting it to utf-8-unix
TERM=eterm-color within the multi-term terminal, or before calling Emacs, etc.
TERM= within the multi-term terminal, or before calling Emacs, etc.
Removing any export TERM from my .zshrc
Update (January 29, 2014):
The best solution so far seems to be to do the following:
TERM=xterm-256color
but causes another problem that I have reported here: Passing escape sequences to shells within ansi-term in Emacs.
Why is it not interpreting the escape characters returned by
git-prompt_info and others correctly?
The answer is most likely that multi-term just isn't prepared to accept those escape sequences, in that format, for whatever reason. This may be a configuration issue, bug, or intentional. Setting the mode to accept colors, i.e. TERM=xterm-256color, improves the situation because it then accepts color escape sequences similar to the standard format used among terminal emulators, e.g.:
RED='\033[0;31m'
NC='\033[0m' # No Color
echo "I ${RED}love${NC} Stack Overflow\n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} Stack Overflow\n" # this output IS interpreting them
code borrowed from here
the salient part is the [0;31m for color, which is referenced in the linked thread in "Update 2" of your other question, asking why lines are printed out that begin with 4m which is part of this color escape sequence.
Here is more info, with a relevant excerpt:
Thus it is your terminal emulator that understands colors. Your
terminal emulator understands that \033[0;36m is cyan, but another
terminal emulator might use an entirely different set of characters
for cyan (though no sane terminal emulator would flaunt the standard
and do this). This is the reason for tput. When you run tput setaf
6, tput is going to look up your terminal's escape codes for the
color 6 (cyan), and output that escape code.
I suspect, in your other question, the reason that alt+b and alt+f aren't working in your other question is due to the terminal width count being off because of improper interpretation of these escape sequences which are supposed to be non-printing or zero-width. I haven't messed with multi-term a lot but the solution may involve using tput or similar to allow it to properly understand the escape sequences.
Possible relevant troubleshooting info
I am using Emacs and just built AUCTeX for LaTeX. Anyway, as I was using column-marker extension while writing in LaTeX without AUCTeX, it is not working anymore with it. I was looking over the internet but couldn't find any help. Is there an elisp code line that allows to use column-marker on AUCTeX?
It works for me in emacs 24.3.1 with the built-in auctex and column-marker.el Update #: 312.
Here you have got an example (right window):
The deviation from the straight line comes from the different fonts/font sizes used for the caret and exponent, for the section titles and so on.
Inspite of that column-marker shows one the column with the specific character distance from the beginning of line.