Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-01 Thread Bastien
Kyle Meyer  writes:

>> This patch autoloads `org-assert-version'.
>
> I don't understand the rationale behind this.  

It was my naive attempt at fixing the "invalid-function
org-assert-version" error several people reported.

> Every spot that calls
> org-assert-version is preceded by a line that requires org-macs, so
> isn't this error likely due to a mixed installation/load-path issue
> where the wrong/older org-macs is taking precedence?

Yes: I thought `org-assert-version' job was to help catching mixed
installations, so my reasoning was that, even when an old org-macs
version has been loaded, autoloading `org-assert-version' would help
report about mixed installation.

Also you're right about org-loaddefs.el, we should keep it.

That said, do you have any idea how to fix the bug people encounter
when installing Org from ELPA and being bitten by "invalid-function
org-assert-version"?

-- 
 Bastien



Re: Looking for new maintainer for ob-sql-mode

2022-12-01 Thread Bastien
Hi Nik

> I wrote https://github.com/nikclayton/ob-sql-mode as a thing that
> scratched my own itch a few years ago. Since then my need for it has
> disappeared, but kind people occasionally report issues or send PRs.
>
> I'm not really in a position to review them, so I'm looking for
> someone who would be interested in taking over maintainership.

Thanks for sharing this on the list - I added you call for help on
https://orgmode.org/worg/org-orphanage.html

All best,

-- 
 Bastien



[PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-11-30 Thread Bastien
Some users reported an (invalid-function org-assert-version) error
when installing Org from ELPA:

https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
https://www.reddit.com/r/emacs/comments/z7qulo/comment/iyd9vam/?context=3

This patch autoloads `org-assert-version'.

It also removes the ;; generated-autoload-file: "org-loaddefs.el"
footer in all files and let Make create org-autoloads.el instead.

Before the patch, installing from ELPA creates both org-loaddefs.el
and org-autoloads.el, which is confusing.

Unless anyone objects, I'll install this patch in the bugfix branch
tomorrow and release 9.6.1.

-- 
 Bastien
>From dab5768422ba1c3cf66cad5d2708d390be87e3d0 Mon Sep 17 00:00:00 2001
From: Bastien 
Date: Thu, 1 Dec 2022 08:16:13 +0100
Subject: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

