From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Commit 49c0ff2 "Don't bind org-agenda .." Date: Mon, 19 Jun 2017 19:36:15 +0000 Message-ID: References: <87a855of9m.fsf@bzg.fr> <87fuevdc6c.fsf@kyleam.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1cd16c373d5505525540ae" X-Trace: blaine.gmane.org 1497901040 2157 195.159.176.226 (19 Jun 2017 19:37:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Jun 2017 19:37:20 +0000 (UTC) Cc: Mark Oteiza , Nicolas Goaziou , Emacs developers To: Kyle Meyer , Bastien Guerry , Eli Zaretskii , John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 19 21:37:10 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dN2U1-0008PM-89 for ged-emacs-devel@m.gmane.org; Mon, 19 Jun 2017 21:37:09 +0200 Original-Received: from localhost ([::1]:44070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dN2U6-0002Fj-65 for ged-emacs-devel@m.gmane.org; Mon, 19 Jun 2017 15:37:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dN2TS-0002Fe-SG for emacs-devel@gnu.org; Mon, 19 Jun 2017 15:36:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dN2TR-0001Nx-PA for emacs-devel@gnu.org; Mon, 19 Jun 2017 15:36:34 -0400 Original-Received: from mail-lf0-x229.google.com ([2a00:1450:4010:c07::229]:36026) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dN2TM-0001Kc-LN; Mon, 19 Jun 2017 15:36:28 -0400 Original-Received: by mail-lf0-x229.google.com with SMTP id o83so61850694lff.3; Mon, 19 Jun 2017 12:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SQdS6GPRz701Qfo2R6HBjD+bGKZPIMICAUfGrIkGEkM=; b=aTJkBNzkPakbwwRUkrzTGUJzaFnBCKYhxGHmNHfxpLUUu5dGEAWq3xqS2zYWmcvz1P 19eUwAso6fWjSYwGfu/quJYiKRRcSCO3WtVu3H4T+BC5WHemzy6RE/V8jE8PkCQOWfuR i9MokS6V7B6WZQhIIh57VgYPQLWPa/mXjgzvJO4tO2HLztjjSkRBz9K2Dh4dZJVglmEr j12/3/IbT1LvXf0+HGTkV2xAzrs1y2ojC+r8QcCBx5kJ/o4gB0a/A1E7/8fbmHe6BD6Q opWhsQVIUM5jlc+REZRCnlr8gnkhAp/oL0cMmDE8qvf0RTfLpV7VtuLcgDM1Qm4m2tyU wTzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SQdS6GPRz701Qfo2R6HBjD+bGKZPIMICAUfGrIkGEkM=; b=iQ84PbRK8s0P+TjWkMjGR0jr/cq/4p7t8YYMGj9S4mcZ2iU6ZWsvSCpsFbjobwVbYL yNCMsaLbvby3o/0hzUo9qp2K+LUKn/86MfXpRtep5EsNUj/9jCYp+Nc3LIzXE/Gv5e/l tHPX7hdZA2i5EhBdhmbpxppzSw8gQLLxge7aHIMXncr1waLfxIjCAsa5vvI8Lu25+ndB dxZUAjZ9XumDZAw8ijbsm33gS6UQWNConY8uNy3zVeeZmTVxvoi5SO3WUayLA3Y45Cpc yltrmBoivOkAwkshQHWFKx8SiszdH37MRyTnoNzgW2N/qVY+YON3eLraSQw0wjJjb3bj eOzQ== X-Gm-Message-State: AKS2vOzz9eBKBCYRMWNej/jnl0RbAZbXESjSL3TZ1xG0QGRCeNgd1hZN pwItOuOJegqSq152tSUT+GEkswlYvQ== X-Received: by 10.46.21.22 with SMTP id s22mr7754458ljd.121.1497900986611; Mon, 19 Jun 2017 12:36:26 -0700 (PDT) In-Reply-To: <87fuevdc6c.fsf@kyleam.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215792 Archived-At: --94eb2c1cd16c373d5505525540ae Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 3:12 PM Kyle Meyer wrote: > > Right, but I think it's worth emphasizing that commits that are more > than just fixes are much harder to deal with. Under the current system > for syncing Emacs and Org [*], bug fixes are (usually) trivial to > backport to Org's maint branch, but changes that are appropriate for > Org's master branch are more problematic because it's a release from the > Org maint branch that will be synced with the Emacs master branch. > I believe that in that case, the user just uses the org master branch.. Just as people wanting the latest and greatest emacs use the emacs master branch :) > [*] As mentioned several times on this list, the Emacs repo is very > overdue for a sync with Org. Aside from this commit, all > Org-related commits on Emacs's side have been backported (or > otherwise resolved) to Org's maint branch. On the Org list, Kaushal > expressed interest in moving along the final step of syncing, Yes! > so > hopefully a sync isn't too far off. > It would need someone with Org authority to do the actual sync.. Bastein? Nicolas? Looks like Bastein did the last Org sync (v8.2.10) onto Emacs master in Oct 2014. We need to happen again; sync the latest release (9.0.8 as of now), and then keep on syncing the next Org release with Emacs master each time. I use emacs master + org master as my daily driver and they work in harmony. Recently a commit in emacs master broke 'make test' on Org, but that has been fixed. I think that the best time to sync Org 9.0.8 with emacs master is *now*. Eli? John? > > In this particular case, the commit should go on Org master. (No > > need to delete it from Emacs.) > > > > About the functionality itself, I just gave a quick look, but it > > feels like (org-agenda-redo t) should be responsible for doing what > > `org-agenda-redo-all' is doing, and we need to carefully check that > > checking all buffers is a good idea. > > I think the options are > > 3. Revert this commit in Emacs and apply it to Org's master branch. > I would vote for this option. -- Kaushal Modi --94eb2c1cd16c373d5505525540ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 19= , 2017 at 3:12 PM Kyle Meyer <kyle@ky= leam.com> wrote:

