For insertion in trunk

For insertion in trunk

[Michael Albinus]

Hi,

I have worked on adding new features for Emacs' D-Bus bindings over the
last months. Usually, it could wait until the trunk is reopened for new
features.

However, one of the patches (using private connections to D-Bus) is
needed by other people for the AT SPI integration which is going
on. Therefore, I would like to commit the D-Bus related patches already
now. Any objections?

Best regards, Michael.

Re: For insertion in trunk

[Stefan Monnier]

> I have worked on adding new features for Emacs' D-Bus bindings over the
> last months. Usually, it could wait until the trunk is reopened for new
> features.

The trunk *is* open for new features now.


        Stefan

Re: For insertion in trunk

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I have worked on adding new features for Emacs' D-Bus bindings over the
> last months. Usually, it could wait until the trunk is reopened for new
> features.

The trunk is open for new features now.  We should avoid committing
"churn" stuff to the trunk, though, to make it easier to merge fixes
committed to the emacs-24 branch.

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

Re: For insertion in trunk

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I have worked on adding new features for Emacs' D-Bus bindings over the
>> last months. Usually, it could wait until the trunk is reopened for new
>> features.
>
> The trunk *is* open for new features now.

You wrote:

| The `trunk' can now be used for non-regression patches.  For now, please
| refrain from installing pervasive changes, tho, to avoid introducing
| unneeded conflicts when merging from the branch.

Wrt D-Bus, my changes are "pervasive" (in implementation, not in its
API). That's why I've asked. Shall I go on?

>         Stefan

Best regards, Michael.

Re: For insertion in trunk

[Michael Albinus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I have worked on adding new features for Emacs' D-Bus bindings over the
>> last months. Usually, it could wait until the trunk is reopened for new
>> features.
>
> The trunk is open for new features now.  We should avoid committing
> "churn" stuff to the trunk, though, to make it easier to merge fixes
> committed to the emacs-24 branch.

After installation of my changes, it would be almost impossible to merge
dbusbind.c or dbus.el automatically between the emacs24 branch and the trunk.

However, I would volunteer to merge needed patches manually :-)

Best regards, Michael.

Re: For insertion in trunk

[Andreas Schwab]

Michael Albinus <michael.albinus@gmx.de> writes:

> After installation of my changes, it would be almost impossible to merge
> dbusbind.c or dbus.el automatically between the emacs24 branch and the trunk.

That's not a problem if the files aren't changed on the emacs-24 branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: For insertion in trunk

[Katsumi Yamaoka]

Andreas Schwab wrote:
> Michael Albinus <michael.albinus@gmx.de> writes:

>> After installation of my changes, it would be almost impossible to merge
>> dbusbind.c or dbus.el automatically between the emacs24 branch and the trunk.

> That's not a problem if the files aren't changed on the emacs-24 branch.

In relation to this, I'd like to merge changes made in the Gnus
git master ever since the feature freeze to the Emacs trunk.  In
that work, may I not change the original ChangeLog timestamps
(and order)?  Or should they be changed to the present time (and
put at the beginning)?

A patch is ready as:
http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs.patch
(or ftp://ftp.jpl.org/pub/tmp/MaGnus-to-Emacs.patch )

Re: For insertion in trunk

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> In relation to this, I'd like to merge changes made in the Gnus
> git master ever since the feature freeze to the Emacs trunk.

Please wait a bit with this.  There seems to be a serious problem with
the nnimap `unexist' tracking on some servers that I still haven't been
able to reproduce, but which makes using nnimap on these servers
kinda... awkward.

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

Re: For insertion in trunk

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> In relation to this, I'd like to merge changes made in the Gnus
>> git master ever since the feature freeze to the Emacs trunk.

> Please wait a bit with this.  There seems to be a serious problem with
> the nnimap `unexist' tracking on some servers that I still haven't been
> able to reproduce, but which makes using nnimap on these servers
> kinda... awkward.

Ok, I keep maintaining it locally till a signal gun fires.

Re: For insertion in trunk

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

Katsumi Yamaoka wrote:
> Lars Magne Ingebrigtsen wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>> In relation to this, I'd like to merge changes made in the Gnus
>>> git master ever since the feature freeze to the Emacs trunk.

>> Please wait a bit with this.  There seems to be a serious problem with
>> the nnimap `unexist' tracking on some servers that I still haven't been
>> able to reproduce, but which makes using nnimap on these servers
>> kinda... awkward.

