Re: Group, Summary buffers: End of line contain whitespaces

Re: Group, Summary buffers: End of line contain whitespaces

[Katsumi Yamaoka]

>>>>> 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,

Re: Group, Summary buffers: End of line contain whitespaces

[Reiner Steib]

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/

Re: Group, Summary buffers: End of line contain whitespaces

[Jari Aalto]

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

Re: Group, Summary buffers: End of line contain whitespaces

[jidanni]

> Why not just set show-trailing-whitespace to nil buffer-locally?

Shame on such "sweep the problem under the rug" thoughts.

Re: Group, Summary buffers: End of line contain whitespaces

[Miles Bader]

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.

Re: Group, Summary buffers: End of line contain whitespaces

[Ted Zlatanov]

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

Re: Group, Summary buffers: End of line contain whitespaces

[Miles Bader]

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.

Re: Group, Summary buffers: End of line contain whitespaces

[Ted Zlatanov]

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

Re: Group, Summary buffers: End of line contain whitespaces

[Reiner Steib]

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/

Re: Group, Summary buffers: End of line contain whitespaces

[Ted Zlatanov]

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

bugs and features (was: Group, Summary buffers: End of line contain whitespaces)

[Ted Zlatanov]

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

Re: Group, Summary buffers: End of line contain whitespaces

[Daiki Ueno]

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

Re: Group, Summary buffers: End of line contain whitespaces

[Ted Zlatanov]

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

Re: Group, Summary buffers: End of line contain whitespaces

[Katsumi Yamaoka]

>>>>> 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,

Re: Group, Summary buffers: End of line contain whitespaces

[Ted Zlatanov]

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

registry doc patch (was: bugs and features)

[Ted Zlatanov]

[-- 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
  

Re: registry doc patch

[Rupert Swarbrick]

[-- 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 --]

Re: registry doc patch

[Magnus Henoch]

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

Re: registry doc patch

[Ted Zlatanov]

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

Re: registry doc patch

[Ted Zlatanov]

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

Re: registry doc patch

[Katsumi Yamaoka]

[-- 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
 

Re: registry doc patch

[Ted Zlatanov]

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

Re: registry doc patch

[Reiner Steib]

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/

Re: registry doc patch

[Katsumi Yamaoka]

>>>>> 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,

Re: registry doc patch

[Katsumi Yamaoka]

>>>>> 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,

informat.el: `Info-split' split size (was: registry doc patch)

[Reiner Steib]

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/

Re: registry doc patch

[Reiner Steib]

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/

Re: informat.el: `Info-split' split size

[Katsumi Yamaoka]

[-- 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))))

Re: informat.el: `Info-split' split size

[Eli Zaretskii]

> 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?

Re: informat.el: `Info-split' split size

[Katsumi Yamaoka]

>>>>> Eli Zaretskii wrote:
>> While the threshold of makeinfo is 30000, I tried it with some
>                                     ^^^^^
> You mean 300000, right?

Oops.  You're right.

Re: informat.el: `Info-split' split size

[Katsumi Yamaoka]

>>>>> 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,