Patch Series: Warping via the registry

Patch Series: Warping via the registry

[Dave Abrahams]

This patch series implements the ability to warp to a message via
information stored in the Gnus registry.  From a user's point-of-view,
this means that articles brought in from other groups by
gnus-*-refer-* can be used as a jumping-off-point for further
references.  For example, I am using this code to jump to a given
message:

(defun gnus-goto-article (message-id)
  (with-temp-buffer
    (erase-buffer)
    ;; Insert dummy article
    (insert (format "From nobody Tue Sep 13 22:05:34 2011\n\n"))
    (gnus-group-read-ephemeral-group
     message-id
     `(nndoc ,message-id
             (nndoc-address ,(current-buffer))
             (nndoc-article-type mbox))
     :activate
     (cons (current-buffer) gnus-current-window-configuration)
     (not :request-only)
     '(-1) ; :select-articles
     (not :parameters)
     0     ; :number
     )
    (gnus-summary-refer-article message-id)
    ))

Before applying this patch series, I could not get to the whole thread
with `A T' because Gnus was unable to warp to the article in its
original group.

How it works
------------

Each time a message is fetched from a backend, its group is noted in
the registry.  Warping now consults the backend of the current group,
and if that fails, tries warping to the article in each group stored
for it in the registry until one succeeds.

Note
----

Patch 6/6 is only to be applied after accepting the patch attached to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9691.  If you don't
accept that patch, you can still apply the other 5 patches.

[PATCH 1/6] Allow gnus-summary-insert-subject to work in empty
[PATCH 2/6] Record information in the registry about each article
[PATCH 3/6] Add `gnus-select-group-with-message-id'
[PATCH 4/6] Add `gnus-try-warping-via-registry()'
[PATCH 5/6] Enable registry-warping as a fallback if warping via the
[PATCH 6/6] Use `gnus-registry-enabled' instead of

[PATCH 1/6] Allow gnus-summary-insert-subject to work in empty groups.

[Dave Abrahams]

In groups that haven't been populated yet, the minimum and maximum
article numbers are nil; that wasn't accounted for
---
 lisp/gnus-sum.el |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 66b6618..f555c2e 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -6609,9 +6609,9 @@ too, instead of trying to fetch new headers."
       ;; article if ID is a number -- so that the next `P' or `N'
       ;; command will fetch the previous (or next) article even
       ;; if the one we tried to fetch this time has been canceled.
-      (when (> number gnus-newsgroup-end)
+      (unless (and gnus-newsgroup-end (< number gnus-newsgroup-end))
 	(setq gnus-newsgroup-end number))
-      (when (< number gnus-newsgroup-begin)
+      (unless (and gnus-newsgroup-begin (> number gnus-newsgroup-begin))
 	(setq gnus-newsgroup-begin number))
       (setq gnus-newsgroup-unselected
 	    (delq number gnus-newsgroup-unselected)))
-- 
1.7.6.1

[PATCH 2/6] Record information in the registry about each article retrieved

[Dave Abrahams]

---
 lisp/gnus-sum.el |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index f555c2e..207d963 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -12384,6 +12384,13 @@ If REVERSE, save parts that do not match TYPE."
 		(not (setq header (car (gnus-get-newsgroup-headers nil t)))))
 	    ()				; Malformed head.
 	  (unless (gnus-summary-article-sparse-p (mail-header-number header))
+            (when (and (bound-and-true-p gnus-registry-install)
+                       (not (gnus-ephemeral-group-p (car where))))
+              (gnus-registry-handle-action
+               (mail-header-id header) nil
+               (gnus-group-prefixed-name (car where) gnus-override-method)
+               (mail-header-subject header)
+               (mail-header-from header)))
 	    (when (and (stringp id)
 		       (or
 			(not (string= (gnus-group-real-name group)
-- 
1.7.6.1

[PATCH 3/6] Add `gnus-select-group-with-message-id'

[Dave Abrahams]

---
 lisp/gnus-int.el |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/lisp/gnus-int.el b/lisp/gnus-int.el
index 2e10263..048f442 100644
--- a/lisp/gnus-int.el
+++ b/lisp/gnus-int.el
@@ -531,6 +531,49 @@ If BUFFER, insert the article in that group."
 	     header
 	     (gnus-group-real-name group))))
 
+(defun gnus-select-group-with-message-id (group message-id)
+  "Activate and select GROUP with the given MESSAGE-ID selected.
+Returns the article number of the message.
+
+If GROUP is not already selected, the message will be the only one in
+the group's summary.
+"
+  ;; TODO: is there a way to know at this point whether the group will
+  ;; be newly-selected?  If so we could clean up the logic at the end
+  ;;
+  ;; save the new group's display parameter, if any, so we
+  ;; can replace it temporarily with zero.
+  (let ((saved-display
+         (gnus-group-get-parameter group 'display :allow-list)))
+
+    ;; Tell gnus we really don't want any articles 
+    (gnus-group-set-parameter group 'display 0)
+
+    (unwind-protect
+        (gnus-summary-read-group-1
+         group (not :show-all) :no-article (not :kill-buffer)
+         ;; The combination of no-display and this dummy list of
+         ;; articles to select somehow makes it possible to open a
+         ;; group with no articles in it.  Black magic.
+         :no-display '(-1); select-articles
+         )
+      ;; Restore the new group's display parameter
+      (gnus-group-set-parameter group 'display saved-display)))
+
+  ;; The summary buffer was suppressed by :no-display above.
+  ;; Create it now and insert the message
+  (let ((group-is-new (gnus-summary-setup-buffer group)))
+    (condition-case err
+        (let ((article-number 
+               (gnus-summary-insert-subject message-id)))
+          (unless article-number
+            (signal 'error "message-id not in group"))
+          (gnus-summary-select-article nil nil nil article-number)
+          article-number)
+      ;; Clean up the new summary and propagate the error
+      (error (when group-is-new (gnus-summary-exit))
+             (apply 'signal err)))))
+
 (defun gnus-warp-to-article ()
   "Warps from an article in a virtual group to the article in its
 real group. Does nothing on a real group."
-- 
1.7.6.1

[PATCH 4/6] Add `gnus-try-warping-via-registry()'

[Dave Abrahams]

The new function attempts to warp to the article based on group
information stored for the article in the registry.
---
 lisp/gnus-int.el |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/lisp/gnus-int.el b/lisp/gnus-int.el
index 048f442..e241689 100644
--- a/lisp/gnus-int.el
+++ b/lisp/gnus-int.el
@@ -574,6 +574,56 @@ the group's summary.
       (error (when group-is-new (gnus-summary-exit))
              (apply 'signal err)))))
 
+(defun gnus-simplify-group-name (group)
+  "Return the simplest representation of the name of GROUP.
+This is the string that Gnus uses to identify the group."
+  (gnus-group-prefixed-name
+   (gnus-group-real-name group)
+   (gnus-group-method group)))
+
+;; largely based on nnir-warp-to-article
+(defun gnus-try-warping-via-registry ()
+  "Attempt to warp to the current article's source group based on
+data stored in the registry."
+  (interactive)
+  (when (gnus-summary-article-header)
+    (let* ((message-id (mail-header-id (gnus-summary-article-header)))
+           ;; Retrieve the message's group(s) from the registry
+           (groups (gnus-registry-get-id-key message-id 'group))
+           ;; If starting from an ephemeral group, this describes
+           ;; how to restore the window configuration
+           (quit-config
+            (gnus-ephemeral-group-p gnus-newsgroup-name))
+           (seen-groups (list (gnus-group-group-name))))
+
+      (catch 'found
+        (dolist (group (mapcar 'gnus-simplify-group-name groups))
+
+          ;; skip over any groups we really don't want to warp to.
+          (unless (or (member group seen-groups)
+                      (gnus-ephemeral-group-p group)          ;; any ephemeral group
+                      (memq (car (gnus-find-method-for-group group))
+                            '(nnir))) ;; Specific methods; this list may need to expand.
+
+            ;; remember that we've seen this group already
+            (push group seen-groups)
+
+            ;; first exit from any ephemeral summary buffer.
+            (when quit-config
+              (gnus-summary-exit)
+              ;; and if the ephemeral summary buffer in turn came from another
+              ;; summary buffer we have to clean that summary up too.
+              (when (eq (cdr quit-config) 'summary)
+                (gnus-summary-exit))
+              ;; remember that we've already done this part
+              (setq quit-config nil))
+
+            ;; Try to activate the group.  If that fails, just move
+            ;; along.  We may have more groups to work with
+            (ignore-errors
+                (gnus-select-group-with-message-id group message-id))
+            (throw 'found t)))))))
+
 (defun gnus-warp-to-article ()
   "Warps from an article in a virtual group to the article in its
 real group. Does nothing on a real group."
-- 
1.7.6.1

[PATCH 5/6] Enable registry-warping as a fallback if warping via the current backend fails.

[Dave Abrahams]

---
 lisp/gnus-int.el |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/gnus-int.el b/lisp/gnus-int.el
index e241689..b6c3487 100644
--- a/lisp/gnus-int.el
+++ b/lisp/gnus-int.el
@@ -630,9 +630,11 @@ real group. Does nothing on a real group."
   (interactive)
   (let ((gnus-command-method
 	 (gnus-find-method-for-group gnus-newsgroup-name)))
-    (when (gnus-check-backend-function
-	   'warp-to-article (car gnus-command-method))
-      (funcall (gnus-get-function gnus-command-method 'warp-to-article)))))
+    (or
+     (when (gnus-check-backend-function
+            'warp-to-article (car gnus-command-method))
+       (funcall (gnus-get-function gnus-command-method 'warp-to-article)))
+     (gnus-try-warping-via-registry))))
 
 (defun gnus-request-head (article group)
   "Request the head of ARTICLE in GROUP."
-- 
1.7.6.1

[PATCH 6/6] Use `gnus-registry-enabled' instead of `gnus-registry-install'.

[Dave Abrahams]

*** NOTE: This patch depends on the patch attached to
*** http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9691
---
 lisp/gnus-sum.el |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 207d963..d1c08c1 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -12384,7 +12384,7 @@ If REVERSE, save parts that do not match TYPE."
 		(not (setq header (car (gnus-get-newsgroup-headers nil t)))))
 	    ()				; Malformed head.
 	  (unless (gnus-summary-article-sparse-p (mail-header-number header))
-            (when (and (bound-and-true-p gnus-registry-install)
+            (when (and (bound-and-true-p gnus-registry-enabled)
                        (not (gnus-ephemeral-group-p (car where))))
               (gnus-registry-handle-action
                (mail-header-id header) nil
-- 
1.7.6.1

Re: Patch Series: Warping via the registry

[Andy Moreton]

On Sun 09 Oct 2011, Dave Abrahams wrote:

> This patch series implements the ability to warp to a message via
> information stored in the Gnus registry.  From a user's point-of-view,
> this means that articles brought in from other groups by
> gnus-*-refer-* can be used as a jumping-off-point for further
> references.

You have invented yet another term to confuse gnus users in this patch
series, but have not defined what "warp" means.

Please add some documentation to explain the use of this new feature. If
you can do so *without* defining new terminology, all the better.

    AndyM

Re: Patch Series: Warping via the registry

[Dave Abrahams]

on Mon Oct 10 2011, Andy Moreton <andrewjmoreton-AT-gmail.com> wrote:

> On Sun 09 Oct 2011, Dave Abrahams wrote:
>
>> This patch series implements the ability to warp to a message via
>> information stored in the Gnus registry.  From a user's point-of-view,
>> this means that articles brought in from other groups by
>> gnus-*-refer-* can be used as a jumping-off-point for further
>> references.
>
> You have invented yet another term to confuse gnus users in this patch
> series, but have not defined what "warp" means.

If you're complaining about the term "warp," I didn't invent it (and
probably wouldn't have thought of a term that cute).

,----[ (info "(gnus)Basic Usage") ]
|    The `nnir' group made in this way is an `ephemeral' group, and some
| changes are not permanent: aside from reading, moving, and deleting,
| you can't act on the original article. But there is an alternative: you
| can _warp_ to the original group for the article on the current line
| with `A W', aka `gnus-warp-to-article'. Even better, the function
| `gnus-summary-refer-thread', bound by default in summary buffers to `A
| T', will first warp to the original group before it works its magic and
| includes all the articles in the thread. From here you can read, move
| and delete articles, but also copy them, alter article marks, whatever.
| Go nuts.
`----

> Please add some documentation to explain the use of this new feature. If
> you can do so *without* defining new terminology, all the better.

I can do some explaining here, but I'm afraid it wouldn't fit into the
manual as is.  I hope this will be helpful.

Warping is admittedly a little obscure.  The reasons are:

- Warping is probably not too useful on its own.  Gnus uses it as part
  of the refer-article machinery when doing `A T', `A R', and `^'.  The
  idea, I think, is that if you have a group with an article that came
  from somewhere else, the rest of the thread is probably there, too.
  (Note: this is just my best understanding of it having crawled through
  the docs) So when you want to go to, say, the parent of an article,
  it's a good idea to be in that article's original thread.

- Before this patch series, the warp functionality was only available
  from nnir groups, so unless you were an nnir user with
  `gnus-refer-thread-use-nnir' enabled you might not have ever
  encountered it.

This patch series makes it possible to initiate a warp from any group,
which in turn makes it possible to follow threads starting from
ephemeral groups other than an nnir group.

Why would you want to do that?  The `gnus-goto-article' function I
posted in the series' introductory email allows me, given just a
Message-ID, to jump into a buffer containing that message, regardless of
which group or server the message came from (set up
gnus-refer-article-method to enable that).  That's awesomely powerful,
but without the patch series, I can't get from that article to its
entire thread.  With the patch series, I can, because gnus will warp me
to the group from which gnus-summary-refer-article plucked it.

If you want to know why I want to fetch articles by Message-ID in the
first place, it's because I store references to them in Org files, and
need to be able to jump from the Org item to the message.

HTH,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

*bump* (was: Patch Series: Warping via the registry)

[Dave Abrahams]

<bump>

Andy, did my explanation help?

Lars, do you have any feedback on this work?  Would you consider
accepting it?

Ted, what about the registry-enabling patch I posted to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9691 and how it relates to
this series?

on Mon Oct 10 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:

> on Mon Oct 10 2011, Andy Moreton <andrewjmoreton-AT-gmail.com> wrote:
>
>> On Sun 09 Oct 2011, Dave Abrahams wrote:
>>
>>> This patch series implements the ability to warp to a message via
>>> information stored in the Gnus registry.  From a user's point-of-view,
>>> this means that articles brought in from other groups by
>>> gnus-*-refer-* can be used as a jumping-off-point for further
>>> references.
>>
>> You have invented yet another term to confuse gnus users in this patch
>> series, but have not defined what "warp" means.
>
> If you're complaining about the term "warp," I didn't invent it (and
> probably wouldn't have thought of a term that cute).
>
> ,----[ (info "(gnus)Basic Usage") ]
> |    The `nnir' group made in this way is an `ephemeral' group, and some
> | changes are not permanent: aside from reading, moving, and deleting,
> | you can't act on the original article. But there is an alternative: you
> | can _warp_ to the original group for the article on the current line
> | with `A W', aka `gnus-warp-to-article'. Even better, the function
> | `gnus-summary-refer-thread', bound by default in summary buffers to `A
> | T', will first warp to the original group before it works its magic and
> | includes all the articles in the thread. From here you can read, move
> | and delete articles, but also copy them, alter article marks, whatever.
> | Go nuts.
> `----
>
>> Please add some documentation to explain the use of this new feature. If
>> you can do so *without* defining new terminology, all the better.
>
> I can do some explaining here, but I'm afraid it wouldn't fit into the
> manual as is.  I hope this will be helpful.
>
> Warping is admittedly a little obscure.  The reasons are:
>
> - Warping is probably not too useful on its own.  Gnus uses it as part
>   of the refer-article machinery when doing `A T', `A R', and `^'.  The
>   idea, I think, is that if you have a group with an article that came
>   from somewhere else, the rest of the thread is probably there, too.
>   (Note: this is just my best understanding of it having crawled through
>   the docs) So when you want to go to, say, the parent of an article,
>   it's a good idea to be in that article's original thread.
>
> - Before this patch series, the warp functionality was only available
>   from nnir groups, so unless you were an nnir user with
>   `gnus-refer-thread-use-nnir' enabled you might not have ever
>   encountered it.
>
> This patch series makes it possible to initiate a warp from any group,
> which in turn makes it possible to follow threads starting from
> ephemeral groups other than an nnir group.
>
> Why would you want to do that?  The `gnus-goto-article' function I
> posted in the series' introductory email allows me, given just a
> Message-ID, to jump into a buffer containing that message, regardless of
> which group or server the message came from (set up
> gnus-refer-article-method to enable that).  That's awesomely powerful,
> but without the patch series, I can't get from that article to its
> entire thread.  With the patch series, I can, because gnus will warp me
> to the group from which gnus-summary-refer-article plucked it.
>
> If you want to know why I want to fetch articles by Message-ID in the
> first place, it's because I store references to them in Org files, and
> need to be able to jump from the Org item to the message.
>
> HTH,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Patch Series: Warping via the registry

[Andy Moreton]

On Tue 11 Oct 2011, Dave Abrahams wrote:

> on Mon Oct 10 2011, Andy Moreton <andrewjmoreton-AT-gmail.com> wrote:
>
>> On Sun 09 Oct 2011, Dave Abrahams wrote:
>>
>>> This patch series implements the ability to warp to a message via
>>> information stored in the Gnus registry.  From a user's point-of-view,
>>> this means that articles brought in from other groups by
>>> gnus-*-refer-* can be used as a jumping-off-point for further
>>> references.
>>
>> You have invented yet another term to confuse gnus users in this patch
>> series, but have not defined what "warp" means.
>
> If you're complaining about the term "warp," I didn't invent it (and
> probably wouldn't have thought of a term that cute).
>
> ,----[ (info "(gnus)Basic Usage") ]
> |    The `nnir' group made in this way is an `ephemeral' group, and some
> | changes are not permanent: aside from reading, moving, and deleting,
> | you can't act on the original article. But there is an alternative: you
> | can _warp_ to the original group for the article on the current line
> | with `A W', aka `gnus-warp-to-article'. Even better, the function
> | `gnus-summary-refer-thread', bound by default in summary buffers to `A
> | T', will first warp to the original group before it works its magic and
> | includes all the articles in the thread. From here you can read, move
> | and delete articles, but also copy them, alter article marks, whatever.
> | Go nuts.
> `----

Ahh, I see. Another part of manual which uses terms without defining
them adequately...

>> Please add some documentation to explain the use of this new feature. If
>> you can do so *without* defining new terminology, all the better.
>
> I can do some explaining here, but I'm afraid it wouldn't fit into the
> manual as is.  I hope this will be helpful.

I wasn't making any judgement on the quality or utility of your patch -
merely trying to nudge you towards also patching the manual :-)

> This patch series makes it possible to initiate a warp from any group,
> which in turn makes it possible to follow threads starting from
> ephemeral groups other than an nnir group.
>
> Why would you want to do that?  The `gnus-goto-article' function I
> posted in the series' introductory email allows me, given just a
> Message-ID, to jump into a buffer containing that message, regardless of
> which group or server the message came from (set up
> gnus-refer-article-method to enable that).  That's awesomely powerful,
> but without the patch series, I can't get from that article to its
> entire thread.  With the patch series, I can, because gnus will warp me
> to the group from which gnus-summary-refer-article plucked it.
>
> If you want to know why I want to fetch articles by Message-ID in the
> first place, it's because I store references to them in Org files, and
> need to be able to jump from the Org item to the message.

This sounds like a useful feature. Please try to add your explanation or
something similar to the manual, as it would make useful docuemntation.

     AndyM

Re: *bump*

[Ted Zlatanov]

On Wed, 12 Oct 2011 10:48:36 -0400 Dave Abrahams <dave@boostpro.com> wrote: 

DA> <bump>

DA> Ted, what about the registry-enabling patch I posted to
DA> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9691 and how it relates to
DA> this series?

I was sick since last week and am now catching up.  It seemed OK at a
glance but I will review in full.

Thanks
Ted

*bump* again

[Dave Abrahams]

Lars, Ted accepted the patch I mentioned below.  If you can find a few
minutes to review this and accept/reject, it'd be much appreciated.

on Wed Oct 12 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:

> <bump>
>
> Andy, did my explanation help?
>
> Lars, do you have any feedback on this work?  Would you consider
> accepting it?
>
> Ted, what about the registry-enabling patch I posted to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9691 and how it relates to
> this series?
>
> on Mon Oct 10 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
>
>> on Mon Oct 10 2011, Andy Moreton <andrewjmoreton-AT-gmail.com> wrote:
>>
>>> On Sun 09 Oct 2011, Dave Abrahams wrote:
>>>
>>>> This patch series implements the ability to warp to a message via
>>>> information stored in the Gnus registry.  From a user's point-of-view,
>>>> this means that articles brought in from other groups by
>>>> gnus-*-refer-* can be used as a jumping-off-point for further
>>>> references.
>>>
>>> You have invented yet another term to confuse gnus users in this patch
>>> series, but have not defined what "warp" means.
>>
>> If you're complaining about the term "warp," I didn't invent it (and
>> probably wouldn't have thought of a term that cute).
>>
>> ,----[ (info "(gnus)Basic Usage") ]
>> |    The `nnir' group made in this way is an `ephemeral' group, and some
>> | changes are not permanent: aside from reading, moving, and deleting,
>> | you can't act on the original article. But there is an alternative: you
>> | can _warp_ to the original group for the article on the current line
>> | with `A W', aka `gnus-warp-to-article'. Even better, the function
>> | `gnus-summary-refer-thread', bound by default in summary buffers to `A
>> | T', will first warp to the original group before it works its magic and
>> | includes all the articles in the thread. From here you can read, move
>> | and delete articles, but also copy them, alter article marks, whatever.
>> | Go nuts.
>> `----
>>
>>> Please add some documentation to explain the use of this new feature. If
>>> you can do so *without* defining new terminology, all the better.
>>
>> I can do some explaining here, but I'm afraid it wouldn't fit into the
>> manual as is.  I hope this will be helpful.
>>
>> Warping is admittedly a little obscure.  The reasons are:
>>
>> - Warping is probably not too useful on its own.  Gnus uses it as part
>>   of the refer-article machinery when doing `A T', `A R', and `^'.  The
>>   idea, I think, is that if you have a group with an article that came
>>   from somewhere else, the rest of the thread is probably there, too.
>>   (Note: this is just my best understanding of it having crawled through
>>   the docs) So when you want to go to, say, the parent of an article,
>>   it's a good idea to be in that article's original thread.
>>
>> - Before this patch series, the warp functionality was only available
>>   from nnir groups, so unless you were an nnir user with
>>   `gnus-refer-thread-use-nnir' enabled you might not have ever
>>   encountered it.
>>
>> This patch series makes it possible to initiate a warp from any group,
>> which in turn makes it possible to follow threads starting from
>> ephemeral groups other than an nnir group.
>>
>> Why would you want to do that?  The `gnus-goto-article' function I
>> posted in the series' introductory email allows me, given just a
>> Message-ID, to jump into a buffer containing that message, regardless of
>> which group or server the message came from (set up
>> gnus-refer-article-method to enable that).  That's awesomely powerful,
>> but without the patch series, I can't get from that article to its
>> entire thread.  With the patch series, I can, because gnus will warp me
>> to the group from which gnus-summary-refer-article plucked it.
>>
>> If you want to know why I want to fetch articles by Message-ID in the
>> first place, it's because I store references to them in Org files, and
>> need to be able to jump from the Org item to the message.
>>
>> HTH,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: *bump* again

[Lars Magne Ingebrigtsen]

Dave Abrahams <dave@boostpro.com> writes:

> Lars, Ted accepted the patch I mentioned below.  If you can find a few
> minutes to review this and accept/reject, it'd be much appreciated.

Looks OK to me, but this is a new feature, and Gnus (and Emacs) is in a
feature freeze...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: *bump* again

[Dave Abrahams]

on Thu Nov 03 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> Lars, Ted accepted the patch I mentioned below.  If you can find a few
>> minutes to review this and accept/reject, it'd be much appreciated.
>
> Looks OK to me, but this is a new feature, and Gnus (and Emacs) is in a
> feature freeze...

You don't have a development/integration branch where things can go
during a feature freeze?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: *bump* again

[Steinar Bang]

>>>>> Dave Abrahams <dave@boostpro.com>:

> You don't have a development/integration branch where things can go
> during a feature freeze?

Note to Lars: having separate branches and merging between them is
_much_ less of a hazzle than in traditional version control tools (CVS,
subversion, perforce).  I know this by first hand experience.

When you do get a conflict, git isn't any smarter than other version
control tools, but git is quiet clever at avoiding conflicts.

The development branch should be frequently merged with master, though.
Maybe a bot could do it, with notifications to a human operator when it
gets conflicts?

Re: *bump* again

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Note to Lars: having separate branches and merging between them is
> _much_ less of a hazzle than in traditional version control tools (CVS,
> subversion, perforce).  I know this by first hand experience.

Command for initially creating a branch, assuming that you're currently
on master, and have no unpushed commits:
 git checkout master
 git checkout -b experimental
 git push origin HEAD

To work on that branch, just
 git fetch
 git checkout experimental

(push and pull and branch and merge as if on master)

> The development branch should be frequently merged with master, though.
> Maybe a bot could do it, with notifications to a human operator when it
> gets conflicts?

To update the experimental branch with current master, do
 git checkout experimental
 git pull
 git merge origin/master
 git push origin HEAD

If you get conflicts you need to resolve them before you can push.
Personally I also always build cleanly, and at least smoke test, before
I push.

However, as long as you don't get conflicts you're usually good (though
I _have_ seen examples of the opposite).  Basically, the more fine
grained people commit, the better merge will work.

Git is really quite clever about branching and merging.  To read about
it, read the "branching" chapter of the "Pro Git" book:
 http://progit.org/book/ch3-0.html

To eventually merge in the experimental branch into master, do:
 git checkout master
 git pull
 git merge origin/experimental
 git push origin HEAD

Re: *bump* again

[Ted Zlatanov]

On Thu, 03 Nov 2011 16:23:03 -0800 Dave Abrahams <dave@boostpro.com> wrote: 

DA> on Thu Nov 03 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

>> Dave Abrahams <dave@boostpro.com> writes:
>> 
>>> Lars, Ted accepted the patch I mentioned below.  If you can find a few
>>> minutes to review this and accept/reject, it'd be much appreciated.
>> 
>> Looks OK to me, but this is a new feature, and Gnus (and Emacs) is in a
>> feature freeze...

DA> You don't have a development/integration branch where things can go
DA> during a feature freeze?

Not so far but I would make one if I needed it (e.g. if Lars made me put
the gnus-sync.el changes back).

In this specific case I feel strongly that `gnus-registry-enabled' is
not a new feature but a necessary fix, which is why I committed it.  The
rest of Dave's patch, dealing with warping and so on, should probably go
in a dev branch that we can merge after the freeze, or be held back,
depending on what Dave and Lars want.  I can go either way.

Thanks
Ted

Gnus Git branching strategy for Emacs sync (was: *bump* again)

[Ted Zlatanov]

We should have a "sync-emacs" branch that gets merged from master
occasionally by Yamaoka-san and then pushed to Emacs; changes from Emacs
would then go into that "sync-emacs" branch and need to be merged back
into Gnus.  Yamaoka, WDYT?  Can you handle that strategy?

Thanks
Ted

Re: *bump* again

[Dave Abrahams]

on Fri Nov 04 2011, Steinar Bang <sb-AT-dod.no> wrote:

>>>>>> Dave Abrahams <dave@boostpro.com>:
>
>> You don't have a development/integration branch where things can go
>> during a feature freeze?
>
> Note to Lars: having separate branches and merging between them is
> _much_ less of a hazzle than in traditional version control tools (CVS,
> subversion, perforce).  I know this by first hand experience.
>
> When you do get a conflict, git isn't any smarter than other version
> control tools, but git is quiet clever at avoiding conflicts.

And magit makes resolution pretty painless.

> The development branch should be frequently merged with master, though.
> Maybe a bot could do it, with notifications to a human operator when it
> gets conflicts?

It would be simpler if the development branch *was* master and one could
branch for release, instead.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: *bump* again

[Steinar Bang]

>>>>> Dave Abrahams <dave@boostpro.com>:

> It would be simpler if the development branch *was* master and one
> could branch for release, instead.

Um... in what way would that be simpler...?

AFAIK other than being the name of the branch created by default, when
creating a new git repo, there's nothing special with the master branch
compared with any other tracking branch.

Re: *bump* again

[Dave Abrahams]

on Fri Nov 04 2011, Steinar Bang <sb-AT-dod.no> wrote:

>>>>>> Dave Abrahams <dave@boostpro.com>:
>
>> It would be simpler if the development branch *was* master and one
>> could branch for release, instead.
>
> Um... in what way would that be simpler...?
>
> AFAIK other than being the name of the branch created by default, when
> creating a new git repo, there's nothing special with the master branch
> compared with any other tracking branch.

True, but you're missing my point, which is that it's better to branch
for release rather than forcing work to come to a screeching halt on the
main development/integration branch (be it "master" or a branch with
some other name).  Creating a new branch to stand in for the usual
development/integration branch when you're in a release feature freeze
is awkward, because then everyone doing active development needs to
change their view of the world.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: *bump* again

[John Wiegley]

>>>>> Dave Abrahams <dave@boostpro.com> writes:

>> AFAIK other than being the name of the branch created by default, when
>> creating a new git repo, there's nothing special with the master branch
>> compared with any other tracking branch.

> True, but you're missing my point, which is that it's better to branch for
> release rather than forcing work to come to a screeching halt on the main
> development/integration branch (be it "master" or a branch with some other
> name).  Creating a new branch to stand in for the usual
> development/integration branch when you're in a release feature freeze is
> awkward, because then everyone doing active development needs to change
> their view of the world.

+1

John