> Ok, I keep maintaining it locally till a signal gun fires.

Well, the diff[1] between Emacs's Gnus and Ma Gnus grew into over
200KB, and pretty amount of them are useful and obviously unrelated
to the problem.  So, I'd like to merge them to the Emacs trunk.
The attached text includes the ChangeLog entries associated with
the Gnus changes not yet merged to Emacs; where lines beginning
with `o' are the ones that I think safe to merge to Emacs.  WDYT?
If that's ok, I'll work on it next week or later.

[1] /ftp.jpl.org:/pub/tmp/MaGnus-to-Emacs.patch
 (or http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs.patch)

[-- Attachment #2: Gnus-Emacs-diffs.gz --]
[-- Type: application/x-gunzip, Size: 6121 bytes --]

Re: For insertion in trunk

[Chong Yidong]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Well, the diff[1] between Emacs's Gnus and Ma Gnus grew into over
> 200KB, and pretty amount of them are useful and obviously unrelated
> to the problem.  So, I'd like to merge them to the Emacs trunk.
> The attached text includes the ChangeLog entries associated with
> the Gnus changes not yet merged to Emacs; where lines beginning
> with `o' are the ones that I think safe to merge to Emacs.  WDYT?
> If that's ok, I'll work on it next week or later.
>
> [1] /ftp.jpl.org:/pub/tmp/MaGnus-to-Emacs.patch
>  (or http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs.patch)

On the Emacs side, I am fine with merging to trunk now.  Lars can make
the call about whether he thinks Ma Gnus is ready to be used by those
following the Emacs trunk.  (Just so we are on the same page: I'm
assuming you guys are intending to have it be included in 24.2, since
the current plan is to release Emacs 24.2 from the trunk.)

Re: For insertion in trunk

[Katsumi Yamaoka]

Chong Yidong wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Well, the diff[1] between Emacs's Gnus and Ma Gnus grew into over
>> 200KB, and pretty amount of them are useful and obviously unrelated
>> to the problem.  So, I'd like to merge them to the Emacs trunk.
>> The attached text includes the ChangeLog entries associated with
>> the Gnus changes not yet merged to Emacs; where lines beginning
>> with `o' are the ones that I think safe to merge to Emacs.  WDYT?
>> If that's ok, I'll work on it next week or later.
>>
>> [1] /ftp.jpl.org:/pub/tmp/MaGnus-to-Emacs.patch
>>  (or http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs.patch)

> On the Emacs side, I am fine with merging to trunk now.  Lars can make
> the call about whether he thinks Ma Gnus is ready to be used by those
> following the Emacs trunk.  (Just so we are on the same page: I'm
> assuming you guys are intending to have it be included in 24.2, since
> the current plan is to release Emacs 24.2 from the trunk.)

Thanks.  I've merged changes made in Gnus master to the Emacs trunk
just now, except for the nnimap and `unexist' related changes.
The unfinished ones are below.  You can find those changes in:

ftp://ftp.jpl.org/pub/tmp/MaGnus-to-Emacs.patch
or http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs.patch

I guess some of them are harmless, or all are safe.  However, I
have no means to verify it since I'm not an IMAP user.

:::::::::::::::::
::: doc/misc/ :::
:::::::::::::::::
2012-03-22 Lars Magne Ingebrigtsen <larsi@gnus.org>
* gnus.texi (Client-Side IMAP Splitting):
  Note that `nnimap-inbox' now can be a list.

::::::::::::::::::
::: lisp/gnus/ :::
::::::::::::::::::
2012-06-25 Julien Danjou <julien@danjou.info>
* nnimap.el (nnimap-request-articles-find-limit): Rename from
`nnimap-request-move-articles-find-limit' since we do not use it
only for move operations.
(nnimap-request-accept-article): Use
`nnimap-request-articles-find-limit' to limit search by message-id.

2012-06-19 Julien Danjou <julien@danjou.info>
* nnir.el (nnir-run-imap): Fix, use `nnimap-change-group'.
* nnimap.el (nnimap-log-buffer): Check that
  `window-point-insertion-type' is boundp, since it's not available
  in XEmacs.

2012-06-19 Michael Welsh Duggan <md5i@md5i.com> (tiny change)
* nnimap.el (nnimap-log-buffer): Add this, setting
  `window-point-insertion-type' in the buffer to t.
  (nnimap-log-command): Use nnimap-log-buffer.