`org-assert-version' macro needs to be autoloaded for Org to be
correctly initialized.

Also, don't create a specific org-loaddefs.el file along the expected
org-autoloads.el.
---
 Makefile |  2 +-
 doc/org-manual.org   |  3 +--
 lisp/Makefile|  4 ++--
 lisp/ob-core.el  |  4 
 lisp/ob-lob.el   |  4 
 lisp/ob-tangle.el|  4 
 lisp/ob.el   |  4 
 lisp/ol-bbdb.el  |  4 
 lisp/ol-irc.el   |  4 
 lisp/ol.el   |  4 
 lisp/org-archive.el  |  4 
 lisp/org-attach.el   |  4 
 lisp/org-clock.el|  1 -
 lisp/org-colview.el  |  5 -
 lisp/org-compat.el   |  5 +
 lisp/org-datetree.el |  4 
 lisp/org-duration.el |  4 
 lisp/org-element.el  |  4 
 lisp/org-feed.el |  4 
 lisp/org-footnote.el |  5 -
 lisp/org-goto.el |  4 
 lisp/org-id.el   |  4 
 lisp/org-indent.el   |  4 
 lisp/org-keys.el |  4 
 lisp/org-lint.el |  4 
 lisp/org-list.el |  4 
 lisp/org-macs.el |  5 +
 lisp/org-mobile.el   |  4 
 lisp/org-num.el  |  4 
 lisp/org-plot.el |  4 
 lisp/org-refile.el   |  4 
 lisp/org-table.el|  4 
 lisp/org-timer.el|  4 
 lisp/org.el  | 10 +-
 lisp/ox-ascii.el |  2 --
 lisp/ox-beamer.el|  4 
 lisp/ox-html.el  |  5 -
 lisp/ox-icalendar.el |  5 -
 lisp/ox-latex.el |  5 -
 lisp/ox-md.el|  4 
 lisp/ox-odt.el   |  4 
 lisp/ox-org.el   |  5 -
 lisp/ox-publish.el   |  4 
 lisp/ox-texinfo.el   |  4 
 lisp/ox.el   |  6 --
 mk/default.mk|  6 +++---
 mk/org-fixup.el  | 16 
 47 files changed, 22 insertions(+), 188 deletions(-)

diff --git a/Makefile b/Makefile
index f476a3ea7..601f691eb 100644
--- a/Makefile
+++ b/Makefile
@@ -27,7 +27,7 @@ help helpall::
 	$(info make all- ditto)
 	$(info make compile- build Org ELisp files)
 	$(info make single - build Org ELisp files, single Emacs per source)
-	$(info make autoloads  - create org-loaddefs.el to load Org in-place)
+	$(info make autoloads  - create org-autoloads.el to load Org in-place)
 	$(info make test   - build Org ELisp files and run test suite)
 	$(info make vanilla- run Emacs with this Org-mode and no personal config)
 helpall::
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 67b8b4dee..4041c7253 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3,7 +3,6 @@
 #+author:The Org Mode Developers
 #+language:  en
 
-
 #+texinfo: @insertcopying
 
 * Introduction
@@ -128,7 +127,7 @@ $ make autoloads
 
 Note that in this case, =make autoloads= is mandatory: it defines
 Org's version in =org-version.el= and Org's autoloads in
-=org-loaddefs.el=.
+=org-autoloads.el=.
 
 Make sure you set the load path correctly in your Emacs init file:
 
diff --git a/lisp/Makefile b/lisp/Makefile
index f2a14b5d5..0bf4e3ddb 100644
--- a/lisp/Makefile
+++ b/lisp/Makefile
@@ -15,7 +15,7 @@ ifneq ($(ORG_ADD_CONTRIB),)
 endif
 
 LISPV 	:= org-version.el
-LISPI 	:= org-loaddefs.el
+LISPI 	:= org-autoloads.el
 LISPA 	:= $(LISPV) $(LISPI)
 LISPB 	:= $(LISPA:%el=%elc) org-install.elc
 LISPF 	:= $(filter-out $(LISPA),$(sort $(wildcard *.el) $(_ORG_ADD_EL_)))
@@ -72,7 +72,7 @@ $(LISPV):	$(LISPF)
 	@$(MAKE_ORG_VERSION)
 
 $(LISPI):	$(LISPV) $(LISPF)
-	@echo "org-loaddefs: $(ORGVERSION) ($(GITVERSION))"
+	@echo "org-autoloads: $(ORGVERSION) ($(GITVERSION))"
 	@$(RM) $(@)
 	@$(MAKE_ORG_INSTALL)
 
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 5b78ee946..7bc3fbf59 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3467,8 +3467,4 @@ Callers of this function will probably want to add an entry to
 
 (provide 'ob-core)
 
-;; Local variables:
-;; generated-autoload-file: "org-loaddefs.el"
-;; End:
-
 ;;; ob-core.el ends here
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index fb2799755..ecbbe4fe3 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -167,8 +167,4 @@ see."
 
 (provide 'ob-lob)
 
-;; Lo

Release 9.6

2022-11-28 Thread Bastien
Hi all,

Org 9.6 a major release, is out, and will be available from GNU ELPA
in a few hours.

The release notes are published on https://orgmode.org/Changes.html.

On top of the many small and big enhancements against 9.5, here are
some changes you might want to be aware of:

- Org tests are now regularily run:
  https://git.sr.ht/~bzg/org-mode-tests/

  Thanks to Christian Köstlin for helping us setting this!  We are
  looking for someone to maintain this repository.

- Because Org is more than Emacs org-mode, and in order to help people
  working on Org parsers/tools, we made an effort to expose the syntax
  for .org files: https://orgmode.org/worg/org-syntax.html

  Thanks a lot to Tim (TEC) for his work on this!

- Worg is a good place to advertize useful Org packages: if you want
  write access to Worg, please create an account on https://sr.ht and
  send me your username.  (Patches can be sent with no account.)

  To help track orphan Org projects, there is now a dedicated page:
  https://orgmode.org/worg/org-orphanage.html

  Let's work from there to provide more useful information on the Org
  ecosystem in general.

- If you enjoy using Org, please consider supporting contributors via
  https://liberapay.com/org-mode/

  If you contribute to the Org ecosystem in any way (not just code),
  you are welcome to join the list of people who share donations, do
  let us know (don't be shy).

Thanks to *everyone* who continues to make this list a nice and useful
place for Orgers of the World.  Last but not least: thanks to Ihor his
truly amazing work and for being the de facto maintainer.

Enjoy!

-- 
 Bastien



Re: [RFC] Re: Headings and Headlines

2022-11-27 Thread Bastien
Ihor Radchenko  writes:

> I looked into this further and I do not think that it is a good idea to
> make this change in the coming release. Renaming some things is very too
> easy to get wrong and cause failures.

Yes, there is absolutely no rush for this.

-- 
 Bastien



Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

2022-11-26 Thread Bastien
Ihor Radchenko  writes:

> Done: https://orgmode.org/list/87lenyjaxx.fsf@localhost
>
> I also added NEWS entry
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6db75d560

Thanks!

-- 
 Bastien



Re: Feedback on Org syntax document

2022-11-26 Thread Bastien
Ihor Radchenko  writes:

> Will it be enough?

As long as we can point to a thread that contains all the information
and pointers that allows to quickly read Tim's comments, yes, fine.

-- 
 Bastien



Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

2022-11-25 Thread Bastien
Jack Kamm  writes:

> If python-mode support is removed, I'd be willing to help create a new
> ob-python-mode package

Indeed.  A suggestion: can you or Ihor send a help request to the
list, explaining the issue at hand and asking if someone wants to
create and maintain ob-python-mode.el?  

This way we can refer to this email on the list when announcing that
ob-python.el do not support python-mode.el anymore.

-- 
 Bastien



Re: Feedback on Org syntax document

2022-11-25 Thread Bastien Guerry
Ihor Radchenko  writes:

> I will merge them if there are no objections.

Thanks!  No objections.  (Sorry I moved org-syntax.org from worg/dev/
to worg/ right before reading this email, I hope that's okay.)

Perhaps, on top of removing Tim's comments from org-syntax.org we can
store them in a dedicated Worg page? worg/dev/org-syntax-comments.org?

To make sure we can refer to a page when we want to discuss them.

-- 
 Bastien



Re: Org Syntax Specification

2022-11-25 Thread Bastien
Ihor Radchenko  writes:

> I think we need to use rewrite rule here in addition to moving the file.
> If we simply move the file, old links will be broken.

Done now, thanks.

-- 
 Bastien



Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

2022-11-25 Thread Bastien Guerry
Ihor Radchenko  writes:

> I am leaning towards announcing the deprecation in the coming
> release.

Agreed, let's move forward in this direction for the release.

-- 
 Bastien



Re: [BUG] Sourcehut Org project mailing list is confusingly pointing to our build failures list

2022-11-24 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> May we ask them to change this?

Yes, you can ask anything by sending an email to the sr.ht discussion
list: https://lists.sr.ht/~sircmpwn/sr.ht-discuss

If the request is to be able to list *any* mailing list in the mailing
list tab of a sr.ht project, I am not sure it is acceptable, though.

A sr.ht project is a place for sr.ht resources: repositories, mailing
lists, bug trackers.  Allowing a "foreign" mailing list to be listed
in the mailing lists tab would call for allowing foreign bug trackers
(and even foreign repositories) as the resources for a project, which
I think will be (rightfully) rejected as not consistent.

Also, I believe the current state of information is okay.

-- 
 Bastien



Re: [BUG] Org project README at sourcehut links to admin page of Org mailing list

2022-11-24 Thread Bastien Guerry
Ihor Radchenko  writes:

> We probably need
> https://lists.gnu.org/mailman/listinfo/emacs-orgmode

Indeed, thanks for catching this, fixed.

-- 
 Bastien



Re: [BUG] Sourcehut Org project mailing list is confusingly pointing to our build failures list

2022-11-24 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> It looks like the mailing list associated with https://sr.ht/~bzg/org/
> is associated with https://lists.sr.ht/~bzg/org-build-failures.
> It is what I get when I click on "mailing list" tab.

Yes.  SourceHut only allows sr.ht projects to be associated with other
sr.ht resources, like repositories or mailing lists.

> I'd expect that tab to point to our main list instead.

I've edited the README in https://git.sr.ht/~bzg/org (displayed as the
default information page for the Org project) to mention the main Org
mailing list, the same way the "Repositories" heading mentions the
main Savannah Org repository first.  I hope it clarifies things a bit.

Thanks for bringing this up,

-- 
 Bastien



Re: [MAINTENANCE] Org orphanage?

2022-11-21 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> WDYT?

I think it is a very good idea and a natural evolution of org-contrib,
thanks for suggesting this.

If we move in this direction, "org-contrib" is probably not a good
name anymore: perhaps "org-stub"? "org-orphanage"? Other ideas?

We can announce this along with the Org 9.6 release.

Thanks,

-- 
 Bastien



Re: [PATCH] updating manual: visibility of ARCHIVEd subtrees

2022-11-20 Thread Bastien
Hi Giovanni,

Giovanni Ridolfi  writes:

> please find attached a patch updating the documentation file:

Sorry we overlooked this patch, thanks for it!

Applied as 225d58341 in the bugfix branch.

Best,

-- 
 Bastien



Re: Patch links babel graphviz-dot

2022-11-20 Thread Bastien
Hi Nicolas,

Nicolas Graves via "General discussions about Org-mode."
 writes:

> Patch to update some links.

Applied to worg as 9a082fc3, thanks.

-- 
 Bastien



Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien
Ihor Radchenko  writes:

> The best idea I can come up with is the following:
>
> 1. We replace headline -> heading where it is safe

Yes, let's do this.

> 2. We introduce a new constant: org-element-heading-type, defaulting to
>'headline
> 3. We use the new constant instead of 'headline element type symbol
> 4. We announce loudly that 'headline will be deprecated in favour of the
>new constant
> 5. Few years later, we change the org-element-heading-type value to
>'heading

I think this is okay too, though `org-element-heading-type' might not
be explicit enough: what about `org-element-heading-type-symbol'?

-- 
 Bastien



Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien Guerry
Timothy  writes:

> Unfortunately I’m completely with you (and previous comments here). The 
> meaning
> of “headline” is closer to “title” than “heading”. A document can have 
> multiple
> headings but only a single headline (which is specifically the line at the 
> top,
> e.g. “Newspaper headline”).

Ah, thanks a lot for this very clear explanation!

-- 
 Bastien



Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien
Ihor Radchenko  writes:

> I know for sure
> that changing `headline' element to `heading' element type will break
> important packages like org-roam. And there is no good way to work
> around this. We cannot make symbol aliases in Elisp in scenarios like
> (memq (org-element-type ...) '(headline inlinetask)).

We cannot make symbol aliases in Elisp but maybe we can support both
symbols for a transitory period during which we warn third-part devs
about replacing the deprecated 'headline symbol?

> I came to the conclusion that it will, in fact, be easier to change all
> things to use "headline" -- all the instances of "heading" in Org code
> are in function names, variable names, and docstrings. All can be
> changed using obsolete aliases.

Given Vikas and Tim feedback, I would rather move forward by changing
"headline" to "heading" *where it does not break anything* then see if
the proposed scenario above is workable.

In this case, I believe it's better to be partially correct (heading
where possible) than to be consistently wrong (headline everywhere) :)

WDYT?

-- 
 Bastien



Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien Guerry
Ihor Radchenko  writes:

> I came to the conclusion that it will, in fact, be easier to change all
> things to use "headline"

FWIW, I'm fine with such a change.  I'm not a native english speaker,
but a "headline" sounds like it's a one-line heading, so it's okay.

-- 
 Bastien



Re: [PATCH] Re: Update Org to MathJax 3

2022-11-19 Thread Bastien Guerry
Ihor Radchenko  writes:

> Is the current news entry is sufficient? 

The ORG-NEWS entry in the patch looks good, thanks.

> Or should we do something in
> addition to announce backwards-incompatible change?

I suggest to make this change visible on update.orgmode.org by sending
an announcement to the list using X-Woof-Change: 9.6 as a header.

-- 
 Bastien



Re: About org-mode-tests and CI

2022-11-19 Thread Bastien
Philip Kaludercic  writes:

> I am sorry, I know too little about Org and use it too superficially to
> be of much use here.

No problem, and thanks for the super quick feedback!

-- 
 Bastien



Re: [PATCH] Re: [STYLE] :version tags in defcustom definitions

2022-11-19 Thread Bastien Guerry
Ihor Radchenko  writes:

> Let me know if there are any objections.

None on my side, thanks for this.

-- 
 Bastien



Re: About org-mode-tests and CI

2022-11-19 Thread Bastien
Thanks Simon for bringing this up!

Our first need is to have someone volunteering for maintaining our
current test infrastructure - Christian is helping with this right
now but cannot afford to become the maintainer right now.

Philip, is this something you would consider?

If so, that'd be very helpful. Let me know your SourceHut username
and I'll give you access to https://git.sr.ht/~bzg/org-mode-tests/

I am a paid user on SourceHut and I'm happy pulling org-mode-tests
from the orgmode.org server to build from the latest repo manifests.

Once we solve this maintenance issue, we might consider evolving
the tests so that they use Guix instead of Debian if it provides a
real benefit for our needs.

In the meantime, this test infrastructure has already proven very
useful IMHO.

Thanks,

-- 
 Bastien



Re: Volunteering to maintain ob-asymptote.el within Org

2022-11-19 Thread Bastien
Hi,

