Re: [PATCH] org-src.el: Add plain to org-src-window-setup customization

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> Bastien, could you please add Matt to tiny change contributor list?

Done in https://git.sr.ht/~bzg/worg/commit/f7825a7c, also sorting the
list of names.

-- 
 Bastien

Re: Improve the docstring for 'org-html-mathjax-options'

[Bastien Guerry]

Hi Ihor and Rudolf,

Ihor Radchenko  writes:

> Bastien, AFAIK Rudolf has completed his FSF copyright assignment. 

I do confirm.

> Can you please add him to the contributor list?

Done, thanks,

-- 
 Bastien

Re: [BUG] Could not resolve host: updates.orgmode.org

[Bastien Guerry]

Ihor Radchenko  writes:

>> dig @9.9.9.9 updates.orgmode.org
>> is not returning any record, and I'm not able to open
>> https://updates.orgmode.org/
>
> Confirmed.
>
> Bastien?

Fixed -- a mistake I made yesterday, sorry for the inconvenience.

Thanks for the heads up!

PS: DNS are propagating, it may take a few hours to be available
everywhere.

-- 
 Bastien

Re: [PATCH worg 0/2] Cleanup of LoB file

[Bastien Guerry]

~theophilusx  writes:

> These patches just perform some basic cleanup of the library-of-
> babel.org file. It also moves a duplicate library-of-babel.org file into
> the archive directory.  Note that I am working on a complete overhaul of
> worg, which I will implement in a separate branch in my sourcehut clone
> of the repo.

Thank you very much!  I applied the patches on worg.

I also added you as a contributor to https://git.sr.ht/~bzg/worg/ so
that you can now push changes directly.

Thanks,

-- 
 Bastien

Re: [BUG] ERR_CERT_DATE_INVALID for https://list.orgmode.org/

[Bastien Guerry]

Ihor Radchenko  writes:

> Certificate for list.orgmode.org appears to be expired:
> My browser is giving me ERR_CERT_DATE_INVALID

There is a CNAME record (handled by digitalocean.com) making the
"list.orgmode.org" domain name an alias for "orgmode.yhetil.org",
hosted by Kyle, which works fine.

On the nginx config, there is:

  server {
  server_name orgmode.org;
  listen 443 ssl; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/xxx/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/xxx/privkey.pem;
  include /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  rewrite ^/list/(.*) https://list.orgmode.org/$1 permanent;
  }
  
The last line rewrites requests like

  https://orgmode.org/list/875ynnojvf.fsf@localhost

to 

  https://list.orgmode.org/875ynnojvf.fsf@localhost 

which is supposed to be handled by the CNAME alias.

This is the configuration that used to work so far, I don't understand
why it doesn't work anymore as I didn't change anything.  Certificates
for orgmode.org and yhetil.org are OK.

Kyle, do you have any clue?

-- 
 Bastien

Re: [BUG] worg-setup.org is outdated

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> Sorry. worg-setup.org is outdated. Bastien, could you update it?

Done, thanks for the heads up.

-- 
 Bastien

Re: [BUG] worg-setup.org is outdated

[Bastien Guerry]

Hi Tim,

Tim Cross  writes:

> A 'refresh' of the look probably isn't a bad thing. However, getting it
> right and consistent is likely non-trivial. Not sure if my css skills
> are up to it, but willing to have a look at it anyway. 

Thanks in advance for looking into this!

-- 
 Bastien

Re: Missing stardiviner repos [org-contrib]

[Bastien Guerry]

Hi Kaushal,

> I read about the release of Org Contrib: https://git.sr.ht/~bzg/
> org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 ..
>
> The release notes mention that few of the org-contrib packages have
> moved to your repos on GitHub. But none of those repos are visible: 
> https://github.com/stardiviner?tab=repositories.

I've updated the release notes here:

https://git.sr.ht/~bzg/org-contrib/refs/release_0.4

They point at Christopher's repositories on repo.or.cz.

