Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. ------------------------------------------------------------------------ I followed the instructions at ... https://orgmode.org/manual/JavaScript-support.html ... adding the following line to my Org file: #+INFOJS_OPT: view:info toc:nil The HTML now contains ... <script src="https://orgmode.org/org-info.js"> // @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt GPL-v3-or-Later // @license-end </script> ... but https://orgmode.org/org-info.js gives 404. P.S. If someone decides to fix this, please consider adding a test. Without it, sooner or later, someone will waste their time again. Rudy Emacs : GNU Emacs 29.0.50 (build 9, x86_64-apple-darwin21.4.0, NS appkit-2113.40 Version 12.3.1 (Build 21E258)) of 2022-05-01 Package: Org mode version 9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/) -- "One can begin to reason only when a clear picture has been formed in the imagination." -- Walter Warwick Sawyer, Mathematician's Delight, 1943 Rudolf Adamkovič <salutis@me.com> [he/him] Studenohorská 25 84103 Bratislava Slovakia
Rudolf Adamkovič <salutis@me.com> writes: > I followed the instructions at ... > > https://orgmode.org/manual/JavaScript-support.html > > ... adding the following line to my Org file: > > #+INFOJS_OPT: view:info toc:nil > > The HTML now contains ... > > <script src="https://orgmode.org/org-info.js"> > // @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt GPL-v3-or-Later > // @license-end > </script> > > ... but https://orgmode.org/org-info.js gives 404. Confirmed. The script is now hosted at https://orgmode.org/worg/code/org-info-js/org-info.js Apparently nobody touched this for a very long time. The last change in this area was 9 years ago. Bastien, I do not fully understand why it is hosted in worg. We mention it in the manual and support in the core. The script is licensed under GPL. Is there any reason to keep it out of the main Org repo? > P.S. If someone decides to fix this, please consider adding a test. Without > it, sooner or later, someone will waste their time again. It is a good idea, though I am not sure if it is appropriate to add network staff into Org tests directly. Best, Ihor
Hi, the https://orgmode.org/org-info.js file is available again, thanks for reporting this. Ihor Radchenko <yantar92@gmail.com> writes: > Apparently nobody touched this for a very long time. The last change > in this area was 9 years ago. Indeed, it would be good to have someone as a maintainer. I suspect the code is stable is still useful to some users. > I do not fully understand why it is hosted in worg. We mention it in the > manual and support in the core. The script is licensed under GPL. > Is there any reason to keep it out of the main Org repo? I'd like the main Org repository to focus on Org's core, i.e. what is sync'ed with GNU Emacs core. I think this nice js hack should live in a dedicated repository, along with a dedicated HTML exporter that enables it. >> P.S. If someone decides to fix this, please consider adding a test. Without >> it, sooner or later, someone will waste their time again. > > It is a good idea, though I am not sure if it is appropriate to add > network staff into Org tests directly. I'm sure it's not a good idea to add network-dependent tests :) Also, we don't want everyone to use https://orgmode.org/org-info.js as the source for the script, as this would put the server under too much load pressure, people should rather host the script themselves. -- Bastien
Bastien <bzg@gnu.org> writes: >> Apparently nobody touched this for a very long time. The last change >> in this area was 9 years ago. > > Indeed, it would be good to have someone as a maintainer. I suspect > the code is stable is still useful to some users. Should we create a help request for updates.orgmode.org? >> I do not fully understand why it is hosted in worg. We mention it in the >> manual and support in the core. The script is licensed under GPL. >> Is there any reason to keep it out of the main Org repo? > > I'd like the main Org repository to focus on Org's core, i.e. what is > sync'ed with GNU Emacs core. This reminds me that Org does not actually consist of a single repo. At this point, we at least have org, org-contrib, worg, and orgweb. Should we create a dedicated project page in sr.ht to group everything together nicely? > I think this nice js hack should live in a dedicated repository, along > with a dedicated HTML exporter that enables it. What about backwards compatibility? > Also, we don't want everyone to use https://orgmode.org/org-info.js as > the source for the script, as this would put the server under too much > load pressure, people should rather host the script themselves. Should we change the default value of org-html-infojs-options then? Alongside with possibly changing the relevant ox-publish code. Best, Ihor
Hi Ihor, Ihor Radchenko <yantar92@gmail.com> writes: > Should we create a help request for updates.orgmode.org? Yes, although this is not a pressant issue IMHO. > Should we create a dedicated project page in sr.ht to group everything > together nicely? There is such a SourceHut project: https://sr.ht/~bzg/orgmode/ The README for the project is that of https://git.sr.ht/~bzg/orgweb because I had to select one, but it is not really what is needed here. I could actually create a meta-repo with only a README that I would use for this project. Also, I could mirror org-mode.git on SourceHut as a read-only repo that would be part of this project - I'm vary that this may confuse users, though. WDYT? >> Also, we don't want everyone to use https://orgmode.org/org-info.js as >> the source for the script, as this would put the server under too much >> load pressure, people should rather host the script themselves. > > Should we change the default value of org-html-infojs-options then? > Alongside with possibly changing the relevant ox-publish code. I don't think we need to change the default value of org-html-infojs-options yet - let's do it when org-info.js is made available for everyone on another URL. Thanks, -- Bastien
Hi Ihor, Bastien <bzg@gnu.org> writes: > There is such a SourceHut project: https://sr.ht/~bzg/orgmode/ The sr.ht project is now on https://sr.ht/~bzg/org/ and lists all relevant repositories, including a mirror of the official org-mode repository at https://git.sr.ht/~bzg/org-mode. -- Bastien
Bastien <bzg@gnu.org> writes:
> Bastien <bzg@gnu.org> writes:
>
>> There is such a SourceHut project: https://sr.ht/~bzg/orgmode/
>
> The sr.ht project is now on https://sr.ht/~bzg/org/ and lists all
> relevant repositories, including a mirror of the official org-mode
> repository at https://git.sr.ht/~bzg/org-mode.
Great! Will it be linked at orgmode.org? Org contribute page is lacking
links to all the repositories (which someone already complained about).
Addition link at the frontpage might also make sense.
Best,
Ihor
Hi Ihor, Ihor Radchenko <yantar92@gmail.com> writes: > Great! Will it be linked at orgmode.org? Good idea, I just added a link to orgmode.org front page. > Org contribute page is lacking > links to all the repositories (which someone already complained about). > Addition link at the frontpage might also make sense. Yes, thanks for suggesting this, I also added an overview of Org repositories on https://orgmode.org/worg/org-contribute.html -- Bastien
Bastien <bzg@gnu.org> writes: >> There is such a SourceHut project: https://sr.ht/~bzg/orgmode/ > > The sr.ht project is now on https://sr.ht/~bzg/org/ and lists all > relevant repositories, including a mirror of the official org-mode > repository at https://git.sr.ht/~bzg/org-mode. I just found some complaints about stability of savannah: https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/packages.el ;; REVIEW I intentionally avoid git.savannah.gnu.org because of SSL ;; issues (see #5655), uptime issues, download time, and lack of ;; shallow clone support. :repo "emacs-straight/org-mode" So, having an official mirror could be handy. However, https://git.sr.ht/~bzg/org-mode does not appear to sync automatically. The last commit in https://git.sr.ht/~bzg/org-mode/log is 15 days ago. Can we setup automatic mirror sync? https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful. Best, Ihor
Hi Ihor, Ihor Radchenko <yantar92@gmail.com> writes: > However, https://git.sr.ht/~bzg/org-mode does not appear to sync > automatically. The last commit in https://git.sr.ht/~bzg/org-mode/log is > 15 days ago. > > Can we setup automatic mirror sync? Sure. > https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful. Yes, somewhat: but I'm not yet clear on the steps to set up a mirror. If anyone can guide me from A to Z, I'd be glad. There is no hurry on this. Thanks! -- Bastien
Bastien <bzg@gnu.org> writes: >> https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful. > > Yes, somewhat: but I'm not yet clear on the steps to set up a mirror. > > If anyone can guide me from A to Z, I'd be glad. The discussion mentions some cron job. Quick googling yielded https://git.sr.ht/~janbaudisch/git-mirror https://www.edwardthomson.com/blog/mirroring_git_repositories.html https://dzone.com/articles/mirroring-git-changes-from-one-server-to-another-s Also, we might try to setup the mirror job via builds.sr.ht, but AFAIK there is no available periodic build trigger, and you may need to request running the job via direct API request (https://man.sr.ht/builds.sr.ht/graphql.md) Hope it helps. Best, Ihor
FWIW, I just set this up: the org-mode.git Savannah repository is now mirrored to git.sr.ht and github.com every day at 1am CET. -- Bastien
Bastien <bzg@gnu.org> writes: > FWIW, I just set this up: the org-mode.git Savannah repository is > now mirrored to git.sr.ht and github.com every day at 1am CET. Thanks! Should we then add an information about mirror to orgmode.org (or, at least, to WORG)? Also, having an actual mirror in sr.ht means that we may set up automatic tests. WDYT about this idea? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Ihor Radchenko <yantar92@gmail.com> writes: > Thanks! Should we then add an information about mirror to orgmode.org > (or, at least, to WORG)? On Worg, sure. > Also, having an actual mirror in sr.ht means that we may set up automatic > tests. WDYT about this idea? Tests are useful if they prevent contributors from changing the code in a way that break them: this must happen before pushing changes to the bugfix or main branches. Automated tests are useful only if we fail to enforce this policy... so I'm not in favor of them. -- Bastien
Bastien <bzg@gnu.org> writes: >> Also, having an actual mirror in sr.ht means that we may set up automatic >> tests. WDYT about this idea? > > Tests are useful if they prevent contributors from changing the code > in a way that break them: this must happen before pushing changes to > the bugfix or main branches. > > Automated tests are useful only if we fail to enforce this policy... > so I'm not in favor of them. I agree that running tests is a good idea before pushing changes. However, it is a big ask for contributors when we need to ensure compatibility with multiple Emacs versions. Running tests on all the supported Emacs version simply takes too much time. Not to mention that installing multiple Emacs versions may not be trivial. Automated tests could cater backwards compatibility checks. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Ihor Radchenko <yantar92@gmail.com> writes:
> Bastien <bzg@gnu.org> writes:
>
>>> Also, having an actual mirror in sr.ht means that we may set up automatic
>>> tests. WDYT about this idea?
>>
>> Tests are useful if they prevent contributors from changing the code
>> in a way that break them: this must happen before pushing changes to
>> the bugfix or main branches.
>>
>> Automated tests are useful only if we fail to enforce this policy...
>> so I'm not in favor of them.
>
> I agree that running tests is a good idea before pushing changes.
> However, it is a big ask for contributors when we need to ensure
> compatibility with multiple Emacs versions. Running tests on all the
> supported Emacs version simply takes too much time. Not to mention that
> installing multiple Emacs versions may not be trivial. Automated tests
> could cater backwards compatibility checks.
+1 on this. However, I do wonder if different positions are due to
different understanding of what we mean when talking about automated
tests.
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Bastien <bzg@gnu.org> writes:
>
>>> Also, having an actual mirror in sr.ht means that we may set up automatic
>>> tests. WDYT about this idea?
>>
>> Tests are useful if they prevent contributors from changing the code
>> in a way that break them: this must happen before pushing changes to
>> the bugfix or main branches.
>>
>> Automated tests are useful only if we fail to enforce this policy...
>> so I'm not in favor of them.
>
> I agree that running tests is a good idea before pushing changes.
> However, it is a big ask for contributors when we need to ensure
> compatibility with multiple Emacs versions. Running tests on all the
> supported Emacs version simply takes too much time. Not to mention that
> installing multiple Emacs versions may not be trivial. Automated tests
> could cater backwards compatibility checks.
I see, you're right -- please go ahead installing a .build.yml file at
the root of the directory so that we can test both the bugfix and main
branches when org-mode.git is sync'ed on sr.ht every day at 1am CET.
I added a note about tests in worg/org-contribute.html.
Thanks!
--
Bastien
Fixed -- Bastien