2012-06-19 Julien Danjou <julien@danjou.info>
* nnimap.el (nnimap-find-article-by-message-id): Add an optional limit
  argument to be able to limit the search.
  (nnimap-request-move-article):
  Use `nnimap-request-move-articles-find-limit'.
  (nnimap-request-move-articles-find-limit):
  Add this to limit the search by Message-Id after a message move.
  (nnimap): Add defgroup.

2012-06-15 Julien Danjou <julien@danjou.info>
* nnimap.el (nnimap-find-article-by-message-id):
  Use `nnimap-possibly-change-group' rather than its own EXAMINE call.
  (nnimap-possibly-change-group): Add read-only argument.
  (nnimap-request-list): Use nnimap-possibly-change-group rather than
  issuing EXAMINE manually.
  (nnimap-find-article-by-message-id): Use `nnimap-possibly-change-group'
  with read-only argument.
  (nnimap-change-group): Rename from `nnimap-possibly-change-group'.
  We cannot possibly change because we need to be sure that it's either
  read-write or read-only.

2012-06-10 Lars Magne Ingebrigtsen <larsi@gnus.org>
  gnus-sum.el (gnus-summary-insert-old-articles): Don't include
   unexistent messages.

2012-04-10 Lars Magne Ingebrigtsen <larsi@gnus.org>
* gnus-start.el (gnus-clean-old-newsrc):
  Remove totally bogus `unexists' entries.
  (gnus-clean-old-newsrc): Fix last checkin.
* nnimap.el (nnimap-update-info):
  None of the articles below the active low-water mark exist.

2012-03-27 Katsumi Yamaoka <yamaoka@jpl.org>
* nnimap.el (gnus-refer-thread-use-nnir): Silence the byte compiler.

2012-03-22 Sergio Martinez <samf0xb58@gmail.com> (tiny change)
* nnimap.el (nnimap-request-scan):
  Allow `nnimap-inbox' to be a list of inboxes.

2012-03-10 Lars Magne Ingebrigtsen <larsi@gnus.org>
* gnus-group.el (gnus-group-expire-articles-1):
  Don't try to expire messages that don't exist.
* gnus-sum.el (gnus-summary-expire-articles): Ditto.

2012-02-20 Lars Ingebrigtsen <larsi@gnus.org>
* gnus-start.el (gnus-clean-old-newsrc): Allow a FORCE parameter.

2012-02-15 Lars Ingebrigtsen <larsi@gnus.org>
* gnus-start.el (gnus-clean-old-newsrc):
  Delete `unexist' from pre-Ma Gnus 0.3.

2012-02-15 Lars Ingebrigtsen <larsi@gnus.org>
* gnus-sum.el (gnus-summary-local-variables):
  Make `gnus-newsgroup-unexist' into a local variable.

