* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. [not found] <E1W124t-0007MM-P3@vcs.savannah.gnu.org> @ 2014-01-08 23:18 ` Glenn Morris 2014-01-08 23:34 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Glenn Morris @ 2014-01-08 23:18 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel "Eric S. Raymond" wrote: > -** If your Emacs was built from a bzr checkout, the new variable > -`emacs-bzr-version' contains information about the bzr revision used. > +** If your Emacs was built from a repository checkout, the new variable > +`emacs-repository-version' contains information about the bzr revision used. This entry was in the NEWS section corresponding to the already-released 24.3, so should not have been changed. Perhaps there should be an obsolete variable alias emacs-bzr-version, since it existed in the previous release and now does not. (Actually, I don't think it should have been changed at all during a feature freeze.) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-08 23:18 ` trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names Glenn Morris @ 2014-01-08 23:34 ` Eric S. Raymond 2014-01-08 23:57 ` Juanma Barranquero 2014-01-09 0:34 ` Glenn Morris 0 siblings, 2 replies; 34+ messages in thread From: Eric S. Raymond @ 2014-01-08 23:34 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel Glenn Morris <rgm@gnu.org>: > > -** If your Emacs was built from a bzr checkout, the new variable > > -`emacs-bzr-version' contains information about the bzr revision used. > > +** If your Emacs was built from a repository checkout, the new variable > > +`emacs-repository-version' contains information about the bzr revision used. > > This entry was in the NEWS section corresponding to the already-released > 24.3, so should not have been changed. Oops. I thought it was in the 24.4 section; I'll revert that and make sure the name change is properly noted in the 24.4 news. > Perhaps there should be an obsolete variable alias emacs-bzr-version, > since it existed in the previous release and now does not. I think it is *highly* doubtful anyone ever used it... > (Actually, I don't think it should have been changed at all during a > feature freeze.) Perhaps not. But I did get a request that the stuff around (what is now) emacs-repository-version be fixed immediately so that at no point would any bug report lack a repository revision stamp. My next intended change is to modify a bit of Lisp so that this variable is set properly whether the repo type is Bazaar or Git. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-08 23:34 ` Eric S. Raymond @ 2014-01-08 23:57 ` Juanma Barranquero 2014-01-09 0:04 ` Eric S. Raymond 2014-01-09 0:34 ` Glenn Morris 1 sibling, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-08 23:57 UTC (permalink / raw) To: Eric Raymond; +Cc: Emacs developers On Thu, Jan 9, 2014 at 12:34 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > Glenn Morris <rgm@gnu.org>: >> Perhaps there should be an obsolete variable alias emacs-bzr-version, >> since it existed in the previous release and now does not. > > I think it is *highly* doubtful anyone ever used it... I use emacs-bzr-version in my .emacs. Please add an obsolete alias if you really have to rename it. Thanks, J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-08 23:57 ` Juanma Barranquero @ 2014-01-09 0:04 ` Eric S. Raymond 2014-01-09 0:06 ` Daniel Colascione ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 0:04 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers Juanma Barranquero <lekktu@gmail.com>: > I use emacs-bzr-version in my .emacs. Please add an obsolete alias if > you really have to rename it. That name was hardly going to serve well once we moved to Git, was it? I don't know how to create an obsolete alias. Can you point me at an example to emulate? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:04 ` Eric S. Raymond @ 2014-01-09 0:06 ` Daniel Colascione 2014-01-09 0:12 ` Eric S. Raymond 2014-01-09 0:09 ` Bastien 2014-01-09 0:10 ` Juanma Barranquero 2 siblings, 1 reply; 34+ messages in thread From: Daniel Colascione @ 2014-01-09 0:06 UTC (permalink / raw) To: esr, Juanma Barranquero; +Cc: Emacs developers On 01/08/2014 04:04 PM, Eric S. Raymond wrote: > Juanma Barranquero <lekktu@gmail.com>: >> I use emacs-bzr-version in my .emacs. Please add an obsolete alias if >> you really have to rename it. > > That name was hardly going to serve well once we moved to Git, was it? > > I don't know how to create an obsolete alias. Can you point me at > an example to emulate? Look for define-obsolete-function-alias. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:06 ` Daniel Colascione @ 2014-01-09 0:12 ` Eric S. Raymond 2014-01-09 0:13 ` Daniel Colascione 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 0:12 UTC (permalink / raw) To: Daniel Colascione; +Cc: Juanma Barranquero, Emacs developers Daniel Colascione <dancol@dancol.org>: > On 01/08/2014 04:04 PM, Eric S. Raymond wrote: > >Juanma Barranquero <lekktu@gmail.com>: > >>I use emacs-bzr-version in my .emacs. Please add an obsolete alias if > >>you really have to rename it. > > > >That name was hardly going to serve well once we moved to Git, was it? > > > >I don't know how to create an obsolete alias. Can you point me at > >an example to emulate? > > Look for define-obsolete-function-alias. Hm. Is there a define-obsolete-variable-alias? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:12 ` Eric S. Raymond @ 2014-01-09 0:13 ` Daniel Colascione 0 siblings, 0 replies; 34+ messages in thread From: Daniel Colascione @ 2014-01-09 0:13 UTC (permalink / raw) To: esr; +Cc: Juanma Barranquero, Emacs developers On 01/08/2014 04:12 PM, Eric S. Raymond wrote: > Daniel Colascione <dancol@dancol.org>: >> On 01/08/2014 04:04 PM, Eric S. Raymond wrote: >>> Juanma Barranquero <lekktu@gmail.com>: >>>> I use emacs-bzr-version in my .emacs. Please add an obsolete alias if >>>> you really have to rename it. >>> >>> That name was hardly going to serve well once we moved to Git, was it? >>> >>> I don't know how to create an obsolete alias. Can you point me at >>> an example to emulate? >> >> Look for define-obsolete-function-alias. > > Hm. Is there a define-obsolete-variable-alias? Yep. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:04 ` Eric S. Raymond 2014-01-09 0:06 ` Daniel Colascione @ 2014-01-09 0:09 ` Bastien 2014-01-09 0:27 ` Eric S. Raymond 2014-01-09 0:10 ` Juanma Barranquero 2 siblings, 1 reply; 34+ messages in thread From: Bastien @ 2014-01-09 0:09 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Juanma Barranquero, Emacs developers "Eric S. Raymond" <esr@thyrsus.com> writes: > I don't know how to create an obsolete alias. Can you point me at > an example to emulate? C-h f define-obsolete-function-alias RET C-h f define-obsolete-variable-alias RET -- Bastien ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:09 ` Bastien @ 2014-01-09 0:27 ` Eric S. Raymond 2014-01-09 0:43 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 0:27 UTC (permalink / raw) To: Bastien; +Cc: Juanma Barranquero, Emacs developers Bastien <bzg@gnu.org>: > "Eric S. Raymond" <esr@thyrsus.com> writes: > > > I don't know how to create an obsolete alias. Can you point me at > > an example to emulate? > > C-h f define-obsolete-function-alias RET > C-h f define-obsolete-variable-alias RET The argument WHEN is not described in the function docstring. Is it supposed to be the last version in which the old name was valid, or the first version in which the new name was? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:27 ` Eric S. Raymond @ 2014-01-09 0:43 ` Juanma Barranquero 2014-01-09 1:25 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 0:43 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 1:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > The argument WHEN is not described in the function docstring. Is it supposed > to be the last version in which the old name was valid, or the first version > in which the new name was? Second option. It says in which version the new name is introduced and the old name turns into an obsolete alias. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:43 ` Juanma Barranquero @ 2014-01-09 1:25 ` Eric S. Raymond 2014-01-09 1:31 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 1:25 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > On Thu, Jan 9, 2014 at 1:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > > > The argument WHEN is not described in the function docstring. Is it supposed > > to be the last version in which the old name was valid, or the first version > > in which the new name was? > > Second option. It says in which version the new name is introduced and > the old name turns into an obsolete alias. Thanks. I'll include the obsolete-alias setup with some docstring fixes that version.el meeded anyway. The theme of all my recent commits is fixing places in the tree where code or documentation knew the VCS in use is Bazaar but didn't actually need to know that. In most cases simply referring to 'the repository' is sufficient, and in fact improves the documentation. The goal, of course, is to get to where plugging in git is a very small and well-isolated change. But these cleanups would be good in themselves for their information-hiding effects even if no change were planned. The renaming of that variable is the most intrusive change I'll have to make to get this part of the job done. Most of the others are documentation. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 1:25 ` Eric S. Raymond @ 2014-01-09 1:31 ` Juanma Barranquero 2014-01-09 2:13 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 1:31 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 2:25 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > I'll include the obsolete-alias setup with some docstring fixes > that version.el meeded anyway. Thanks. > But these cleanups would be good in themselves for > their information-hiding effects even if no change were planned. I agree, though I also agree with Glenn in that it wasn't really necessary right now, as Stefan has suggested, IIUC, that the switch won't happen until the freeze is over. But no big deal anyway. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 1:31 ` Juanma Barranquero @ 2014-01-09 2:13 ` Juanma Barranquero 2014-01-09 5:27 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 2:13 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On second thought, I'm not so sure that renaming emacs-bzr-version and emacs-bzr-get-version is a good idea (though I agree with your other changes, to remove Bazaar-specific references in docs, etc.) The reason is that emacs-repository-version and emacs-repository-get-version won't be true replacements for the current variable and function. They won't contain or return data in the same format, and I won't be able, for example, to just use emacs-repository-version in the same way I'm using emacs-bzr-version right now. It's not possible, because I'm using the fact that their value started with a numerical revno (I'm doing arithmetic with that value), which does not make sense in Git. I will be forced to change my code, so just making emacs-bzr-version into an obsolete alias of emacs-repository-version is misleading. IMO it would make more sense to define new emacs-git-version and emacs-git-get-version instances and let user code sort which one needs to use. These function and variable are never going to be really repository- or DVCS-independent anyway. And it's not like we're likely to switch DVCS again in a few years... J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 2:13 ` Juanma Barranquero @ 2014-01-09 5:27 ` Eric S. Raymond 2014-01-09 9:36 ` Juanma Barranquero 2014-01-09 12:00 ` Rüdiger Sonderfeld 0 siblings, 2 replies; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 5:27 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > On second thought, I'm not so sure that renaming emacs-bzr-version and > emacs-bzr-get-version is a good idea > > The reason is that emacs-repository-version and > emacs-repository-get-version won't be true replacements for the > current variable and function. They won't contain or return data in > the same format, and I won't be able, for example, to just use > emacs-repository-version in the same way I'm using emacs-bzr-version > right now. That's true, but it has nothing to do with how the function and vaeriable are named and cannot be fixed by changing the name back or twinning the function. If you look at emacs-repository-version, it now returns exactly what you're used to with the bzr local revision number up front. When we change over to git, there won't be a local revision number because there is no such entity in the git universe. This can't be fixed by anything in the way our LISP is named or factored. > It's not possible, because I'm using the fact that their > value started with a numerical revno (I'm doing arithmetic with that > value), which does not make sense in Git. I will be forced to change > my code, so just making emacs-bzr-version into an obsolete alias of > emacs-repository-version is misleading. You're making a good case for removing the obsolete alias. But... > IMO it would make more sense to define new emacs-git-version and > emacs-git-get-version instances and let user code sort which one needs > to use. It might, if we were going to use two VCSes in parallel. That's not the case. Where the rubber meets the road is: What should emacs-bug call to get a build version to report? There can be only one... > These function and variable are never going to be really > repository- or DVCS-independent anyway. The implementation, no. But the behavior "return a unique magic cookie that identifies the build" is DVCS-independent. You're feeling pain because you want the magic cookie to have substructure, and *that* can't be guaranteed across VCSes. But reverting my renames wouldn't solve that problem either. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 5:27 ` Eric S. Raymond @ 2014-01-09 9:36 ` Juanma Barranquero 2014-01-09 12:37 ` Eric S. Raymond 2014-01-09 12:00 ` Rüdiger Sonderfeld 1 sibling, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 9:36 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 6:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > When we change > over to git, there won't be a local revision number because there is > no such entity in the git universe. This can't be fixed by anything > in the way our LISP is named or factored. True. > You're making a good case for removing the obsolete alias. No. I'm making a case for keeping both variables (and functions) different. You've rushed a bit with the change, and currently, if you remove the alias, you'll break my code**. The logical things would be to keep emacs-bzr(-get)-version as they were, because we *are* still using Bazaar, and when we switch, or just a bit before, you introduce your new API (with "repository" or "git" names, to your liking) and make the old ones obsolete, but *not* obsolete aliases. **[It's broken right now, in fact; I also use emacs-bzr-get-version from my .emacs] > It might, if we were going to use two VCSes in parallel. That's not > the case. Where the rubber meets the road is: What should emacs-bug call to > get a build version to report? There can be only one... Yes. Currently, it's Bazaar that we are using. After the switch, it should call your function. Having the two (but one pair as obsolete non-aliases) does not depend of using two VCSes in parallel, depends that the fact that you're changing an already published API. So you have to make it obsolete, and it cannot be an alias of the new one because both aren't compatible. > The implementation, no. But the behavior "return a unique magic cookie > that identifies the build" is DVCS-independent. You're feeling pain > because you want the magic cookie to have substructure, and *that* > can't be guaranteed across VCSes. Eric, the behavior of the old emacs-bzr(-get)-version was not to "return a unique magic cookie that identifies the build". I am not using the revno because I wanted to do weird things with the cookie. It was *documented* as having structure and I used that fact; it's your commits which have changed it, so you're effectively changing that interface. Which it's perhaps the right thing to do (or not, depending of what the cookie has I will still extract information from it, so documenting it would be nice), but you shouldn't rewrite the past. So, to summarize, I think the right thing to do is: 1.- Restore emacs-bzr(-get)-version, with docstring and all. 2.- (Keep, if you want, your new and currently useless emacs-revision(-get)-version API) 3.- Just after the switch, make obsolete the old pair with (make-obsolete 'emacs-bzr-get-version 'emacs-repository-get-version "24.4") (make-obsolete-variable 'emacs-bzr-version 'emacs-repository-version "24.4") J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 9:36 ` Juanma Barranquero @ 2014-01-09 12:37 ` Eric S. Raymond 2014-01-09 12:48 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 12:37 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > So, to summarize, I think the right thing to do is: > > 1.- Restore emacs-bzr(-get)-version, with docstring and all. > 2.- (Keep, if you want, your new and currently useless > emacs-revision(-get)-version API) > 3.- Just after the switch, make obsolete the old pair with > > (make-obsolete 'emacs-bzr-get-version 'emacs-repository-get-version "24.4") > (make-obsolete-variable 'emacs-bzr-version 'emacs-repository-version "24.4") I must be missing something. I don't see how this would solve any problem at all. I don't understand why simply looking at emacs-bzr-version isn't working for you, given that it's now aliased. What would (emacs-bug) look at under this plan? If your answer is emacs-bzr-version, I strongly object. The fact that the VCS name was exposed at that level was a *bug*, a layering violation (and I would say the same thing if the name had been emacs-git-version). Nothing in Lisp outside version.el has need to know that and therefore should not know it. You're going to have a flag day either way when the VCS changes; I don't get why pushing it into the future by deferring the rename would help you. I don't see any win at all in this reversion. And because doing it would reintroduce a layering violation, I'm going to need a lot of convincing. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 12:37 ` Eric S. Raymond @ 2014-01-09 12:48 ` Juanma Barranquero 2014-01-09 13:13 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 12:48 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 1:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > I must be missing something. I don't see how this would solve any problem > at all. It's no different of any other change that obsoletes a variable. Old code uses it, even if there's newer code with improved features. > I don't understand why simply looking at emacs-bzr-version isn't working > for you, given that it's now aliased. It is working (at least, the part that does not call emacs-bzr-get-version, which does not exist anymore). I'm saying that my previous suggestion of defining an obsolete alias is wrong, because the old and the new variables are NOT compatible. > What would (emacs-bug) look at under this plan? If your answer is > emacs-bzr-version, I strongly object. Currently? emacs-bzr-version. After the switch? Whatever you want. > The fact that the VCS name > was exposed at that level was a *bug*, a layering violation (and I would > say the same thing if the name had been emacs-git-version). Nothing > in Lisp outside version.el has need to know that and therefore > should not know it. That it is a layering violation is a matter of opinion. That is was documented as having a specific structure is a fact, and that at least one person in the universe (though perhaps more, as it has been available since 24.3, almost a year ago) is using it, is another fact. These aren't up for discussion. I understand that you feel strongly about how that API should be, and I'm not opposing your changes in the future. But I don't accept that you have the right to rewrite the past and just *remove* a published API because you think it is wrong (*even* if you're right) when we have a perfectly clear mechanism to deal with such situations, named obsolescence. > I don't see any win at all in this reversion. And because doing it would > reintroduce a layering violation, I'm going to need a lot of convincing. Why should I have to convince you that you shouldn't remove published APIs? I don't want to turn this into a silly commit battle, but if you don't fix it in a compatible way, I will. I'm only asking that your changes for the future (need I to remind you that we're still using Bazaar?) do not break anything that does not *need* to be broken. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 12:48 ` Juanma Barranquero @ 2014-01-09 13:13 ` Eric S. Raymond 2014-01-09 13:27 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 13:13 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > > I don't see any win at all in this reversion. And because doing it would > > reintroduce a layering violation, I'm going to need a lot of convincing. > > Why should I have to convince you that you shouldn't remove published > APIs? I don't want to turn this into a silly commit battle, but if you > don't fix it in a compatible way, I will. I'm only asking that your > changes for the future (need I to remind you that we're still using > Bazaar?) do not break anything that does not *need* to be broken. Wouldn't defining emacs-bzr-get-version as an obsolete function alias for emacs-repository-get-version solve the problem in a way satisfactory to both of us? It wouldn't reintroduce a layering bug into loadup.el, and it would give you your compatible API. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 13:13 ` Eric S. Raymond @ 2014-01-09 13:27 ` Juanma Barranquero 2014-01-09 13:47 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 13:27 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > Wouldn't defining emacs-bzr-get-version as an obsolete function alias > for emacs-repository-get-version solve the problem in a way > satisfactory to both of us? Sorry, no. It is not compatible. Code has been written that understands the case that emacs-bzr-version isn't bound, or bound and nil, or bound and meaningful (with structure). That code will have to be changed if you insist in conflating it with your higher-level API which IMO is not really a new layer (Emacs is not going to have to deal with several underlying DVCS at once in its repository, as you said yourself a few messages ago; DVCS-specific functions and variables are not only not a bug, but a feature). > It wouldn't reintroduce a layering bug into loadup.el, and it would give you > your compatible API. Even accepting that it is a layering bug (which I don't), there's no problem in keeping it in loadup.el; that's why we have make-obsolete(-variable). We don't need to clean up in a hurry every possible clue of past mistakes; just fix the mistakes. And, as said, what you offer is not compatible. emacs-repository-version is not compatible with emacs-bzr-version; the structure was documented, it never was a magical, opaque cookie. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 13:27 ` Juanma Barranquero @ 2014-01-09 13:47 ` Eric S. Raymond 2014-01-09 14:05 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 13:47 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > > > Wouldn't defining emacs-bzr-get-version as an obsolete function alias > > for emacs-repository-get-version solve the problem in a way > > satisfactory to both of us? > > Sorry, no. It is not compatible. Code has been written that > understands the case that emacs-bzr-version isn't bound, or bound and > nil, or bound and meaningful (with structure). That code will have to > be changed if you insist in conflating it with your higher-level API > which IMO is not really a new layer (Emacs is not going to have to > deal with several underlying DVCS at once in its repository, as you > said yourself a few messages ago; DVCS-specific functions and > variables are not only not a bug, but a feature). > > > It wouldn't reintroduce a layering bug into loadup.el, and it would give you > > your compatible API. > > Even accepting that it is a layering bug (which I don't), there's no > problem in keeping it in loadup.el; that's why we have > make-obsolete(-variable). We don't need to clean up in a hurry every > possible clue of past mistakes; just fix the mistakes. And, as said, > what you offer is not compatible. emacs-repository-version is not > compatible with emacs-bzr-version; the structure was documented, it > never was a magical, opaque cookie. > > J The more you talk about this, the less you're making any sense to me. All this about the return value having structure is a red herring. You still *get* that structure by looking at emacs-bzr-version. I have not changed that and will not; only the VCS transition will do that. Similarly, the unbound and bound-but-nil cases will still work; that's the point of declaring an alias, isn't it? With both the variable and function alias in place, I don't understand what code would need to be changed. Show me. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 13:47 ` Eric S. Raymond @ 2014-01-09 14:05 ` Juanma Barranquero 2014-01-09 14:29 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 14:05 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 2:47 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > The more you talk about this, the less you're making any sense to me. Same here. > All this about the return value having structure is a red herring. You > still *get* that structure by looking at emacs-bzr-version. I have > not changed that and will not; only the VCS transition will do that. Yes. And after the transition, code that depends on emacs-release-version and emacs-release-get-version will get a string with a different structure. With your current aliases, they will continue existing, and they will return something different. That is an incompatible change. > With both the variable and function alias in place, I don't understand > what code would need to be changed. (and (bound-and-true-p emacs-bzr-version) (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) This fails right now because you didn't introduce an alias for emacs-bzr-get-version. But, once that is fixed, it will still fail after the switch because emacs-bzr(-get)-version won't return a string containing a revno. So the only compatible fix is to keep these, not as aliases, but as obsolete. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 14:05 ` Juanma Barranquero @ 2014-01-09 14:29 ` Eric S. Raymond 2014-01-09 14:45 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 14:29 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > So the only compatible fix is to keep these, not as aliases, but as obsolete. By your own analysis, there is *no* compatible fix. Whatever the function and variable are called, stuff is going to break because the revision-ID format is different. Now explain to me how reverting the rename would make this (and (bound-and-true-p emacs-bzr-version) (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) work any differently than with both aliases in place. (I agree that not having the function alias in place was an error on my part.) -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 14:29 ` Eric S. Raymond @ 2014-01-09 14:45 ` Juanma Barranquero 2014-01-09 15:08 ` Eric S. Raymond 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 14:45 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 3:29 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > By your own analysis, there is *no* compatible fix. Whatever the function > and variable are called, stuff is going to break because the revision-ID > format is different. It won't be able to extract the required information, because it will not exist anymore. But, as that code is checking for nil, it won't break. Your change will make it break: (setq emacs-repository-version "fce2a09142ddccc242931edd16712c2c24e10e8e") Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p fce2a09142ddccc242931edd16712c2c24e10e8e) -(115933 fce2a09142ddccc242931edd16712c2c24e10e8e) (and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) eval((and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) nil) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) command-execute(eval-last-sexp) > work any differently than with both aliases in place. Switching to Git with remove some functionality (specifically, being easily able to check how many commits there are between the compiled Emacs and the repository head). That cannot be helped, sort of looking for alternatives. I'm not complaining about lack of functionality, but code breaking. But anyway, that's not even the issue. The issue is that we had an interface which said that it would return a string with some format, or nil. You want to keep that interface, but make it return something different. That's incompatible *and* unnecessary. And you seem to insist just because you don't like the idea of the old APIs being around in loadup.el? J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 14:45 ` Juanma Barranquero @ 2014-01-09 15:08 ` Eric S. Raymond 2014-01-09 15:21 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Eric S. Raymond @ 2014-01-09 15:08 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Bastien, Emacs developers Juanma Barranquero <lekktu@gmail.com>: > On Thu, Jan 9, 2014 at 3:29 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > > > By your own analysis, there is *no* compatible fix. Whatever the function > > and variable are called, stuff is going to break because the revision-ID > > format is different. > > It won't be able to extract the required information, because it will > not exist anymore. But, as that code is checking for nil, it won't > break. Your change will make it break: > > (setq emacs-repository-version "fce2a09142ddccc242931edd16712c2c24e10e8e") > > Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p > fce2a09142ddccc242931edd16712c2c24e10e8e) > -(115933 fce2a09142ddccc242931edd16712c2c24e10e8e) > (and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) (- > (read (emacs-bzr-get-version)) (read emacs-bzr-version))) > eval((and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) > (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) nil) > eval-last-sexp-1(nil) > eval-last-sexp(nil) > call-interactively(eval-last-sexp nil nil) > command-execute(eval-last-sexp) That's before putting the function alias in place, right? I'm going to push a change to fix that. The only reason I haven't already is that I have another change waiting > But anyway, that's not even the issue. The issue is that we had an > interface which said that it would return a string with some format, > or nil. That is correct. > You want to keep that interface, but make it return something > different. That's incompatible *and* unnecessary. That is incorrect. emacs-bzr-get-version will return *exactly the name thing* as it did before the change, *under all circumstances*. That's the point of the alias. Are you telling me the alias geature doesn't work? If so, we have larger problems... > And you seem to > insist just because you don't like the idea of the old APIs being > around in loadup.el? That's right. The old API was misdesigned; it leaked information that it should not. Since that can be fixed in a compatible way, it should be. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 15:08 ` Eric S. Raymond @ 2014-01-09 15:21 ` Juanma Barranquero 2014-01-09 20:43 ` chad 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 15:21 UTC (permalink / raw) To: Eric Raymond; +Cc: Bastien, Emacs developers On Thu, Jan 9, 2014 at 4:08 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > That's before putting the function alias in place, right? No, I aliased emacs-bzr-get-version to emacs-repository-get-version before evalling that code. The error is because (read emacs-repository-version) will not be guaranteed to return an integer. > That is incorrect. emacs-bzr-get-version will return *exactly the name thing* > as it did before the change, *under all circumstances*. Not true. - Before: => nnnn some-bzr-revid - Now: => nnnn some-bzr-revid (because of the alias) - In the future, *without* the alias => nil - In the future, *with* your alias => some-git-revid > That's right. The old API was misdesigned; it leaked information that > it should not. Misdesigned or not (and it was not: it gave me useful information), it's what it was, what still would be if you hadn't broken it. You want to design a better API? By all means, do it. Just leave the old one as obsolete. > Since that can be fixed in a compatible way, it should be. "Fixing it in a compatible way" is what I try to do, and you refuse: - Introduce your newfangled API - Leave the old one as obsolete. You're "breaking it in an incompatible way", which is quite different. J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 15:21 ` Juanma Barranquero @ 2014-01-09 20:43 ` chad 0 siblings, 0 replies; 34+ messages in thread From: chad @ 2014-01-09 20:43 UTC (permalink / raw) To: Eric Raymond; +Cc: Juanma Barranquero, Emacs developers It’s probably dumb of me to jump in here, but… If you make an obsolete ALIAS, you’re telling people that the same functionality exists under a new name. That is not what you’re proposing to do. Instead, you want to tell people that the old names are going away, by marking them as obsolete, without the alias. Does that help? ~Chad On 09 Jan 2014, at 07:21, Juanma Barranquero <lekktu@gmail.com> wrote: > On Thu, Jan 9, 2014 at 4:08 PM, Eric S. Raymond <esr@thyrsus.com> wrote: > >> That's before putting the function alias in place, right? > > No, I aliased emacs-bzr-get-version to emacs-repository-get-version > before evalling that code. The error is because (read > emacs-repository-version) will not be guaranteed to return an > integer. > >> That is incorrect. emacs-bzr-get-version will return *exactly the name thing* >> as it did before the change, *under all circumstances*. > > Not true. > > - Before: => nnnn some-bzr-revid > - Now: => nnnn some-bzr-revid (because of the alias) > - In the future, *without* the alias => nil > - In the future, *with* your alias => some-git-revid > >> That's right. The old API was misdesigned; it leaked information that >> it should not. > > Misdesigned or not (and it was not: it gave me useful information), > it's what it was, what still would be if you hadn't broken it. You > want to design a better API? By all means, do it. Just leave the old > one as obsolete. > >> Since that can be fixed in a compatible way, it should be. > > "Fixing it in a compatible way" is what I try to do, and you refuse: > > - Introduce your newfangled API > - Leave the old one as obsolete. > > You're "breaking it in an incompatible way", which is quite different. > > J > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 5:27 ` Eric S. Raymond 2014-01-09 9:36 ` Juanma Barranquero @ 2014-01-09 12:00 ` Rüdiger Sonderfeld 2014-01-09 12:12 ` Juanma Barranquero 1 sibling, 1 reply; 34+ messages in thread From: Rüdiger Sonderfeld @ 2014-01-09 12:00 UTC (permalink / raw) To: emacs-devel, esr; +Cc: Bastien, Juanma Barranquero On Thursday 09 January 2014 00:27:05 Eric S. Raymond wrote: > The implementation, no. But the behavior "return a unique magic cookie > that identifies the build" is DVCS-independent. You're feeling pain > because you want the magic cookie to have substructure, and *that* > can't be guaranteed across VCSes. But reverting my renames wouldn't > solve that problem either. I think the problem is that `emacs-bzr-version' specified a certain format. It will probably be worse to change it to a different format than simply setting it to nil and marking it obsolete (and quickly removing it). Instead of turning it into an alias. Regards, Rüdiger ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 12:00 ` Rüdiger Sonderfeld @ 2014-01-09 12:12 ` Juanma Barranquero 2014-01-09 12:20 ` Rüdiger Sonderfeld 0 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 12:12 UTC (permalink / raw) To: Rüdiger Sonderfeld; +Cc: Eric Raymond, Bastien, Emacs developers On Thu, Jan 9, 2014 at 1:00 PM, Rüdiger Sonderfeld <ruediger@c-plusplus.de> wrote: > It will probably be worse to change it to a different format than simply > setting it to nil and marking it obsolete Yes. Nil, or, not to break code, a string with the last Bazaar revision before the switch. > (and quickly removing it). Why? We've had variables marked obsolete for years (10+). There's no need to remove it "quickly". J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 12:12 ` Juanma Barranquero @ 2014-01-09 12:20 ` Rüdiger Sonderfeld 2014-01-09 12:24 ` Juanma Barranquero 0 siblings, 1 reply; 34+ messages in thread From: Rüdiger Sonderfeld @ 2014-01-09 12:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Eric Raymond, Bastien, Emacs developers On Thursday 09 January 2014 13:12:15 Juanma Barranquero wrote: > On Thu, Jan 9, 2014 at 1:00 PM, Rüdiger Sonderfeld > > <ruediger@c-plusplus.de> wrote: > > It will probably be worse to change it to a different format than simply > > setting it to nil and marking it obsolete > > Yes. Nil, or, not to break code, a string with the last Bazaar > revision before the switch. nil is a specified value: "Value is nil if Emacs was not built from a bzr checkout, or if we could not determine the revision." Fixing it to the last bzr revision seems like a bad idea. Regards, Rüdiger ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 12:20 ` Rüdiger Sonderfeld @ 2014-01-09 12:24 ` Juanma Barranquero 0 siblings, 0 replies; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 12:24 UTC (permalink / raw) To: Rüdiger Sonderfeld; +Cc: Eric Raymond, Bastien, Emacs developers On Thu, Jan 9, 2014 at 1:20 PM, Rüdiger Sonderfeld <ruediger@c-plusplus.de> wrote: > nil is a specified value: "Value is nil if Emacs was not built from a bzr > checkout, or if we could not determine the revision." Yes, you're right. Anyway, it's not really important, as long as the variable and function are kept and marked as obsolete (once they are obsolete, which they currently aren't). J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:04 ` Eric S. Raymond 2014-01-09 0:06 ` Daniel Colascione 2014-01-09 0:09 ` Bastien @ 2014-01-09 0:10 ` Juanma Barranquero 2014-01-09 3:48 ` Stephen J. Turnbull 2 siblings, 1 reply; 34+ messages in thread From: Juanma Barranquero @ 2014-01-09 0:10 UTC (permalink / raw) To: Eric Raymond; +Cc: Emacs developers On Thu, Jan 9, 2014 at 1:04 AM, Eric S. Raymond <esr@thyrsus.com> wrote: > That name was hardly going to serve well once we moved to Git, was it? I think it's safe to assume most of us didn't expect a switch to Git for many years to come. Anyway, it's irrelevant whether it would serve me well at some point in the future; when I used it, that's what the variable was named. :-) > I don't know how to create an obsolete alias. Can you point me at > an example to emulate? (define-obsolete-variable-alias 'emacs-bzr-version 'emacs-repository-version "24.4") HTH, J ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:10 ` Juanma Barranquero @ 2014-01-09 3:48 ` Stephen J. Turnbull 0 siblings, 0 replies; 34+ messages in thread From: Stephen J. Turnbull @ 2014-01-09 3:48 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Eric Raymond, Emacs developers Juanma Barranquero writes: > Anyway, it's irrelevant whether it would serve me well at some point > in the future; when I used it, that's what the variable was > named. :-) More important, Emacsen built from the bzr repo are not going to go away. People are going to be making the transition over a period of *years*, not months. Probably only developers are really interested in this variable, but you just never know what 3rd parties are going to put in their packages or .emacs. Continuity is a good thing. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-08 23:34 ` Eric S. Raymond 2014-01-08 23:57 ` Juanma Barranquero @ 2014-01-09 0:34 ` Glenn Morris 2014-01-09 6:36 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Glenn Morris @ 2014-01-09 0:34 UTC (permalink / raw) To: esr; +Cc: emacs-devel "Eric S. Raymond" wrote: > But I did get a request that the stuff around (what is now) > emacs-repository-version be fixed immediately so that at no point > would any bug report lack a repository revision stamp. I believe the request was that it keep working across the switch, whenever that happens, not that it get changed Right Now in trunk. After the feature freeze ends (which I guess will be no more than a few weeks from now), the 24.4 release will be split off to the emacs-24 branch, and the trunk will be available for development again. It will be some time (I guess no less than a few months) after this that 24.4 is released; and nobody said this transition had to happen immediately after that anyway. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. 2014-01-09 0:34 ` Glenn Morris @ 2014-01-09 6:36 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2014-01-09 6:36 UTC (permalink / raw) To: Glenn Morris; +Cc: esr, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Date: Wed, 08 Jan 2014 19:34:32 -0500 > Cc: emacs-devel@gnu.org > > "Eric S. Raymond" wrote: > > > But I did get a request that the stuff around (what is now) > > emacs-repository-version be fixed immediately so that at no point > > would any bug report lack a repository revision stamp. > > I believe the request was that it keep working across the switch, > whenever that happens, not that it get changed Right Now in trunk. Yes, that's what I meant. Sorry if it was unclear. ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-01-09 20:43 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1W124t-0007MM-P3@vcs.savannah.gnu.org> 2014-01-08 23:18 ` trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names Glenn Morris 2014-01-08 23:34 ` Eric S. Raymond 2014-01-08 23:57 ` Juanma Barranquero 2014-01-09 0:04 ` Eric S. Raymond 2014-01-09 0:06 ` Daniel Colascione 2014-01-09 0:12 ` Eric S. Raymond 2014-01-09 0:13 ` Daniel Colascione 2014-01-09 0:09 ` Bastien 2014-01-09 0:27 ` Eric S. Raymond 2014-01-09 0:43 ` Juanma Barranquero 2014-01-09 1:25 ` Eric S. Raymond 2014-01-09 1:31 ` Juanma Barranquero 2014-01-09 2:13 ` Juanma Barranquero 2014-01-09 5:27 ` Eric S. Raymond 2014-01-09 9:36 ` Juanma Barranquero 2014-01-09 12:37 ` Eric S. Raymond 2014-01-09 12:48 ` Juanma Barranquero 2014-01-09 13:13 ` Eric S. Raymond 2014-01-09 13:27 ` Juanma Barranquero 2014-01-09 13:47 ` Eric S. Raymond 2014-01-09 14:05 ` Juanma Barranquero 2014-01-09 14:29 ` Eric S. Raymond 2014-01-09 14:45 ` Juanma Barranquero 2014-01-09 15:08 ` Eric S. Raymond 2014-01-09 15:21 ` Juanma Barranquero 2014-01-09 20:43 ` chad 2014-01-09 12:00 ` Rüdiger Sonderfeld 2014-01-09 12:12 ` Juanma Barranquero 2014-01-09 12:20 ` Rüdiger Sonderfeld 2014-01-09 12:24 ` Juanma Barranquero 2014-01-09 0:10 ` Juanma Barranquero 2014-01-09 3:48 ` Stephen J. Turnbull 2014-01-09 0:34 ` Glenn Morris 2014-01-09 6:36 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.