* org mode moves to GNU emacs core @ 2017-06-29 8:02 Uwe Brauer 2017-06-29 8:50 ` Rasmus 2017-07-03 7:28 ` Bastien 0 siblings, 2 replies; 22+ messages in thread From: Uwe Brauer @ 2017-06-29 8:02 UTC (permalink / raw) To: emacs-orgmode Hi I am not sure whether I understand that discussion in emacs dev correctly. Will orgmode be moved into the GNU emacs try as it was done with gnus? If so, how can I download and test for example the current master branch. I didn't mind that policy for gnus, since the development is rather slow and install GNU emacs every 6 months, but org mode is different beast. Uwe Brauer ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-06-29 8:02 org mode moves to GNU emacs core Uwe Brauer @ 2017-06-29 8:50 ` Rasmus 2017-06-29 9:18 ` Uwe Brauer 2017-07-03 7:28 ` Bastien 1 sibling, 1 reply; 22+ messages in thread From: Rasmus @ 2017-06-29 8:50 UTC (permalink / raw) To: emacs-orgmode Uwe Brauer <oub@mat.ucm.es> writes: > I am not sure whether I understand that discussion in emacs dev > correctly. Will orgmode be moved into the GNU emacs try as it was done > with gnus? AFAIK, there are no such plans. The *version* of Org shipped with Emacs is being updated to v9, though. But perhaps I missed a thread that explicitly talks about moving the development center of Org... Rasmus -- Governments should be afraid of their people ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-06-29 8:50 ` Rasmus @ 2017-06-29 9:18 ` Uwe Brauer 0 siblings, 0 replies; 22+ messages in thread From: Uwe Brauer @ 2017-06-29 9:18 UTC (permalink / raw) To: emacs-orgmode >>> "Rasmus" == Rasmus <rasmus@gmx.us> writes: > Uwe Brauer <oub@mat.ucm.es> writes: >> I am not sure whether I understand that discussion in emacs dev >> correctly. Will orgmode be moved into the GNU emacs try as it was done >> with gnus? > AFAIK, there are no such plans. The *version* of Org shipped with Emacs > is being updated to v9, though. Thanks for clarifying. > But perhaps I missed a thread that explicitly talks about moving the > development center of Org... More likely that I did not catch up the thread and panicked :-D ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-06-29 8:02 org mode moves to GNU emacs core Uwe Brauer 2017-06-29 8:50 ` Rasmus @ 2017-07-03 7:28 ` Bastien 2017-07-03 8:33 ` Uwe Brauer ` (3 more replies) 1 sibling, 4 replies; 22+ messages in thread From: Bastien @ 2017-07-03 7:28 UTC (permalink / raw) To: emacs-orgmode Hi Uwe, Uwe Brauer <oub@mat.ucm.es> writes: > I am not sure whether I understand that discussion in emacs dev > correctly. Will orgmode be moved into the GNU emacs try as it was done > with gnus? for the record, I would be in favor of this. Why? - Less installation headaches - Less maintainance and backward-compatibility headaches - Possibility of having etc/TODO in Emacs using org-mode - Attracting Org developers/contributors to Emacs repo As a maintainer, I don't see any advantage of having Org maintained as an ELPA package. -- Bastien ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 7:28 ` Bastien @ 2017-07-03 8:33 ` Uwe Brauer 2017-07-03 12:52 ` qTim Cross [not found] ` <f53ab9c6e9a440bbb5d939a425a97b62@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> ` (2 subsequent siblings) 3 siblings, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2017-07-03 8:33 UTC (permalink / raw) To: emacs-orgmode >>> "Bastien" == Bastien <bzg@gnu.org> writes: > Hi Uwe, > Uwe Brauer <oub@mat.ucm.es> writes: >> I am not sure whether I understand that discussion in emacs dev >> correctly. Will orgmode be moved into the GNU emacs try as it was done >> with gnus? > for the record, I would be in favor of this. Why? > - Less installation headaches > - Less maintainance and backward-compatibility headaches > - Possibility of having etc/TODO in Emacs using org-mode > - Attracting Org developers/contributors to Emacs repo > As a maintainer, I don't see any advantage of having Org > maintained as an ELPA package. But the release cycles are very different, so in order to have always the latest stable org package, I need to compile and install the whole GNU emacs beast. I thought the whole idea of a package system is to avoid this headache. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 8:33 ` Uwe Brauer @ 2017-07-03 12:52 ` qTim Cross 2017-07-03 14:21 ` Uwe Brauer [not found] ` <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk> 0 siblings, 2 replies; 22+ messages in thread From: qTim Cross @ 2017-07-03 12:52 UTC (permalink / raw) To: Uwe Brauer; +Cc: emacs-orgmode Just to throw my 2 cents in. While I can understand the benefits of being able to easily install the latest org package via elpa, I think there are some significant benefits to org being a part of core Emacs. I currently find three issues with the current situation which may be somewhat resolved if org was part of core emacs. 1. Problems with mixed versions. Currently, Emacs has org 8.x included in the distribution. This is despite 9.x being out before the release of 25.2. Something needs to be done to improve coordination and perhaps if it was part of the core, this would be more likely. At any rate, the current situation means you need to be very careful to ensure no org feature is loaded before the ELPA package is loaded or you will get odd behaviour and the symbol's value is void errors. 2. If you just want to load the ELPA version of org (not org-plus-contrib) it can be a real pain. You have to play around with package lists to ensure you actually get the right one. This can be a real hassle if you also use the use-package package as you will often get the older version bundled with Emacs if you don't have your package lists in the right order. 3. I would really like to see two completely separate packages rather than having org and org-plus-contrib. Currently, if you have packages which have org as a dependency and you have loaded org-plus-contrib rather than just org, you will end up with both. Not a big issue, unless your on a slow link as now you will download updates for both org and org-plus-contrib. (there is no 'cleverness' with ELPA dependency specifications - you cannot specify alternative dependencies). A lot will depend on when org becomes part f core. The trick will be to do it once development of org slows down. I've been using org for a long time now and have noticed that the rate of new features being added has slowed down. Much of the changes now is about improvement and refinement of the code base. I would imagine that at some point, things will become even more stable with fewer releases. This would be the point at which it would make sense to bring into core. The other advantage of being part of core is that updates and changes to Emacs will be integrated into org much better. We won't see situations where new versions of Emacs require a rush to update org. for the end user, this should create a much more stable org environment. Then of course, there will always be the option to run org straight from the git repository for those who really want the latest version. I find that once you have the path added to load-path, running from the git repo is not much more effort than installing the latest ELPA package. Uwe Brauer writes: >>>> "Bastien" == Bastien <bzg@gnu.org> writes: > > > Hi Uwe, > > Uwe Brauer <oub@mat.ucm.es> writes: > > >> I am not sure whether I understand that discussion in emacs dev > >> correctly. Will orgmode be moved into the GNU emacs try as it was done > >> with gnus? > > > for the record, I would be in favor of this. Why? > > > - Less installation headaches > > - Less maintainance and backward-compatibility headaches > > - Possibility of having etc/TODO in Emacs using org-mode > > - Attracting Org developers/contributors to Emacs repo > > > As a maintainer, I don't see any advantage of having Org > > maintained as an ELPA package. > > But the release cycles are very different, so in order to have always > the latest stable org package, I need to compile and install the whole > GNU emacs beast. I thought the whole idea of a package system is to > avoid this headache. -- Tim Cross ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 12:52 ` qTim Cross @ 2017-07-03 14:21 ` Uwe Brauer 2017-07-03 22:13 ` Tim Cross [not found] ` <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk> 1 sibling, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2017-07-03 14:21 UTC (permalink / raw) To: emacs-orgmode >>> "qTim" == qTim Cross <theophilusx@gmail.com> writes: > Just to throw my 2 cents in. > 1. Problems with mixed versions. Currently, Emacs has org 8.x included > in the distribution. This is despite 9.x being out before the release of > 25.2. Something needs to be done to improve coordination and perhaps if > it was part of the core, this would be more likely. At any rate, the > current situation means you need to be very careful to ensure no org > feature is loaded before the ELPA package is loaded or you will get odd > behaviour and the symbol's value is void errors. > 2. If you just want to load the ELPA version of org (not > org-plus-contrib) it can be a real pain. You have to play around with > package lists to ensure you actually get the right one. This can be a > real hassle if you also use the use-package package as you will often > get the older version bundled with Emacs if you don't have your package > lists in the right order. > 3. I would really like to see two completely separate packages rather > than having org and org-plus-contrib. Currently, if you have packages > which have org as a dependency and you have loaded org-plus-contrib > rather than just org, you will end up with both. Not a big issue, unless > your on a slow link as now you will download updates for both org and > org-plus-contrib. (there is no 'cleverness' with ELPA dependency > specifications - you cannot specify alternative dependencies). But this critics could be applied to any emacs package and therefore to the package system itself. > A lot will depend on when org becomes part f core. The trick will be to > do it once development of org slows down. I've been using org for a long > time now and have noticed that the rate of new features being added has > slowed down. Much of the changes now is about improvement and refinement > of the code base. I would imagine that at some point, things will become > even more stable with fewer releases. This would be the point at which > it would make sense to bring into core. > The other advantage of being part of core is that updates and changes to > Emacs will be integrated into org much better. We won't see situations > where new versions of Emacs require a rush to update org. for the end > user, this should create a much more stable org environment. Well I update GNU emacs every 6 months it is not difficult but needs considerable longer to compile and install than org mode. > Then of course, there will always be the option to run org straight from > the git repository for those who really want the latest version. I find > that once you have the path added to load-path, running from the git > repo is not much more effort than installing the latest ELPA package. I don't see how that would possible once it is integrated in GNU emacs core, there will be no separate makefile or anything of that sort, but maybe I am missing something. Uwe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 14:21 ` Uwe Brauer @ 2017-07-03 22:13 ` Tim Cross [not found] ` <WM!dafdc952e01c9db7d6439bb691272a1ba664e1bae5ab4554e86ed6b7dfea8661d8bbaf476f3ba9dbb09c0c663c84ecc2!@mailhub-mx5.ncl.ac.uk> 0 siblings, 1 reply; 22+ messages in thread From: Tim Cross @ 2017-07-03 22:13 UTC (permalink / raw) To: Uwe Brauer; +Cc: emacs-orgmode Uwe Brauer writes: >>>> "qTim" == qTim Cross <theophilusx@gmail.com> writes: > > > Just to throw my 2 cents in. > > > 1. Problems with mixed versions. Currently, Emacs has org 8.x included > > in the distribution. This is despite 9.x being out before the release of > > 25.2. Something needs to be done to improve coordination and perhaps if > > it was part of the core, this would be more likely. At any rate, the > > current situation means you need to be very careful to ensure no org > > feature is loaded before the ELPA package is loaded or you will get odd > > behaviour and the symbol's value is void errors. > > > 2. If you just want to load the ELPA version of org (not > > org-plus-contrib) it can be a real pain. You have to play around with > > package lists to ensure you actually get the right one. This can be a > > real hassle if you also use the use-package package as you will often > > get the older version bundled with Emacs if you don't have your package > > lists in the right order. > > > 3. I would really like to see two completely separate packages rather > > than having org and org-plus-contrib. Currently, if you have packages > > which have org as a dependency and you have loaded org-plus-contrib > > rather than just org, you will end up with both. Not a big issue, unless > > your on a slow link as now you will download updates for both org and > > org-plus-contrib. (there is no 'cleverness' with ELPA dependency > > specifications - you cannot specify alternative dependencies). > > But this critics could be applied to any emacs package and therefore to > the package system itself. > Yes. It is a weakness of the package system not org. However, while I have quite a few packages installed, org is the only one where I have two versions installed at once. > > A lot will depend on when org becomes part f core. The trick will be to > > do it once development of org slows down. I've been using org for a long > > time now and have noticed that the rate of new features being added has > > slowed down. Much of the changes now is about improvement and refinement > > of the code base. I would imagine that at some point, things will become > > even more stable with fewer releases. This would be the point at which > > it would make sense to bring into core. > > > The other advantage of being part of core is that updates and changes to > > Emacs will be integrated into org much better. We won't see situations > > where new versions of Emacs require a rush to update org. for the end > > user, this should create a much more stable org environment. > > Well I update GNU emacs every 6 months it is not difficult but needs > considerable longer to compile and install than org mode. > I use to do that - actually, probably even more frequently. I still run from my own build rather than distribution versions because they are even further behind (generally). However, these days, I just run the most recent Emacs release i.e. now 25.2 > > Then of course, there will always be the option to run org straight from > > the git repository for those who really want the latest version. I find > > that once you have the path added to load-path, running from the git > > repo is not much more effort than installing the latest ELPA package. > > I don't see how that would possible once it is integrated in GNU emacs > core, there will be no separate makefile or anything of that sort, but > maybe I am missing something. > There is going to have to be a way for people to maintain and build org independently. When you are maintaining Emacs, you don't want to have to re-build the whole system every time you create a change. What you tend to find is there are multiple Makefiles with a top level Emacs makefile which calls sub-level makefiles as part of the build. It may be necessary to modify configure or add a new option to build outside the emacs tree, but that shouldn't be too difficult. I should emphasise that while I agree org would be good as part of Emacs' core, I don't think this should occur until org change velocity has stabilised to a point where change velocity is lower than it is now. At that point, there will be much less need to be running the most recent snapshot. Maybe my experience is very different. However, I found a lot more motivation to go from org 7.x to 8.x than I did from 8.x to 9.x. In fact, the only visible changes in 9.x I've had to deal with have been about compatibility changes and minor bugs I've had to update for/fix. I could still be running 8.x. The only reason I've updated to 9.x is to avoid issues with some of the contrib packages that have/may have been updated to work with 9.x The other point to keep in mind is that this change won't happen quickly. It will take some time before this can occur and we probably need to start thinking/talking about it now so that when the right time arrives, things can move forward. -- Tim Cross ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <WM!dafdc952e01c9db7d6439bb691272a1ba664e1bae5ab4554e86ed6b7dfea8661d8bbaf476f3ba9dbb09c0c663c84ecc2!@mailhub-mx5.ncl.ac.uk>]
* Re: org mode moves to GNU emacs core [not found] ` <WM!dafdc952e01c9db7d6439bb691272a1ba664e1bae5ab4554e86ed6b7dfea8661d8bbaf476f3ba9dbb09c0c663c84ecc2!@mailhub-mx5.ncl.ac.uk> @ 2017-07-04 10:45 ` Phillip Lord 0 siblings, 0 replies; 22+ messages in thread From: Phillip Lord @ 2017-07-04 10:45 UTC (permalink / raw) To: Tim Cross; +Cc: Uwe Brauer, emacs-orgmode Tim Cross <theophilusx@gmail.com> writes: >> I don't see how that would possible once it is integrated in GNU emacs >> core, there will be no separate makefile or anything of that sort, but >> maybe I am missing something. >> > > There is going to have to be a way for people to maintain and build org > independently. When you are maintaining Emacs, you don't want to have to > re-build the whole system every time you create a change. What you tend > to find is there are multiple Makefiles with a top level Emacs makefile > which calls sub-level makefiles as part of the build. It may be > necessary to modify configure or add a new option to build outside the > emacs tree, but that shouldn't be too difficult. Emacs builds all its lisp with a single Makefile, but the build is incremental. So the rebuild is very quick. To be honest, even if you modify the C layer, the dump is pretty fast. > I should emphasise that while I agree org would be good as part of > Emacs' core, I don't think this should occur until org change velocity > has stabilised to a point where change velocity is lower than it is > now. At that point, there will be much less need to be running the most > recent snapshot. > > Maybe my experience is very different. However, I found a lot more > motivation to go from org 7.x to 8.x than I did from 8.x to 9.x. In > fact, the only visible changes in 9.x I've had to deal with have been > about compatibility changes and minor bugs I've had to update > for/fix. I could still be running 8.x. The only reason I've updated to > 9.x is to avoid issues with some of the contrib packages that have/may > have been updated to work with 9.x This makes the assumption that all of org moves at the same speed. It seems to me that the things currently in contrib still move fairly fast. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk>]
* Re: org mode moves to GNU emacs core [not found] ` <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk> @ 2017-07-04 10:36 ` Phillip Lord 0 siblings, 0 replies; 22+ messages in thread From: Phillip Lord @ 2017-07-04 10:36 UTC (permalink / raw) To: qTim Cross; +Cc: Uwe Brauer, emacs-orgmode Tim Cross <theophilusx@gmail.com> writes: > Just to throw my 2 cents in. > > While I can understand the benefits of being able to easily install the > latest org package via elpa, I think there are some significant benefits > to org being a part of core Emacs. > > I currently find three issues with the current situation which may be > somewhat resolved if org was part of core emacs. > > 1. Problems with mixed versions. Currently, Emacs has org 8.x included > in the distribution. This is despite 9.x being out before the release of > 25.2. Something needs to be done to improve coordination and perhaps if > it was part of the core, this would be more likely. At any rate, the > current situation means you need to be very careful to ensure no org > feature is loaded before the ELPA package is loaded or you will get odd > behaviour and the symbol's value is void errors. I've argued on emacs-devel about this. The problem here is that the distributed org-mode remains in the load path, so you are totally dependent on load path shadowing to ensure the right package gets loaded. This doesn't happen with ELPA packages since only the latest gets added to the load path. My solution to this would be to have Emacs use package.el to load files in core as well as elsewhere. Then, when you installed org from ELPA, package.el would remove the core installed files from the load-path (or rather never add them). You'd need to restart Emacs after installation, but otherwise the problem goes away. Everybody else thought this was a bad idea! Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <f53ab9c6e9a440bbb5d939a425a97b62@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>]
* Re: org mode moves to GNU emacs core [not found] ` <f53ab9c6e9a440bbb5d939a425a97b62@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> @ 2017-07-03 8:52 ` Eric S Fraga 2017-07-03 9:20 ` Alan Schmitt 0 siblings, 1 reply; 22+ messages in thread From: Eric S Fraga @ 2017-07-03 8:52 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 601 bytes --] On Monday, 3 Jul 2017 at 08:33, Uwe Brauer wrote: > But the release cycles are very different, so in order to have always > the latest stable org package, I need to compile and install the whole > GNU emacs beast. I thought the whole idea of a package system is to > avoid this headache. I agree. I like tracking org development but would not be at all keen on tracking emacs in the same way. I was actually quite disappointed when gnus went into emacs master as I can no longer easily play with any experimental branches etc. -- : Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-551-g92e8c8 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 8:52 ` Eric S Fraga @ 2017-07-03 9:20 ` Alan Schmitt 0 siblings, 0 replies; 22+ messages in thread From: Alan Schmitt @ 2017-07-03 9:20 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1090 bytes --] "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes: ESF> On Monday, 3 Jul 2017 at 08:33, Uwe Brauer wrote: >> But the release cycles are very different, so in order to have always >> the latest stable org package, I need to compile and install the whole >> GNU emacs beast. I thought the whole idea of a package system is to >> avoid this headache. ESF> I agree. I like tracking org development but would not be at all keen ESF> on tracking emacs in the same way. I was actually quite disappointed ESF> when gnus went into emacs master as I can no longer easily play with any ESF> experimental branches etc. Same here. I stopped trying to debug some gnus issues when I could no longer easily compile and install new versions independently of emacs. (I use a port of emacs for macOS, so I cannot simply recompile emacs. I need to wait until the changes are incorporated in that port.) It would be too bad if the same happened with org mode. Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <WM!87da95345c53f08eaef15c5b7433fda36bb968c366f5815f7f948ed74d91e1259bbc88820ebbf91e3556ee6a4a3e9852!@mailhub-mx5.ncl.ac.uk>]
* Re: org mode moves to GNU emacs core [not found] ` <WM!87da95345c53f08eaef15c5b7433fda36bb968c366f5815f7f948ed74d91e1259bbc88820ebbf91e3556ee6a4a3e9852!@mailhub-mx5.ncl.ac.uk> @ 2017-07-03 12:10 ` Phillip Lord 2017-07-03 12:40 ` Bastien Guerry [not found] ` <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> 0 siblings, 2 replies; 22+ messages in thread From: Phillip Lord @ 2017-07-03 12:10 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode Bastien <bzg@gnu.org> writes: > Hi Uwe, > > Uwe Brauer <oub@mat.ucm.es> writes: > >> I am not sure whether I understand that discussion in emacs dev >> correctly. Will orgmode be moved into the GNU emacs try as it was done >> with gnus? > > for the record, I would be in favor of this. Why? > > - Less installation headaches > - Less maintainance and backward-compatibility headaches > - Possibility of having etc/TODO in Emacs using org-mode > - Attracting Org developers/contributors to Emacs repo > > As a maintainer, I don't see any advantage of having Org > maintained as an ELPA package. The advantage should be that it allows an independent upgrade cycle for org from the long cycle of Emacs. I presume you do see this as an advantage? The issue is, surely, that it's too much of a PITA for the advantage that you gain? If that's true, I'm interested in which bits are a PITA. Is it fundementally because of ELPA? That is, the latest version of org-mode has to support more than one version of Emacs? Or, is it having two version repos, with all the merging? Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 12:10 ` Phillip Lord @ 2017-07-03 12:40 ` Bastien Guerry 2017-07-03 15:23 ` Robert Horn [not found] ` <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk> [not found] ` <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> 1 sibling, 2 replies; 22+ messages in thread From: Bastien Guerry @ 2017-07-03 12:40 UTC (permalink / raw) To: Phillip Lord; +Cc: emacs-orgmode Hi Philip, phillip.lord@russet.org.uk (Phillip Lord) writes: > I presume you do see this as an advantage? The issue is, surely, > that it's too much of a PITA for the advantage that you gain? Well, it's not really about PITA-or-not-PITA, it's just that I want org-mode to be the default mode for some files in Emacs, and having org-mode in Emacs' core is the most simple way to go for this. Maintainers of projects like Gnus or CEDET don't want their code to live outside of Emacs repo neither, so I guess simplicity is a big win. -- Bastien ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 12:40 ` Bastien Guerry @ 2017-07-03 15:23 ` Robert Horn 2017-07-04 8:01 ` Bastien Guerry [not found] ` <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk> 1 sibling, 1 reply; 22+ messages in thread From: Robert Horn @ 2017-07-03 15:23 UTC (permalink / raw) To: Bastien Guerry; +Cc: emacs-orgmode, Phillip Lord Bastien Guerry writes: > Hi Philip, > > phillip.lord@russet.org.uk (Phillip Lord) writes: > >> I presume you do see this as an advantage? The issue is, surely, >> that it's too much of a PITA for the advantage that you gain? > > Well, it's not really about PITA-or-not-PITA, it's just that I want > org-mode to be the default mode for some files in Emacs, and having > org-mode in Emacs' core is the most simple way to go for this. > I just did a quick check of my git repositories for org-mode and emacs. There is a significant difference in release cycle policies, and this will affect users. Emacs makes a release about once every 9 months, usually a point release. Major feature releases are less frequent. Org-mode makes a release about once per month, also usually a point release. I think that switching to the emacs cycle would be perceived as making org-mode far less responsive to problem reports and feature improvements. There are ways that the git repositories and release policies can be organized to enable more rapid response to minor bugs and small features while still integrating into core emacs. I think that you should figure out a mutually acceptable means of maintaining the present rapid responsiveness. With a suitable structuring of make files, etc., you can probably also deal with the performance issues associated with building updated versions. The emacs maintainers would have to agree. It does call for a little more setup work, and probably a semi-permanent branch structure in git to allow for org updates, while gaining most of what you want. It would also mean that those who want to stay on the leading edge of org-mode would need to maintain git synchronization with emacs rather than org-mode. With good explanation and documentation that shouldn't be too much of a problem. I do it already on an ad-hoc basis because I found elpa to be too problematic. R Horn ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 15:23 ` Robert Horn @ 2017-07-04 8:01 ` Bastien Guerry 0 siblings, 0 replies; 22+ messages in thread From: Bastien Guerry @ 2017-07-04 8:01 UTC (permalink / raw) To: Robert Horn; +Cc: emacs-orgmode, Phillip Lord Hi Robert, first of all, my bad: what I should have said in all these discussion is that any decision regarding moving Org to Emacs' core won't happen any time soon (I'd say two or three years). Keeping Emacs master branch in sync with Org maint branch is not a problem anymore, so the decision of whether Org should go into Emacs core will not depend on this. And by the time the decision will be made, I expect Emacs and Org release cycles will come close. In other words: when Org will be as stable as Emacs and when most of Org's development will happen in its external modules, it will be time to move Org's development to Emacs. But all this is very hypothetical, right now very much "bikeshed" :) Best, -- Bastien ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk>]
* Re: org mode moves to GNU emacs core [not found] ` <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk> @ 2017-07-04 9:59 ` Phillip Lord 0 siblings, 0 replies; 22+ messages in thread From: Phillip Lord @ 2017-07-04 9:59 UTC (permalink / raw) To: Bastien Guerry; +Cc: emacs-orgmode Bastien Guerry <bzg@gnu.org> writes: > Hi Philip, > > phillip.lord@russet.org.uk (Phillip Lord) writes: > >> I presume you do see this as an advantage? The issue is, surely, >> that it's too much of a PITA for the advantage that you gain? > > Well, it's not really about PITA-or-not-PITA, it's just that I want > org-mode to be the default mode for some files in Emacs, and having > org-mode in Emacs' core is the most simple way to go for this. > > Maintainers of projects like Gnus or CEDET don't want their code to > live outside of Emacs repo neither, so I guess simplicity is a big > win. Yes, it would appear that way. But, at the moment, to be distributed with Emacs you have to be in the emacs repo. We've discussed this before, I know, but these two things are not an absolute necessity. Having the Emacs build populate it's source tree with packages is also possible. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>]
* Re: org mode moves to GNU emacs core [not found] ` <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> @ 2017-07-03 13:12 ` Eric S Fraga 0 siblings, 0 replies; 22+ messages in thread From: Eric S Fraga @ 2017-07-03 13:12 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 846 bytes --] On Monday, 3 Jul 2017 at 12:40, Bastien Guerry wrote: [...] > Well, it's not really about PITA-or-not-PITA, it's just that I want > org-mode to be the default mode for some files in Emacs, and having > org-mode in Emacs' core is the most simple way to go for this. This, I must admit, is quite a good reason. I do think of org as an integral part of Emacs these days (org is my default mode essentially) so hadn't stopped to think that without it being formally part of Emacs, Emacs cannot depend on it. Okay. I'm convinced. :-) Will have to update emacs-snapshot more often then... although unfortunately not available for my wee Pandora as far as I can see. And the thought of building Emacs on the Pandora sends me into a catatonic state (600 MHz arm5 processor). -- : Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-551-g92e8c8 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 7:28 ` Bastien ` (2 preceding siblings ...) [not found] ` <WM!87da95345c53f08eaef15c5b7433fda36bb968c366f5815f7f948ed74d91e1259bbc88820ebbf91e3556ee6a4a3e9852!@mailhub-mx5.ncl.ac.uk> @ 2017-07-03 13:30 ` Adonay Felipe Nogueira 2017-07-03 16:52 ` Adonay Felipe Nogueira 2017-07-03 17:58 ` Nick Dokos 3 siblings, 2 replies; 22+ messages in thread From: Adonay Felipe Nogueira @ 2017-07-03 13:30 UTC (permalink / raw) To: emacs-orgmode I have just thought of some more advantages and disadvantages too. * Strengths ** One less split in development effort This one explains itself. Also, for a related article against "forking", "bundling", and "reinventing the wheel" practices, see [[https://wingolog.org/archives/2015/11/09/embracing-conways-law]]. * Threats ** People who still refuse to contribute to GNU Emacs for some reason I have seem people making completely separated projects from GNU Emacs due to concerns of being required to assign copyright to the FSF. However, first and foremost, I must add that I'm in favor of doing such assignment, because FSF is a charity organization --- not just a non-profit ---, and they, together with other organizations, do community-oriented copyleft enforcement, not the "average"/"extortion-based" copyleft enforcement. One thing that I would like to test would be to ask the same people who deny copyright assignments to the FSF: Would they assign copyright to some organization if such organization were to offer them a 1 bi job? Between the two scenarios, I don't see much difference, except that FSF works for a free/libre and just/fair digital society, whereas the "organization" works for its own interests and can kick all their workers and these wouldn't be able to take their own copyrights/work back. -- - [[https://libreplanet.org/wiki/User:Adfeno]] - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard que está no endereço acima aos teus contatos. - Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu aceito, mas não repasso. Entrego apenas em formatos favoráveis ao /software/ livre. Favor entrar em contato em caso de dúvida. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 13:30 ` Adonay Felipe Nogueira @ 2017-07-03 16:52 ` Adonay Felipe Nogueira 2017-07-03 17:58 ` Nick Dokos 1 sibling, 0 replies; 22+ messages in thread From: Adonay Felipe Nogueira @ 2017-07-03 16:52 UTC (permalink / raw) To: emacs-orgmode Also, all the issues related to updates and compatibility would be solved if more poeple used GNU Guix package manager. This way, GNU Emacs can integrate Org in its core, and use the "1 release per 9 months" cycle, and also could have package recipes pointing to arbitrary commits if there is a critical feature or critical bug. Also, GNU Guix users can make and use their own package recipes with ease. Lastly, now a bit more technical: Among other things, GNU Guix project tries to make package recipes in such a way that the package recipe being created or edited avoids depending on specific versions of other packages. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 13:30 ` Adonay Felipe Nogueira 2017-07-03 16:52 ` Adonay Felipe Nogueira @ 2017-07-03 17:58 ` Nick Dokos 2017-07-03 19:38 ` Adonay Felipe Nogueira 1 sibling, 1 reply; 22+ messages in thread From: Nick Dokos @ 2017-07-03 17:58 UTC (permalink / raw) To: emacs-orgmode Adonay Felipe Nogueira <adfeno@openmailbox.org> writes: > I have just thought of some more advantages and disadvantages too. > > * Strengths > > ** One less split in development effort > > This one explains itself. Also, for a related article against "forking", > "bundling", and "reinventing the wheel" practices, see > [[https://wingolog.org/archives/2015/11/09/embracing-conways-law]]. > > * Threats > > ** People who still refuse to contribute to GNU Emacs for some reason > > I have seem people making completely separated projects from GNU Emacs > due to concerns of being required to assign copyright to the > FSF. However, first and foremost, I must add that I'm in favor of doing > such assignment, because FSF is a charity organization --- not just a > non-profit ---, and they, together with other organizations, do > community-oriented copyleft enforcement, not the > "average"/"extortion-based" copyleft enforcement. > Whoa: some of what you describe exists (see e.g. https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-gpl-enforcement/), but it is a distant outlier. Calling it "average" is as inaccurate as calling Pele an "average" footballer. -- Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: org mode moves to GNU emacs core 2017-07-03 17:58 ` Nick Dokos @ 2017-07-03 19:38 ` Adonay Felipe Nogueira 0 siblings, 0 replies; 22+ messages in thread From: Adonay Felipe Nogueira @ 2017-07-03 19:38 UTC (permalink / raw) To: emacs-orgmode Indeed I admit that I might have exagerated when I called it "average". Please excuse my wrong doing. :) ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-07-04 10:45 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-29 8:02 org mode moves to GNU emacs core Uwe Brauer
2017-06-29 8:50 ` Rasmus
2017-06-29 9:18 ` Uwe Brauer
2017-07-03 7:28 ` Bastien
2017-07-03 8:33 ` Uwe Brauer
2017-07-03 12:52 ` qTim Cross
2017-07-03 14:21 ` Uwe Brauer
2017-07-03 22:13 ` Tim Cross
[not found] ` <WM!dafdc952e01c9db7d6439bb691272a1ba664e1bae5ab4554e86ed6b7dfea8661d8bbaf476f3ba9dbb09c0c663c84ecc2!@mailhub-mx5.ncl.ac.uk>
2017-07-04 10:45 ` Phillip Lord
[not found] ` <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk>
2017-07-04 10:36 ` Phillip Lord
[not found] ` <f53ab9c6e9a440bbb5d939a425a97b62@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-03 8:52 ` Eric S Fraga
2017-07-03 9:20 ` Alan Schmitt
[not found] ` <WM!87da95345c53f08eaef15c5b7433fda36bb968c366f5815f7f948ed74d91e1259bbc88820ebbf91e3556ee6a4a3e9852!@mailhub-mx5.ncl.ac.uk>
2017-07-03 12:10 ` Phillip Lord
2017-07-03 12:40 ` Bastien Guerry
2017-07-03 15:23 ` Robert Horn
2017-07-04 8:01 ` Bastien Guerry
[not found] ` <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk>
2017-07-04 9:59 ` Phillip Lord
[not found] ` <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-03 13:12 ` Eric S Fraga
2017-07-03 13:30 ` Adonay Felipe Nogueira
2017-07-03 16:52 ` Adonay Felipe Nogueira
2017-07-03 17:58 ` Nick Dokos
2017-07-03 19:38 ` Adonay Felipe Nogueira
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).