* Re: Group, Summary buffers: End of line contain whitespaces
[not found] <87abfkmuko.fsf@jondo.cante.net>
@ 2008-08-13 8:29 ` Katsumi Yamaoka
2008-08-13 18:56 ` Reiner Steib
2008-08-22 15:52 ` Ted Zlatanov
0 siblings, 2 replies; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-08-13 8:29 UTC (permalink / raw)
To: Jari Aalto; +Cc: bugs, ding
>>>>> Jari Aalto wrote:
> With setting:
> (setq-default show-trailing-whitespace t)
> The *Group* and **Summary* buffers seem to have EOL whitespaces. It
> would be nice if these could be taken cared of (consider: copy/pasting
> the buffer contents/areas elsewhere).
> [2. Summary buffer --- image/png; gnus-1.png]
=> http://www.jpl.org/tmp/gnus-1.png
> [3. Group buffer --- image/png; gnus-2.png]
=> http://www.jpl.org/tmp/gnus-2.png
It is due to the space character that the default values of the
following variables contain:
`gnus-group-line-format'
"%M\%S\%p\%P\%5y:%B%(%g%)%l %O\n" --- Gnus v5.11
"%M\%S\%p\%P\%5y:%B%(%g%)%O\n" --- Gnus v5.13
`gnus-summary-line-format'
"%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n" --- Gnus v5.11 and v5.13
You use Gnus v5.11. So, for *Group* you can simply replace it with
that of Gnus v5.13 since GroupLens (i.e. %l) is no longer available.
For *Summary*, though it doesn't look good for me, this will work:
(setq gnus-summary-line-format "%U%R%z%I%(%[%4L: %-23,23f%]%)%s\n")
I'm not sure what is the best way but I have two ideas. One is
to remove trailing whitespace after the group buffer and the summary
buffer have been generated or updated:
--8<---------------cut here---------------start------------->8---
(add-hook
'gnus-group-prepare-hook
(lambda nil
(save-excursion
(goto-char (point-min))
(while (re-search-forward " +$" nil t)
(delete-region (match-beginning 0) (match-end 0))))))
(add-hook
'gnus-group-update-group-hook
(lambda nil
(end-of-line)
(skip-chars-backward " ")
(delete-region (point) (point-at-eol))))
(add-hook
'gnus-summary-prepare-hook
(lambda nil
(while (re-search-forward " +$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))))
--8<---------------cut here---------------end--------------->8---
The other is to make the format-spec (which is a Lisp form) remove
trailing whitespace by itself:
--8<---------------cut here---------------start------------->8---
--- gnus-spec.el~ 2008-03-02 21:50:11 +0000
+++ gnus-spec.el 2008-08-13 08:25:45 +0000
@@ -703,7 +703,14 @@
(when result
(if dontinsert
result
- (cons 'insert result)))
+ `(progn
+ (insert ,@result)
+ (if (bolp)
+ (progn
+ (end-of-line 0)
+ (skip-chars-backward " ")
+ (delete-region (point) (point-at-eol))
+ (forward-line 1))))))
(cond ((stringp result)
result)
((consp result)
--8<---------------cut here---------------end--------------->8---
Maybe the former is faster than the later. Before trying the later,
you need to eval the form:
(gnus-update-format-specifications t 'group 'summary)
Regards,
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka
@ 2008-08-13 18:56 ` Reiner Steib
2008-08-13 21:47 ` Jari Aalto
2008-08-22 15:52 ` Ted Zlatanov
1 sibling, 1 reply; 31+ messages in thread
From: Reiner Steib @ 2008-08-13 18:56 UTC (permalink / raw)
To: Jari Aalto, ding
On Wed, Aug 13 2008, Katsumi Yamaoka wrote:
>>>>>> Jari Aalto wrote:
>> (setq-default show-trailing-whitespace t)
[...]
> I'm not sure what is the best way but I have two ideas. One is
> to remove trailing whitespace after the group buffer and the summary
> buffer have been generated or updated: [...]
Why not just set show-trailing-whitespace to nil buffer-locally?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-13 18:56 ` Reiner Steib
@ 2008-08-13 21:47 ` Jari Aalto
2008-08-15 16:31 ` jidanni
2008-08-19 11:48 ` Miles Bader
0 siblings, 2 replies; 31+ messages in thread
From: Jari Aalto @ 2008-08-13 21:47 UTC (permalink / raw)
To: ding
Reiner Steib <reinersteib+gmane@imap.cc> writes:
> On Wed, Aug 13 2008, Katsumi Yamaoka wrote:
>
>>>>>>> Jari Aalto wrote:
>>> (setq-default show-trailing-whitespace t)
> [...]
>> I'm not sure what is the best way but I have two ideas. One is
>> to remove trailing whitespace after the group buffer and the summary
>> buffer have been generated or updated: [...]
>
> Why not just set show-trailing-whitespace to nil buffer-locally?
Copying the files from buffer with copy/paste is still a problem with
trailing spaces. It would be best if buffer had none.
Jari
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-13 21:47 ` Jari Aalto
@ 2008-08-15 16:31 ` jidanni
2008-08-19 11:48 ` Miles Bader
1 sibling, 0 replies; 31+ messages in thread
From: jidanni @ 2008-08-15 16:31 UTC (permalink / raw)
To: ding
> Why not just set show-trailing-whitespace to nil buffer-locally?
Shame on such "sweep the problem under the rug" thoughts.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-13 21:47 ` Jari Aalto
2008-08-15 16:31 ` jidanni
@ 2008-08-19 11:48 ` Miles Bader
1 sibling, 0 replies; 31+ messages in thread
From: Miles Bader @ 2008-08-19 11:48 UTC (permalink / raw)
To: ding
Jari Aalto <jari.aalto@cante.net> writes:
>> Why not just set show-trailing-whitespace to nil buffer-locally?
>
> Copying the files from buffer with copy/paste is still a problem with
> trailing spaces. It would be best if buffer had none.
If you don't like it, you can always use "M-x delete-trailing-whitespace"
after pasting.
-Miles
--
Year, n. A period of three hundred and sixty-five disappointments.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka
2008-08-13 18:56 ` Reiner Steib
@ 2008-08-22 15:52 ` Ted Zlatanov
2008-08-27 23:01 ` Miles Bader
1 sibling, 1 reply; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-22 15:52 UTC (permalink / raw)
To: ding
On Wed, 13 Aug 2008 17:29:40 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:
KY> The other is to make the format-spec (which is a Lisp form) remove
KY> trailing whitespace by itself:
KY> --- gnus-spec.el~ 2008-03-02 21:50:11 +0000
KY> +++ gnus-spec.el 2008-08-13 08:25:45 +0000
KY> @@ -703,7 +703,14 @@
KY> (when result
KY> (if dontinsert
KY> result
KY> - (cons 'insert result)))
KY> + `(progn
KY> + (insert ,@result)
KY> + (if (bolp)
KY> + (progn
KY> + (end-of-line 0)
KY> + (skip-chars-backward " ")
KY> + (delete-region (point) (point-at-eol))
KY> + (forward-line 1))))))
KY> (cond ((stringp result)
KY> result)
KY> ((consp result)
I think this is the right solution. No one has explained why we need
the trailing spaces AFAIK.
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-22 15:52 ` Ted Zlatanov
@ 2008-08-27 23:01 ` Miles Bader
2008-08-28 13:51 ` Ted Zlatanov
0 siblings, 1 reply; 31+ messages in thread
From: Miles Bader @ 2008-08-27 23:01 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: ding
Ted Zlatanov <tzz@lifelogs.com> writes:
> I think this is the right solution. No one has explained why we need
> the trailing spaces AFAIK.
I don't think anyone has claimed they're _needed_. It's more than they
aren't particularly harmful, and going to great lengths to avoid them is
silly.
-Miles
--
Advice, n. The smallest current coin.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-27 23:01 ` Miles Bader
@ 2008-08-28 13:51 ` Ted Zlatanov
2008-08-29 11:15 ` Reiner Steib
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-28 13:51 UTC (permalink / raw)
To: ding
On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote:
MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think this is the right solution. No one has explained why we need
>> the trailing spaces AFAIK.
MB> I don't think anyone has claimed they're _needed_. It's more than they
MB> aren't particularly harmful, and going to great lengths to avoid them is
MB> silly.
I don't think it's silly: we're producing unneeded data for no clear
purpose, and there's no harm in removing it. If so, it should be
removed. I can do it unless someone explains why I shouldn't.
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-28 13:51 ` Ted Zlatanov
@ 2008-08-29 11:15 ` Reiner Steib
2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov
2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov
2008-08-29 15:31 ` Daiki Ueno
2 siblings, 1 reply; 31+ messages in thread
From: Reiner Steib @ 2008-08-29 11:15 UTC (permalink / raw)
To: ding
On Thu, Aug 28 2008, Ted Zlatanov wrote:
> On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote:
>
> MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I think this is the right solution. No one has explained why we need
>>> the trailing spaces AFAIK.
>
> MB> I don't think anyone has claimed they're _needed_. It's more than they
> MB> aren't particularly harmful, and going to great lengths to avoid them is
> MB> silly.
>
> I don't think it's silly: we're producing unneeded data for no clear
> purpose, and there's no harm in removing it. If so, it should be
> removed. I can do it unless someone explains why I shouldn't.
IMHO it's a minor cosmetic "problem".
There are dozens of real bugs that are more important to fix: I have
~200 ticked articles in ding and more in gnus.gnus-bug and
gmane.emacs.*. Most of them are bug reports for Gnus. I hoped to be
able to at least forward them to the Emacs bug tracker. AFAIK,
there's not Emacs/Gnus function to do this conveniently yet [1].
So, if you think is worth to care about this trailing whitespace in
the Summary buffer, I won't object. But I think there's much more
useful and important work to do.
Bye, Reiner.
[1] Cf. http://thread.gmane.org/gmane.emacs.devel/93575/focus=94338
http://thread.gmane.org/gmane.emacs.devel/97827/focus=97932
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-28 13:51 ` Ted Zlatanov
2008-08-29 11:15 ` Reiner Steib
@ 2008-08-29 13:51 ` Ted Zlatanov
2008-08-29 15:31 ` Daiki Ueno
2 siblings, 0 replies; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-29 13:51 UTC (permalink / raw)
To: ding
On Thu, 28 Aug 2008 08:51:00 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote:
TZ> I don't think it's silly: we're producing unneeded data for no clear
TZ> purpose, and there's no harm in removing it. If so, it should be
TZ> removed. I can do it unless someone explains why I shouldn't.
I comitted Katsumi Yamaoka's patch, let me know if you see any issues.
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* bugs and features (was: Group, Summary buffers: End of line contain whitespaces)
2008-08-29 11:15 ` Reiner Steib
@ 2008-08-29 15:12 ` Ted Zlatanov
2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov
0 siblings, 1 reply; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-29 15:12 UTC (permalink / raw)
To: ding
On Fri, 29 Aug 2008 13:15:51 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote:
RS> IMHO it's a minor cosmetic "problem".
RS> There are dozens of real bugs that are more important to fix: I have
RS> ~200 ticked articles in ding and more in gnus.gnus-bug and
RS> gmane.emacs.*. Most of them are bug reports for Gnus. I hoped to be
RS> able to at least forward them to the Emacs bug tracker. AFAIK,
RS> there's not Emacs/Gnus function to do this conveniently yet [1].
I wish I could work on more issues: it's for lack of time and not for
lack of interest that I've been less productive.
Daiki Ueno's fix for IMAP also needs to be examined; that and Vitaly's
IMAP and backend patches are a pretty major undertaking.
I also need to write the gnus-registry documentation sometime this century.
RS> So, if you think is worth to care about this trailing whitespace in
RS> the Summary buffer, I won't object. But I think there's much more
RS> useful and important work to do.
I agree. But we had a patch, and it annoyed more than one person
apparently.
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-28 13:51 ` Ted Zlatanov
2008-08-29 11:15 ` Reiner Steib
2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov
@ 2008-08-29 15:31 ` Daiki Ueno
2008-08-29 15:55 ` Ted Zlatanov
2 siblings, 1 reply; 31+ messages in thread
From: Daiki Ueno @ 2008-08-29 15:31 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: ding
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote:
>
> MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I think this is the right solution. No one has explained why we need
>>> the trailing spaces AFAIK.
>
> MB> I don't think anyone has claimed they're _needed_. It's more than they
> MB> aren't particularly harmful, and going to great lengths to avoid them is
> MB> silly.
>
> I don't think it's silly: we're producing unneeded data for no clear
> purpose, and there's no harm in removing it. If so, it should be
> removed. I can do it unless someone explains why I shouldn't.
I also think that it's silly. After the patch applied,
(gnus-parse-format "%A" '((?A "ABCDE " ?s)))
=> (concat "ABCDE ")
(gnus-parse-format "%A" '((?A "ABCDE " ?s)) t)
=> "ABCDE"
Future Gnus developers will be troubled with the difference of the
results. Also, this change makes gnus-parse-simple-format specific for
rendering *Group* and *Summary* lines. That's a layer breakage.
I think Katsumi's first approach is even better.
Regards,
--
Daiki Ueno
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-29 15:31 ` Daiki Ueno
@ 2008-08-29 15:55 ` Ted Zlatanov
2008-08-30 5:07 ` Katsumi Yamaoka
0 siblings, 1 reply; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-29 15:55 UTC (permalink / raw)
To: ding
On Sat, 30 Aug 2008 00:31:24 +0900 Daiki Ueno <ueno@unixuser.org> wrote:
DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote:
>>
MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>> I think this is the right solution. No one has explained why we need
>>>> the trailing spaces AFAIK.
>>
MB> I don't think anyone has claimed they're _needed_. It's more than they
MB> aren't particularly harmful, and going to great lengths to avoid them is
MB> silly.
>>
>> I don't think it's silly: we're producing unneeded data for no clear
>> purpose, and there's no harm in removing it. If so, it should be
>> removed. I can do it unless someone explains why I shouldn't.
DU> I also think that it's silly. After the patch applied,
DU> (gnus-parse-format "%A" '((?A "ABCDE " ?s)))
DU> => (concat "ABCDE ")
DU> (gnus-parse-format "%A" '((?A "ABCDE " ?s)) t)
DU> => "ABCDE"
DU> Future Gnus developers will be troubled with the difference of the
DU> results. Also, this change makes gnus-parse-simple-format specific for
DU> rendering *Group* and *Summary* lines. That's a layer breakage.
DU> I think Katsumi's first approach is even better.
Before I revert and apply the other patch, I'd like to hear what Katsumi
thinks. I agree format and layer breakage is bad, and don't want to
break more inadvertently.
Thanks
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-29 15:55 ` Ted Zlatanov
@ 2008-08-30 5:07 ` Katsumi Yamaoka
2008-08-30 9:33 ` Ted Zlatanov
0 siblings, 1 reply; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-08-30 5:07 UTC (permalink / raw)
To: ding
>>>>> In <864p53ke7n.fsf@lifelogs.com>
>>>>> Ted Zlatanov <tzz@lifelogs.com> wrote:
DU> I think Katsumi's first approach is even better.
> Before I revert and apply the other patch, I'd like to hear what Katsumi
> thinks. I agree format and layer breakage is bad, and don't want to
> break more inadvertently.
I hesitated to propose that one because it will not only make
the Summary buffer generation slow a bit but also remove trailing
space characters *unconditionally*. So I agree with Daiki and
agree to revert the last change in gnus-spec.el.
Regards,
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces
2008-08-30 5:07 ` Katsumi Yamaoka
@ 2008-08-30 9:33 ` Ted Zlatanov
0 siblings, 0 replies; 31+ messages in thread
From: Ted Zlatanov @ 2008-08-30 9:33 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: ding
On Sat, 30 Aug 2008 14:07:54 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:
>>>>>> In <864p53ke7n.fsf@lifelogs.com>
>>>>>> Ted Zlatanov <tzz@lifelogs.com> wrote:
DU> I think Katsumi's first approach is even better.
>> Before I revert and apply the other patch, I'd like to hear what Katsumi
>> thinks. I agree format and layer breakage is bad, and don't want to
>> break more inadvertently.
KY> I hesitated to propose that one because it will not only make
KY> the Summary buffer generation slow a bit but also remove trailing
KY> space characters *unconditionally*. So I agree with Daiki and
KY> agree to revert the last change in gnus-spec.el.
All right, it's undone. We'll revisit this in 2020 :)
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* registry doc patch (was: bugs and features)
2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov
@ 2008-09-15 21:00 ` Ted Zlatanov
2008-09-16 9:17 ` registry doc patch Rupert Swarbrick
2008-09-16 12:30 ` Magnus Henoch
0 siblings, 2 replies; 31+ messages in thread
From: Ted Zlatanov @ 2008-09-15 21:00 UTC (permalink / raw)
To: ding
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
On Fri, 29 Aug 2008 10:12:06 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote:
TZ> I also need to write the gnus-registry documentation sometime this century.
The unthinkable has happened. Attached is a patch to the docs to
document the Gnus registry.
I didn't commit it because I'd like some comments (it's a very quick
read) and because the menu update screwed up the Gnus menus in it (I
edited that out of the patch), so I am not sure if the menus are
correct. It's been many years since I edited Texinfo so any hints are
welcome.
Ted
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: registry.gnus.texi.patch --]
[-- Type: text/x-diff, Size: 8698 bytes --]
Index: gnus.texi
===================================================================
RCS file: /usr/local/cvsroot/gnus/texi/gnus.texi,v
retrieving revision 7.305
diff -c -r7.305 gnus.texi
*** gnus.texi 8 Sep 2008 21:29:47 -0000 7.305
--- gnus.texi 15 Sep 2008 20:50:27 -0000
***************
*** 22740,22745 ****
--- 22209,22215 ----
* Fuzzy Matching:: What's the big fuzz?
* Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
* Spam Package:: A package for filtering and processing spam.
+ * The Gnus Registry:: A package for tracking messages by Message-ID.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@end menu
***************
*** 26502,26507 ****
--- 25972,26190 ----
Save table: (spam-stat-save)
@end smallexample
+ @node The Gnus Registry
+ @section The Gnus Registry
+
+ @cindex registry
+ @cindex split
+ @cindex track
+
+ The Gnus registry is a package that tracks messages by their
+ Message-ID across all backends. This allows Gnus users to do several
+ cool things, be the envy of the locals, get free haircuts, and be
+ experts on world issues. Well, maybe not all of those, but the
+ features are pretty cool.
+
+ Although they will be explained in detail shortly, here's a quick list
+ of said features in case your attention span is... never mind.
+
+ @enumerate
+
+ @item Split messages to their parent
+ This keeps discussions in the same group. You can use the subject and
+ the sender in addition to the Message-ID. Several strategies are
+ available.
+
+ @item Store custom flags and keywords
+ The registry can store custom flags and keywords for a message. For
+ instance, you can mark a message ``To-Do'' this way and the flag will
+ persist whether the message is in the nnimap, nnml, nnmaildir,
+ etc. backends.
+
+ @item Store arbitrary data
+ Through a simple ELisp API, the registry can remember any data for a
+ message. A built-in inverse map, when activated, allows quick lookups
+ of all messages matching a particular set of criteria.
+
+ @end enumerate
+
+
+ @menu
+ * Setup::
+ * Fancy splitting to parent::
+ * Store custom flags and keywords::
+ * Store arbitrary data::
+ @end menu
+
+ @node Setup
+ @subsection Setup
+
+ Fortunately, setting up the Gnus registry is pretty easy:
+
+ @lisp
+ (setq gnus-registry-max-entries 2500
+ gnus-registry-use-long-group-names t)
+
+ (gnus-registry-initialize)
+ @end lisp
+
+ This adds registry saves to Gnus newsrc saves (which happen on exit
+ and when you press @kbd{s} from the @code{*Group*} buffer. It also
+ adds registry calls to article actions in Gnus (copy, move, etc.) so
+ it's not easy to undo the initialization. See
+ @code{gnus-registry-initialize} for the gory details.
+
+ Here are other settings used by the author of the registry (understand
+ what they do before you copy them blindly).
+
+ @lisp
+ (setq
+ gnus-registry-split-strategy 'majority
+ gnus-registry-ignored-groups '(("nntp" t)
+ ("nnrss" t)
+ ("spam" t)
+ ("train" t))
+ gnus-registry-max-entries 500000
+ gnus-registry-use-long-group-names t
+ gnus-registry-track-extra '(sender subject))
+ @end lisp
+
+ They say: keep a lot of messages around, use long group names, track
+ messages by sender and subject (not just parent Message-ID), and when
+ the registry splits incoming mail, use a majority rule to decide where
+ messages should go if there's more than one possibility. In addition,
+ the registry should ignore messages in groups that match ``nntp'',
+ ``nnrss'', ``spam'', or ``train.''
+
+ You are doubtless impressed by all this, but you ask: ``I am a Gnus
+ user, I customize to live. Give me more.'' Here you go, these are
+ the general settings.
+
+ @defvar gnus-registry-unfollowed-groups
+ The groups that will not be followed by
+ @code{gnus-registry-split-fancy-with-parent}. They will still be
+ remembered by the registry. This is a list of regular expressions.
+ @end defvar
+
+ @defvar gnus-registry-ignored-groups
+ The groups that will not be remembered by the registry. This is a
+ list of regular expressions, also available through Group/Topic
+ customization (so you can ignore or keep a specific group or a whole
+ topic).
+ @end defvar
+
+ @defvar gnus-registry-use-long-group-names
+ Whether the registry will use long group names. It's recommended to
+ set this to t, although everything works if you don't. Future
+ functionality will require it.
+ @end defvar
+
+ @defvar gnus-registry-max-entries
+ The number (an integer or nil for unlimited) of entries the registry
+ will keep.
+ @end defvar
+
+ @defvar gnus-registry-cache-file
+ The file where the registry will be stored between Gnus sessions.
+ @end defvar
+
+ @node Fancy splitting to parent
+ @subsection Fancy splitting to parent
+
+ Simply put, this lets you put followup e-mail where it belongs.
+
+ Every message has a Message-ID, which is unique, and the registry
+ remembers it. When the message is moved or copied, the registry will
+ notice this and offer the new group as a choice to the splitting
+ strategy.
+
+ When a followup is made, usually it mentions the original message's
+ Message-ID in the headers. The registry knows this and uses that
+ mention to find the group where the original message lives. You only
+ have to put a rule like this:
+
+ @lisp
+ (setq nnimap-my-split-fancy '(|
+
+ ;; split to parent: you need this
+ (: gnus-registry-split-fancy-with-parent)
+
+ ;; other rules, as an example
+ (: spam-split)
+ ;; default mailbox
+ "mail")
+ @end lisp
+
+ in your fancy split setup. In addition, you may want to customize the
+ following variables.
+
+ @defvar gnus-registry-track-extra
+ This is a list of symbols, so it's best to change it from the
+ Customize interface. By default it's nil, but you may want to track
+ subject and sender as well when splitting by parent. It may work
+ for you. It can be annoying if your mail flow is large and people
+ don't stick to the same groups.
+ @end defvar
+
+ @defvar gnus-registry-split-strategy
+ This is a symbol, so it's best to change it from the Customize
+ interface. By default it's nil, but you may want to set it to
+ @code{'majority} or @code{'first} to split by sender or subject based
+ on the majority of matches or on the first found.
+ @end defvar
+
+ @node Store custom flags and keywords
+ @subsection Store custom flags and keywords
+
+ The registry lets you set custom flags and keywords per message. You
+ can use the Gnus->Registry Marks menu or the @kbd{M M x} keyboard
+ shortcuts, where @code{x} is the first letter of the mark's name.
+
+ @defvar gnus-registry-marks
+ The custom marks that the registry can use. You can modify the
+ default list, if you like. If you do, you'll have to exit Emacs
+ before they take effect (you can also unload the registry and reload
+ it or evaluate the specific macros you'll need, but you probably don't
+ want to bother). Use the Customize interface to modify the list.
+
+ By default this list has the Important, Work, Personal, To-Do, and
+ Later marks. They all have keyboard shortcuts like @kbd{M M i} for
+ Important, using the first letter.
+ @end defvar
+
+ @defun gnus-registry-mark-article
+ Call this function to mark an article with a custom registry mark. It
+ will offer the available marks for completion.
+ @end defun
+
+ @node Store arbitrary data
+ @subsection Store arbitrary data
+
+ The registry has a simple API that uses a Message-ID as the key to
+ store arbitrary data (as long as it can be converted to a list for
+ storage).
+
+ @defun gnus-registry-store-extra-entry (id key value)
+ Store @code{value} in the extra data key @code{key} for message
+ @code{id}.
+ @end defun
+
+ @defun gnus-registry-delete-extra-entry (id key)
+ Delete the extra data key @code{key} for message @code{id}.
+ @end defun
+
+ @defun gnus-registry-fetch-extra (id key)
+ Get the extra data key @code{key} for message @code{id}.
+ @end defun
+
+ @defvar gnus-registry-extra-entries-precious
+ If any extra entries are previous, their presence will make the
+ registry keep the whole entry forever, even if there are no groups for
+ the Message-ID and if the size limit of the registry is reached. By
+ default this is just @code{'(marks)} so the custom registry marks are
+ precious.
+ @end defvar
+
@node Other modes
@section Interaction with other modes
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov
@ 2008-09-16 9:17 ` Rupert Swarbrick
2008-09-16 13:36 ` Ted Zlatanov
2008-09-16 12:30 ` Magnus Henoch
1 sibling, 1 reply; 31+ messages in thread
From: Rupert Swarbrick @ 2008-09-16 9:17 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: ding
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
Ted Zlatanov <tzz@lifelogs.com> writes:
> The unthinkable has happened. Attached is a patch to the docs to
> document the Gnus registry.
I'm afraid I don't know much texinfo, but I have read through it for
spelling and grammar (and information!) and didn't find anything
wrong. I wasn't going to send anything, but thought maybe a +1 for "this
looks good" was worth having.
Rupert
P.S. When hitting C-u f, I got asked whether to strip the old
subject. It seems I've not replied to a message with an "old subject"
before. That's a really cool feature!
[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov
2008-09-16 9:17 ` registry doc patch Rupert Swarbrick
@ 2008-09-16 12:30 ` Magnus Henoch
2008-09-16 13:39 ` Ted Zlatanov
1 sibling, 1 reply; 31+ messages in thread
From: Magnus Henoch @ 2008-09-16 12:30 UTC (permalink / raw)
To: ding
Ted Zlatanov <tzz@lifelogs.com> writes:
> + @defvar gnus-registry-extra-entries-precious
> + If any extra entries are previous, their presence will make the
That should be "precious", I think.
Magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-16 9:17 ` registry doc patch Rupert Swarbrick
@ 2008-09-16 13:36 ` Ted Zlatanov
0 siblings, 0 replies; 31+ messages in thread
From: Ted Zlatanov @ 2008-09-16 13:36 UTC (permalink / raw)
To: ding
On Tue, 16 Sep 2008 10:17:27 +0100 Rupert Swarbrick <rswarbrick@googlemail.com> wrote:
RS> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The unthinkable has happened. Attached is a patch to the docs to
>> document the Gnus registry.
RS> I'm afraid I don't know much texinfo, but I have read through it for
RS> spelling and grammar (and information!) and didn't find anything
RS> wrong. I wasn't going to send anything, but thought maybe a +1 for "this
RS> looks good" was worth having.
Great, thanks. The goal is to make it cover only what people really
need to know; I can expand on anything you think was not well covered.
RS> P.S. When hitting C-u f, I got asked whether to strip the old
RS> subject. It seems I've not replied to a message with an "old subject"
RS> before. That's a really cool feature!
Yeah, it even knows about the AW: syntax used sometimes (in Germany IIRC).
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-16 12:30 ` Magnus Henoch
@ 2008-09-16 13:39 ` Ted Zlatanov
2008-09-18 23:19 ` Katsumi Yamaoka
0 siblings, 1 reply; 31+ messages in thread
From: Ted Zlatanov @ 2008-09-16 13:39 UTC (permalink / raw)
To: ding
On Tue, 16 Sep 2008 14:30:56 +0200 Magnus Henoch <mange@freemail.hu> wrote:
MH> Ted Zlatanov <tzz@lifelogs.com> writes:
>> + @defvar gnus-registry-extra-entries-precious
>> + If any extra entries are previous, their presence will make the
MH> That should be "precious", I think.
Thanks. With two looks, I'll assume it's not horrible and commit my
patch. Please let me know if you have corrections or it needs more
detail anywhere.
Thanks
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-16 13:39 ` Ted Zlatanov
@ 2008-09-18 23:19 ` Katsumi Yamaoka
2008-09-19 16:19 ` Ted Zlatanov
0 siblings, 1 reply; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-18 23:19 UTC (permalink / raw)
To: ding
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
>>>>> Ted Zlatanov wrote:
> Please let me know if you have corrections or it needs more detail
> anywhere.
Thank you for uploading the Gnus Registry manual. It will be
very useful for those who want to start using the registry (I'm
not an exception ;-). When having been translating the manual
into Japanese[1], I found some oddities there.
The menu entry had better be put in the `Top' node, too.
Conventionally `t' and `nil' are quoted with @code{} at least in
the Gnus manual (even though they aren't so in a doc string).
Some Lisp symbols used in values of the gnus-registry- variables
aren't quoted. Or they are quoted as if they are in Lisp forms.
A patch is attached below.
Regards,
[1] http://cvs.m17n.org/viewcvs/root/gnus-doc-ja/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3662 bytes --]
--- gnus.texi~ 2008-09-16 21:41:21 +0000
+++ gnus.texi 2008-09-18 23:17:52 +0000
@@ -827,6 +827,7 @@
* Fuzzy Matching:: What's the big fuzz?
* Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email.
* Spam Package:: A package for filtering and processing spam.
+* The Gnus Registry:: A package for tracking messages by Message-ID.
* Other modes:: Interaction with other modes.
* Various Various:: Things that are really various.
@@ -26606,13 +26607,13 @@
@defvar gnus-registry-use-long-group-names
Whether the registry will use long group names. It's recommended to
-set this to t, although everything works if you don't. Future
+set this to @code{t}, although everything works if you don't. Future
functionality will require it.
@end defvar
@defvar gnus-registry-max-entries
-The number (an integer or nil for unlimited) of entries the registry
-will keep.
+The number (an integer or @code{nil} for unlimited) of entries the
+registry will keep.
@end defvar
@defvar gnus-registry-cache-file
@@ -26627,7 +26628,7 @@
Every message has a Message-ID, which is unique, and the registry
remembers it. When the message is moved or copied, the registry will
notice this and offer the new group as a choice to the splitting
-strategy.
+strategy.
When a followup is made, usually it mentions the original message's
Message-ID in the headers. The registry knows this and uses that
@@ -26651,17 +26652,17 @@
@defvar gnus-registry-track-extra
This is a list of symbols, so it's best to change it from the
-Customize interface. By default it's nil, but you may want to track
-subject and sender as well when splitting by parent. It may work
-for you. It can be annoying if your mail flow is large and people
-don't stick to the same groups.
+Customize interface. By default it's @code{nil}, but you may want to
+track @code{subject} and @code{sender} as well when splitting by parent.
+It may work for you. It can be annoying if your mail flow is large and
+people don't stick to the same groups.
@end defvar
@defvar gnus-registry-split-strategy
This is a symbol, so it's best to change it from the Customize
-interface. By default it's nil, but you may want to set it to
-@code{'majority} or @code{'first} to split by sender or subject based
-on the majority of matches or on the first found.
+interface. By default it's @code{nil}, but you may want to set it to
+@code{majority} or @code{first} to split by sender or subject based on
+the majority of matches or on the first found.
@end defvar
@node Store custom flags and keywords
@@ -26678,9 +26679,10 @@
it or evaluate the specific macros you'll need, but you probably don't
want to bother). Use the Customize interface to modify the list.
-By default this list has the Important, Work, Personal, To-Do, and
-Later marks. They all have keyboard shortcuts like @kbd{M M i} for
-Important, using the first letter.
+By default this list has the @code{Important}, @code{Work},
+@code{Personal}, @code{To-Do}, and @code{Later} marks. They all have
+keyboard shortcuts like @kbd{M M i} for Important, using the first
+letter.
@end defvar
@defun gnus-registry-mark-article
@@ -26712,7 +26714,7 @@
If any extra entries are precious, their presence will make the
registry keep the whole entry forever, even if there are no groups for
the Message-ID and if the size limit of the registry is reached. By
-default this is just @code{'(marks)} so the custom registry marks are
+default this is just @code{(marks)} so the custom registry marks are
precious.
@end defvar
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-18 23:19 ` Katsumi Yamaoka
@ 2008-09-19 16:19 ` Ted Zlatanov
2008-09-23 19:18 ` Reiner Steib
0 siblings, 1 reply; 31+ messages in thread
From: Ted Zlatanov @ 2008-09-19 16:19 UTC (permalink / raw)
To: ding
On Fri, 19 Sep 2008 08:19:17 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:
>>>>>> Ted Zlatanov wrote:
>> Please let me know if you have corrections or it needs more detail
>> anywhere.
KY> Thank you for uploading the Gnus Registry manual. It will be
KY> very useful for those who want to start using the registry (I'm
KY> not an exception ;-). When having been translating the manual
KY> into Japanese[1], I found some oddities there.
KY> The menu entry had better be put in the `Top' node, too.
I thought I did that, oops.
KY> Conventionally `t' and `nil' are quoted with @code{} at least in
KY> the Gnus manual (even though they aren't so in a doc string).
KY> Some Lisp symbols used in values of the gnus-registry- variables
KY> aren't quoted. Or they are quoted as if they are in Lisp forms.
KY> A patch is attached below.
Thanks for catching all those issues. I applied your patch in your
name to expedite things.
Ted
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-19 16:19 ` Ted Zlatanov
@ 2008-09-23 19:18 ` Reiner Steib
2008-09-24 0:37 ` Katsumi Yamaoka
0 siblings, 1 reply; 31+ messages in thread
From: Reiner Steib @ 2008-09-23 19:18 UTC (permalink / raw)
To: ding
Hi,
formating the gnus.texi with MAKEINFO=no fails:
$ emacs -batch -q -no-site-file -l ./infohack.el -f batch-makeinfo gnus.texi
[...]
Formatting: Low-level interface to the spam-stat dictionary ...
Formatting: The Gnus Registry ...
Extraneous text at end of command line
make: *** [gnus] Error 255
Could someone please fix this?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-23 19:18 ` Reiner Steib
@ 2008-09-24 0:37 ` Katsumi Yamaoka
2008-09-24 6:45 ` Katsumi Yamaoka
2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib
0 siblings, 2 replies; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-24 0:37 UTC (permalink / raw)
To: ding
>>>>> Reiner Steib wrote:
> Hi,
> formating the gnus.texi with MAKEINFO=no fails:
> $ emacs -batch -q -no-site-file -l ./infohack.el -f batch-makeinfo gnus.texi
> [...]
> Formatting: Low-level interface to the spam-stat dictionary ...
> Formatting: The Gnus Registry ...
> Extraneous text at end of command line
> make: *** [gnus] Error 255
> Could someone please fix this?
Fixed in the Gnus trunk. For texinfmt.el the @item command used
in the @enumerate section seems not to allow argument, so I've
modified the lines "@item TITLE\n" into "@item\nTITLE\n\n".
BTW, with MAKEINFO=no the Gnus Info files are divided into 24
files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't
they? The threshold is hard-coded in `Info-split' (informat.el).
A workaround I added to the Japanese edition of the Gnus Info is:
--8<---------------cut here---------------start------------->8---
;; Reduce the number of split Info files.
(if (featurep 'xemacs)
(if (load "informat.el" t t)
(let* ((fn (symbol-function 'Info-split))
(fns (prin1-to-string fn)))
(load "informat.elc" t t)
(when (and (string-match "\\([\t\n ]+\\)50000\\([\t\n )]+\\)" fns)
(condition-case nil
(setq fn (byte-compile
(read (replace-match "\\1200000\\2" nil nil
fns))))
(error nil))
(fset 'Info-split fn)))))
(require 'informat)
(let* ((fn (symbol-function 'Info-split))
(fns (prin1-to-string fn)))
(when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns)
(condition-case nil
(fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns)))
(error
(fset 'Info-split fn))))))
--8<---------------cut here---------------end--------------->8---
Regards,
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-24 0:37 ` Katsumi Yamaoka
@ 2008-09-24 6:45 ` Katsumi Yamaoka
2008-09-24 16:45 ` Reiner Steib
2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib
1 sibling, 1 reply; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-24 6:45 UTC (permalink / raw)
To: ding
>>>>> Katsumi Yamaoka wrote:
>>>>>> Reiner Steib wrote:
>> formating the gnus.texi with MAKEINFO=no fails:
[...]
> Fixed in the Gnus trunk.
I've installed another fix to infohack.el. The Gnus Info generated
with MAKEINFO=no was unable to read using the recent `info' command.
Regards,
^ permalink raw reply [flat|nested] 31+ messages in thread
* informat.el: `Info-split' split size (was: registry doc patch)
2008-09-24 0:37 ` Katsumi Yamaoka
2008-09-24 6:45 ` Katsumi Yamaoka
@ 2008-09-24 16:44 ` Reiner Steib
2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka
1 sibling, 1 reply; 31+ messages in thread
From: Reiner Steib @ 2008-09-24 16:44 UTC (permalink / raw)
To: emacs-devel, Katsumi Yamaoka; +Cc: ding
On Wed, Sep 24 2008, Katsumi Yamaoka wrote:
> BTW, with MAKEINFO=no the Gnus Info files are divided into 24
> files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't
> they? The threshold is hard-coded in `Info-split' (informat.el).
,----[ <f1> f Info-split RET ]
| Info-split is an interactive autoloaded Lisp function in `informat'.
| (Info-split)
|
| Split an info file into an indirect file plus bounded-size subfiles.
| Each subfile will be up to 50,000 characters plus one node. [...]
`----
I think the threshold should not be hard-coded and it's default should
be like makeinfo's so that we don't need such workarounds:
> A workaround I added to the Japanese edition of the Gnus Info is:
>
> ;; Reduce the number of split Info files.
> (if (featurep 'xemacs)
> (if (load "informat.el" t t)
> (let* ((fn (symbol-function 'Info-split))
> (fns (prin1-to-string fn)))
> (load "informat.elc" t t)
> (when (and (string-match "\\([\t\n ]+\\)50000\\([\t\n )]+\\)" fns)
> (condition-case nil
> (setq fn (byte-compile
> (read (replace-match "\\1200000\\2" nil nil
> fns))))
> (error nil))
> (fset 'Info-split fn)))))
> (require 'informat)
> (let* ((fn (symbol-function 'Info-split))
> (fns (prin1-to-string fn)))
> (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns)
> (condition-case nil
> (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns)))
> (error
> (fset 'Info-split fn))))))
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch
2008-09-24 6:45 ` Katsumi Yamaoka
@ 2008-09-24 16:45 ` Reiner Steib
0 siblings, 0 replies; 31+ messages in thread
From: Reiner Steib @ 2008-09-24 16:45 UTC (permalink / raw)
To: ding
On Wed, Sep 24 2008, Katsumi Yamaoka wrote:
>>>>>> Katsumi Yamaoka wrote:
>>>>>>> Reiner Steib wrote:
>>> formating the gnus.texi with MAKEINFO=no fails:
> [...]
>> Fixed in the Gnus trunk.
>
> I've installed another fix to infohack.el. The Gnus Info generated
> with MAKEINFO=no was unable to read using the recent `info' command.
Thanks.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size
2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib
@ 2008-09-24 23:58 ` Katsumi Yamaoka
2008-09-25 3:10 ` Eli Zaretskii
2008-09-25 23:10 ` Katsumi Yamaoka
0 siblings, 2 replies; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-24 23:58 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
>>>>> Reiner Steib wrote:
> On Wed, Sep 24 2008, Katsumi Yamaoka wrote:
>> BTW, with MAKEINFO=no the Gnus Info files are divided into 24
>> files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't
>> they? The threshold is hard-coded in `Info-split' (informat.el).
> ,----[ <f1> f Info-split RET ]
>| Info-split is an interactive autoloaded Lisp function in `informat'.
>| (Info-split)
>|
>| Split an info file into an indirect file plus bounded-size subfiles.
>| Each subfile will be up to 50,000 characters plus one node. [...]
> `----
> I think the threshold should not be hard-coded and it's default should
> be like makeinfo's so that we don't need such workarounds:
>> A workaround I added to the Japanese edition of the Gnus Info is:
[...]
>> (require 'informat)
>> (let* ((fn (symbol-function 'Info-split))
>> (fns (prin1-to-string fn)))
>> (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns)
>> (condition-case nil
>> (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns)))
>> (error
>> (fset 'Info-split fn)))))
Thank you for following it up. How about the attached patch?
While the threshold of makeinfo is 30000, I tried it with some
texinfo files and reduced it a bit for `Info-split'. Now the
command ``./configure; make MAKEINFO=no info'' performed in the
Gnus trunk splits the Gnus Info into six files.
(Note that loaddefs.el, i.e. ldefs-boot.el, should be updated if
this patch is applied because of autoloading `Info-split-threshold'.)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 1732 bytes --]
--- informat.el~ 2008-05-06 07:57:40 +0000
+++ informat.el 2008-09-24 23:54:45 +0000
@@ -153,9 +153,16 @@
\f
;;;###autoload
+(defcustom Info-split-threshold 262144
+ "The number of characters by which `Info-split' splits an info file."
+ :type 'integer
+ :group 'texinfo)
+
+;;;###autoload
(defun Info-split ()
"Split an info file into an indirect file plus bounded-size subfiles.
-Each subfile will be up to 50,000 characters plus one node.
+Each subfile will be up to the number of characters that
+`Info-split-threshold' specifies, plus one node.
To use this command, first visit a large Info file that has a tag
table. The buffer is modified into a (small) indirect info file which
@@ -167,7 +174,7 @@
contains just the tag table and a directory of subfiles."
(interactive)
- (if (< (buffer-size) 70000)
+ (if (< (buffer-size) (+ 20000 Info-split-threshold))
(error "This is too small to be worth splitting"))
(goto-char (point-min))
(search-forward "\^_")
@@ -192,7 +199,7 @@
(narrow-to-region (point-min) (point))
(goto-char (point-min))
(while (< (1+ (point)) (point-max))
- (goto-char (min (+ (point) 50000) (point-max)))
+ (goto-char (min (+ (point) Info-split-threshold) (point-max)))
(search-forward "\^_" nil 'move)
(setq subfiles
(cons (list (+ start chars-deleted)
--- textmodes/texinfmt.el~ 2008-07-31 21:47:43 +0000
+++ textmodes/texinfmt.el 2008-09-24 23:54:45 +0000
@@ -166,7 +166,7 @@
(Info-tagify)
(if nosplit
nil
- (if (> (buffer-size) 100000)
+ (if (> (buffer-size) (+ 50000 Info-split-threshold))
(progn
(message (setq lastmessage "Splitting Info file..."))
(Info-split))))
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size
2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka
@ 2008-09-25 3:10 ` Eli Zaretskii
2008-09-25 4:01 ` Katsumi Yamaoka
2008-09-25 23:10 ` Katsumi Yamaoka
1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2008-09-25 3:10 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: ding, emacs-devel
> Date: Thu, 25 Sep 2008 08:58:06 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: ding@gnus.org
>
> > ,----[ <f1> f Info-split RET ]
> >| Info-split is an interactive autoloaded Lisp function in `informat'.
> >| (Info-split)
> >|
> >| Split an info file into an indirect file plus bounded-size subfiles.
> >| Each subfile will be up to 50,000 characters plus one node. [...]
> > `----
>
> > I think the threshold should not be hard-coded and it's default should
> > be like makeinfo's so that we don't need such workarounds:
>
> >> A workaround I added to the Japanese edition of the Gnus Info is:
> [...]
> >> (require 'informat)
> >> (let* ((fn (symbol-function 'Info-split))
> >> (fns (prin1-to-string fn)))
> >> (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns)
> >> (condition-case nil
> >> (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns)))
> >> (error
> >> (fset 'Info-split fn)))))
>
> Thank you for following it up. How about the attached patch?
> While the threshold of makeinfo is 30000, I tried it with some
^^^^^
You mean 300000, right?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size
2008-09-25 3:10 ` Eli Zaretskii
@ 2008-09-25 4:01 ` Katsumi Yamaoka
0 siblings, 0 replies; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-25 4:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, ding
>>>>> Eli Zaretskii wrote:
>> While the threshold of makeinfo is 30000, I tried it with some
> ^^^^^
> You mean 300000, right?
Oops. You're right.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size
2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka
2008-09-25 3:10 ` Eli Zaretskii
@ 2008-09-25 23:10 ` Katsumi Yamaoka
1 sibling, 0 replies; 31+ messages in thread
From: Katsumi Yamaoka @ 2008-09-25 23:10 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
>>>>> Katsumi Yamaoka wrote:
> While the threshold of makeinfo is 30000, I tried it with some
no, that's 300000 to be accurate
> texinfo files and reduced it a bit for `Info-split'. Now the
> command ``./configure; make MAKEINFO=no info'' performed in the
> Gnus trunk splits the Gnus Info into six files.
> (Note that loaddefs.el, i.e. ldefs-boot.el, should be updated if
> this patch is applied because of autoloading `Info-split-threshold'.)
> --- informat.el~ 2008-05-06 07:57:40 +0000
> +++ informat.el 2008-09-24 23:54:45 +0000
[...]
> +(defcustom Info-split-threshold 262144
> + "The number of characters by which `Info-split' splits an info file."
> + :type 'integer
> + :group 'texinfo)
I've installed the fix with ``:version "23.1"''.
Regards,
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2008-09-25 23:10 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <87abfkmuko.fsf@jondo.cante.net>
2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka
2008-08-13 18:56 ` Reiner Steib
2008-08-13 21:47 ` Jari Aalto
2008-08-15 16:31 ` jidanni
2008-08-19 11:48 ` Miles Bader
2008-08-22 15:52 ` Ted Zlatanov
2008-08-27 23:01 ` Miles Bader
2008-08-28 13:51 ` Ted Zlatanov
2008-08-29 11:15 ` Reiner Steib
2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov
2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov
2008-09-16 9:17 ` registry doc patch Rupert Swarbrick
2008-09-16 13:36 ` Ted Zlatanov
2008-09-16 12:30 ` Magnus Henoch
2008-09-16 13:39 ` Ted Zlatanov
2008-09-18 23:19 ` Katsumi Yamaoka
2008-09-19 16:19 ` Ted Zlatanov
2008-09-23 19:18 ` Reiner Steib
2008-09-24 0:37 ` Katsumi Yamaoka
2008-09-24 6:45 ` Katsumi Yamaoka
2008-09-24 16:45 ` Reiner Steib
2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib
2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka
2008-09-25 3:10 ` Eli Zaretskii
2008-09-25 4:01 ` Katsumi Yamaoka
2008-09-25 23:10 ` Katsumi Yamaoka
2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov
2008-08-29 15:31 ` Daiki Ueno
2008-08-29 15:55 ` Ted Zlatanov
2008-08-30 5:07 ` Katsumi Yamaoka
2008-08-30 9:33 ` Ted Zlatanov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).