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.
is there any reason not to propagate it there?
If it will be propagated, that will
In article [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] writes:
As I said, I don't really know anything about emacs 23, nor do I know
very much about unicode for that matter. I just thought that there
might be more such links between characters of different rows in
Hi all,
sorry for the delayed response, I've been rather busy these days.
@Reiner: Thanks for Cc-ing me, otherwise I'd most likely have missed
this thread.
Reiner Steib [EMAIL PROTECTED] wrote:
On Thu, Nov 09 2006, Alexandre Oliva wrote:
Ultimately, I'm a bit concerned about messing with the
This should be fixed in the current sources. Is it?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Reiner Steib wrote:
As Elias Oltmanns already has pointed out, the problem is that
nnfolder often does re-searches for X-Gnus-Article-Number:
(`nnfolder-article-marker'). Wrapping these calls inside ...
(with-case-table some-case-table-without-dotless-i/dotted-I
(re-search-forward
On Thu, Nov 09 2006, Alexandre Oliva wrote:
Ultimately, I'm a bit concerned about messing with the case table of
an nnfolder buffer for the entire duration of the buffer. It's hard
to tell whether there'd be any less visible fallouts.
Richard has eliminated the peculiar upcasing dotless-i to
I wrote code to (1) eliminate the peculiar upcasing dotless-i to I,
and downcasing I-with-dot to i in the default case, and (2) make the
Turkish language environment fully set up Turkish case conversion for
all four characters.
I will install it soon.
It works in that it does speed up entering in new folders.
However, it breaks mail splitting in that, at the time buffers are to
be saved, vc-before-save ends up trying to require vc-RCS, so
newly-split e-mail is not saved, remaining in open modified buffers
until I override
On Nov 8, 2006, Reiner Steib [EMAIL PROTECTED] wrote:
On Tue, Nov 07 2006, Reiner Steib wrote:
Alexandre and Elias: Does this patch give good results?
Please consider this patch instead:
Thanks for the patch. It works, but it doesn't.
It works in that it does speed up entering in new
On Tue, Nov 07 2006, Reiner Steib wrote:
Alexandre and Elias: Does this patch give good results?
Please consider this patch instead:
--8---cut here---start-8---
--- nnheader.el 01 Aug 2006 12:10:19 +0200 7.24
+++ nnheader.el 08 Nov 2006 15:33:18 +0100
[ Cc-ing Elias Oltmanns; See
http://thread.gmane.org/or4ptezc71.fsf%40fsfla.org or
http://thread.gmane.org/gmane.emacs.gnus.general/63925/focus=63929
for the full thread. ]
On Mon, Nov 06 2006, Alexandre Oliva wrote:
On Nov 6, 2006, Reiner Steib [EMAIL PROTECTED] wrote:
My guess is
On Mon, Nov 06 2006, Katsumi Yamaoka wrote:
In [EMAIL PROTECTED] Richard Stallman wrote:
Scoring of the messages closer to the beginning of the buffer is fast,
but as we move to higher-numbered messages, that are closer to the end
of such big files/buffers, gnus will only score
On Nov 6, 2006, Reiner Steib [EMAIL PROTECTED] wrote:
My guess is that it's problem with case-fold-search when searching for
X-Gnus-Article-Number in mbox files in Emacs 22 as analyzed by Elias
Oltmanns back in June:
Yep, that's it!
| --- ~/.emacs ---
| (unless ( emacs-major-version 22)
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I use gnus to read my e-mail, and most of my messages are in nnfolder
groups. This means lots and lots of messages are kept in a single
mbox-like file. A few commonly-used groups have their e-mail
Scoring of the messages closer to the beginning of the buffer is fast,
but as we move to higher-numbered messages, that are closer to the end
of such big files/buffers, gnus will only score 2-3 messages per
minute, and that's what kills performance.
Does Gnus make lots of
In [EMAIL PROTECTED] Richard Stallman wrote:
Scoring of the messages closer to the beginning of the buffer is fast,
but as we move to higher-numbered messages, that are closer to the end
of such big files/buffers, gnus will only score 2-3 messages per
minute, and that's what
16 matches
Mail list logo