Ihor Radchenko  writes:

> Bastien, ob-asymptote is still a part of org-contrib [1]. 
> Should we just go ahead and change the maintainer now?
>
> [1] https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/ob-asymptote.el

Yes, done.  Thanks Jarmo for taking over the maintenance!

Feel free to package ob-asymptote.el as a GNU ELPA package so that it
gets more users and let me know when this is done so that I can remove
it from org-contrib.

-- 
 Bastien



Re: [BUG] Null character in block/drawer regexps (but not in org-element parser)

2022-11-12 Thread Bastien Guerry
Hi Ihor,

Ihor Radchenko  writes:

> So, we should probably remove zero-width shenanigans from the code.

+1.

> Unless I miss something.
>
> Bastien, maybe you recall something about presence of null character in
> regexs?

No, I don't.

> P.S. If we decide to remove the null character, I'd prefer to do it
> after the release: this change may affect a lot of code and the bug is
> not that major to risk breakage.

Yes, that's more prudent.

-- 
 Bastien



Re: [patch] improved: add TTL as defcustom to ox-icalendar

2022-11-09 Thread Bastien Guerry
Hi,

Ihor Radchenko  writes:

>> In the meantime I have the paperwork done and have "it" :-)
>
> Bastien, could you please check FSF records?

Yes, I confirm Detlef is registered in the FSF records.

-- 
 Bastien



Re: Typos on https://orgmode.org/manuals.html

2022-11-08 Thread Bastien Guerry
Ihor Radchenko  writes:

> Thanks for reporting!
> I am attaching tentative fix.

Applied, thanks.

> Bastien, I do not have access to orgweb repo.

Now you do :)

-- 
 Bastien



Re: [PATCH] ob-sql: Respect database param when using dbconnection

2022-11-03 Thread Bastien Guerry
Ihor Radchenko  writes:

> Bastien, could you please add Daniel as the maintainer of
> lisp/ob-sql.el?

Done in bd468136d.  Thanks Daniel!

-- 
 Bastien



Re: indent-tabs-mode in org

2022-10-31 Thread Bastien Guerry
Hi Daniel and Ihor,

Daniel Kraus  writes:

> So that clarifies it for me and I do NOT indent with tabs in the
> future :)

We can progressively replace tab chars with spaces, thus re-indenting
correctly all files in the repository.

The Emacs convention is to *not* commit space-only changes as they may
create merge conflicts.

For files that do not have pending patches, we can do the replacement
with the next code-related change.

2 cts,

-- 
 Bastien



Re: Auto detect ob-clojure backend

2022-10-30 Thread Bastien Guerry
Ihor Radchenko  writes:

>> What's your opinion?
>
> I agree.

+1 (FWIW)

-- 
 Bastien



Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

2022-10-29 Thread Bastien
Daniel Kraus  writes:

> I think I'll go with the big `cond` above to auto-detect what's
> installed. That's probably the best out-of-the-box experience.

Indeed, thank you!

-- 
 Bastien



Re: ob-clojure session support

2022-10-29 Thread Bastien Guerry
Hi Ihor and Daniel,

Ihor Radchenko  writes:

> If Bastien removed session support, and you do not see any justification,
> it was most likely an oversight. 

>From memory, I removed session support in ob-clojure.el because it was
too buggy.

> We generally avoid feature regressions:
> https://bzg.fr/en/the-software-maintainers-pledge/
>
> So, if sessions are currently not supported, it should be considered a
> bug and fixed. 

Indeed, having session support would be better.  
Thanks for reimplementing it!

-- 
 Bastien



Re: [WORG] Document in more detail about what maintainers do?

2022-10-29 Thread Bastien Guerry
Hi Ihor,

Ihor Radchenko  writes:

> One month has passed, and I decided to apply the patch as is.
> https://git.sr.ht/~bzg/worg/commit/6fbe51dee6bf276584c24fa1e7ec673526c9326e

Thanks!

-- 
 Bastien



Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

2022-10-28 Thread Bastien
Hi Daniel,

Daniel Kraus  writes:

