-iso-escape-detection to t.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs and emacs-23.0.0.19
1116287 pure bytes used
./emacs -q -batch -f list-load-path-shadows
[...]
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that the `coding:' tag is produced in
info/emacs-mime. Please see if that solves the problem.
Thank you Eli for working on this matter, I agree with your
fix. And, I'm sorry for being late in reponding.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
On 2007-07-12 12:19 +0100, Kenichi Handa wrote:
It appears that Chinese characters have pixelsize 16 in Emacs
rxvt-unicode gnome-terminal but have a larger pixelsize in gedit
xterm.
How did you specify the font pixelsize
-Preferences-FontColors is
pointsize?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
in X11.
However, C-u C-x = shows that the characters have pixelsize 16. Is this
a bug?
I'm not sure. Is the font size of ASCII characters the same
in emacs and xterm?
Could you please check the actual pixel size of a Chinese
character by, for instance, xmag?
---
Kenichi Handa
[EMAIL PROTECTED
. The *Backtrace* buffer will show
you exactly which code causes that error.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
use to read the
complain with:
Ignoring unknown mode `*-mode'
in *Messages* when the recover the last session/desktop with this
file open.
Which version are you using?
Do you see the same warning when you visit README.unicode
freshly?
---
Kenichi Handa
[EMAIL PROTECTED
of the build log, and a
patch that should fix the problem.
[...]
Thank you for the report. I've just committed your fix.
---
Kenichi Handa
[EMAIL PROTECTED]
--- src/Makefile.in 11 Jun 2007 00:57:42 - 1.279.2.44
+++ src/Makefile.in 12 Jun 2007 22:34:23 -
@@ -1000,7 +1000,7
the remaining files.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that x_encode_text had been used to encode X
selection data, but now it is not in Emacs 22.
But, in emacs-unicode-2, x_encode_text uses
encode_coding_object, and that function does call Lisp for
pre-write-conversion.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs
(face-list)) = 140
So we won't reach the limit 511 for a while.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
In article [EMAIL PROTECTED], Eli Zaretskii [EMAIL PROTECTED] writes:
From: Kenichi Handa [EMAIL PROTECTED]
Date: Mon, 28 May 2007 21:24:29 +0900
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
By the way, in emacs-unicode-2, make-glyph-code doesn't work
for a face of ID greater
that change in the CVS tree, as make-glyph-code already
exists there.]
I've already installed that change in emacs-unicode-2
branch.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org
) is the right thing.
So, my suggestion it to do that and see if it works well if
no one can investigate the code and RFC-822.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
- Kenichi Handa (2007-04-17) wrote:-
I found a suspicious code and just installed a patch. Could
you please try with the latest source? The page
www.6park.com has a character U+25CF (BLACK CIRCLE) near the
center
.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
conversion by its own CCL
programs. I'll be able to suggest a better way for Emacs
23.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
is deleted in
emacs-unicode-2 branch (and in comming Emacs 23). So even
if we describe that feature now, it should be reverted quite
soon.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org
In article [EMAIL PROTECTED], Peter Dyballa [EMAIL PROTECTED] writes:
Am 01.05.2007 um 13:02 schrieb Kenichi Handa:
Anyway, the new configure should avoid using libotf
if it's too old. Have you tried it?
Just finished: works!
checking for libotf-config... yes
checking
of libotf not sufficient? Was it incorrectly
configured? Should I remove it?
I don't know how you installed libotf, but you can get the
latest code from http://www.m17n.org/libotf.
You can also uninstall your libotf because the current Emacs
doesn't utilize it yet.
---
Kenichi Handa
[EMAIL
please try with the latest source? The page
www.6park.com has a character U+25CF (BLACK CIRCLE) near the
center of the top page. I think the crash happened when you
put mouse-cursor on it, and the new code stops the crashing.
And, I think the frequency of flickering is also reduced.
---
Kenichi
to reduce it. I'm now working
on improving it.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
not sure until I re-read my code about handling Xft
fonts. There's a possibility that I made some mistake on
calculating font/glyph metrics.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http
-backend, and start
emacs with --enable-font-backend. As you said you are
using Xft font, I think you did the same. Can't you show me
the exact operation to produce that bug by starting Emacs
with -Q --enable-font-backend -fn SOMEFONT?
---
Kenichi Handa
[EMAIL PROTECTED
is shorter than glyphs' data.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
CHECK_NUMBER to CHECK_CHARACTER in Fchar_to_string.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that they share a concrete representation in lisp.
I agree.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.
Thank you for confirming that. I'll soon commit this new
version, and keep on working for the problem with U+2500.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs
by which toolkit you
compiled Emacs with.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
think there's no way to make it use Xft fonts. If
you like Xft fonts, how about using gtk toolkit?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
was not yet completely
fixed by the fontset.c I sent. I'm now working on it.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that bold
vesion. Please show me from where I can get that font. I
want to try by myself.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
as to use
`select-frame-set-input-focus'[1] if it is not a bug of Emacs 23.
WDYT?
I'm not sure. That may solve the gnus case, but there will
be another code that uses select-frame in the similar
situation. I think we must first find why only Emacs 23
doesn't work well.
---
Kenichi Handa
[EMAIL
-cjk-load-tables))
nil)
and it is byte-compiled BEFORE you built Emacs.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that
utf-translate-cjk-mode is not in Info. Could someone put it
in Info? I'm not good at writing Info.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
try again.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
just installed a fix. Could
you please try with the latest code again?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
2 pixel underline to the right
of some lines. The underlines should not be there; they are rendering
artifacts.
Emacs was going to display an empty box of negative width
when a font for a non-spacing character is not found. I've
just installed a fix.
---
Kenichi Handa
[EMAIL PROTECTED
. So, how about treating this matter as
a documentation bug, and fix it to:
ISO646 IRV:1983[4/0] (ASCII graphic characters)
instead of modifying the code?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
code(s))
make-char(japanese-jisx0213-a)
list-character-sets-2()
mule-diag()
call-interactively(mule-diag)
I've just installed a fix. As the concept of charset
width is vague in emacs-unicode-2, I simply disabled
printing that information.
---
Kenichi Handa
In article [EMAIL PROTECTED], Romain Francoise [EMAIL PROTECTED] writes:
Kenichi Handa [EMAIL PROTECTED] writes:
The process of byte compiling them is, I think, not that slow; for
instance, I can byte-compile ZIRANMA.el in 1.5 second.
Does your Emacs binary include the byte-compiler change
it?
I do edited several dicstionary source files and updated the
generated *.el files, but *.elc are not in the repository.
They are byte-compiled at the time of building emacs.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs
In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes:
In [EMAIL PROTECTED] Kenichi Handa wrote:
In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes:
Stefan Monnier [EMAIL PROTECTED] writes:
Which function is it?
I believe the function at fault is uudecode
update. The process of byte compiling
them is, I think, not that slow; for instance, I can
byte-compile ZIRANMA.el in 1.5 second.
As, those dictionary files are updated very very rarely, I
don't think it's a big problem. And a tarball contains
generated *.el files.
---
Kenichi Handa
[EMAIL
in the second form, nil is
returned.
FYI, (compare-strings \200 0 1 \x80 0 1) returns t
because it adjusts multibyteness before comparing.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org
buffer.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
the release.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
, it seems that you are the maintainer of this package.
Could you please work on it with emacs-unicode-2 branch?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs
-encoding
conversion?
The byte sequence 0x81 0xCE looks like Emacs' internal
character representation for ISO-8859-1 0xCE character. So,
it seems that Emacs is doing character-DECODING conversion
on reading that 1-byte file, and then it writes without
encoding it back.
---
Kenichi Handa
[EMAIL
converted back to 0x81 by
(set-buffer-multibyte nil). That make the difference.
But, as Stefan wrote, it is better to call
(set-buffer-multibyte nil) much earlier.
Anyway, it is better to fix the function bound to loc-dec to
work in a multibyte buffer too. Which function is it?
---
Kenichi Handa
[EMAIL
it will only ever contain
bytes, and never chars: using a multibyte buffer here is inefficient and is
asking for trouble.
I agree.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org
In article [EMAIL PROTECTED], Jason Rumney [EMAIL PROTECTED] writes:
Kenichi Handa wrote:
It seems that default-process-coding-system is not setup
properly on Windows. When I run Emacs on my Windows,
default-buffer-file-coding-system is set correctly to:
japanese-shift-jis-dos
-system is:
(undecided-dos . undecided-unix)
On the other hand, when I run Emacs on GNU-Linux with
ja_JP.EUC-JP locale, default-process-coding-system is:
(japanese-iso-8bit . japanese-iso-8bit)
Is this because of DOS/Windows specific code in mule-cmds.el?
---
Kenichi Handa
[EMAIL PROTECTED
the system, the result of the
programs changed as this:
Program1:
SYS: 0x804, USR: 0x411
Program2:
LangID = SYS: 0x805, USR: 0x411
LCID = SYS: 0x411, USR: 0x411
GetUserDefaultUILanguage() = 0411
GetSystemDefaultUILanguage = 0411
---
Kenichi Handa
[EMAIL PROTECTED
/ccmE5qPc.o:mstest.c:(.text+0x214):
undefined reference to `__imp___iob'
collect2: ld returned 1 exit status
[IBM-F5F27A11743:~:517]
I have no idea what to do.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
fontset,
but, for the moment, I don't have a time to work on it,
sorry.
---
Kenichi Handa
[EMAIL PROTECTED]
2006-12-20 Kenichi Handa [EMAIL PROTECTED]
* xrdb.c (x_load_resources): Setup the default fontSet X reource.
Index: xrdb.c
encodings
are different), I'm not sure what is the right thing. If we
decode the both hunks correctly, a user will see no
difference and wonder why Emacs tells those lines are
different.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing
.
Anyway, I suspect that somehow the menu widget is not
created with a correct fontset. Though, I have not yet
investigated the problem deeper.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http
Emacs reads the output of process
while decoding by a detected coding system. That method
works for your test case, but fails in a case that two files
contain non-ascii characters in different encoding
(e.g. UTF-8 vs GBK).
---
Kenichi Handa
[EMAIL PROTECTED
=0x8e81fc8,
id=43) at fontset.c:618
In the latest code, line 618 is this.
retry:
and that should should not cause crash.
Please update and rebuild your emacs, and show me the result
of:
(gdb) bt full
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest
to make the command work
with universal-coding-system-argument (C-x RET c) (if not
yet done), and warn user to use it when the output diff
contains eight-bit characters.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug
In article [EMAIL PROTECTED], Glenn Morris [EMAIL PROTECTED] writes:
Kenichi Handa wrote:
I've just updated all AIST copyright years.
It seems as if in every case, you just added every year from the first
copyright date to the present. This is not exactly how it is supposed
to work
In article [EMAIL PROTECTED], Glenn Morris [EMAIL PROTECTED] writes:
Kenichi Handa wrote:
years that I modified the code. But, AIST keeps copyright
for all continuous years. If we must list all years
explicitely in such a case, could you please update the lines
for AIST too?
I've
-unicode on Windows-XP under
Cygwin, but it sets default-buffer-file-coding-system
correctly to japanese-shift-jis-dos.
And, when I run Emacs with LANG=zh_CN.GBK,
default-buffer-file-coding-system is set to chinese-gbk-dos.
---
Kenichi Handa
[EMAIL PROTECTED
that I modified the code. But, AIST keeps copyright
for all continuous years. If we must list all years
explicitely in such a case, could you please update the lines
for AIST too?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
fixes were not yet reflected in emacs-unicode-2,
please let us know.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
that I wrote and
have been modified by someone else who assigned his changes
to FSF.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
crash is also caused by the same bug, but
could you please try again with the latest code?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
I update emacs to the latest unicode-2 branch and the crash still
happens.
I've just installed another fix which seems more related to
your crash.
---
Kenichi Handa
[EMAIL PROTECTED
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
On Thursday, 30 Nov 2006, Kenichi Handa wrote:
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
I update emacs to the latest unicode-2 branch and the crash still
happens.
I've just installed another fix which seems
))
--
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
It happens when the cursor is over the @ char.
I still can't reproduce that bug.
If you still can't reproduce the bug and report-emacs-bug would help,
I'd do it.
Please do that.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
RET to
send a bug report. That command inserts various important
information in *mail* buffer in advance.
---
Kenichi Handa
[EMAIL PROTECTED]
[2 emacs-crash.log text/plain (7bit)]
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software
]\\([^[
\n]*\\)[ ]*Local Variables:[ ]*\\([^
\n]*\\)[
\n] 92026099 t)
find-auto-coding(/tmp/metamail13934BAc 3503)
Do you still see this error? If so, please type this in
*Backtrace* buffer and show me the result.
e(list (point) (point-min) (point-max))RET
---
Kenichi Handa
[EMAIL
in
future case and translation tables.
Is this in fact the case, for the default case table of Emacs unicode
2 branch, when the change I made for dotless i is installed there?
Your change is not yet propagated to emacs-unicode-2 branch.
---
Kenichi Handa
[EMAIL PROTECTED
it appears in.)
I've just installed a fix.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
, the proces output actually contains 8-bit bytes, so it
was going to be decoded by ISO-8859-1 (which is one of
iso-2022 based coding systems).
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org
In article [EMAIL PROTECTED], James Cloos [EMAIL PROTECTED] writes:
Kenichi == Kenichi Handa [EMAIL PROTECTED] writes:
Kenichi They are ambiguous according to EastAsianWidth.txt of
Kenichi Unicode. I think the right thing is to set them to the
Kenichi symbol `ambiguous', and make display
In article [EMAIL PROTECTED], Zhang Wei [EMAIL PROTECTED] writes:
Kenichi Handa [EMAIL PROTECTED] writes:
! (modify-category-entry elt ?\|)))
This is questionable. At least, shouldn't we exclude Hangul?
I don't konw korean, does Hangul has a different char break rule?
Try C-u C-h
-from=/test/testsuite/input/godwit/ucm/system/all-sources.lst\n-\n-#
Thank you, but I have no idea why nbytes (1058) can be less
than coding-consumed (2374). Please show the value of
p-decoding_carryover too.
(gdb) p p-decoding_carryover
(gdb) pr
---
Kenichi Handa
[EMAIL PROTECTED
-consumed and shrinked_bytes.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
). On the other hand, as
thai-tis620 decodes byte seuquences into characters of the
charset thai-tis620, an TIS620 font is used for them.
Try C-u C-x = on an empty box in a buffer decoded by
iso-8859-11 and on the corresponding Thai character in a
buffer decoded by thai-tis620.
---
Kenichi Handa
[EMAIL
to post to [EMAIL PROTECTED] I
installed Bob's fix, so please try again with the latest CVS
code.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Handa
[EMAIL PROTECTED]
2006-10-30 Kenichi Handa [EMAIL PROTECTED]
* files.el (revert-buffer): If a unibyte buffer is being reverted
with a coding system for multibyte, set buffer multibyte before
calling insert-file-contents.
*** files.el20 Oct 2006 11:10:12 +0900
are in the middle of a line.
I can't reproduce it. How gibberish it is? If it can't
be described by words, please attach an image file. And how
did you start Emacs? Does it happen when you run Emacs with
-Q?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs
string-make-multibyte
method to string-to-multibyte method a while ago, didn't
you? I think that change is good too.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo
-between-words' property?
You are right. I've just installed a fix which is slightly
different from your patch in the way of initializing the
tables.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http
In article [EMAIL PROTECTED], Reiner Steib [EMAIL PROTECTED] writes:
Hi,
in emacs-unicode-2, the coding systems ibm437 and cp437 are aliases:
,[ M-x describe-coding-system RET ibm437 RET ]
| D -- ibm437 (alias of cp437)
|
| DOS codepage 437
| Type: charset (charset)
| EOL type:
way. Could you please
try with the latest code?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
basically agree with you, but as I don't know the code of
dired, I don't know which part is the right place to fix.
I'd like to ask maintainers of dired.el to work on it.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug
agree. Keeping around encoded strings quite easily leads
to bugs. String/buffer should be encoded only just before
writing out.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman
XCreateFontSet (bug of X?). I
couldn't figure out what pattern of fontsetname causes that
failure, but found a workaround and installed it. At least
it works with XFree85 4.3.
Could people try Test Case One/Two/Three/Four with the
latest code?
---
Kenichi Handa
[EMAIL PROTECTED]
The Problem
opposed to
your patch) -- it is a gross hack which cannot DTRT in all cases.
I agree. As I wrote, the original problem of slowness
doesn't exist anymore, so I think your change should be
cancelled.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug
branch?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
codes. Please wait for
that.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
of bindings for self-insert-command (i.e. the length
of the return value of (where-is-internal
'self-insert-command)) is just 499. Are you sure that you
are testing with the latest version?
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
, and there is no difference. To me, that means that the problem
still exists.
I thought that you compared the execution time of the latest
one againt the old one.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
1 - 100 of 244 matches
Mail list logo
