After `(setq display-buffer-reuse-frames t)', `C-h f'(or `C-h v' and the
alike) to view help, `C-x o' to jump to the help window, `q' to quit view
mode, then I find `View-quit' does not restore window and buffer to previous
state as usual, instead Emacs pops one of other buffers.
In GNU Emacs 23.
Input the character U+ with `M-x ucs-insert ', it won't
display, not even in a hollow box, it looks like as if that char
doesn't exist, but moving the cursor *does* stop at it.
`C-x =' gives the following message:
Char: ㌳ (13107, #o31463, #x, file ...) point=310 of 2427 (13%) column=1
Zhang Wei wrote:
> Input the character U+ with `M-x ucs-insert ', it won't
> display, not even in a hollow box, it looks like as if that char
> doesn't exist, but moving the cursor *does* stop at it.
>
Try a different font. It may be that the font you are using claims to
support that ch
Jason Rumney <[EMAIL PROTECTED]> writes:
> Zhang Wei wrote:
>> Input the character U+ with `M-x ucs-insert ', it won't
>> display, not even in a hollow box, it looks like as if that char
>> doesn't exist, but moving the cursor *does* stop at it.
>
> Try a different font. It may be that the
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> Input the character U+ with `M-x ucs-insert ', it won't
> display, not even in a hollow box, it looks like as if that char
> doesn't exist, but moving the cursor *does* stop at it.
I think it's a font problem. Do you
==
I'd like to give a workaround for the bug report appearing at
http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00473.html
It appears the culprit was a (setq inhibit-eol-convertion t) buried in
one of my ~/.elisp fi
Hi all,
It seems that some Unicode characters (rarely used although) cannot be
displayed properly. That is, when emacs opens a file containing such
characters or user inputs them directly, these characters are not shown
at all. For example, input the Unicode char 0x (by ucs input
method) be
Jason Rumney wrote:
> Try a different font. It may be that the font you are using claims to
> support that character, but doesn't have a glyph for it.
I'm afraid not. I can re-produce this bug with the font DejaVu Sans
Mono, which does contain the Unicode char 0x (in Common section).
Thanks.
Hongzheng Wang wrote:
> Jason Rumney wrote:
>
>> Try a different font. It may be that the font you are using claims to
>> support that character, but doesn't have a glyph for it.
>>
>
> I'm afraid not. I can re-produce this bug with the font DejaVu Sans
> Mono, which does contain the Unico
Hi,
Thank you for your explanation. I think I understand this problem now.
The problem is really due to the lack of some glyphs in the font I'm
using. In fact, U+ is not covered by DejaVu fonts at all. It is
displayed properly in other editor, say gvim, just because fontconfig
automaticall
10 matches
Mail list logo