2012-02-11 Lars Ingebrigtsen <larsi@gnus.org>
* gnus-sum.el (gnus-adjust-marked-articles):
  Add to `gnus-newsgroup-unexist'.
* gnus.el (gnus-article-mark-lists):
  Add `unexist' to the list of marks.
  (gnus-article-special-mark-lists):
  Put the `unexist' in the special marks list instead.
* gnus-sum.el (gnus-articles-to-read): Don't include unexisting
  articles in the list of articles to be selected.
* nnimap.el (nnimap-retrieve-group-data-early):
  Query for unexisting articles.
  (nnimap-update-info): Keep track of unexisting articles.
  (nnimap-update-qresync-info): Ditto.

2012-02-01 Lars Ingebrigtsen <larsi@gnus.org>
* gnus-start.el (gnus-clean-old-newsrc): New function.
  (gnus-read-newsrc-file): Use it.

Re: For insertion in trunk

[Glenn Morris]

Katsumi Yamaoka wrote:

> I've merged changes made in Gnus master to the Emacs trunk

Merging is a thankless task. :)
It doesn't build:

http://hydra.nixos.org/build/2731306/nixlog/1/tail-reload

gnus/tests/gnustest-nntp.el:62:1:Error: Cannot open load file: gnus-load


In any case surely these test files should be under test/, not lisp/?

Re: For insertion in trunk

[Katsumi Yamaoka]

Glenn Morris wrote:
> Katsumi Yamaoka wrote:

>> I've merged changes made in Gnus master to the Emacs trunk

> Merging is a thankless task. :)
> It doesn't build:

> http://hydra.nixos.org/build/2731306/nixlog/1/tail-reload

> gnus/tests/gnustest-nntp.el:62:1:Error: Cannot open load file: gnus-load

I've set no-byte-compile and no-update-autoloads in those files.
(I'm going to try rebuilding now, though it takes time on Cygwin.)

> In any case surely these test files should be under test/, not lisp/?

Currently those modules are of no use for the run time I believe.
I only did sync of Ma Gnus and Emacs.

Re: For insertion in trunk

[Glenn Morris]

Katsumi Yamaoka wrote:

> I've set no-byte-compile and no-update-autoloads in those files.

OK, that works as a stopgap.

> (I'm going to try rebuilding now, though it takes time on Cygwin.)

Hydra will do it for you:
http://hydra.nixos.org/jobset/gnu/emacs-trunk

It's a nice service, although it has a few too many false build failures
(full disk, missing dependency, some other glitch, etc).

>> In any case surely these test files should be under test/, not lisp/?
>
> Currently those modules are of no use for the run time I believe.
> I only did sync of Ma Gnus and Emacs.

I don't understand. Not being used at runtime means they should go in
test/, like every other test file (including gnus-test.el).

They are no use at all in Emacs if they rely on parts of Gnus that are
not present though (whatever gnus-load is).


Also (my pet peeve) the license headers are obviously wrong in two of
them:

  ;; This file is not part of GNU Emacs.
  [...]
  ;; If not, write to the Free Software Foundation, Inc., 51 Franklin
  ;; Street, Fifth Floor, Boston, MA 02110-1301, USA.

The modern version uses a URL instead of a street address.

Re: For insertion in trunk

[Katsumi Yamaoka]

Glenn Morris wrote:
> Katsumi Yamaoka wrote:

>> I've set no-byte-compile and no-update-autoloads in those files.

> OK, that works as a stopgap.

>> (I'm going to try rebuilding now, though it takes time on Cygwin.)

> Hydra will do it for you:
> http://hydra.nixos.org/jobset/gnu/emacs-trunk

> It's a nice service, although it has a few too many false build failures
> (full disk, missing dependency, some other glitch, etc).

>>> In any case surely these test files should be under test/, not lisp/?
>>
>> Currently those modules are of no use for the run time I believe.
>> I only did sync of Ma Gnus and Emacs.

> I don't understand. Not being used at runtime means they should go in
> test/, like every other test file (including gnus-test.el).

> They are no use at all in Emacs if they rely on parts of Gnus that are
> not present though (whatever gnus-load is).

> Also (my pet peeve) the license headers are obviously wrong in two of
> them:

>   ;; This file is not part of GNU Emacs.
>   [...]
>   ;; If not, write to the Free Software Foundation, Inc., 51 Franklin
>   ;; Street, Fifth Floor, Boston, MA 02110-1301, USA.

> The modern version uses a URL instead of a street address.

I'd like to simply remove those files and directory in Emacs since
I think they are worthless if the launchers (in Gnus lisp/Makefile
provides) lack, and also got to think adding the launchers to Emacs
is not very helpful to Emacs developers either.  So, I'd wait for
other responses for a while.

Re: For insertion in trunk

[Glenn Morris]

Katsumi Yamaoka wrote:

> So, I'd wait for other responses for a while.

Sure. If they end up not being in Emacs, the headers still need fixing,
since they are logically inconsistent (they say they are "not part of
GNU Emacs", but then go on to quote the copying conditions for "GNU Emacs"
rather than "this file").

Re: For insertion in trunk

[Katsumi Yamaoka]

Glenn Morris wrote:
> Katsumi Yamaoka wrote:

>> So, I'd wait for other responses for a while.

> Sure. If they end up not being in Emacs, the headers still need fixing,
> since they are logically inconsistent (they say they are "not part of
> GNU Emacs", but then go on to quote the copying conditions for "GNU Emacs"
> rather than "this file").

I've removed lisp/gnus/tests/ in Emacs after all.  (Also in Gnus
Git master I've fixed the licence headers of files remained old.)