> I would set it to (and (executable-find "bb") 'babashka) so it's still nil
> when babashka is installed?

(You mean "not installed", right?)

> Or we could even test more available backends like
>
> (cond
>  ((executable-find "bb") 'babashka)
>  ((executable-find "nbb") 'nbb)
>  ((featurep 'cider) 'cider)
>  ((featurep 'inf-clojure) 'inf-clojure)
>  ((featurep 'slime) 'slime))
>
> Or is that too much "magic" in that on some systems the default is bb
> and in others it's cider etc?

I think this is acceptable magic: perhaps we should first check what
is done in other Babel languages and align with their level of magic
for guessing the correct executable -- but I suspect Clojure is a bit
special here, in that it has a lot of different options.

Thanks for taking care of this,

-- 
 Bastien



Re: ob-clojure session support

2022-10-28 Thread Bastien Guerry
Hi Daniel,

Daniel Kraus  writes:

> Does anyone remember what's the status of ob-clojure session
> support?

I'm randomly connected for the next days so I won't risk a reply here,
I hope others can help.

-- 
 Bastien



Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

2022-10-28 Thread Bastien Guerry
Hi Daniel,

Daniel Kraus  writes:

> Just in case you want to play around with Clojure, installing
> babashka (https://github.com/babashka/babashka) is a single binary
> and very simple to install.

For now `org-babel-clojure-backend' is nil.

I suggest to set it to babashka by default: babashka is stable and
well established now, it is by far the most efficient way to run
Clojure code.  Also, it is particularily suitable for Babel use.

What do you think?

-- 
 Bastien



Re: [PATCH] org-manual: Suggest to wait for one month and followup when reporting bugs

2022-10-27 Thread Bastien Guerry
Hi Ihor,

Ihor Radchenko  writes:

> I think we can expose our mailing list policy a bit more in the manual.

Yes, I think this is a good idea.

FWIW, the next version of Woof! (on which I'm focusing right now) will
sending various reminders about things to do, but making the current
policy more apparent to every user is still good.

-- 
 Bastien



Re: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference

2022-10-26 Thread Bastien Guerry
Hi Ihor,

Ihor Radchenko  writes:

>> I have already signed the copyright assignment. (Though I used my
>> other email rudiwillalwayslove...@gmail.com when signing it.)
>
> Bastien, could you kindly check the FSF records?

Yes, I confirm the FSF record is here.

-- 
 Bastien



Re: Org-mode syntax as a tool-independent MIME type

2022-10-18 Thread Bastien
Hi Karl and Timothy,

thank you Karl for reviving this important topic.

I think our collective priority should be to work on
https://orgmode.org/worg/dev/org-synxtax.html so that it reflects the
current Org syntax.  Hopefully we can do this before Org 9.6.  As
discussed with TEC, we can factor out suggestions from this document
so that it is not a mix of facts and hypotheses.

Then we can work on suggestions for evolutions of the current Org-mode
syntax chunk by chunk, as a long-term goal for stabilizing changes for
Org 10 (2023 ?)

What occurred to me while rereading this thread is that definining a
syntax for a IETF RFC on an Org mimetype probably needs to be done not
just by this Emacs Org-mode community, but by bringing together other
"consumers" of .org files, from ecosystems outside of Emacs.

Such a collective work could lead to define what subset of the Org
syntax is useful as the corner-stone for .org files everywhere - which
is what you rightfully brought up with "Orgdown".

If successful, such a process could end up in defining the minimal and
official "Org syntax" while allowing implementations (like the one for
Emacs org-mode) to supercharge this syntax if deemed useful.

Perhaps TEC is right and we will end up having the minimal syntax
being the one we currently use for Org-mode: we'll see.

But we need volunteers: one to work on worg/dev/org-synxtax.org (I'm
assuming TEC can lead the work here) and one to set up a discussion
with people implementing Org in various places (you ?).

I suggest to take this sequentially and not tackle the second work
before we're done with the first one.

2 cts,

-- 
 Bastien



[ANN] We are now regularily testing Org main branch against Emacs 26, 27, 28

2022-10-16 Thread Bastien
Hi all,

thanks to joint efforts by Christian Köstlin and Ihor, we are running
the Org test suite from the Org main branch against Emacs 26, 27, 28.

Every three hours, a script from the orgmode.org server checks if the
Org main branch changed.

If yes, we run the Org test suite against Emacs 26, 27 and 28.

If a test fails, a failure report is sent to a new mailing list:
https://lists.sr.ht/~bzg/org-build-failures and we can inspect what
did go wrong.

If a test fails again (i.e. there was a failure, then the repo was
updated, then there is a failure again for the same test), reports are
sent to Ihor, Christian and me, not to the dedicated list.

Tests are performed by running builds on sr.ht.  You can read the
builds in this new repository: https://git.sr.ht/~bzg/org-mode-tests

We are now testing this setup: if it useful enough, we will redirect
failure reports to the Org mailing list, while using the new one for
repeated failures, so as to not spam the list.

In the future, resources at https://git.sr.ht/~bzg/org-mode-tests
will also perhaps help contributors defining new ways on how to run
tests, beyond the current way ("make test").

Patch submitters are required to run the tests themselves before
submitting a patch: we don't rely on this new setup to test patches,
only to catch errors that may inadvertently slip through the cracks.

Thanks again to Christian and Ihor for setting this up!

-- 
 Bastien



Re: [PATCH] org-manual: Remove mention of print edition

2022-10-15 Thread Bastien
Hi Gregor,

Gregor Zattler  writes:

> Dear org-mode developers, the manual still links to
> network-theory.co.uk for the printed version of the manual.

Thanks for reporting this.

Canceled and replaced by this change, which mentions that the
publisher closed in 2009:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix=58a46fab

I think it is good to remember that Network Theory Ltd. was the
original publisher of the printed manual, as people may find others
options online now.

-- 
 Bastien



Re: links to orgcard.pdf and orgcard.txt are broken

2022-10-15 Thread Bastien Guerry
Ihor Radchenko  writes:

> Bastien, could you take a look?

Now https://orgmode.org/orgcard.txt is back too.

-- 
 Bastien



Re: links to orgcard.pdf and orgcard.txt are broken

2022-10-15 Thread Bastien Guerry
Ihor Radchenko  writes:

>> both the link to the English reference card as .pdf as well as the
>> plain ASCII version mentioned on https://orgmode.org/worg/ are
>> inaccessible.
>
> Confirmed.

Fixed, thanks!

Not for the ASCII version, as I need to find orgcard2ref.pl back in
the repo history before recreating the ASCII card.

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-11 Thread Bastien Guerry
Max Nikulin  writes:

> Unfortunately some redirection targets still respond with 301
>
> 301 https://orgmode.org/manual/Dates-and-Times.html
> 301 https://orgmode.org/manual/Deadlines-and-Scheduling.html
> 301 https://orgmode.org/manual/Emphasis-and-Monospace.html
> 301 https://orgmode.org/manual/Export-in-Foreign-Buffers.html
> 301 https://orgmode.org/manual/HTML-export-commands.html
> 301 https://orgmode.org/manual/Properties-and-Columns.html

Fixed, thanks.

> If redirection directives were included as separate files then it
> would be possible to just check them by a command like
>
> awk '{ if ($NF >= 3) print $3; }' /tmp/manual.txt  |
> xargs --replace -- \
> curl --head --write-out '%{http_code} %{url_effective}\n' \
> --silent --show-error --output /dev/null \
> 'https://orgmode.org/manual/{}'

https://git.sr.ht/~bzg/worg/tree/master/item/nginx.conf contains the
list of redirections -- the checks could be done from here, right?

> Original proposal to add redirections contained an s-expression with
> mappings. I would consider tracking it in the main Org repository. I
> believe, list of info nodes in the released manual should be added to
> it as known names. 

I'm not sure I understand.  Nothing should be added to the main Org
repository to fix a problem with the orgmode.org website, even if it
is a problem with the HTML manual as produced from org-mode.git.

> The idea is to make it easier to add redirections
> before new release. With such list as an input, a simple script could
> detect nodes absent in new release but existed in the earlier
> one. Another case is names appeared again making redirection rules
> obsolete.

I'm not in favor of going into this direction.

So far we provide an easy fix via rewrite rules to the problem created
with the change in the way Texinfo produces URLs.

Such rewrite rules are fine when they are like "rewrite THIS-URL.html
this-url.html" because stumbling on a dead link just because of lower
vs upper case letters is way too frustrating.

But more complex rewrite rules (from old manual nodes to new ones) is
IMHO calling for trouble. What if we split the "Properties and Column"
manual page into "Properties" and "Columns"?  Where to redirect?

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-11 Thread Bastien Guerry
Max Nikulin  writes:

> More:

Fixed, thanks!  

https://git.sr.ht/~bzg/worg/commit/408f05a0

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-11 Thread Bastien
Max Nikulin  writes:

> rewrite /HTML-export-commands\.html HTML-export-commands.html
> permanent;
>
> Redirection loop

Fixed, thanks!

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-11 Thread Bastien
Max Nikulin  writes:

> Bastien, unfortunately you have not fix the problem.

You're right, I updated the nginx conf again.

Let me know if you find any remaining problem.

Thanks!

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-10 Thread Bastien
Hi Max,

Max Nikulin  writes:

> Bastien, I have not tried full configuration, but after a quick check
> I believe that it is a reasonable suggestion. It prevents 301
> redirection from valid URLs like
> https://orgmode.org/manual/Links-in-HTML-export.html
> to
> https://orgmode.org/manual/HTML-Export.html

Indeed, thanks for the heads up.

> In addition I would consider
>
> location /manual/ {
> }
>
> around the rewrite directives to prevent unintentional false positives
> in e.g. worg.

Yes -- there is also location /guide/.

Not that if we use "/manual/" with the ending slash in the location
directive, I don't think the "/" is needed at the beginning of, say,
"HTML-Export.html" to disambiguate.

I completely reviewed the nginx configuration again and updated it
on Worg:  https://git.sr.ht/~bzg/worg/commit/601ebf48

Thanks,

-- 
 Bastien



Re: Some links in online manual do not work

2022-10-07 Thread Bastien Guerry
Ihor Radchenko  writes:

> AFAIK, our nginx configs are not public, but Bastien may privately share
> them if you are willing to help.

FWIW, I've shared the nginx.config here:
https://git.sr.ht/~bzg/worg/tree/master/item/nginx.conf

-- 
 Bastien



Re: [PATCH] lisp/org-agenda.el: Fix filter preset problem for sticky agenda

2022-10-05 Thread Bastien Guerry
Hi Ihor and Liu,

Ihor Radchenko  writes:

>>  I have signed the FSF
>> copyright assignment paper.
>
> Bastien, could you please confirm the FSF records?

I do confirm, I updated https://orgmode.org/worg/contributors.html

Liu, thanks in advance for contributing to Org!

Best,

-- 
 Bastien



Re: Numbered footnotes in the manual interfere with diff

2022-10-04 Thread Bastien
Ihor Radchenko  writes:

> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0641ece57b9d980b63e3a3bb6dc4d467eff3051b
>
> I also documented this in doc/Documentation_Standards.org

Great, thank you.

>>> Also, there is one footnote that is indexed (does it even work?):
>>
>> AFACT it does not work and I think it should not work, we can remove
>> these index entries.
>
> Instead of removing, I moved the entries to the footnote reference.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=180966c645547bf8e0f78ea28d63a686a286d2b2

Even better, thanks.

-- 
 Bastien



Re: Numbered footnotes in the manual interfere with diff

2022-10-03 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> Should we just inline the one-sentence footnotes?

Yes, this would be a progress already.

> Also, there is one footnote that is indexed (does it even work?):

AFACT it does not work and I think it should not work, we can remove
these index entries.

-- 
 Bastien



Re: Markup page 404

2022-10-02 Thread Bastien
kalathilvish...@gmail.com writes:

> Update the page on Literal Examples also 404s.
> https://orgmode.org/guide/Literal-Examples.html

Fixed too, thanks!

-- 
 Bastien



Re: Markup page 404

2022-10-02 Thread Bastien
Hi Vishal,

thanks for reporting this, this is fixed now.

Best,

-- 
 Bastien



Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

2022-10-01 Thread Bastien Guerry
Fixed

-- 
 Bastien



Re: Org ML integration with an existing Discourse instance

2022-09-28 Thread Bastien
Hi Timothy,

Timothy  writes:

>> Not just this: I’m concerned with setting up a user-to-user discussion
>> space that reify a split between users (on a forum) and developers (on
>> the mailing list).
>
> For what it’s worth, as a developer I’d be very interested in the ability of a
> forum to categorise feature requests/bug reports/workflow discussions, etc.

But then the ML and the forum would compete with each other from a
maintainer's point a view: the ones using solely the ML would not get
the same information than the ones using the forum.

>> If a community-driven Discourse instance for Org emerges, that will be
>> a good thing: people could go there instead (or on top) of SO/reddit
>> if they don’t want/like to interact on a mailing list.
>
> We could canvas reddit for example to see if the people currently on there 
> would
> be interested in an Org discourse.

Yes, but mentioning that this would not be "the" Org discourse (not
forum.orgmode.org), just "a" Org forum maintained by X for the benefit
of the whole Org community (which is not really a thing actually, just
a mental shortcut for "every Org user out there").

It would be a good outcome to have such a forum: I'd be more comfy
recommending users to ask questions there iff they don't want/like
sharing questions on the ML than recommending them using reddit and
the like.

All best,

-- 
 Bastien



Re: [WORG] Document in more detail about what maintainers do?

2022-09-28 Thread Bastien
Ihor Radchenko  writes:

> I think the part about CC is missing in
> https://orgmode.org/worg/org-maintenance.html#orga0c76fb

Indeed - can you add it?

Also, I'd more comfortable if org-maintenance.org would use stable
anchors (not #orga0c76fb).

> Also, I find it important to take note about worg documentation for
> built-in babel backends. I did not even know it exist for a long time.
>
> WDYT?

+1 -- and also suggest adding tests, a part that I missed.

-- 
 Bastien



Re: IM dev discussions?

2022-09-28 Thread Bastien
Ihor Radchenko  writes:

> Discourse does allow anonymous email replies.
> https://blog.discourse.org/2016/07/reply-by-email-enabled-for-all-discourse-customers/
> (search "unregistered")

I did not know that - thanks for the pointer.

I'd interested in exploring a use-case: does anyone know of a
Discourse instance that is *fully* bridged with a mailing list?

In the hypothesis of

1. someone maintains a Discourse instance for Org users

2. this instance proves to be very useful to many Org users

3. we find an example of a full ML/Discourse bridge that works

3. Org maintainers decide at some point to promote it from
   org-mode-community-forum.org to forum.orgmode.org

then I'd be in favor of a *partial* bridge with the list, forwarding
only topics that have a "ML" category, for example.

This way forum.orgmode.org would compete with reddit, stackoverflow,
etc. as a user-to-user platform without competing with the list as the
place to contribute to Org's development.

This is the same reasoning than the one I presented on how to handle
third-places like reddit/SO: it is good if they offer various ways for
users to interact with each other *provided* that we have a good way
to ensure that we the ML don't lose those interactions that belongs to
the ML (bug reports, patches, feature requests, etc.) - the "way" here
is to ask for Org contributor stewards on these places.

I hope this all makes sense - I suggest we revisit this topics in a
few months, so that we can all focus on releasing Org 9.6.

-- 
 Bastien



Re: Attempting to create orgcard.org

2022-09-28 Thread Bastien
Kyle Meyer  writes:

> Something to consider: orgcard.tex is included in the Emacs repo and
> fits into their refcard machinery.  If the source changes from .tex to
> .org, the .org file must be included in the Emacs repo, as is done with
> the .org of the manual now (bug#45143, bug#46837).  Doing so would
> involve extra setup and handling on the Emacs side.  Even if someone on
> the Org side volunteers to do that work, another case of special
> handling probably wouldn't be received warmly.

Fully agreed.  And I don't want to be in the same situation than for
the manual, where someone puts a lot of energy into something that we
accept as a temporary experiment, and which becomes something like a
burden for some Emacs maintainers.

Timothy, I believe your efforts are worthwhile as a way to provide
Emacs third-party package maintainers a way to produce a refcard-like
PDF document for their libraries.  But not for Org, where the refcard
is really good enough as it is, especially the Emacs sync constraints
we have right now.

Is that okay with you?

-- 
 Bastien



Re: changing orgcard.tex

2022-09-28 Thread Bastien
Hi Timothy,

Timothy  writes:

>> If we are to make changes against orgcard.tex we should be careful to
>> stick to GNU conventions regarding creating refcards.
>
> Might you have a link to those conventions on hand?

I meant sticking to the .tex commands used for Emacs refcard and its
visual output.

-- 
 Bastien



Re: Serving .org files for worg

2022-09-28 Thread Bastien
Hi Max,

Max Nikulin  writes:

> The following snippet should be added to nginx configuration to assign
> MIME type for .org files:
>
> types {
> # Chromium opens text/x-org in the browser tab,
> # Firefox downloads files and offers to open in some other
>   application.
> # text/x-org  org;
> text/plain  org;
> }

this is now done -- thanks for the reminder.

-- 
 Bastien



Re: Volunteering to maintain ob-asymptote.el within Org

2022-09-27 Thread Bastien
Hi Jarmo,

Jarmo Hurri  writes:

>> As maintainer(s) or ob-asymptote.el, the first step should probably be
>> to package it for GNU ELPA: both you and Luc have signed the FSF
>> copyright assignment, so there is no blocker for joining GNU ELPA.
>> Then we can move it out of org-contrib, which just serves as a
>> transitory repository.
>
> This is an excellent idea. I would certainly want ob-asymptote.el out of
> org-contrib, since the advertisement for org-contrib almost guarantees
> that the files are not maintained. :-)

Did you manage to get feedback from Luc, maintainer of ob-asymptote.el
on org-contrib to decide who will maintain it, where to host it?  It
seems like having ob-asymptote.el on GNU ELPA would be very good.

Let us know how it goes, thanks!

-- 
 Bastien



Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

2022-09-27 Thread Bastien
Hi Eduardo,

Eduardo Mercovich  writes:

> Going back to think about some user testing, we should talk a bit about
> the test objectives to determine the sample screening, starting context
> and tasks...

Here are a the two main goals I see for https://orgmode.org:

- Answer the 3 top questions newbies ask themselves about Org.

- Answer the 3 top questions willing contributors ask themselves on
  how to contribute.

But you'll probably have many more ideas on how to use this space
effectively.  Perhaps you can discuss this off-list with Timothy and
come back with a plan (depending on the time/energy you both have for
this, of course)?

Let us know how it goes!

-- 
 Bastien



Re: IM dev discussions?

2022-09-27 Thread Bastien
Ihor Radchenko  writes:

> Which social website do you have in mind?
>
> I can ask @alphapapa from /r/orgmode.
>
> I guess we can also ask people hanging out on Doom discord and
> discourse.
>
> Maybe also Org roam people. They have discourse.

I'm short of additional ideas.  This is a good start already!

If they are willing to become contributors stewards on these places, I
suggest we advertize this on worg/org-maintenance.org in a new section
dedicated to contributor stewards.

> I am unsure how visible this kind of information will be for new
> third-party package maintainers.
>
> Should we add some information to Appendix A Hacking section of the
> manual? (something along the lines that one may contact Org maintainers
> in other media like IRC, Matrix, etc and then link to
> worg/org-maintenance.org)

I added a "Web presence of maintainers" section in
https://orgmode.org/worg/org-maintenance.html right after the first
one - please go ahead with adding relevant information.

I think this is really "community" information, not something that
pertains to the manual.

> And, of course, we need to announce this to the existing maintainers.
> Upcoming Emacsconf may be a good opportunity.

We could also have an informal OrgConf as a one day gathering online
for bug squashing and discussing community topics like this one.  :)

-- 
 Bastien



Re: org-assert-version considered harmful

2022-09-27 Thread Bastien
Ihor Radchenko  writes:

> Done now.

Thanks!

-- 
 Bastien



Re: Org ML integration with an existing Discourse instance

2022-09-27 Thread Bastien
Ihor Radchenko  writes:

> The main question we need to answer is who is going to maintain that
> Discourse instance. AFAIU, Bastien is mainly concerned with the extra
> maintenance burden.

Not just this: I'm concerned with setting up a user-to-user discussion
space that reify a split between users (on a forum) and developers (on
the mailing list).

If a community-driven Discourse instance for Org emerges, that will be
a good thing: people could go there instead (or on top) of SO/reddit
if they don't want/like to interact on a mailing list.

If this instance is stable and useful enough and futur Org maintainers
feel like this should be advertized as forum.orgmode.org, they will be
able to do it of course.

-- 
 Bastien



Re: IM dev discussions?

2022-09-27 Thread Bastien
I don't think we should try to bridge the current mailing list with a
Discourse instance.  One heavy blocker is that the Discourse instance
will not accept incoming emails from people who are not registered on
the instance.

If someone wants to set up a Discourse instance dedicated to the Org
community, please go for it -- we don't "own" the community.

We can advertize it like we do for SO and reddit here:
https://orgmode.org/worg/org-web-social.html

-- 
 Bastien



Re: Please add support for dlangs packagemanager to ob-C.el

2022-09-27 Thread Bastien
Hi Christian,

thanks for the patch (you forgot to advertize it by adding [PATCH] in
the subject.)

Christian Köstlin  writes:

> Please see the patch comment. I reworked my original patch to fit
> into the TINYPATCH category.

I'm CC'ing Thierry as the maintainer of ob-C.el.

The commit message should be reworked - see
https://orgmode.org/worg/org-contribute.html#commit-messages

I would recommend not using source blocks in the message.

I hope Thierry will have time to review it.

Thanks!

-- 
 Bastien



Re: Attempting to create orgcard.org

2022-09-27 Thread Bastien
Hi Timothy,

Timothy  writes:

> I’m trying to make a .org refcard. 

Is it intented to replace orgcard.tex at some point?  I believe we
should stick to using the same format for Org than for Emacs.  If this
is doable via an .org file that is easier to maintain, that's good.

PS: FWIW, I don't think refcards should include custom keybindings.

-- 
 Bastien



Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

2022-09-27 Thread Bastien
Hi Daniel,

thanks for volunteering!  I added you as the ob-clojure.el maintainer
on the main branch (commit 1c7acb427).

Replying to emails when we CC you should be enough, but more help is
always welcome, of course.

Also, please create an account on https://savannah.gnu.org/git/ and
ask to join the Emacs group: https://savannah.gnu.org/git/?group=emacs

An Emacs maintainer will give you write access so that you can push
commits for ob-clojure.el directly.

When in doubt, just ask the mailing list :)

Cheers,

-- 
 Bastien



Re: IM dev discussions?

2022-09-27 Thread Bastien
Ihor Radchenko  writes:

> Do note that I sometimes referred to reddit/SO questions in patches.
> Should we avoid this? 

Yes.  If someone reports a bug on reddit/SO/X we should encourage
her/him to fill it on the list.  If he/she doesn't, we should fill it
ourselve there for the record, adding the reddit/SO/X link in the
email, and mention that email in the commit message.

> If so, should this convention be added to
> https://orgmode.org/worg/org-contribute.html?

Yes, I added this on Worg as commit 1b5a8177.

-- 
 Bastien



Re: IM dev discussions?

2022-09-26 Thread Bastien
Ihor Radchenko  writes:

> Does #org-mode share such a strong stand?

I don't know.  People in charge of the #org-mode channel should decide.

I'm fine with Org referring to #org-mode in both cases.

> If so, it may be problematic even to quote the discussions there in Org
> commit messages.
> IMHO, it makes #org-mode a lot less usable for the purposes of Org
> development. Deliberately public and unencrypted matrix #org-mode room
> is better in this regard.

Our commit messages should only refer to public archives of the Org
mailing list (https://lists.gnu.org/archive/html/emacs-orgmode/ or
https://list.orgmode.org). 

If a discussion on #org-mode or a GitHub repository is relevant for
Org development, it has to be referred to in a thread on the list,
which we can then be quoted for context in the commit message.

-- 
 Bastien



Re: IM dev discussions?

2022-09-26 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> Maybe we can nicely ask moderators/active users of reddit/SO to redirect
> people to Org ML when appropriate? Similar to our current effort with
> contributor stewards.

That's a very good idea!

If these contributor stewards agree, we can even advertise their role
on https://orgmode.org/worg/org-maintenance.html

> I think you are missing one important category of contributors --
> maintainers of third-party packages. I've got involved into several
> Org-related discussions on Github because I got @mentioned in some
> threads. My impression is that a number of package maintainers on Github
> actively cross-link issues between repos and try to resolve problems
> together. However, they rarely reach out to Org ML.

True that.

> Notably, I managed to communicate on GitHub simply using email.

I too.

> May we set a single account on GitHub and link it to Org ML so that
> people can @mention Org team on GitHub, and we automatically get the
> email directly to Org ML?

I'm against it: it will make it easier for Org ecosystem maintainers
on GitHub to send notifications to the Org ML without joining it while
probably forcing Org maintainers on the ML to follow-up discussions on
GitHub.  That's not a positive outcome.

What I suggest instead to do is to document GitHub accounts of Org
core maintainers on worg/org-maintenance.org for those who have one.

This way maintainers of Org libraries on GitHub will know they can @
these accounts in their issues.  And it will stay the responsability
of Org core maintainers to decide how to deal with these issues.

For some of them, it will just lead to a reply on the issue (as when
Org maintainers contribute to non-official Org spaces, like the Doom
or spacemacs discord servers); for issues that are of importance for
Org core development, we should suggest them to send an email to the
list.

WDYT?

-- 
 Bastien



Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

2022-09-25 Thread Bastien
Timothy  writes:

> Done :)

Thanks!

-- 
 Bastien



Re: IM dev discussions?

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

> Both these things may not come together, or at the same time. For instance, 
> I’m
> currently talking to someone on the Doom discord who has a few potential
> improvement to Org in the works, and the main barrier to us hearing about them
> is their nervousness at sending an email in to the Org ML.

We probably can reassure them and teach them how not to be afraid to
go public and send an email to this list.

> Like it or not, I have the distinct impression that
>> to be fine with working by email, the old way.
> is a much greater ask than it used to be. Some people may come around with 
> time,
> but for getting started at least I think there’s quite a bit of value in 
> having
> less “alien” way of getting started. One could argue that by neglecting
> non-ML/IRC ways of interacting with the Org project we are accidentally 
> seceding
> territory to non-free services like reddit, stackexchange, and co.

Let's imagine we set up a Discourse instance on forum.orgmode.org.

It will probably attract users that don't really like/want to interact
through a mailing list, and maybe some of them will prefer this option
rather than posting to reddit, SO, etc.

It is a good outcome per se, and a way not to cede too much territory
to non-free services.

But then at some point we will have two problems: we will need to
spend energy encouraging these Discourse users send their patches to
the mailing list and people on this ML who are mostly here to help
others will have to split their time and attention between the ML and
forum.orgmode.org, because both will be official support channels
for the Org community.

To sum it up (1) I don't think we have the resources to compete with
non-free services like reddit (and should accept that they work as
users-to-users support channels) and (2) teaching users how to send a
patch to the mailing list is something we will have to do anyway at
some point if we want to help users become contributors.

So I really see why a Discourse instance might be tempting but this
will surely break something that works okay right now: this list as
the place where to keep track of Org's development and contribute
to it.

...

For french-speaking people, we have both a ML and a forum.

- the list: https://lists.sr.ht/~bzg/emacsfr
- the forum: https://emacs.gnu.re/public/

We advertize both equally on https://emacs-doctor.com.

It is okay to have both here because they are not competing with each
other, they are just places for discussing things.

Interestingly, the ML seems more active than the forum, but I would
not mind seeing the forum become more active than the list.  They are
just places to discuss Org topics in french.

The difference with considering list.orgmode.org + forum.orgmode.org
is that none of these places (FR-ML and FR-forum) is "the place were
we keep track of Org's development and where we encourage and teach
people how to contribute"... that's what matters in this discussion.

All best,

-- 
 Bastien



Re: IM dev discussions?

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

> Yep, but I do think it’s good to have a few promoted places, ideally based on
> FOSS services. Not to start another tangent, but this is one of the reasons 
> why
> I think discourse could be a good idea — as a FOSS replacement for reddit,
> stackoverflow, etc.

If someone wants to set up a Discourse instance and maintain it, of
course (s)he can.  The question is: should this become an *official*
place for Org discussions, maintained by Org maintainers?  I don't
think this is desirable, given the resources we have*.

It is so easy to set up a Discourse instance and quite difficult
to maintain it in the long run -- also, how to explain to newcomers
when to send messages to Discourse and when to reach the list?  This
will probably end up as "a place for users" (Discourse) and "a place
for developers" (the ML), which I don't want.

* FWIW I would much prefer to have contributors commit to enhance
  Worg: it is a critical resource, seen by ~30K per month, and many
  pages are outdated.

>> I think I get your point about categorisation in general, but in this
>> case, there is the risk of excluding a category of people (lurkers,
>> occasional contributors, etc.) or more precisely: to incidently and
>> inadvertently encourage them to self-exclude themselves.
>
> I hear what you’re saying, I’m just not sure how much of an issue this 
> actually
> would be. My initial suspicion is with a this issue would be small to
> non-existent.

Perhaps -- or perhaps not.  What Ihor says in another email is that
people who post on e.g. reddit don't want to bother hardcore devs on
this list.  I'm quite sure if we setup an official #org-dev channel,
people from #org-mode will shy away from #org-dev.

>> Is it possible to lurk in a Matrix room without any login?
>
> With a matrix client you can peek in public rooms without joining them, and
> <https://view.matrix.org/room/%21rUhEinythPhVTdddsb:matrix.org/> currently 
> exists.

This link does not allow me to send an anonymous/pseudonymous message
to the Matrix room, right?  That's what I'm talking about, that IRC
permits.

All best,

-- 
 Bastien



Re: Dynamic keybindings in the manual

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

> In the recent discussion about potentially no longer generating `org-release' 
> in
> the Makefile, it was mentioned that `orgcard.tex' may be a bit of a blocker to
> that.

If we are to make changes against orgcard.tex we should be careful to
stick to GNU conventions regarding creating refcards.

Also, maybe some improvements can be shared upstream against the Emacs
refcard?

-- 
 Bastien



Re: [PATCH] Add .org suffixes to CONTRIBUTE and README

2022-09-25 Thread Bastien
"Christopher M. Miles"  writes:

> I agree this change too. This is more clear.

Applied on main as 52be6f0f4, thanks.

-- 
 Bastien



Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

2022-09-25 Thread Bastien
Hi Christopher,

"Christopher M. Miles"  writes:

> Thanks, Bastien.

(I know you sent a patch and I'll review it, no worry!)

>> Would you consider taking over the maintainance of ob-clojure.el?
>
> Thanks for invitation, I already maintained many org-mode related
> libraries. Even though clojure is my favourite programming language, But
> I'm not familiar with CIDER and other Clojure tools interaction. So
> currently I'm not confident to maintain ob-clojure.el. But I think I
> might be able to do this in future someday. (If someone already
> maintained, I still can contribute)

Actually the invitation was for Daniel as I recalled you declined it
already (correct me if I'm wrong!).  Of course, we can have several
maintainers.

> BTW, I have a question, If someone maintain the ob-clojure.el, does this
> library need to be separated out org-mode repository?

No: we have many lisp/*el files with a specific maintainer.

These maintainers of Org's cor handle bug fixes against the files they
are maintaining and can be cc'ed on the list when discussing features.

The burden is general quite low, it's just a guarantee that someone is
in charge and can alleviate the workload of core maintainers.

All best,

-- 
 Bastien



Re: org-assert-version considered harmful

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> One valid option is 9.6-pre

Let's go for this one.  I've add a note about our conventions for the
;; Version header in https://orgmode.org/worg/org-maintenance.html

-- 
 Bastien



Re: org-assert-version considered harmful

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> Also, they are used by Makefile to generate orgcard.tex
> We need to be careful in this area.

Yes...

> Note that in
> Org mode version 9.6 (release_9.5.5-830-g77f9e1 @ [load-path])
>
> release_9.5.5 while version is 9.6
> I feel like you missed this detail.

Yes I did :)

Still, "Org mode version 9.6-pre (...)" is more accurate IMO.

-- 
 Bastien



Re: org-assert-version considered harmful

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> I think that it will still be useful. In particular, consider major new
> feature development. We may take a longer delay between releases then.

Yes.

> The code I quoted explicitly removes the "-dev" part. Would you prefer
> to keep it?

Yes, let's keep it, otherwise (org-release) reads like a lie.

Why is it necessary to emit org-version.el?

We could have (defun org-version ...) and (defun org-git-version ...)
from within org.el, right?

Also, I don't think we need org-release: the info org-version provides
is enough to know if you are loading Org from a stable (ELPA) release
or from a local git repository.

WDYT?

> See the attached.

Tested and works fine, modulo the -dev part that we should keep.

Thanks!

-- 
 Bastien



Re: IM dev discussions?

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> Familiarity is important. 

I agree with all what you said.

> Ideally, it would be nice to
> have ML front-end that looks similar to GitHub issues. I recall the
> latest versions of mailman had somewhat familiar look. Sourcehut is also
> trying to implement a web-based front-end (though is it not familiar at
> all, unfortunately).

Note that if the GNU project moves to using its instance of sourcehut,
then we will also benefit from such a web-based front-end.

> Note that the opposite to the above is not true. We should not prefer
> familiar front-ends at the cost of sacrificing technical accessibility.

Agreed again.

Another parameter I put in the equation: what do we want?

If our priority were to redirect reports made on r/org-mode and SO to
the Org maintainers, then switching to GitHub would probably be a good
move: users that feel comfortable sharing reports and ideas on these
platforms would create more issues on GitHub than emails we currently
receive on the list.

I believe our priority should be to motivate more Elisp hackers to
become Org maintainers.  I expect potential candidates to be okay with
the GNU recommendation of trying to avoid GitHub for ethical reasons
and to be fine with working by email, the old way.  Especially if we
have maintainers for small files: they certainly don't want to follow
everything in Org's development but agree to be cc'ed occasionally.

2 cts,

-- 
 Bastien



Re: IM dev discussions?

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

> Doing something similar for Org development is an interesting idea. Something
> similar probably could be set up with the Org room, or a dedicated Org-dev 
> room
> (I’m aware of Bastien’s thoughts on wanting development and help to not be
> separated, but while I like the idea of them living in the same space, I’m
> personally a big fan of categorisation. For instance, we could make an 
> org-mode
> space with a few different rooms: org-dev, org-help, org-showcase, org-chat,
> etc.).

I'm all for places where people can freely discuss anything related to
Org.  There are already many such places: #org-mode and #org-mode-fr
on IRC, r/org-mode on reddit.com, stackoverflow.com, etc.

I don't want development decisions to be taken in such places---that I
think we all agree upon.

Based on that, I don't want a separated IRC channel or a Matrix room
to be promoted (de facto, by its name) as the place for "contributing
to Org's development": #org-dev or a dedicated Matrix room would sound
like this to newcomers.  #orgmode is the IM complement of the mailing
list: a place where Orgers discuss.  On top of that, the ML is the
place where to suggest patches.

I think I get your point about categorisation in general, but in this
case, there is the risk of excluding a category of people (lurkers,
occasional contributors, etc.) or more precisely: to incidently and
inadvertently encourage them to self-exclude themselves.

> With regards to accessibility, I think Matrix is also reaching a rather good
> point. 

Is it possible to lurk in a Matrix room without any login?

The same way you can send an email to the mailing list without being a
subscriber (vs opening a GitHub issue without having a GitHub account)
you can lurk in #org-mode without having a registered account on the
IRC server, which is good.

> The current state of affairs includes an Emacs client, a host of
> dedicated apps, in-browser web clients, and more. While the ability to peruse
> archives has not yet been developed, it is also possible to copy a link to a
> particular message, and so a conversation can be transferred from Matrix to 
> the
> ML with a link to the initial conversation, e.g.
> <https://matrix.to/#/!rUhEinythPhVTdddsb:matrix.org/$1663983705132172ICPRd:matrix.org>

It's good to be able to connect to Matrix via Emacs: I will try this
myself soon.  

All best,

-- 
 Bastien



Re: IM dev discussions?

2022-09-25 Thread Bastien
Tim Cross  writes:

> FB is what their parents use and email is what their
> grandparents use!

So true, but quite painful to read on a mailing list ;)

-- 
 Bastien



Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> So, we may create a badge with an icon representing src code (maybe
> " | source code"?) that will point to
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

+1

-- 
 Bastien



Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

>> IMHO if someone with UX/UI experience can/wants to interview real Org
>> newcomers, that will help us a lot for deciding about such tiny changes.
>
> Unfortunately, it can be quite hard to find such people on the ML etc. (funny
> about that ).

I'm copying Eduardo who volunteered in the past for this kind of work.

> For what it’s worth, when doing the original website re-design I went to some
> effort to get the thoughts of people who don’t use Org to make sure it did a
> decent job communicating the essentials.

Definitely an ingredient of why your work improved the situation a lot!

> With regards to the current banner, I’m inclined to remove the report bug 
> text:
> having that as well as the badge-link is simply confusing, and the badge-link 
> to
> the feedback page is better.

> We can also add a source code badge using the git icon and linking to
> <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/>, and I’d then be 
> inclined
> to remove the “Repository …” text for similar reasons.

I'd definitely love to get more feedback on this: I don't think the
current banner is *that* cluttered, and the info about the repo and
the way to send bug reports seems really useful - but perhaps that's
just me.

Please go ahead with what seems better to you (especially since it
matches Ihor's preferences too), but if Eduardo has some time to help,
it be great to really stabilize what kind of info is expected on this
banner.

Thanks!

-- 
 Bastien



Re: org-assert-version considered harmful

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> org-git-version is very useful when people report bugs.
> M-x org-submit-bug-report supplies org-git-version output for bug
> subject. Thus, we can easily check which git commit their build
> corresponds to.

Let's keep `org-git-version'.  If we manage to release Org more often
(minor and major versions), I doubt keep `org-git-version' will remain
that useful in practise, though.  Let's revisit the topic then.

> I am not very familiar with all the code paths our Makefile and
> autoloads take from setting ORG-VERSION to generating the appropriate
> Elisp constants.
>
> However, I do note that mk/targets.mk contains the following:
>
> ifneq ($(wildcard .git),)
>   ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* 
> --abbrev=0 HEAD))
>   ifeq ($(ORGVERSION),)
> # In elpa.git, there are no tags available.  Fall back to using
> # the org.el header.
> ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
>   --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
>   else
> GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
>   endif
>   GITSTATUS  ?= $(shell git status -uno --porcelain)
> else
>  -include mk/version.mk
>   GITVERSION ?= N/A
>   ORGVERSION ?= N/A
> endif
>
> Note that we already have a way to parse Org version from lisp/org.el,
> similar to what the commit you referenced does.
> It is just that this code path is not used by default.

I'd favor using it by default.

When using Org from the main branch of the git repository,
M-x org-version RET should return this:

"Org mode version 9.6-dev (release_9.5.5-822-g0a6a56 @ [load-path])"

> We can remove the current default and simply use
>
> ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
>   --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
>
> all the time.
>
> I do not know if more involved fix is required (because I am not
> familiar enough with the relevant code).

Can you provide a patch for the above suggestions?  I'll test and see
if more fixes are needed, even though I'm also not that familiar with
the code either.

-- 
 Bastien



[PATCH] Add .org suffixes to CONTRIBUTE and README

2022-09-25 Thread Bastien
I'm considering apply the patch below, renaming CONTRIBUTE to
CONTRIBUTE.org and README to README.org.

The main benefit is to enhance the rendering of the README on 
GNU ELPA.

I also do some minor reformatting and remove the warning about
org-contrib.

Any objection?

diff --git a/CONTRIBUTE b/CONTRIBUTE.org
similarity index 89%
rename from CONTRIBUTE
rename to CONTRIBUTE.org
index f8a81515e..fbd1616f5 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE.org
@@ -1,5 +1,3 @@
--*- mode: org; fill-column:70 -*-
-
 The text below explains the rules for participating in Org mode
 development.
 
@@ -66,9 +64,3 @@ Org maintenance is detailed on Worg: see [[https://orgmode.org/worg/org-maintena
  them and ask everyone to keep this in mind when posting changes.
 
 See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively.
-
-* The =contrib/= directory
-
-The git repository used to contain a =contrib/= directory.  Files in
-this directory were moved to a new [[https://git.sr.ht/~bzg/org-contrib][org-contrib]] repository before Org
-9.5.  You can install the new =org-contrib= from [[https://elpa.nongnu.org/nongnu/][NonGNU ELPA]].
diff --git a/README b/README.org
similarity index 50%
rename from README
rename to README.org
index bb0a0c582..bf9301169 100644
--- a/README
+++ b/README.org
@@ -1,32 +1,16 @@
--*- mode: org; fill-column:70 -*-
+This is a distribution of Org Mode, a major mode for keeping notes,
+authoring documents, computational notebooks, literate programming,
+maintaining to-do lists, planning projects, and more — in a fast and
+effective plain text system.
 
-This is a distribution of Org, a plain text notes and project planning
-tool for Emacs.
+Check the [[https://orgmode.org][Org Mode website]] for more.
 
-Check the Org Mode website at https://orgmode.org and the installation
-instructions at https://orgmode.org/org.html#Installation.
+* Install Org
 
-* Contents of this distribution
+Org is part of GNU Emacs: you probably don't need to install it.
 
-- README :: This file.
-
-- COPYING :: The GNU General Public License.
-
-- Makefile :: The makefile to compile and install Org.  See the
-  installation instructions https://orgmode.org/org.html#Installation
-  or this more detailed procedure on Worg:
-  https://orgmode.org/worg/dev/org-build-system.html.
-  
-- mk/ :: Files needed for building Org.
-
-- lisp/ :: Directory with all the Emacs Lisp files that make up Org.
-
-- doc/ :: The documentation files.  org.texi is the source of the
-  documentation, org.html and org.pdf are formatted versions of it.
-
-- etc/ :: Files needed for the ODT exporter.
-
-- testing/ :: Testing suite for Org.
+To install a more recent version, please do it from [[https://elpa.gnu.org/packages/org.html][GNU ELPA]] by
+running this command: =M-x package-install RET org RET=
 
 * Join the GNU Project
 
@@ -36,19 +20,18 @@ System, developed by the GNU Project.
 If you are the author of an awesome program and want to join us in
 writing Free (libre) Software, please consider making it an official
 GNU program and become a GNU Maintainer.  Instructions on how to do
-this are here http://www.gnu.org/help/evaluation
+this are here http://www.gnu.org/help/evaluation.
 
 Don't have a program to contribute?  Look at all the other ways to
-help: https://www.gnu.org/help/help.html
+help: https://www.gnu.org/help/help.html.
 
 And to learn more about Free (libre) Software in general, please read
 and share this page: https://gnu.org/philosophy/free-sw.html
 
 * License
 
-Org-mode is published under the GNU GPLv3 license or any later
-version, the same as GNU Emacs:
-https://www.gnu.org/licenses/gpl-3.0.html
+Org-mode is published under the [[https://www.gnu.org/licenses/gpl-3.0.html][GNU GPLv3 license]] or any later
+version, the same as GNU Emacs.
 
 Org-mode is free software: you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the

-- 
 Bastien


Re: org-assert-version considered harmful

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> Currently, main and bugfix branches both have (org-version) ; => "9.5.5"
> As a result, the assertion will not catch the important case when users
> mix Org version installed via package.el and Org version installed from
> git.
>
> Should we use the next planned release version number on main branch as
> a convention?

I'd rather use the value set in the ";; Version:" header.

It is "9.5.5" in the bugfix branch and "9.6-dev" on the main branch.

I'm not even sure we should keep `org-git-version' at all: if we need
to distinguish between pre-release states, it seems easy enough to set
the header as 9.6rc1, 9.6rc2, etc.

WDYT?

PS: I have a vague memory that Stefan suggested to look at how things
are done on bbdb.el:

https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/lisp/bbdb.el?h=externals/bbdb#n4750

If we can remove the complex Make machinery we have right now, I'd be
very happy.  One reason for this machinery was to avoid merge conflict
(thanks to getting rid of the Version: header), but we do have these
conflicts (now that the header is back) and they are easy to solve.

-- 
 Bastien



Re: Org Syntax Specification

2022-09-25 Thread Bastien
Hi Timothy,

I'm late to the party, but *thanks* for these important improvements
on the https://orgmode.org/worg/dev/org-syntax.html page!

A few suggestions:

- Make it a description of the syntax of the latest stable Org.  (For
  now let's consider 9.6 to be the latest stable as we are working on
  releasing it soon.)  Perhaps this is already the case and I missed
  it?

- Remove the "draft" status ("DRAFT v2β"). Don't describe it as a
  draft in the org-manual.org if it accurately reflects the current
  syntax (current = latest stable).

- Remove all the inline notes (some suggest changes in Org's grammar,
  that might scare the readers a bit.)

- Promote the page to orgmode.org/worg/org-syntax.html: the /dev/ path
  in the current URL makes it read like it is the syntax for the "dev"
  version.

What do you think?

-- 
 Bastien



Re: Numbered footnotes in the manual interfere with diff

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> Do you have any suggestion on how to deal with changing footnotes in the
> manual? When I delete this footnote, all the footnotes must be
> re-numbered creating a lot of garbage in the diff. Is it ok? Or should
> we prefer inline footnote definitions in the manual to avoid such
> situations?

I propose to use inline footnotes for notes of one paragraph and to
use regular footnotes for notes spanning over more than one paragraph.
This will enhance both diffs readability and that of the manual's .org
source.

WDYT?

-- 
 Bastien



Re: [BUG] Nitpick: https://liberapay.com/org-mode/ says "Org-mode" while our convention is to use "Org mode" [9.5.5 (release_9.5.5-827-g3b0c4a @ /home/yantar92/.emacs.d/straight/build/org/)]

2022-09-25 Thread Bastien
Ihor Radchenko  writes:

> s/Org-mode/Org mode

Done, thanks!

-- 
 Bastien



Re: [ANN] An Org parser for Julia

2022-09-25 Thread Bastien
Hi Timothy,

Timothy  writes:

> https://github.com/tecosaur/OrgMode.jl

Great!  I advertized this new parser on Worg:
https://orgmode.org/worg/org-tools/index.html

Thanks!

-- 
 Bastien



Re: [Translation] Add Persian/Farsi to org-export

2022-09-25 Thread Bastien
Hi Sajad,

Sorry it took long to review and apply this.

Sajad Hosseini Balef  writes:

> lisp/ox.el: Add Persian/Farsi to org-export

Applied on the main branch as 36c27f11d.

I also added your name to https://orgmode.org/worg/contributors.html.

If you want to submit other patches, please fill the FSF copyright
assignment: https://orgmode.org/request-assign-future.txt

Thanks!

-- 
 Bastien



Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

2022-09-24 Thread Bastien
Hi Daniel,

Daniel Kraus  writes:

> Attached is the patch changed the logic to use a temp file with
> org-babel-eval.

Applied in main as 764642f5, thanks a lot and sorry for the delay.

I also added you to https://orgmode.org/worg/contributors.html.

Would you consider taking over the maintainance of ob-clojure.el?

-- 
 Bastien



Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

2022-09-24 Thread Bastien
Ihor Radchenko  writes:

> For reference, I am seeing this feature as a step towards better
> modularity of org-list.el.

Modularity is good if we have use-cases for it, at least one feature
relying on it.  I wouldn't implement a feature just to add modularity.

> The current list code is rather monolithic
> and leaves no room for user customization of the commands. (Also, see
> recent discussions about converting between lists and headings
> https://list.orgmode.org/orgmode/877d4luxb8.fsf@localhost/
> https://orgmode.org/list/877d3k70lu.fsf@localhost)

I'm not convinced the first report is a bug in the way list are
handled.  The second is a bug in the way headings are transformed as
list items (leaving footnotes in a poor state).  If more modularity
helps fixing these edge cases, then why not.

> Even if we do not provide "canceled" items in lists, having an
> infrastructure to customize list commands better will be a good thing to
> have.

Of course, I guess you can think of useful customization of list
commands -- perhaps that what we should think about first: would it be
a good thing to allow customization of list commands? what use-case?

2 cts,

-- 
 Bastien



Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

2022-09-24 Thread Bastien Guerry
Ihor Radchenko  writes:

> I am leaning towards removing `this-command' check, unless there are
> important reasons to keep it.

Yes, please go ahead.

-- 
 Bastien



  1   2   3   4   5   6   7   8   9   10   >