Right, but I think it's worth emphasizing that commits that are more than just fixes are much harder to deal with.=C2=A0 Under the current syste= m
for syncing Emacs and Org [*], bug fixes are (usually) trivial to
backport to Org's maint branch, but changes that are appropriate for Org's master branch are more problematic because it's a release fro= m the
Org maint branch that will be synced with the Emacs master branch.

I believe that in that case, the user just uses= the org master branch.. Just as people wanting the latest and greatest ema= cs use the emacs master branch :)
=C2=A0
[*] As mentioned several times on this list, the Emacs repo i= s very
=C2=A0 =C2=A0 overdue for a sync with Org.=C2=A0 Aside from this commit, al= l
=C2=A0 =C2=A0 Org-related commits on Emacs's side have been backported = (or
=C2=A0 =C2=A0 otherwise resolved) to Org's maint branch.=C2=A0 On the O= rg list, Kaushal
=C2=A0 =C2=A0 expressed interest in moving along the final step of syncing,=

Yes!
=C2=A0
so
=C2=A0 =C2=A0 hopefully a sync isn't too far off.
=
It would need someone with Org authority to do the actual sy= nc.. Bastein? Nicolas? Looks like Bastein did the last Org sync (v8.2.10) o= nto Emacs master in Oct 2014. We need to happen again; sync the latest rele= ase (9.0.8 as of now), and then keep on syncing the next Org release with E= macs master each time.

I use emacs master=C2=A0+ o= rg master as my daily driver and they work in harmony. Recently a commit in= emacs master broke 'make test' on Org, but that has been fixed. I = think that the best time to sync Org 9.0.8 with emacs master is *now*. Eli?= John?=C2=A0
=C2=A0
> In = this particular case, the commit should go on Org master.=C2=A0 (No
> need to delete it from Emacs.)
>
> About the functionality itself, I just gave a quick look, but it
> feels like (org-agenda-redo t) should be responsible for doing what > `org-agenda-redo-all' is doing, and we need to carefully check tha= t
> checking all buffers is a good idea.

I think the options are

=C2=A03. Revert this commit in Emacs and apply it to Org's master b= ranch.

I would vote for this option.
--

Kaushal Modi

--94eb2c1cd16c373d5505525540ae--