In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> --- 1977,1983
>> SDATA_NBYTES (data) = nbytes;
>>#endif
s-> size = nchars;
>> ! s->size_byte = nchars != nbytes ? nbytes : -1;
s-> data[nbytes] = '\0';
>>#ifdef GC_CHECK_STRING_OVERRUN
>> bcop
Sorry for the late response on this thread.
At first, I think xassert in lisp_data_to_selection_data
(xselect.c) is wrong. Here, obj is generated by a Lisp code
that may generate a multibyte string by error (as in the
current case). But, in general, an error in Lisp code
should not lead to abort
In article <[EMAIL PROTECTED]>, "Jan D." <[EMAIL PROTECTED]> writes:
> If the multibyte string is generated by an error and this is one of the
> places where we can detect the error, should we not keep the xassert?
[EMAIL PROTECTED] (Kim F. Storm) writes:
> I agree, but since the source of the e
negative on signaling an error in
lisp_data_to_selection_data because I was not sure it is
safe to do that. But, I found that Fsignal is already use
in this function. So, I've just installed these changes.
2005-02-14 Kenichi Handa <[EMAIL PROTECTED]>
* coding.c (encode_cod
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> Hello!
> I tried to spell-check a LaTeX file in an AUCTeX (version: 11.55)
> buffer. When ispell hit the word sérifs (of sans-sérifs) this error was
> reported:
> Debugger entered--Lisp error: (error "Ispell misal
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> The buffer is according its modeline ("-0:--") in ISO Latin-15. It is
I think you mean Latin-9 here---^^
(Latin-9 == ISO-8859-15)
> using fontfaces to display di
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> I changed them this way:
> (setq ispell-local-dictionary-alist
> '(("english"
> "[a-zA-Z]" "[^a-zA-Z]" "[']" t ("-C") "~tex" iso-8859-1)
> ; ("german"
> ; "[a-zA-Z\"]" "
1/app-defaults or
>> /usr/X11R6/lib/X11/app-defaults or /usr/lib/X11/app-defaults? It looks
>> like the default fontset does not exist on your computer.
> Ar an ceathrà là is fiche de mà Feabhra, scrÃobh Kenichi Handa:
>> Please set break point at the function font
In article <[EMAIL PROTECTED]>, Miles Bader <[EMAIL PROTECTED]> writes:
> On Tue, 1 Mar 2005 18:35:04 +0100 (CET), Frederik Fouvry
> <[EMAIL PROTECTED]> wrote:
>> With the latin-1-prefix input method, what is the reason for turning
>> input "_ " (underscore space) into "\ " (backslash space)?
In article <[EMAIL PROTECTED]>, Kenichi Handa <[EMAIL PROTECTED]> writes:
>> I donât have the resolution-specific XFree86 directories in my font path,
>> so
>> the "-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1" font wasnât
>> available. The
In article <[EMAIL PROTECTED]>, Frederik Fouvry <[EMAIL PROTECTED]> writes:
> | Me too and I don't know why that sequence is selected. Anyway how
> | about adding a rule "__"->"_" (like "^^"->"^").?
> Would make sense (and is shorter than _ C-q ;-).
Ok, I've just added it.
> result for "_ ": an
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> The guillemets â, â,  and  should all be punctuation. The single
> ones currently have word syntax, and the double ones are treated as
> parens in latin-{1,5,9}.el.
As I don't use those characters, I don't know what is
cor
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> As I don't use those characters, I don't know what is
>> correct. But, it seems that they are used as a pair; isn't
>> i
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> The following entries could usefully be added to
> `locale-language-names' (taken from recent glibc):
> aa_DJ Latin-1
> aa UTF-8
> az UTF-8
> kn Kannada
> ml Malayalam
> mn UTF-8
> se UTF-8
> so_ET U
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
>>
>>> Maybe a workaround is to give them "generic string fence" syntax (a
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> I agree. Could you please install a proper change?
> No, I can't.
Ok, I've just installed changes for them. I modified the
format o
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> The encoding of a utf-16 file isn't detected correctly when finding
> the file.
> To reproduce: push 'coding-category-utf-16-le onto
> `coding-category-list', and put "foo" into a new buffer. C-x h and
> M-x encode-coding-re
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>> \glq, \glqq, ... are defined in the babel LaTeX package (see "texdoc
>> babel", table 4 or babel/babel.def and babel/*.ldf).
> Ah, that explains why I couldn't find them under t
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> When you modify coding-category-list by hand, you must call
>> update-coding-systems-internal.
> Oops, sorry I forgot how this works.
>
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> Ok, I've just installed changes for them. I modified the
>> format of locale-language-names and adjusted
>> set-locale-environment
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> And, what to do with the followings? Doesn't babel table
>> contain mnemonics for them?
> The problem with the Babel ones is that
In article <[EMAIL PROTECTED]>, Joakim Verona <[EMAIL PROTECTED]> writes:
> Symptoms:
> utf-8 chars doesnt work in todays emacs.
> they show up as empty spaces.
> I tried emacs -nw --no-init
> and typed some swedish chars =8e5=8e4=8f6.
> swedish chars do work at the shell prompt.
You are in en_
In article <[EMAIL PROTECTED]>, Stefan <[EMAIL PROTECTED]> writes:
>> So, which terminal-coding-system should we set by default when LANG is
>> de_DE.UTF-8(en_US.UTF-8), iso-latin-1 or utf-8?
> At least on reasonably recent xterms, it needs to be utf-8.
> On older xterms, I'd expect people don'
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>>> Doesn't this cause incompatible changes for some environments (like
>>> Vietnamese changing from viscii)?
>>
>> Yes.
&
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> How about enabling quail-completion on using "TeX" input
>> method as below? I think it's rare to use TAB while editing
>>
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> I don't know which coding systems should be utf-16 in that
>> environment. It seems that at least
>> default-file-coding-system shou
In article <[EMAIL PROTECTED]>, Jason Rumney <[EMAIL PROTECTED]> writes:
> Dave Love <[EMAIL PROTECTED]> writes:
>> Yes. Perhaps someone knows exactly what Windows does (assuming the
>> only significant use of it is in Windows)?
> I would guess that the presence of a BOM is sufficient
> heuris
In article <[EMAIL PROTECTED]>, Jason Rumney <[EMAIL PROTECTED]> writes:
>> I think BOM is not that safe because there are many charsets
>> who have normal letters at 0xFE and 0xFF.
>>
> But what are those characters, and are they likely to appear as a pair
> at the beginning of the file, and now
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> After updating I see this in my compilation buffer:
[...]
> Finally compilation ended here:
> Compiling
> /Users/pete/Quellen/Emacs_CVS/emacs/lisp/./international/mule-cmds.el
> In toplevel form:
>
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> A test file, starting with that header:
> ;;; -*- mode: Text; coding: iso-8859-13; -*-
> and consisting of lines like these:
> ; oct dec hex
> ;==
> = 240 = 160 = A
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> Am 04.04.2005 um 03:19 schrieb Kenichi Handa:
>> The above script outputs raw bytes 0..255, which is not a
>> valid utf-8 code expected in *shell* buffer. So, Emacs
>> decodes
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>>> I didn't realize that was implemented. It looks helpful, but it
>>> doesn't do what I'd expect. For instance, if
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Unicode says how guillemets are used as a matter of fact, which you
> can verify. It's manifestly wrong for single ones to have word syntax
> and double ones to have paren syntax and I wish I'd just changed it
> when I had th
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> Hello!
> Few characters are not correctly coded:
Thank you for finding those error. I've just fixed the code
of code-pages.el. Although you didn't list it, 0241 = A1 =
U+201D was also incorrectly decoded.
---
Ken'ichi H
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> Am 09.04.2005 um 01:46 schrieb Kenichi Handa:
>> Although you didn't list it, 0241 = A1 = U+201D was also incorrectly
>> decoded.
> Was too used to see ¡ always in this place ...
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> Unicode doesn't say which syntax a character should have in
>> Emacs.
> I know it doesn't in detail -- the Emacs syntax code
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> Sorry, I don't remember what discussion we had and which
>> code I showed you.
> For what it's worth, I think you suggested t
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
> Hmm... indeed the translation-table-for-input is not used for X11 keys.
> Now that I look at it a bit more, I think the patch below would make sense.
> What do other people think?
That doesn't work in some case. The val
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> Hmm... indeed the translation-table-for-input is not used for X11 keys.
>>> Now that I look at it a bit more, I think the patch below would make sense.
>>> What do other people think?
>> That doesn't work in some c
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> No, I can't. But shouldn't we avoid such an incompatible
>> change at this stage?
> Can be. But since it's about a year now since we called a freeze and I see
> no sign of getting to the pretest stage, I figure I do
In article <[EMAIL PROTECTED]>, Dave Love <[EMAIL PROTECTED]> writes:
> With the default case-fold-search (i.e. t), set the language
> environment to Latin-1 and do M-x list-charset-chars latin-iso8859-1
> C-x o C-\ C-s "a i.e. search for ä. This finds ä, but not Ä, although
> C-s a finds both a
isplayed as a
>> white rectangle. Before this change, and in Emacs 21.3, the Euro sign
>> was displayed as expected.
>>
>> 2005-04-20 Kenichi Handa <[EMAIL PROTECTED]>
>>
>> * lisp.h (CHAR_TABLE_DEFAULT_SLOT_ASCII): New macro. .
In article <[EMAIL PROTECTED]>, David PONCE <[EMAIL PROTECTED]> writes:
> Since I updated my local copy of Emacs 22 with the following change,
> when I type an Euro sign character (Altgr+E) it is now displayed as a
> white rectangle. Before this change, and in Emacs 21.3, the Euro sign
> was displ
me:
> Selected encoding raw-text-unix disagrees with iso-8859-1-unix
> specified by file contents. Really save (else edit coding cookies
> and try again)? (yes or no)
---
Ken'ichi HANDA
[EMAIL PROTECTED]
2005-04-25 Kenichi Handa <[EMAIL PROTECTED]>
* internat
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> The very right way is to shift to emacs-unicode. As long as
>> we have multiple character codes for characters that user
>> don't want to distinguish, any fix is just a dirty work
>> around.
> I'm not sure about "w
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> Is there any reason why fonts in these encodings can't be used as
> elements of a fontset?
That's because Emacs doesn't have such charsets. What Emacs
has is coding systems iso-8859-10 (iso-latin-6) and
iso-8859-13 (iso
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes:
> We (me and Stefan) has already shown opinions and solutions
> to the problem. Richard, could you please decide what to
> do?
> I have not been reading these messages, because they were numerous and
> long.
In article <[EMAIL PROTECTED]>, Luc Teirlinck <[EMAIL PROTECTED]> writes:
> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant. If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicod
In article <[EMAIL PROTECTED]>, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> The problem is apparently caused by being out of sync with the trunk
> in the font handling part. It would not be too difficult to cure
> that problem in the unicode-2 branch by adjusting the trunk code
> that
In article <[EMAIL PROTECTED]>, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
>> If it gets usable,
>> * We can have more test-users of emacs-unicode, and
>> * we don't have to spend time on replying to this kind of question
>> any more. :-p
> Without ATSUI support, I expect we'll get a
In article <[EMAIL PROTECTED]>, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> Anyway, I've just installed a change for trivial cases, and at least
> it should startup now.
Thank you very much!
> I'd like to wait for a response from Steven because
> further changes require some investigation,
ian-bdf and
bulgarian-phonetic input methods for Bulgarian. They are
listed when you type C-h L RET
(describe-language-environment). They produce characters of
charset mule-unicode-0100-24ff, and thus can be saved safely
by cp1251.
By the w
In article <[EMAIL PROTECTED]>, Ognyan Kulev <[EMAIL PROTECTED]> writes:
> Kenichi Handa wrote:
>> In short, Emacs 22 provides only bulgarian-bdf and
>> bulgarian-phonetic input methods for Bulgarian. They are
>> listed when you type C-h L RET
>>
In article <[EMAIL PROTECTED]>, Kenichi Handa <[EMAIL PROTECTED]> writes:
> Coding system cp1251 of Emacs 21 handles characters of
> Emacs' internal charset cyrillic-iso8859-5 (thus it can
> read/write only characters belonging to iso8859-5), but that
> of Emacs 2
. But, it's strange. I remember
I installed something like that long ago. And, ChangeLog
surely has this entry.
2004-06-11 Kenichi Handa <[EMAIL PROTECTED]>
* coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
A
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Yes, the patch is correct. But, it's strange. I remember
>> I installed something like that long ago. And, ChangeLog
>> surely has this entry.
>> 200
>
> Recent messages:
> Loading view...done
> Loading outline...done
> Loading vc-cvs...done
> View mode: type C-h for help, h for commands, q to quit.
> Quit
> Loading sendmail...done
> Quit [2 times]
> Making c
In article <[EMAIL PROTECTED]>, sangu <[EMAIL PROTECTED]> writes:
> HI!
> 2005-06-12 (일), 20:31 +0900, Kenichi Handa 쓰시길:
>> In article <[EMAIL PROTECTED]>, sangu <[EMAIL PROTECTED]> writes:
>>
>> > //gulimche is Korean truetype fixed font.
ot;make bootstrap". It seems
that the recent merge Miles has done fixed the above problem.
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ve garbage-collection-messages
> set to t) which required conversion as well, using the same buffer that was
> still being converted.
Thank you for finding the cause of this bug. I've just
installed the attached change. Could you please try it?
---
Kenichi Handa
[EMAIL PROTECTED]
20
ed files, as
If Tramp uses comint for transferring files, it should
anyway set process coding system to `no-conversion' (at
least while transferring files).
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
uot;)))
> (load "term/rxvt")
> THE REST OF TERM/XTERM.EL
> )
Isnt't it cleaner to modify startup.el?
---
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]>, Dan Nicolaescu <[EMAIL PROTECTED]> writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> In article <[EMAIL PROTECTED]>, Dan Nicolaescu <[EMAIL PROTECTED]> writes:
>> > How about we put something like tha
input by typing "zi". My
Chinese-Japanese dictionary also lists it under "zi". And,
Unicode's unihan database contains this line (子 is U+5B50):
U+5B50 kHanyuPinlu zi5(6853) zi3(1114)
---
Kenichi Handa
[EMAIL PROTECTED]
_
is called and
it (re)loads the tables if necessary. But, the decoding of
keyboard input via XIM is done in handle_one_xevent of
xterm.c, and I'm not sure we can call Lisp there. So, I
dared not call post-read-conversion function there.
---
Kenichi Handa
[EMAIL PROTECTED]
2005-09-23 Kenichi
in read_char.
I have not yet considered this problem in deep, but it seems
that kbd_buffer_get_event is the appropriate place to
perform decoding.
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
e better suited.
I see, though I have not yet checked if kbd_buffer_get_event
can safely call Lisp.
> BTW, hopefully making such a change would allow us to handle the funny X11
> keysyms of the form "U" for unicode char ""
(bold-italic builtin "FONTNAME_FOR_BOLD_ITALIC" ps-mule-encode-8bit))
ps-mule-font-info-database-ps)
(setq ps-multibyte-buffer 'non-latin-printer)
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
-table is not
modified, for instance, \300 is incorrectly changed to \340
by downcasing.
I've just installed the attached fix. It should fix the
current problem, but it still has a problem. That is, when
you start Emacs with --unibyte, and later set
enable-multibyte-buffer to t, case tables a
moveto
(D0-DF:\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337) show
100 200 moveto
(E0-EF:\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357) show
100 150 moveto
(F0-FF:\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377) show
showpage
cut h
uffer "*Character List*".
This works at least in my environment. But, as we need
non-trivial change to the current code to make that work in
general, I think we must wait for Emacs 23.
---
Kenichi Handa
[EMAIL PROTECTED]
*** ps-prin1.ps 07 Jul 2005 11:07:43 +0900
suggest to
> add it to the trunk. Not being able to print Latin-9 is a serious
> problem, IMHO.
Hmmm, ok, I'll investigate whether there is a way to achieve
that without a big change of the current code.
---
Kenichi Handa
[EMAIL PROTECTED]
_
l
> latin-9.el
> But their names still appear in lib-src/makefile.w32-in, when
> emacs-unicode-2 branch is compiled on Windows platform, that will
> cause some compile errors.
Thank you for the report. I've just installed your change.
---
Kenichi Handa
[EMAIL PROTECTED]
_
while searching for `i'.
>Every successive `C-s' takes at least 1 sec.
As `i' now can match with dotless-i and dotted-I, we can't
use BM search to search for a text containing `i'. So,
searching for such a text should become slower. But, at
least for interactive u
Thank you for the bug report. I've just added autoload
cookies to utf-7-{post-read|pre-write}-conversion.
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
dy entered.
Though, I admit that it's not convenient. We long ago
discussed about a way to improve the behaviour of isearch in
such a case, but, as far as I remember, no one has provided
a concrete code.
---
Kenichi Handa
[EMAIL PROTECTED]
___
eing before or after the previously found "o". So, isearch
sometimes moves point back and forward.
But, for the moment, no one has worked on implementing it.
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
. This is wrong. When the input
> sequence "shc" is completed, the result should be "шц", i.e. the first
> character corresponding to "sh", and the second - translated according
> to the rules of the same input method, as if "c" was typed solely.
[...]
&
make input method function accept
INPUT-CONTEXT as the second arg, update it, and return
(EVENT-SEQ . INPUT-CONTEXT) instantly. In the case of "o",
the returned EVENT-SEQ is nil which means no events to
propagate but INPUT-CONTEXT can carry infor
using the fix below. Please review this fix very
> carefully, since I am not familiar with the quail code at all, and
> it may break something else.
It seems that the change is incomplete. At least it should
handle the case that `str1' is nil, perhaps by trying
to lookup shorter k
reak
> is allowed at '\,'.
Thank you for the contribution. I agree that the change is
good, so I've just installed it.
---
Kenichi Handa
[EMAIL PROTECTED]
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
e will always be zh_CN.GB.
> This could be improved by the following patch:
Thank you. I've just installed your change.
---
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]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> The `locale-preferred-coding-systems' variable should also
> be improved for chinese locales.
Thank you that change was also installed.
---
Kenichi
translation in such
cases (e.g. you'll see what I meen when you type "chua" in
chinese-py).
> But I think this doesn't mean that the input method is not well
> designed. I must say that this input method is highly unambiguous.
To input "шч", you must type, fo
t; --
> but no change in pop-up buffers menu!
All those confusions are because of normalization form used
on your system. Emacs and the system don't agree with file
name encoding.
Mr. Kawabata is now working on implementing converters
between a
2 too? There is
> something needed for this too ...
As I have not yet checked his code, I don't know. But I
suspect that his code assumes that Emacs can handle all
Unicode characters and that is not true for Emacs 22, which
means we need fairly amount of extra
20 20 20 20 20 20 20
020 9e 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
040 9e 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
060 9e 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
100
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
e can't improve this situation in the current Emacs 22
without huge amount of nontrivial changes.
---
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]>, Michael Ernst <[EMAIL PROTECTED]> writes:
> This patch deletes some spurious trailing whitespace in two files.
Thank you! I've just committed those changes.
---
Kenichi Handa
[EMAIL PROTECTED]
_
that rmail-mime package is
currently not available on the web. So, I created this page:
<http://www.m17n.org/rmail-mime/index.html>.
---
Kenichi Handa
[EMAIL PROTECTED]
*** rmail.el10 Jan 2006 20:52:13 +0900 1.418
--- rmail.el11 Jan 2006 13:24:19 +0900
***
***
: symbolp, "autodefs.el"
> make: *** [autodefs.el] Error 255
There's also another problem for this package.
I'll update a new vesion as soon as the problem of
mh-acros.el advising `require' is fixed.
---
Kenichi Handa
[EMAIL PROTECTED]
__
In article <[EMAIL PROTECTED]>, Kenichi Handa <[EMAIL PROTECTED]> writes:
> In article
> <[EMAIL PROTECTED]>,
> Xavier Maillard <[EMAIL PROTECTED]> writes:
>> Except that here, it just fails when trying to make it:
>> [EMAIL PROTECTED] 22:37:02 rma
has worked without this
> error until recently.
I've just installed nxml-mode-20041004 and tried
rng-validate-mode on several xml files, but it shows "Using
vacuous schema" without error. Please send me same sample
file that trigers that error.
---
Kenichi Handa
[EMAIL PROTECT
lias of mule-utf-8)
UTF-8 encoding for Emacs-supported Unicode characters.
It supports Unicode characters of these ranges:
U+..U+33FF, U+E000..U+.
They correspond to these Emacs character sets:
ascii, latin-iso8859-1, mule-unicode-0100-24ff,
mule-unicode-2500-33ff, mule-unicode
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes:
> While compiling GNU Emacs 23 these showed up:
All of them will be fixed when they are fixed in Emacs 22
(CVS HEAD) and the changes are reflected to Emacs 23.
---
Kenichi Handa
[EMAIL PROTECTED]
>
om raw-8-bit char 0xC0 in a multibyte
buffer. Perhaps, we should add a new function `byte-after'
(which signals an error when a multibyte character is
found).
By the way, your changes are accumulating, and soon reach
the limit of 15 lines. For further changes, FSF requires
assignement paper fr
e-key test-menu [test-insert]
'(menu-item "å ä ö Å" (lambda () (interactive) (insert "å ä ö Å"
> Maybe specific to Aquamacs 0.9.6?
I have no idea.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
te sequence.
By the way, I've just installed debian package "xcingb"
(which include crxvt-gb-2.3). But, when I run it with
LANG=zh_CN.bgk, it doesn't send/accept ctext to/from Emacs.
It only sends/accepts GBK encoded text (or perhaps it's just
GB2312 en
/emacs/${version}/site-lisp:${datadir}/emacs/site-lisp:${datadir}/emacs/${version}/leim
and the other variables are:
datadir=${prefix}/share
version=23.0.0
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Nozomu Ando <[EMAIL PROTECTED]> writes:
> emacs-unicode-2 hangs when finding a file contains "\0".
Thank you for finding this bug. I've just committed a fix.
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug ma
1 - 100 of 329 matches
Mail list logo