The problem was that the "Homepage:" keyword was not up to date in 
the org-contrib/lisp/*el files.

> Have you moved those repos elsewhere?

Christopher: there is one repo I've not found, the one for
ob-clojure-literate.el.  Did you move this somewhere?

Thanks for letting me know!

-- 
 Bastien

Re: Error with org-agenda with 9.5.3

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> Bastien, can we bump the Org version to 9.5.4 and trigger ELPA update?

Done yesterday, thanks for the heads up.

-- 
 Bastien

Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Bastien Guerry]

Hi Ihor and Ignacio,

sorry for the late answer.

Ihor Radchenko  writes:

> Bastien, could you kindly check if Ignacio Casso
>  has FSF assignment and update contributors
> page accordingly?

I confirm Ignacio has FSF assignment (since 2022-03-28) and I updated
the Org contributors page.

Best,

-- 
 Bastien

Re: Release 9.5.3

[Bastien Guerry]

Hi Sébastien,

Sébastien Gendre  writes:

> Where can we found the release notes of this version ?

Bugfix releases don't have release notes, only major releases.

See https://orgmode.org/worg/org-maintenance.html for details 
on what to expect on releases.

-- 
 Bastien

Re: Drop defadvice from Org

[Bastien Guerry]

Hi Stefan,

Stefan Monnier  writes:

> The patch below gets rid of the old `defadvice`, replacing it with
> `advice-add`.

Applied in the main branch as 6d73cd34a, thanks a lot!

-- 
 Bastien

Re: Communication problems and possible problems with the website

[Bastien Guerry]

Ihor Radchenko  writes:

> Some time ago, Timothy shared an idea of creating a discourse forum at
> orgmode.org. Discourse is FOSS and provides a familiar interface +
> ability to create and tag topics. The question is integration with Org
> ML, but I am pretty sure that discourse might be much easier to start
> with for new users. WDYT?

Discourse is nice but I'm not favor of installing an instance for Org.

Beginners often ask questions on reddit.com and stackoverflow.com (and
perhaps elsewhere): perhaps some regular users of these websites could
serve as "contributors stewards", redirecting interesting bug reports,
patches or feature requests on this mailing list.

My gut feeling is that we should focus on making the mailing list more
accessible for beginners, more useful for everyone before considering
setting up another communication channel.

I have a new version for Woof! (https://git.sr.ht/~bzg/woof) that I'd
like to finalize and set up this month - let's see how this helps and
reopen this topic in three or four months?

-- 
 Bastien

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Bastien Guerry]

Jean Louis  writes:

> Open up few crypto accounts and let people donate their crypto money
> as well. 

I'm not in favor of this.

-- 
 Bastien

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Bastien Guerry]

Thanks for raising this issues.

Ihor Radchenko  writes:

> Fair point. Paypal requires non-free javascript. Github as well,
> AFAIK.

I've removed the GitHub Sponsors and Paypal links from orgmode.org.

I've not removed the link to https://liberapay.com: I suppose it is
usable without requiring non-free Javascript, but I've not checked.
If someone wants to check, that'd be appreciated.

I've not removed every links to github.com on orgmode.org: e.g. the
link to TEC's homepage at the bottom of the website is still here.

The reason is that browsing TEC's GitHub profile does not require
non-free Javascript: I can browse it fine with M-x eww.

I guess we shall remove references to non-free software (like the
Sublime Text editor - I will do this later on.)

> While orgmode.org is not developed in the same repository with the Org
> mode itself, I have a gut feeling that we still have to follow GNU
> coding standards on the website. 

Yes -- please report other problems for orgmode.org.

> However, WORG contains links to various blogs, reddit,
> stackoverflow, and even youtube and it feels right. I notice that I
> am confused. I would like to hear Bastien's opinion on the topic.

Here is my view on this: the orgmode.org website is part of the GNU
project because Org is part of the GNU project, hence the root pages
of https://orgmode.org should follow the GNU standards.

Worg is different: it is a community-driven documentation about Org.
Even though worg contents are licensed under GNU FDL, they are not
part of the GNU project.

If needed, we can make this clearer on the website or even host worg
on a dedicated domain name.

-- 
 Bastien

Re: Dodgy Worg publishing?

[Bastien Guerry]

Hi Timothy and Thomas,

Timothy  writes:

> Thanks for catching this problem. To me this looks more like a
> problem with the worg publishing than an outdated link. I’ve cc’d
> Bastien as he’s much more familiar with the Worg publish process
> than I am.

You can check the output of Worg publishing process here:

https://builds.sr.ht/~bzg/worg

The latest build contains a line showing that library-of-babel.org
does not export:

https://builds.sr.ht/~bzg/job/627192#task-install-784

  "Reference `fibs' not found in this buffer"

Can someone have a look at this and fix the ref?  

Here is the relevant part of the .org file that does not export:

https://git.sr.ht/~bzg/worg/tree/master/item/library-of-babel.org#L134

Thanks a lot,

-- 
 Bastien

Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html

[Bastien Guerry]

Hi,

Sun Lin  writes:

> Please help to review this patch.

I will - but please be aware that we have a policy of waiting at least
one month before bumping a thread:

https://orgmode.org/worg/org-mailing-list.html#i-didnt-receive-an-answer

Thanks,

-- 
 Bastien

Re: org-table-blank-field key binding removal

[Bastien Guerry]

Hi Eric,

Eric Abrahamsen  writes:

> I also agree it should have had a NEWS entry (something I never
> remember)

I added a note about this on
https://orgmode.org/worg/org-contribute.html 

Thanks,

-- 
 Bastien

Re: org-table-blank-field key binding removal

[Bastien Guerry]

Hi Kyle,

thanks for the heads up!

Kyle Meyer  writes:

> Right, I agree this change should have come with a NEWS entry, though
> 0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
> is from the 9.5 release not 9.4.
>
> However, 9.5 is out, and my understanding is that released NEWS sections
> should not be substantially modified in most cases
> ().  I'll leave it to
> the author of the original change and Bastien to decide if they want to
> make an exception in this case.

I suggest we add a news entry in etc/ORG-NEWS in the bugfix branch for
the change to be advertized for 9.5.x users.

Can anyone do that?

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:

I'm now discarding this call for help on updates.orgmode.org.

-- 
 Bastien

Re: [patch] priorities range reversed

[Bastien Guerry]

Hi Joe,

Bastien  writes:

> See the docstring of `org-priority-highest':

I'm discarding this patch right now - feel free to submit a bug report
if there is something I missed.

Thanks,

-- 
 Bastien

Re: [PATCH] Fix some typos

[Bastien Guerry]

Hi Max,

Max Nikulin  writes:

> A message in this thread
> https://orgmode.org/list/87tuiaxivh@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org

Thanks for bringing this to my attention: I've now applied Juan's
change in the main branch.

-- 
 Bastien

Re: Adjust git redirect to [correct] savannah repo

[Bastien Guerry]

Hi John,

John Hendy  writes:

> $ git pull
> make clfatal: unable to update url base from redirection:
>   asked for: 
> https://code.orgmode.org/bzg/org-mode.git/info/refs?service=git-upload-pack
>redirect: 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/?service=git-upload-pack

I've now added a new redirection so that people trying to pull from
code.orgmode.org will be redirected to the correct git.savannah.gnu.org
address.

Thanks a lot for raising this issue!

-- 
 Bastien

Re: [PATCH] oc-csl: Add support for the text and year citation styles

[Bastien Guerry]

Hi András,

András Simonyi  writes:

> I've attached a patch with the pcase pattern refactored following
> Nicolas's example -- hopefully this solves the problem.

Applied - as you guess, I'm in "optimistic push" mode.  Hopefully
this will help have someone review this if needed.

Thanks, and thanks to Nicolas for alerting soon enough,

-- 
 Bastien

Re: [PATCH]

[Bastien Guerry]

Bastien  writes:

> It seems to me that the defvar declaration is good enough.

I just pushed this.

-- 
 Bastien

Re: Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]

[Bastien Guerry]

Hi Bruce and Emmanuel,

"Bruce D'Arcus"  writes:

> Finally, a question: what's the best way to do complex-ish
> documentation like this collaboratively? Is there an alternative to
> email + patches for the create, comment, revise cycle of refining
> this?

I'm sending you (and Timothy and Nicolas) a link off-list.

> And related: if the goal is to finish this week (?), do we have time
> to do comprehensive documentation? I'm a little skeptical.

The goal is to have something by tomorrow afternoon, of course it does
not need to be "finished" in any sense, it just needs to be better
than what is already committed.

*Thanks*!

-- 
 Bastien

Re: org-cite not mentioned in ORG-NEWS for 9.5

[Bastien Guerry]

Hi all,

Bastien  writes:

>> Emmanuel Charpentier (Cc'ed) wrote some nice documentation for this
>> feature. He might want to chime in.
>
> that'd be great - thanks in advance Emmanuel!

Just a quick heads up to mention that I created a new "Citations
handling" section in the manual, as a first start.  The content is
directly copied from the comment section of oc.el.

If anyone feels like enhancing this, please be my guest.

Thanks,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Hi all,

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation

I've made this move now, with the exceptions we discussed in this
thread.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=db67c7e9231d35e34341431bb4fc8ba213f1d811

Please report anything weird that might happen here.

-- 
 Bastien

Re: [PATCH] lisp/ox-html.el: Restore org-svg class

[Bastien Guerry]

Hi Tom,

Tom Gillespie  writes:

> Bumping this patch for 9.5.

Applied, thanks and sorry for the delay.

Re: ox-slimhtml

[Bastien Guerry]

Hi Laszlo,

Bastien  writes:

> I encourage everyone to try exporting Org documents to HTML using your
> library and see how it compares with ox-html.el for a daily usage.

nobody seemed to be that interested in helping :/

I hope you were able to continue working on this, don't hesitate to
send an update.

In the meantime, I'm dismissing this thread from the "calls for help"
on https://updates.orgmode.org

Re: [ORG] Moving the org-mode.git repo to savannah.gnu.org

[Bastien Guerry]

Hi Pedro,

thanks for your email.

Pedro Bruel  writes:

> I'm already registered at the Emacs Savannah group with access to the
> org-mode repository, but it seems to be a month behind https://
> code.orgmode.org/bzg/org-mode.

The code.orgmode.org and Emacs Savannah repositories are now sync'ed
again.

> I'm new and I don't have an account on code.orgmode.org, but I'm
> ready to submit a new version of ob-julia.el. Should I wait for the
> complete move to Savannah?

I will make the switch to the Emacs Savannah repository official over
the week-end by sending a separate message to the list, you will be
able to send the new ob-julia.el version after this message.

I will keep code.orgmode.org around for a while after 9.5 is out, so
that everyone has a chance to be aware of the official switch.

Thanks,

-- 
 Bastien

Re: [O] Bug: Matching tags: results incomplete when mixing group tags and their ancestors [9.1.7 (9.1.7-12-g74f6ed-elpaplus @ /home/martin/.emacs.d/elpa/org-plus-contrib-20180305/)]

[Bastien Guerry]

Hi Martin,

applied with a slight change in the changelog message, as we
ought to avoid commit references there.  Such references are
fine at the bottom of the message though.

Thanks!

-- 
 Bastien

Re: [O] How can I obtain Org via HTTPS?

[Bastien Guerry]

Hi Radon,

Radon Rosborough  writes:

>> > It does not appear to be possible to obtain the Git repository for Org
>> > via HTTPS
>>
>> FWIW it is now and since a few weeks: see https://orgmode.org
>
> Yep, I noticed and added support for it in straight.el, see
> https://github.com/raxod502/straight.el/commit/25a978830a78ecd73a89c355da47d3dc482aab64

Great, thanks!

-- 
 Bastien

Re: [O] Bug: Broken orgmode.org links in doc/misc/org.texi and lisp/org

[Bastien Guerry]

Hi Tim,

Tim Landscheidt  writes:

>> - https://orgmode.org/org-remember.pdf
>> - https://orgmode.org/worg/code/org-info-js/
>> - https://orgmode.org/worg/org-contrib/babel/languages.html
>> - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
>> - https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-stan.html
>
> The last four work now (merci Bastien!), the first still
> not.

This is now fixed, thanks a lot!

-- 
 Bastien

Re: [O] org-adapt-indentation 'content (was Re: [RFC] Moving "manual.org" into core)

[Bastien Guerry]

Hi Nicolas,

Christian Moe  writes:

>>> Me too, for the same argument.  But this points to a strong limitation
>>> to `org-adapt-indentation' for which I'd like to propose this change.
>>>
>>>(setq org-adapt-indentation t) => current behavior
>>>  (setq org-adapt-indentation nil) => current behavior
>>> (setq org-adapt-indentation 'content) => only adapt content's
>>>  indentation, not that of the property drawer.
>>
>> I proposed this very change some years ago, but it didn't get much
>> traction and wasn't implemented in the end.
>
> FWIW, I'd like this.

Just to make sure we don't lose this idea: do you have code for this?

If not, I'll put a stab at it, I think it would be nice.

Thanks!

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I disagree. My motivation is not to attract more contributors. I don't
> think this was Thomas and Jonathan's motivation when they started the
> project either, but I may be wrong.

For the record, I think having more contributors for the manual is a
very sane goal.

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

phillip.l...@russet.org.uk (Phillip Lord) writes:

> Probably, by the time all of the manuals are in org-mode,
> machines will be significantly faster, there will be emacs-free org mode
> converter, or we will have hit the heat death of the universe. Perhaps
> it's not a problem.

:)

The output of pandoc is encouraging but not usable yet.

~$ pandoc -f org -t texinfo contrib/manual.org > org2.texi

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> You recently re-introduced a file named "orgmanual.org" in contrib/
> alongside "manual.org". The former is apparently outdated.

Yes, my mistake, fixed now.

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Kaushal,

Kaushal Modi  writes:

> Exactly. Emacs will anyways ship with org.texi. So moving the manual
> source to Org in the Org repo shouldn't concern the Emacs repo.

Yes, but it is still a concern for Emacs contributors like Glenn and
others who occasionnally make corrections in Emacs' org.texi.  I'm
fine if we can backport these corrections by hand for the time being.

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Thomas and all,

please, let's take a deep breath and let me try to explain myself as
clearly as possible.  And remember english is not my first language,
so sometimes I may not express myself in the most adequate manner.

First, let me just restate this clearly: I am in favor of editing the
manual.org version instead of org.texi and I am in favor of doing it
as a 1-year experiment, to see how it goes, and I'm in favor of moving
forward as quickly as reasonable here.

But Org is not an island: Org is part of Emacs and Emacs documentation
is written in Texinfo.  This move is not a small one and I agree with
Glenn that it is worth discussing it to the Emacs mailing list before
we make the switch.  I assume the delay it may take.

"Discussing it" is not a hidden plan for not doing it :) It is just a
way of collecting thoughts from the Emacs community.

Also, please accept my apologies if I hurt your feelings when I said:

   "To speak the truth, I first thought migrating to org as the
   preferred format for editing the manual was just a bad idea."

"Bad" was too harsh and too simplistic.

What I thought was more this: editing manual.org instead of org.texi
can be very nice indeed, but it goes in the opposite direction of one
of the goals I've set for Org's code, which is to be directly edited
from within Emacs repo at some point, as Gnus does today.

If we make the switch -- and I want to make it! -- we won't be able
to merge Org's code into Emacs repo anytime soon.

So, to put things in perspective:

- You started the project in 2013:
  https://github.com/tsdye/orgmanual
  
- Someone resurrected it on the list in 2016:
  http://article.gmane.org/gmane.emacs.orgmode/107141
  
- Nicolas made a giant leap forward and announced it was ready last
  December.

I never expressed myself negatively about this experiment because this
is how I saw it: a very nice experiment!  I was amazed at what you did
in 2013 the same way I'm amazed at what Nicolas did last year, because
this is truly a great achievement.

Maybe this is where some misunderstanding arose: to me, there was no
_project_ to migrate to manual.org -- it was an idea in the air after
you made your experiment and we now have the decision at hand because
the project is, well, DONE.

We could have done it another way: we could have discussed it as a
project, then anticipated that it will prevent Org's code to migrate
to Emacs repository, then discussed the pros and cons before investing
more time.

Anyway, here we are, I think it is safe to assume that editing an .org
version of the manual will help us write better documentation within a
year than to assume that Org's code will migrate into Emacs repository
within a year -- so let's celebrate the achievement by moving forward!

Let's just mention this on emacs-devel first.

And I hope my point of view is a bit more clear.

Thanks!

-- 
 Bastien

Re: [O] Patch for documentation standards

[Bastien Guerry]

"Thomas S. Dye"  writes:

> I hope you find it useful.

I definitely do, thanks again!

-- 
 Bastien

Re: [O] Patch for documentation standards

[Bastien Guerry]

Hi Thomas,

> Feel free to cmmit when appropriate.  IMO, the comment period for
> Nicolas' manual project has been sufficiently long and I do not want
> to work with you to prolong it.

Mhh... "working with me" would shorten it for sure!

Anyway, I committed this:

https://code.orgmode.org/bzg/org-mode/commit/dd99ed74430a8b6a48f6b63fac71a0bede3e772f

Let me know what you think.

Thanks,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

>> Is the current contrib/orgmanual.org in sync with doc/org.texi in both
>> master and maint?
>
> Not at all. It is in sync (and a bit above) in master only.

Okay.

>> How difficult is it to keep it in sync in both branches?
>
> "manual.org" relies on improvements made to the Texinfo exporter in
> master branch only, and probably to some smaller parts of the export
> framework. I wouldn't try to sync the manual in maint branch.

So when we make the move, we publish 9.2 by merging master in maint
and edit orgmanual.org from both maint and master.  Correct?

> I find it much easier to handle and edit than its Texinfo counterpart,
> even though I have a good command of the Texinfo syntax. This allowed me
> to do a large number of improvements to it (structure, index,
> typography, overall consistency...), still not integrated in our
> official manual.

For the record: I have no doubt on this and this is also one of the
reasons I'm willing to make the switch.

> I would be surprised, to say the least, if anyone browsing in parallel
> "org.texi" and "manual.org" told me in good faith the former is clearer.

I find orgmanual.org to be clearer.  And I think we can make even more
aesthetics progress on this.

> That being said, we can hold as many number of weeks as you see fit.

It is not about setting a time window: we just need to be careful with
this move and discuss it.  One week seems fine.

I know I have been missing in action very often, and asking for more
time may not sound reassuring... but I'll push this forward, no worry.

Thanks,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.

Is the current contrib/orgmanual.org in sync with doc/org.texi in both
master and maint?

How difficult is it to keep it in sync in both branches?

Would it be okay to hold on for one week before we make the switch,
just to collect more feedback on this?

Thanks,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Glenn,

Glenn Morris  writes:

> Maybe I'm worried about nothing, but I do suggest asking on emacs-devel.

Thanks for your feedback.

You are definitely not worried about nothing.  I share some of your
worries.

To speak the truth, I first thought migrating to org as the preferred
format for editing the manual was just a bad idea.

More precisely: we went from "Oh, it would be nice to have the Org
manual in org" from "Hey, we have it now, why not make the switch?"

But in the process, we didn't define what were the problems we were
tryig to solve.  At least ones that core contributors agreed on.  Or
maybe I missed this discussion.  But no contributor complained about
.texi being such an horrible format for documentation.  I, for one,
feel like it's a very good format, with its apparent rigidity making
for careful contributions, while .org flexibility will bring us new
problems.

That said, why do I accept now?

It is *not* to honor people's work - although that kind of move is
very tempting, because I'm impressed by this achievement and don't
want to waste people's time.

I would define the problem we are trying to solve like this:

  We don't have enough manual contributors.  Many Org users report
  problems in the manual without proposing a patch, probably they
  afraid of making mistakes against a .texi file, so let's make it
  easier for them.

So I do accept to make the switch as a 1-year experiment.

During this year, the process of updating org.texi in Emacs branch
will not change: we will produce org.texi in org-mode/doc/ and then
sync it with Emacs as we do now.

There are very few direct edits of org.texi within Emacs, so we can
handle those changes by hand for now.

The switch will help us move forward like this:

- Let's stabilize editing standards around the org.org file.

- Let's test org capabilities against a giant .org file.

- Let's make `C-x 4 a' do something useful in an .org section.

- Let's write more non-emacs parsers and exporters.

- Let's see if we have more contributions to the manual and if
  we really solved a problem here.

If, in one year, we don't have more contributors and don't feel
the switch made us progress on anything above, and instead is a
blocker to get Org code directly edited from within Emacs, then
we can simply go back to editing org.texi directly.

So thanks for suggesting to bring this to emacs-devel: I will
do it later today, and we won't make the switch before getting
more feedback.  But let's not get blocked by false alarms!

Best,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I don't understand this part. Currently, "manual.org" is exported as
> "org.texi" per
>
>   #+export_file_name: org.texi
>
> So we are getting the best of both worlds. Am I missing something?

No, I was missing the "#+export_file_name: org.texi" part.

>> Or org-manual.org, which seems more readable.
>
> I think "manual.org" is simpler, but I do not mind renaming it to
> "org-manual.org". However, I find "org.org" silly.
>
> In any case, I let you decide the name before moving forward.

I don't have a strong opinion on this.

The rationale for using org.org (which, I agree, sounds a bit
childish) is that this is the current convention for naming GNU
manual is [package-name].[extension].

See emacs.texi, gnus.texi, calc.texi, etc.

If using Org becomes popular, it makes sense to have emacs.org,
gnus.org, calc.org but I find emacs-manual.org, gnus-manual.org
calc-manual.org to be cumbersome.

Ok, we're not there yet, I know :)

But still: RMS recently raised the question on emacs-devel of
whether using .rst for the GNU documentation would be better,
so using .org for this purpose is not entirely hypothetical.

What people think?  Let's just collect votes on this.

+1 for org.org

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I'm bumping the thread. What is still needed for that to move
> forward?

Nothing, please move ahead.

I suggest to rename the file org.org, which will produce org.texi.

Or org-manual.org, which seems more readable.

It would be great to have org-guide.org too, but I guess that's a
lot of work.

> Again, the first step could be to move manual.org to core and have
> it generate a new org.texi, overwriting the previous one.

Yes, let's do that manually for now.

> I would also be nice to think about what can be done to automatically
> generate org.texi upon releases, and remove it from the repository. But
> that can come later.

Indeed.

Sorry it took me long to give the green light on this, I was trying
to anticipate all possible outcomes.

One of my worries was that moving toward editing a manual in .org
does not match GNU developers good practices and habits, which are
to edit .texi files.  But as long as the .texi file exists I guess
we can shake the habits by allowing to edit .org files, which are
more convenient to read and write.

Hopefully this step forward will help create a useful precedent
amont GNU developers.

Thanks to you and to anyone who has been involved in making this
possible!

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Kaushal Modi  writes:

>   - use example blocks for Org syntax instead of "begin_src org",
>
>
> I'd prefer "begin_src org". When these manuals are converted to HTML,
> we can use syntax highlighting to format comments, etc in Org
> snippets. I think it's good to retain the meta data that that is not
> an arbitrary block of text, but Org data. Can you please revert to
> "begin_src org"?

I agree this makes sense.

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Kaushal,

Kaushal Modi  writes:

> I have always started PROPERTIES at col 0. With org-indent-mode
> enabled, it doesn't matter.. looks pretty (PROPERTY drawer in below
> screenshot actually starts at col 0):

what do you think of the proposal to have

  (setq org-adapt-indentation 'content)

set :PROPERTIES: aligned with the beginning of the headline,
while leaving content unindented?

I'd also like to have the better of both worlds without the
need to use `org-indent-mode'.

Thanks for your feedback!

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

thanks for your answer.

Nicolas Goaziou  writes:

>> fill-column: 70
>
> This is already the case.

Okay, I've found .dir-locals.el.

>> org-list-description-max-indent: 5
>> org-edit-src-content-indentation: ?
>
> It is 2. I'd favor 0, but I don't care much.

I've added (org-list-description-max-indent . 5)

>> org-src-preserve-indentation: ?
>
> nil.

OK.

>> This is necessary so that contributors don't mess up accidentally with
>> the desired format.
>
> Why does it matter? We just put them in ".dir-locals.el" and be done
> with it. They override user's preferences anyway.

I meant: it matters to have .dir-locals.el, so we're all set.

>> Can we grow a list here:
>> https://bimestriel.framapad.org/p/22KTn231su
>>
>> Also, why are :PROPERTIES: drawers at the beginning of the line?
>
> I set `org-adapt-indentation' to nil in the file above. It gives more
> columns in a line, which I find more comfortable (e.g., text always
> starts at the same column).

Me too, for the same argument.  But this points to a strong limitation
to `org-adapt-indentation' for which I'd like to propose this change.

   (setq org-adapt-indentation t) => current behavior
 (setq org-adapt-indentation nil) => current behavior
(setq org-adapt-indentation 'content) => only adapt content's
 indentation, not that of the property drawer.

Having the property drawer at the beginning of the line while all
other metadata (e.g. SCHEDULED etc.) are aligned with the beginning
of the headline's content feels wrong.

Would anyone else use (setq org-adapt-indentation 'content) ?

>> - Line 1013: Why an orphan dash?  Because of #+vindex entries?
>
> Yes.

This is definitely a corner-case, but can we imagine another way of
adding #+vindex entries here?

>> - Line 1077: Why indenting this list ?
>
> Fixed. Note that it didn't change output.

Thanks.  Noted.

>> - It would be nice to have #+[kvc]index with multiple entries per
>> line.
>
> I'm not sure I'd like it. The current state eases reviewing all index
> entries associated to a location.

Not that important anyway.

>> - Line 1303 : Why "- =[fn:NAME]= ::" lives on a single line here?
>
> It is on a single line like almost every item definition in the file. Am
> I missing something?

I was noticing different styles, just wondering if there was a
favorite one, as contributors may ask themselves.

>> - Line 21228 ("possible, including the version"): a macro spanning
>>   over multiple lines is not fontified.
>
> This is a fontification bug, unrelated to "manual.org". I suggest to
> discuss about it in another thread.

Sure.

>> - Footnotes: it would be nice to get an overview of a footnote when
>>   the pointer is hovering on some [fn:x] reference.
>
> You can use C-c ' on a footnote reference.

An "electric" display would also be good IMO.

>> We still need to create org.texi for inclusion into Emacs repository.
>
> Why do we need it? If it is mandatory (I fail to see why, since we
> provide the source of the info file), can we include it read-only?

It is mandatory, as long as the GNU standard for documentation is to
provide it as a .texi file.

I don't think providing it read-only is a good idea: people should be
able to edit it and provide patches against it, even though we prefer
to encourage patches against manual.org.

> Note that I made a few design choices I didn't write about, e.g.,:
>
>   - use fixed-width area for one-line examples,

Agreed.

>   - use example blocks for Org syntax instead of "begin_src org",

Agreed.

>   - internal links to headlines always start with a star,

No problem.  Is the leading star optional?

>   - tags, node properties, are not shown with the surrounding columns,
>   - when to use =...= or ~...~ markup: 
> - files or extensions use =...=,
> - anything that is meant to be written in the Org buffer uses =...=,
> - any meaningful token in a programming language uses ~...~.
>
> I used {{{var(...)}}} for meta-syntactic names, but we may simply use
> capitals instead, depending on the output of HTML export. It doesn't
> change anything in Info format.

I guess the above should be part of a guideline on how to contribute
to manual.org - which btw should better be named org.org.

To be continued,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.

Having the manual in .org is a great achievement, congrats to anyone
who worked on this titanic task!

I'm all for editing manual.org instead of org.texi in the long run.

Before moving manual.org into doc/, I'd suggest we agree on editing
variables like `fill-column' and the like:

fill-column: 70
org-list-description-max-indent: 5
org-edit-src-content-indentation: ?
org-src-preserve-indentation: ?

This is necessary so that contributors don't mess up accidentally with
the desired format.

Can we grow a list here:
https://bimestriel.framapad.org/p/22KTn231su

Also, why are :PROPERTIES: drawers at the beginning of the line?  I
have them aligned with the headline in my configuration, which I find
much more readable. Can we fix this?

IMO the above questions should be resolved before exposing manual.org
to collaboration.

Some other micro-reports/requests, not blocking anything:

- Line 1013: Why an orphan dash?  Because of #+vindex entries?

- Line 1077: Why indenting this list ?

- It would be nice to have #+[kvc]index with multiple entries per line.

- Line 1303 : Why "- =[fn:NAME]= ::" lives on a single line here?

- Line 21228 ("possible, including the version"): a macro spanning
  over multiple lines is not fontified.

- Footnotes: it would be nice to get an overview of a footnote when
  the pointer is hovering on some [fn:x] reference.

> The first obvious step is to move the file into "doc/" directory. Then
> I assume we could delete "org.texi" and "org.info" there and generate
> new ones from the Org file. For example, the following command, called
> from the "manual.org" file,
>
> (let ((org-texinfo-logfiles-extensions
>(cons "texi" org-texinfo-logfiles-extensions)))
>   (org-texinfo-export-to-info))
>
> produces an "org.info" file without an "org.texi". It thus prevents
> direct editing of "org.texi". I assume this could be called by "make
> info" target.

We still need to create org.texi for inclusion into Emacs repository.

> So basically, the idea would be to not provide anymore an "org.texi"
> file. Only "manual.org" and "org.info". Emacs developers already apply
> fixes to ORG-NEWS, which is a plain Org file, so I guess it would not
> make their life harder if "manual.org" replaces "org.texi".
>
> WDYT?

I think it's a great step forward but a big one, so let's move
carefully here.

Thanks!

-- 
 Bastien

Re: [O] I created a package ob-clojure-literate for Clojure Literate Programming in Org-mode

[Bastien Guerry]

Thanks!

"numbch...@gmail.com"  writes:

> No, I asked Clojure ML, and posted an issue on clojure-mode GitHub
> issues. I need to find a workaround on myself.
> You can check out the discussion here https://github.com/
> clojure-emacs/clojure-mode/pull/465.

I posted a comment too -- I still think a change in CIDER would be
better.

-- 
 Bastien

Re: [O] I created a package ob-clojure-literate for Clojure Literate Programming in Org-mode

[Bastien Guerry]

"numbch...@gmail.com"  writes:

> https://github.com/stardiviner/ob-clojure-literate

Thanks for sharing this.

About this part:

(defun ob-clojure-cider-do-not-find-ns ()
  "Fix the issue that `cider-current-ns' try to invoke
`clojure-find-ns' to extract ns from buffer."
  (setq-local cider-buffer-ns "user"))

I'm not entirely sure what is the problem here, but it
looks like something that can be fixed directly un CIDER.

Is it so?

-- 
 Bastien

Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]

[Bastien Guerry]

Hi Michel and Nicolas,

Nicolas Goaziou  writes:

> I think this is an issue with Org ELPA. I'm cc'ing Bastien. 

Yes it was, thanks for reporting it.

Things should be fine now.

PS: I'm on the road, with limited access to my emails, so please bare
with me if there is any delay in fixing this kinds of problems.

-- 
 Bastien

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Bastien Guerry]

Correcting myself:

Bastien Guerry <b...@gnu.org> writes:

> You can clone Org from the new server with one of these commands:
>
> ~$ git clone g...@code.orgmode.org:bzg/org-mode.git
   ^^^

This is for when you have an account on code.orgmode.org and want
to clone through ssh.

> ~$ git clone https://code.orgmode.org/bzg/org-mode.git
   ^

This is for users who want to clone and don't need an account on
code.orgmode.org.

-- 
 Bastien

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Bastien Guerry]

Hi Achim,

Achim Gratz  writes:

> And if you'd read through the entirety of the Register article you
> linked to you'd find that presumably any existing OSS hosting would
> continue to be free, so why exactly does Org need to migrate?

I didn't decide to migrate the server based on reading this article
but based on email exchanges with Jason.

Migrating to a new vultr instance was easier than trying to upgrade
the rackspace hosting service and the vultr pricing is better.

Best,

-- 
 Bastien

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Bastien Guerry]

Hi Michael,

Michael Welle  writes:

> thank you all, who are involved in keeping Org going. Not only the
> people, who provide infrastructure, but also the people, who do the daily
> work, who provide patches and the people, who use Org.

+1!

> Is there a way to throw a bit of money on the project, not using the
> company behind the support button on the web page?

I'm on Liberapay and Flattr: 

- https://liberapay.com/bzg
- https://flattr.com/@bzg

I'm not receiving donations through these websites, but it should work.

We are discussing with Nicolas on how to set up a better "donations"
page, we will open the discussion soon.

-- 
 Bastien

[O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Bastien Guerry]

Dear all,

thanks to Jason Dunsmore, we were able to have our orgmode.org server
sponsored by Rackspace.  Their OSS hosting program ends by the end of
the year¹.  Thanks a lot to Rackspace for this program, it saved us a
lot of money!  And to Jason for letting us know about it.

I have configured a new server: a vultr.com Debian 9 x64 with 1024 MB
at 5$ per month -- for a start.

I will make the DNS switch to the new server on the 30/12/2017 between
8pm CET and midnight CET.

**IF YOU USE GIT FOR ORG/WORG, YOU NEED TO UPDATE YOUR REPOSITORIES!**

If you don't use Git for Org, you can jump directly to the end of this
email, where I explain the purpose of code.orgmode.org.


For Org/Worg USERS who use Git to clone Org/Worg
=

After 31/12/2017 (leaving a 24h window for DNS propagation), the only
way to clone the Org git repository will be through our Gogs instance:

  https://code.orgmode.org/bzg/org-mode

If you cloned from the old server, your current .git/config file has:

[remote "origin"]
url = orgm...@orgmode.org:org-mode.git
fetch = +refs/heads/*:refs/remotes/origin/*

You can clone Org from the new server with one of these commands:

~$ git clone g...@code.orgmode.org:bzg/org-mode.git
~$ git clone https://code.orgmode.org/bzg/org-mode.git

In the newly created repository, your .git/config file will now read:

[remote "origin"]
url = g...@code.orgmode.org:bzg/org-mode.git
fetch = +refs/heads/*:refs/remotes/origin/*

or

[remote "origin"]
url = https://code.orgmode.org/bzg/org-mode.git
fetch = +refs/heads/*:refs/remotes/origin/*

You can also use https instead of git, see the repository page.

Instructions are similar for Worg.


For Org and Worg COMMITTERS


You will need to create a new user on https://code.orgmode.org in
order to push commits to org-mode.git or worg.git:

1. Create a user on https://code.orgmode.org
2. Add your ssh public key
3. Send me an email to be added as a collaborator on Org/Worg


Why code.orgmode.org ?
===

The https://code.orgmode.org gogs instance is intended as being a home
for every Org developers, whether they are contributing to Org's core,
Worg documentation - or any other Org-related package.  The idea is to
create a place for code that we collectively take care of.

New Org packages are already welcome.

Mirrors for active Org packages are welcome.

Also, I would like to migrate Elisp files currently in Org's contrib/
directory as separate packages on https://code.orgmode.org.


Testing the new server
===

You can test the new website here: https://beta.orgmode.org

If someone asks anywhere about a broken Org repository, please refer
to this email.

Happy hacking and *thanks*!

¹ 
https://www.theregister.co.uk/2017/10/20/rackspace_ends_discount_hosting_for_open_source_projects/

-- 
 Bastien

[O] Release 9.1.5

[Bastien Guerry]

Hi all,

Org 9.1.5, a bugfix release, is out.

Many thanks to Nicolas and all the contributors.

Merry chrismas and happy hacking to everyone!

-- 
 Bastien

Re: [O] 27.0.50;Missing requirement in org-gnus.el

[Bastien Guerry]

Hi Rasmus,

Rasmus  writes:

> To be honest, I am not sure what Bastien does to prepare a release.  I
> have tried to document up-stream syncing bit.

Most of what I do is documented in README_maintainer.org.

On the orgmode.org server, I run:

~$ make release
~$ make upload

I do

~$ make doc
~$ make upload-doc
~$ make elpa
~$ make upload-elpa
~$ make elpaplus
~$ make upload-elpaplus

I also update orgweb.git to display the correct version number and to
fix the download URLs.

The whole process takes about 10 minutes.

-- 
 Bastien

Re: [O] Issue with org git repo and/or worg?

[Bastien Guerry]

Kaushal Modi  writes:

> Thank you! It just made another commit and it got published
> instantly.

Great, thanks for confirming.

-- 
 Bastien

Re: [O] 27.0.50;Missing requirement in org-gnus.el

[Bastien Guerry]

Kyle Meyer <k...@kyleam.com> writes:

> Bastien Guerry <b...@gnu.org> writes:
>
>> I've just released 9.1.4 which fixes this bug, this minor release can
>> be merged into Emacs.
>
> Thanks, Bastien.  Rasmus, the emacs-sync branch is ready.

Wow, that was fast.  Thanks a lot Kyle!

-- 
 Bastien

Re: [O] Issue with org git repo and/or worg?

[Bastien Guerry]

Hi Kaushal,

> Shouldn't that commit update this page: http://orgmode.org/worg/
> org-blog-wiki.html ? But it hasn't been updated. 
>
> That page hasn't yet updated.

I've fix something in the Worg publishing configuration, can you
check again, maybe by making a test commit?

Thanks!

-- 
 Bastien

[O] Release 9.1.4

[Bastien Guerry]

Hi all,

Org 9.1.4, a bugfix release, is out.

Enjoy!

-- 
 Bastien

Re: [O] 27.0.50;Missing requirement in org-gnus.el

[Bastien Guerry]

Hi Nicolas and Rasmus,

Nicolas Goaziou  writes:

> It would be great. Org 9.1.3 contains a nasty fontification bug. We
> certainly don't want that in Emacs 26.1.

I've just released 9.1.4 which fixes this bug, this minor release can
be merged into Emacs.

Thanks,

-- 
 Bastien

Re: [O] Issue with org git repo and/or worg?

[Bastien Guerry]

Hi Kaushal,

I can pull/push for org-mode and worg correctly, I'm not sure what
could be wrong on the server, nothing changed in a while.

Hope you can find a solution!

-- 
 Bastien

Re: [O] function for inserting a block

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> Bastien  writes:
>
>> is there a simple mechanism in Emacs core to restore the same
>> functionnality?
>
> Of course, it is called Abbrev mode: (info "(emacs)Abbrev
> Concepts").

Abbrev only expands on words constituents, so " You may also use (info "(autotype)Using Skeletons") for more advanced
> uses.

I see.  So combining the two, we would have something like this:

(define-skeleton org-skeleton-src-block
 "" nil
 >
 "#+begin_src" \n
 _ \n
 "#+end_src")

(define-abbrev org-mode-abbrev-table "

Re: [O] Restore old easy template feature (Re: function for inserting a block)

[Bastien Guerry]

Hi Kaushal,

Kaushal Modi  writes:

> I am suggesting to have a minor mode that simply binds "<" to do the
> template insertion (only when that is typed at BOL with optional
> leading whitespace, or if a region is selected).

I think this is a great suggestion and brings the best of both the new
and the old system.

I cannot test this myself until this week-end, but I'd happy too then.

Thanks!

-- 
 Bastien

Re: [O] Release 9.1.2

[Bastien Guerry]

Hi,

"Cook, Malcolm"  writes:

> Should we expect to find release notes at
> http://orgmode.org/Changes.html or somewhere else?

Yes, that's the place for human readable changelogs, which we update
for major and minor releases, not for bugfix releases.

And http://orgmode.org/cgit.cgi/org-mode.git/log/ gives the detailed
git logs.

HTH,

-- 
 Bastien

Re: [O] mimetype for orgmode files

[Bastien Guerry]

John Kitchin  writes:

> I guess I have no objections. Let me know when it is done, and I will
> see about updating mimedb.

Done!

-- 
 Bastien

Re: [O] mimetype for orgmode files

[Bastien Guerry]

Hi Yasushi,

Yasushi SHOJI  writes:

> There is RFC 6648, which "deprecating the "X-" Prefix".

Thanks for letting us know!

> So, it might be better to use "text/org".

I’m fine with "text/org".  John?  Others?

I’ll make the change later this week if nobody disagrees.

Thanks,

-- 
 Bastien

Re: [O] mimetype for orgmode files

[Bastien Guerry]

Hi John,

John Kitchin  writes:

> Let me know the url to that note when you update it so I can use it as a
> primary source for the github registration.

It is now on orgmode.org homepage: http://orgmode.org/index.html

Best,

-- 
 Bastien

Re: [O] Release Org 9.1 soon ?

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> Meanwhile, I'm quite certain that excising Org Struct mode is the best
> option for Org core.

I agree, provided that we don’t deprive some users of some useful
functionalities.

-- 
 Bastien

[O] Release Org 9.0.10

[Bastien Guerry]

Hi all,

Org 9.0.10 is out, the last bugfix release before 9.1,
which is to be released next week.

Thanks to everyone involved!

-- 
 Bastien

Re: [O] Release Org 9.1 soon ?

[Bastien Guerry]

Hi Kaushal and Nicolas,

Nicolas Goaziou  writes:

> There's no hurry anyways. I don't consider this to be a blocker for Org
> 9.1. Of course, it is better if it can be integrated before.

If org-set-tags is to be rewritten, we need to carefully test the
rewrite before integrating it.  So 9.2 is a decent goal for it,
assuming 9.2 will be closer to 9.1 than 9.1 to 9.0.

> Please do, but first, why do you think it is better to have it in core
> instead of, e.g., GNU Elpa? Doesn't "ox-publish" provide some static
> site generation features already?
>
> Also, "ox-hugo" requires "ox-blackfriday", which is another Markdown
> back-end. I'm not questioning the usefulness of this package, but
> I think we need very good reasons to provide overlapping features out of
> the box.

Indeed.  Again, the biggest issue here is that of discoverability,
and moving code into core is the simplest way, but not necessarily
the better.  We can expect new exporters to live in GNU ELPA (or
elsewhere) first, then to be included in core is there is a strong
support and a strong need for it.

-- 
 Bastien

Re: [O] Release Org 9.1 soon ?

[Bastien Guerry]

Hi Kaushal,

Kaushal Modi  writes:

> I'd also like to add a new Org exporter, ox-hugo. As adding it
> wouldn't break other Org functionality, would it be safe to add it
> before this master cut? About this, would it be OK to start by
> creating a scratch branch?

no problem at all for creating a Scratch branch for any purpose in
general, but please wait before adding more exporters.

I would like to set up something like https://gogs.io on the server
to move the code in contribs/ outside of Org’s repo, and to be more
conservative on what’s goes in Org’s core.

I plan to do this move in the next coming weeks, and to discuss it
on the mailing list precisely before, of course.

Thanks,

-- 
 Bastien

Re: [O] Release Org 9.1 soon ?

[Bastien Guerry]

Hi Nicolas,

I’m just back from vacation.

Nicolas Goaziou  writes:

> I think it would be good to release Org 9.1 before the end of the month,
> if possible.

Yes, that’s a good date.

> Is there any major issue left, or any important pending patch to apply
> before doing the merge?

I’ll have a look today and tomorrow and let you know if there is
something on my side.

> Once this is done, I will merge the "hide-column" branch in master.

Thanks.

> I will also take care of removing Org Struct mode from the code
> base.

What are the good alternatives?

Even if the functionality is buggy and the implementation hugly, some
users may still find it useful, we need to take care of providing good
alternatives.

-- 
 Bastien

Re: [O] Scheme output results

[Bastien Guerry]

Hi Neil,

Nicolas Goaziou  writes:

> I cannot, I'm not the maintainer. I'm Cc'ing Bastien. I'll apply your
> patch as soon as it is sorted out.

Thanks for contributing.

I’ve found your copyright assignment for GUILE but it does not cover
changes for GNU Emacs, you would need another copyright assignment for
this.

Thanks in advance,

-- 
 Bastien

Re: [O] org-plus-contrib, where is library-of-babel.org?

[Bastien Guerry]

Hi Kyle,

the library of Babel now lives in Worg here:
http://orgmode.org/worg/library-of-babel.html

I’ve checked and fixed references to it in Org’s documentation,
but if I missed something please let me know.

Thanks,

-- 
 Bastien

Re: [O] org-plus-contrib, where is library-of-babel.org?

[Bastien Guerry]

Kyle Meyer  writes:

>>> Apparently, library-of-babel.org is not distributed with the Org mode
>>> that ships with emacs.  Not sure why that is.  I'm guessing it's a
>>> license issue?
>>
>> It will be in the next release (in /emacs/etc/org/).  If there's a license
>> issue it needs to be removed.

The reason why this library-of-babel.org was not in Emacs is not
because of its lack of license.  I guess it's because Carsten and
Eric didn't think of it as something that should land in Emacs.

Hence my will to clarify this by moving it to Worg, where it will
be more easily accessed.

-- 
 Bastien

Re: [O] org-plus-contrib, where is library-of-babel.org?

[Bastien Guerry]

Hi Kyle,

Kyle Meyer  writes:

> On the Emacs list, Glenn asked us to add a license to
> library-of-babel.org:
>
> https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00169.html

thanks for the heads up -- I'm focusing on my work this week and I
won't have time to deal with orgmode requests until this week-end,
but I will then.

> At the time, I wondered whether that file had any contributors without
> copyright assignment.  I briefly looked through the list of authors
> touching library-of-babel.org in the Org repo and the worg repo, and I
> didn't find any contributors that aren't included in the assignment list
> at http://orgmode.org/worg/org-contribute.html

Thanks for checking this.

In general, if some contributors are not listed on org-contribute.html
I can also check on the GNU server for the list of people with copyright
assignment.

I suggest using the same copyright conditions than the one we have for
Worg documentation:

  Documentation from the http://orgmode.org/worg/ website (either in
  its HTML format or in its Org format) is licensed under the GNU Free
  Documentation License version 1.3 or later.  The code examples and
  css stylesheets are licensed under the GNU General Public License v3
  or later.

But: I would first consider whether this file should be part of Emacs
and Org's core.  I think it should be on Worg instead, to get a chance
to be maintained by more contributors.

What do you think?

-- 
 Bastien

Re: [O] org mode moves to GNU emacs core

[Bastien Guerry]

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

Re: [O] Emacs master now updated to Org 9.0.9

[Bastien Guerry]

Indeed, thanks to you and to everyone involved.

I'm very grateful everyone has been patiently baring
with me for this task.

-- 
 Bastien

Re: [O] org mode moves to GNU emacs core

[Bastien Guerry]

Hi Philip,

phillip.l...@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

Re: [O] Capture template stopped working: nil

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

>> What is the reason for this change?
>
> I don't like `eval' in the code base.

May I ask you why `eval' in the code base is problematic?

This change may break current configurations.  Such changes should
be made with extreme parcimony and for very consensual reasons.

-- 
 Bastien

Re: [O] [PATCH] doc/Makefile: Auto-generate org-version.tex for orgcard

[Bastien Guerry]

Hi Kyle,

Kyle Meyer  writes:

> It seems that the only place where we hardcode the Org version is
> orgcard.tex.  Any objections to auto-generating this as well?

None from me, thanks for this.

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Hi Nicolas,

I'm all for lexical-binding, and it's good to have it in Org's core.

The author of ob-sclang.el used "2011-2017" for the copyright years,
which was obviously a typo and tells that the header was simply copied
from another file (which is 100% fine btw).

>From that, I inferred that the "lexical-binding:t" was also copied
without further thinking, especially since there is no binding at all
in this file.

I think Stardiviner is the one who should make the decision, but I
don't see what "lexical-binding:t" would add to his actual code.

For the more general concern: again, I'm all for lexical binding and
I'm well aware of its numerous advantages, but I don't think we should
rule dynamic binding from contributed Org code.  Dynamic binding has
it's limitations, but when used carefully, it also has the advantage
of being easier to grok for beginners.  We want to welcome beginner's
contributions.  So I simply recommand lexical binding for Org's core,
and what fits developers best for Org's contributions.

And I agree we can move on to something else :)

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> There is absolutely no drawback in using lexical binding. Since Emacs
> 24.1, it _is_ the default for Elisp: every Elisp file created activates
> it, the other binding being for compatibility with older libraries.

Maybe I miss something: when I create a file with C-x C-f whatever.el RET
it does not use a template or does not get created with lexical binding on.

What are you referring to when you say "every Elisp file created activates it"?

> Please, pretty please, don't suggest it is different.

Quoting the Emacs Lisp manual:

  This is the ‘GNU Emacs Lisp Reference Manual’ corresponding to Emacs
  version 26.0.50.

  ...

  Scoping Rules for Variable Bindings

  * Dynamic Binding:: The default for binding local variables in Emacs.
  * Dynamic Binding Tips::Avoiding problems with dynamic binding.
  * Lexical Binding:: A different type of local variable binding.

  ...

  12.10.1 Dynamic Binding
  ---
  
  By default, the local variable bindings made by Emacs are dynamic
  bindings.  When a variable is dynamically bound, its current binding at
  any point in the execution of the Lisp program is simply the most
  recently-created dynamic local binding for that symbol, or the global
  binding if there is no such local binding.

To me the manual clearly says dynamic binding is the default, and
that's why using lexical binding requires additional info in the file.

Whether lexical binding is a good default or not is another question,
and whether lexical-binding:t makes sense in a file with no binding
yet another, third one.

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Bastien Guerry <b...@gnu.org> writes:
>
>> Still: when it is not used, why adding it?
>
> We are not adding it since it is in the file by default; you removed
> it :)

I guess it is in the file by default because the odds are good that
lexical scoping will be actually used.

> This is an odd question, however. The thing is: how is Emacs-lisp
> scoping, dynamic or lexical? We ought not consider it to be both
> throughout the code base (even though one file still uses dynamic
> scoping) as it is just confusing for developers. Since lexical scoping
> prevents a whole class of (vicious) bugs, it is the most common type of
> scoping among modern languages, by large. As of Emacs 24.1, let's just
> consider Elisp to be lexically scoped.

I agree it's good to have lexical scoping, but I don't consider Elisp
to be lexical scopped -- I consider Elisp to let the user pick up the
constraints he wants, with dynamic binding still being the default.

> In a nutshell, "-*- lexical-binding:t ; -*-" ought to be a mandatory
> cookie in every Elisp file.

Maybe lexical binding will be the default behavior one day, but in the
meantime, I would suggest to use "-*- lexical-binding:t ; -*-" only if
lexical binding is actually used in the file.

Best,

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I'm not sure to understand commit
> a023d670eceb9121ef6a511b108fd82265e6d6a8.  In particular, why did
> you remove lexical binding? It really should be active in every
> library, and is the default when you create a new one.

I didn't know lexical binding was now the default when creating a
library.

Still: when it is not used, why adding it?

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

"numbch...@gmail.com"  writes:

> Did my SSH public key add to org-mode repository?

Now yes.

You first need to pull org-mode again like this:

~$ git clone orgm...@orgmode.org:org-mode.git

Then you will be able to push commits.

Do not commit changes outside of the contrib/ repository.

If you have signed the FSF copyright papers, please let me
know under what name.

Best,

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Applied, thanks!

-- 
 Bastien

Re: [O] Backward incompatible outline-invisible-p change in emacs master for Org

[Bastien Guerry]

Kaushal Modi  writes:

> Before I commit this to master, I was thinking that this patch looks
> safe enough for the maint branch. If there are no objections, I can
> commit this to maint and merge to master.

Sure, please go ahead.

Thanks!

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

"numbch...@gmail.com"  writes:

> Here is the patch

The patch needs to have a proper changelog.  You can read
http://orgmode.org/worg/org-contribute.html#patches carefully
for details.

Thanks!

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

"numbch...@gmail.com"  writes:

> Sorry, update SSH public key:

Please resend it as an attachment in a private email.

Thanks,

-- 
 Bastien

Re: [O] Add ob-sclang.el for sclang Org-mode babel support in contrib/

[Bastien Guerry]

Hi,

if you need commit access to org-mode to add code to contrib/,
please send me your public key (the one in ~/.ssh/id...).

Best,

-- 
 Bastien

Re: [O] Backward incompatible outline-invisible-p change in emacs master for Org

[Bastien Guerry]

Hi Paul,

thanks for the follow-up -- Kaushal, thanks for the fix, please go
ahead and commit it.

Best,

-- 
 Bastien

Re: [O] Backward incompatible outline-invisible-p change in emacs master for Org

[Bastien Guerry]

Hi Kaushal,

thanks for putting me in the loop.

Kaushal Modi  writes:

> I also find an org-invisible-p2 function, but it's not clear why it
> does a (backward-char  1) before doing invisibility check.. and that
> too eventually relies on outline-visible-p. (Turns out this function
> has a long history: http://orgmode.org/cgit.cgi/org-mode.git/commit/?
> id=93a4128a6fe47b4e05c0a7cb3ec14878b41d6000 )

The question is: why this patch in the first place?  Paul authored it
and I committed it, so I should know--but I don't.  Maybe Paul know or
you know better?

> Here's a patch for the above proposed solution.

This looks fine, but I'd rather revert the faulty Emacs commit if
it is not necessary.

Until Paul enlighten us, I'll have a deeper look.

Thanks,

-- 
 Bastien

Re: [O] [PATCH] allow klipse export in html

[Bastien Guerry]

Hi Yehonathan,

Yehonathan Sharvit  writes:

> Good news. Where is the commit?

Here : http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=d5bbf3

-- 
 Bastien

Re: [O] [PATCH] allow klipse export in html

[Bastien Guerry]

Hi Matt,

I finally committed this.  Sorry it took so long and thanks
again for the patch!

Best,

-- 
 Bastien