Zhang Wei [EMAIL PROTECTED] writes:
This bug is quite subtle and hard to trace. The problem is that other
applications collaborate with gnome-settings-daemon quite well except
Emacs, and you can activate XIM in Emacs with no difficulty if
gnome-settings-daemon is not running.
If Emacs _did_
If the timer function cancels the timer, the timer should not
be triggered again. So if three repetitions for times T+2,
T+4 and T+6 have been delayed until time T+7, and the first
call (which should have been at T+2) cancels the timer, the
timer should not reschedule itself for T+4, and
Am 21.09.2006 um 04:13 schrieb Kenichi Handa:
In article [EMAIL PROTECTED], Peter
Dyballa [EMAIL PROTECTED] writes:
The CVS code is from Sunday or Monday. After applying your patch
nothing changes for my simple test (emacs-22.0.50 -Q). I did it also
for °, which can't be found in ISO
Am 21.09.2006 um 04:27 schrieb Kenichi Handa:
In article [EMAIL PROTECTED], Peter
Dyballa [EMAIL PROTECTED] writes:
My test files starts with: ;;; -*- coding: iso-8859-6; -*-
The mode-line starts with -6:
GNU Emacs 22.0.50 was started with -Q
When I try to save it I get in
Miles Bader [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Kim F. Storm) writes:
I have added new primitive memql, and modified pushnew and member* to use it.
Er, well Richard said to wait until after the release, but ...
But it was later said that making the change fixed a different bug...
I
2006/9/21, Miles Bader [EMAIL PROTECTED]:
If Emacs _did_ cooperate, it would screw up common Emacs bindings. That
isn't a problem for many Gnome apps, because they barely use any
keybindings, but Emacs obviously uses keybindings very heavily, and this
particular keybinding is extremely common
2006/9/21, Richard Stallman [EMAIL PROTECTED]:
The developers of the gnome-settings-daemon should not have chosen a
character that is so important for Emacs. Can you tell me their names
and email addresses, so I can talk with them about this?
I have talked to some of the initial reporters of
[EMAIL PROTECTED] (Kim F. Storm) writes:
A change to `pushnew' is not necessary anyway: for simple cases (a value
with no side-effects), the change to `member*' is enough to do the job,
so `pushnew' itself can just be reverted to what it was before Richard's
change (just calling adjoin).
On Thu, Sep 20 2006, Andreas Roehler wrote:
Little correction, concerning last mail to Reiner Steib:
Phenomen is gone if I
- mark and delete a portion from the beginning of the buffer
- mark and delete a portion from the end of the buffer
- save and reopen;
also - as reported - its
Pressing TAB on each line in this file.sh produces the first line of
this case expression indented different than the rest:
(sed 's/.$/ /'|while read route company; do case $company in
r)set 仁友 Renyou;;
z)set 台中 Taizhong;;
q)set 全航 Quanhang;;
j)set 巨業
Miles Bader [EMAIL PROTECTED] writes:
IIRC, the reason for Richard's change was simply to make pushnew with
default arguments (no :test keyword arg) usable in compiled code that
only does (eval-when-compile (require 'cl)) -- before that wasn't the
case because the default predicate for
There is nothing in the documentation that suggests that it
should generate a unique value for every possible key sequence.
Maybe there is nothing about that in the doc, but doesn't it
seem logical?
No. If that was its purpose, then it should be called
Shouldn't the `single-key-description of a Chinese etc.
character simply be that Chinese character in a string?
Er, perhaps I misunderstand you, but that's exactly what it
appears to be:
(single-key-description ?字)
字
Do you see something different?
Er, yes.
K Which toolkit are you using with Emacs?
GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2006-08-18 on pacem, modified by Debian
(Debian emacs-snapshot package, version 1:20060817-1)
X server distributor `The X.Org Foundation', version 11.0.7000
configured using
So, I've just installed the attached change. But, there
still exists a case that isearch fails. For instance, if
your buffer's buffer-file-coding-system is iso-8859-2, and
you somehow insert a-acute of iso-8859-1, isearch won't be
able to find that a-acute. The fix for that
I don't think it is unreasonable for single-key-description to use the
same description for these many thousands of characters especially if
they are not produced directly by any keyboard in common use.
If those values are meaningless junk, then it is not crucial what happens
for
Shouldn't the `single-key-description of a Chinese etc. character simply be
that Chinese character in a string?
In an ideal world, that would be ok, but most people's terminals probably
can't display the Chinese character, so they will see just a box.
Er, well Richard said to wait until after the release, but ...
Yes, I did.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Shouldn't the `single-key-description of a Chinese etc.
character simply be that Chinese character in a string?
In an ideal world, that would be ok, but most people's
terminals probably
can't display the Chinese character, so they will see just a box.
That would be
GNU Emacs 22.0.50 was started with -Q
When I try to save it I get in mini-buffer:
Selected encoding mule-utf-8-unix disagrees with iso-8859-6-unix
specified by file contents. Really save (else edit coding cookies
and try again)? (yes or no)
What caused
This bug has nothing to do with keybindings. Whatever hotkey is used
for activate the input method, they won't function in Emacs if the
gnome-settings-daemon is running, evenif you select the XIM panel with
mouse, that means you won't find a way to input chinese with XIM in
`ispell-change-dictionary' does not change the global dictionary if
the local dictionary has the value we try to change to. For instance,
the following code should return en_GB (as the 3rd call to
`ispell-change-dictionary' changed global dictionary to en_GB) but
the result is en.
Moreover,
From: Chris Moore [EMAIL PROTECTED]
To: emacs-pretest-bug@gnu.org
Subject: ads
Reply-to: Chris Moore [EMAIL PROTECTED]
FCC: ~/Mail/SENT
--text follows this line--
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
If I use 'dired' on a directory which has
On Fri, 2006-09-22 at 00:17 +0200, Chris Moore wrote:
If I use 'dired' on a directory which has a subdirectory with a name
ending with a colon, and do a recursive directory listing in there, I
can't visit any files under subdirectories.
It seems the problem is related to the value of
Am 21.09.2006 um 04:27 schrieb Kenichi Handa:
In article [EMAIL PROTECTED], Peter
Dyballa [EMAIL PROTECTED] writes:
My test files starts with: ;;; -*- coding: iso-8859-6; -*-
The mode-line starts with -6:
GNU Emacs 22.0.50 was started with -Q
When I try to save it I get in
On Fri, 2006-09-22 at 00:31 +0200, Chris Moore wrote:
It seems the problem is related to the value of dired-subdir-alist.
The problem doesn't only happen with directories whose names end with a
colon, it also happens with directories, sockets, symlinks, fifos, etc,
etc.
The following patch
Am 21.09.2006 um 04:13 schrieb Kenichi Handa:
In article [EMAIL PROTECTED], Peter
Dyballa [EMAIL PROTECTED] writes:
The CVS code is from Sunday or Monday. After applying your patch
nothing changes for my simple test (emacs-22.0.50 -Q). I did it also
for °, which can't be found in ISO
On Fri, 2006-09-22 at 01:18 +0200, Chris Moore wrote:
The following patch makes things better for me
I've found a better patch. There's a bug in dired-build-subdir-alist().
It loops through the buffer looking for lines which match
dired-subdir-regexp, but the loop breaks when the first filename
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
29 matches
Mail list logo
