org-ctags land grab

org-ctags land grab

[Nick Dokos]

`org-ctags' unilaterally sets the hook `org-open-link-functions' to a
bunch of org-ctags functions and enables itself by default. That has
the unfortunate consequence of invalidating the documentation for
internal CUSTOM_ID links - see

https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode

It is also confusing. To quote the unfortunate victim:

  Now, when I click on the link, or C-c C-o, I get a dialog to "visit
  tags table"... ???

I proposed a work-around, but it seems to me that `org-ctags'
functionality should be opt-in and there should be a way to turn it
off. In addition, it needs a better way to interpolate itself into the
link ecosystem: breaking internal link functionality is rather
obnoxious IMO.

WDYT?

-- 
Nick

Re: org-ctags land grab

[Rudolf Adamkovič]

Nick Dokos <ndokos@gmail.com> writes:

> It is also confusing. To quote the unfortunate victim:
>
>   Now, when I click on the link, or C-c C-o, I get a dialog to "visit
>   tags table"... ???

I have had this happen to me many times too, so +1.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: org-ctags land grab

[Ihor Radchenko]

Nick Dokos <ndokos@gmail.com> writes:

> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a
> bunch of org-ctags functions and enables itself by default. That has
> the unfortunate consequence of invalidating the documentation for
> internal CUSTOM_ID links - see
>
> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode

As documented in the top comment of org-ctags.el, the default behaviour
of C-c C-o is modified as you observe:

    ;; By default, with org-ctags loaded, org will first try and visit the tag
    ;; with the same name as the link; then, if unsuccessful, ask the user if
    ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
    ;; the user wishes to append 'tag' as a new toplevel heading at the end of
    ;; the buffer; and finally, defer to org's default behavior which is to
    ;; search the entire text of the current buffer for 'tag'.

> I proposed a work-around, but it seems to me that `org-ctags'
> functionality should be opt-in and there should be a way to turn it
> off.

It is off by default.

> In addition, it needs a better way to interpolate itself into the
> link ecosystem: breaking internal link functionality is rather
> obnoxious IMO.

It is not breaking the functionality. If you go through the afferent
dialogues, saying "no", it will finally fall back to default Org link
behaviour.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org-ctags land grab

[Nick Dokos]

Ihor Radchenko <yantar92@posteo.net> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a
>> bunch of org-ctags functions and enables itself by default. That has
>> the unfortunate consequence of invalidating the documentation for
>> internal CUSTOM_ID links - see
>>
>> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode
>
> As documented in the top comment of org-ctags.el, the default behaviour
> of C-c C-o is modified as you observe:
>
>     ;; By default, with org-ctags loaded, org will first try and visit the tag
>     ;; with the same name as the link; then, if unsuccessful, ask the user if
>     ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
>     ;; the user wishes to append 'tag' as a new toplevel heading at the end of
>     ;; the buffer; and finally, defer to org's default behavior which is to
>     ;; search the entire text of the current buffer for 'tag'.
>
>> I proposed a work-around, but it seems to me that `org-ctags'
>> functionality should be opt-in and there should be a way to turn it
>> off.
>
> It is off by default.

It is off until org-ctags is loaded. *When* it is loaded, it runs
`(org-ctags-enable)' and the behavior changes.

Now I'm not loading it explicitly, but nevertheless, *somebody* does
because it goes ahead and mucks with my `org-open-link-functions'.
One clue was that it does not happen in 28.2 (which is the version
in Fedora 36 and 37) but it *does* happen in a 30.0.50 Emacs built
from upstream sources.

So I ran some tests, all with -Q so my init file is out of the
picture.

It turns out that it is enough to ask for help on an Org variable to
have `org-ctags' loaded!  I put a watch on `org-open-link-functions'
and did `C-h v org-latex-pdf-process': it stopped once on setting it to
nil and it stopped again with this backtrace (I elided long lines but I left
the relevant portion of the one that mentions `org-ctags'):



--8<---------------cut here---------------start------------->8---
Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): 
  debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) set nil)
  set-default(org-open-link-functions (org-ctags-find-tag))
  add-hook(org-open-link-functions org-ctags-find-tag t)
  org-ctags-enable()
  byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2)
  load("org-ctags" noerror nomessage)
  help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" "org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" "org-keys" "org-habit" "org-faces" "org-ctags" ...
  help--symbol-completion-table("org-latex-pdf-process" ...
  test-completion("org-latex-pdf-process" help--symbol-completion-table ...
  completion--complete-and-exit(20 41 exit-minibuffer ...
  completion-complete-and-exit(20 41 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Describe variable: " nil ...
  completing-read-default("Describe variable: " help--symbol-completion-table ...
  completing-read("Describe variable: " help--symbol-completion-table ...
  byte-code(...
  call-interactively(describe-variable nil nil)
  command-execute(describe-variable)
--8<---------------cut here---------------end--------------->8---

As you see, `help--load-prefixes' loads `org-ctags'. If you look at
the `help-definition-prefixes' radix tree, `org-ctags' is subsumed
under the `org-' prefix, so any lookup with that prefix will end up
loading it (and therefore enabling it). The reason it does not happen
in 28.2 is that it is only under the `org-ctags` prefix.

It seems to me that `org-ctags' should be registered under the
`org-ctags' prefix only, just like in 28.2 (the registration is in
`org-loaddefs.el' but I don't know how it ends up there. I guess
`org-fixup.el' is doing it, but I didn't chase it any further).

I also think that loading `org-ctags' should not automatically enable
it: it should require the user to explicitly run `org-ctags-enable' to
do that. That way, if there is a mechanism that loads it
surreptitiously, it wouldn't cause the confusion that it causes
now. That would require documentation changes, but it would avoid
unpleasant surprises, and preserve some toes even if users load it
accidentally. Eventually, it might be nice to provide a disabling
function as well, although the workaround in the SE post works well
enough for now. Maybe the thing to do is to turn it into a proper
minor mode.

Thoughts?

-- 
Nick

Re: org-ctags land grab

[Ihor Radchenko]

Nick Dokos <ndokos@gmail.com> writes:

>> It is off by default.
>
> It is off until org-ctags is loaded. *When* it is loaded, it runs
> `(org-ctags-enable)' and the behavior changes.

Sure. This is not by itself a big deal. A number of Elisp libraries,
including built-in Emacs libraries are loaded with side effects.

> Now I'm not loading it explicitly, but nevertheless, *somebody* does
> because it goes ahead and mucks with my `org-open-link-functions'.

If somebody is loading org-ctags explicitly, it is their choice to use
this library. Instructions how to modify its behaviour are in the top
comment, including instructions how to deal with modified link opening.

> Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): 
>   debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) set nil)
>   set-default(org-open-link-functions (org-ctags-find-tag))
>   add-hook(org-open-link-functions org-ctags-find-tag t)
>   org-ctags-enable()
>   byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2)
>   load("org-ctags" noerror nomessage)
>   help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" "org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" "org-keys" "org-habit" "org-faces" "org-ctags" ...
> ...
> As you see, `help--load-prefixes' loads `org-ctags'. If you look at
> the `help-definition-prefixes' radix tree, `org-ctags' is subsumed
> under the `org-' prefix, so any lookup with that prefix will end up
> loading it (and therefore enabling it). The reason it does not happen
> in 28.2 is that it is only under the `org-ctags` prefix.

This sounds like Emacs bug.
Note that you can disable this behaviour by setting
`help-enable-completion-autoload' and/or `help-enable-autoload'.

> It seems to me that `org-ctags' should be registered under the
> `org-ctags' prefix only, just like in 28.2 (the registration is in
> `org-loaddefs.el' but I don't know how it ends up there. I guess
> `org-fixup.el' is doing it, but I didn't chase it any further).

We did nothing to change how autoloads are being generated. However,
newer Emacs uses a different autoloading system.

> I also think that loading `org-ctags' should not automatically enable
> it: it should require the user to explicitly run `org-ctags-enable' to
> do that. That way, if there is a mechanism that loads it
> surreptitiously, it wouldn't cause the confusion that it causes
> now. That would require documentation changes, but it would avoid
> unpleasant surprises, and preserve some toes even if users load it
> accidentally. Eventually, it might be nice to provide a disabling
> function as well, although the workaround in the SE post works well
> enough for now. Maybe the thing to do is to turn it into a proper
> minor mode.

Yes and no. It will indeed avoid this unpleasant surprise, but it will
create an unpleasant surprise for users who do use org-ctags, which is
the problem.

Note that we discussed loading side effects in
https://list.orgmode.org/orgmode/tn4ql0$bu2$1@ciao.gmane.io/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org-ctags land grab

[Max Nikulin]

On 23/03/2023 17:49, Ihor Radchenko wrote:
> Nick Dokos writes:
> 
>> It is off until org-ctags is loaded. *When* it is loaded, it runs
>> `(org-ctags-enable)' and the behavior changes.
> 
> Sure. This is not by itself a big deal. A number of Elisp libraries,
> including built-in Emacs libraries are loaded with side effects.

It is still violation of conventions:

(info "(elisp) Coding Conventions")
https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
> D.1 Emacs Lisp Coding Conventions
> 
> Simply loading a package should not change Emacs’s editing behavior.
> Include a command or commands to enable and disable the feature, or to
> invoke it.
> 
> This convention is mandatory for any file that includes custom
> definitions. If fixing such a file to follow this convention requires an
> incompatible change, go ahead and make the incompatible change; don’t
> postpone it.

Notice *incompatible*.

On 23/03/2023 17:49, Ihor Radchenko wrote:
> Nick Dokos writes:
>> As you see, `help--load-prefixes' loads `org-ctags'.
...
> This sounds like Emacs bug.

I would say that it sounds like a fix for
https://debbugs.gnu.org/60085
`help-enable-autoload' is not fully obeyed

See also:

Max Nikulin to emacs-orgmode… Re: Does variable 'org-goto-interface' 
exist? Wed, 14 Dec 2022 21:20:07 +0700. 
https://lists.orgmode.org/6dd5a4fe-b99b-73a9-26dd-bb522ff1b892@gmail.com

> Note that we discussed loading side effects in
> https://list.orgmode.org/orgmode/tn4ql0$bu2$1@ciao.gmane.io/

I have not responded to that thread. My opinion is that besides 
functions that just loads files and packages there should be 
counterparts that loads and activates libraries. A proof of concept may 
be implemented for Org and in the case of success it may be proposed for 
inclusion into Emacs core.

[POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>> including built-in Emacs libraries are loaded with side effects.
>
> It is still violation of conventions:
>
> (info "(elisp) Coding Conventions")
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>> D.1 Emacs Lisp Coding Conventions
>> 
>> Simply loading a package should not change Emacs’s editing behavior.
>> Include a command or commands to enable and disable the feature, or to
>> invoke it.
>> 
>> This convention is mandatory for any file that includes custom
>> definitions. If fixing such a file to follow this convention requires an
>> incompatible change, go ahead and make the incompatible change; don’t
>> postpone it.

This is convincing.
I am then CCing Bastien, as, despite the Elisp convention, following it
will break https://bzg.fr/en/the-software-maintainers-pledge/

>> Note that we discussed loading side effects in
>> https://list.orgmode.org/orgmode/tn4ql0$bu2$1@ciao.gmane.io/
>
> I have not responded to that thread. My opinion is that besides 
> functions that just loads files and packages there should be 
> counterparts that loads and activates libraries. A proof of concept may 
> be implemented for Org and in the case of success it may be proposed for 
> inclusion into Emacs core.

Maybe. We can do something similar to `unload-feature'. However, it will
still require users to adapt.

Tentative implementation:

(defun enable-feature (feature &optional filename noerror)
  "Load and enable FEATURE.
FILENAME and NOERROR arguments are the same as in `require'."
  (when (require feature filename noerror)
    (let ((enabler-cmd (intern (format "%s-enable-function" feature))))
      (and (fboundp enabler-cmd) (funcall enabler-cmd)))))

(defun disable-feature (feature)
  "Disable FEATURE."
  (let ((disabler-cmd (intern (format "%s-disable-function" feature))))
    (and (fboundp disabler-cmd) (funcall disabler-cmd))))

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 26/03/2023 00:45, Ihor Radchenko wrote:
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

I hope, it may be mitigated to some degree, e.g. loading of 
`org-modules' and `org-babel-load-languages' may include their 
activation. Perhaps `org-require-package' should activate the loaded 
package as well.

If it is possible to avoid user prompt in org-ctags then migration may 
be done in 2 steps separated by a year: add new require helper and do 
not activate by default. Unsure if it is possible to add some warnings 
on first step that activate function is not called.

> (defun enable-feature (feature &optional filename noerror)
>    "Load and enable FEATURE.
> FILENAME and NOERROR arguments are the same as in `require'."
>    (when (require feature filename noerror)
>      (let ((enabler-cmd (intern (format "%s-enable-function" feature))))
>        (and (fboundp enabler-cmd) (funcall enabler-cmd)))))

I would prefer activating on first call only, subsequent calls should be 
no op.

> (defun disable-feature (feature)

I had a hope that existing `unload-feature' is enough.

My idea was something like `org-require' that is (require feature) and 
(feature-activate) or (feature-activate-function) *once*.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 26/03/2023 00:45, Ihor Radchenko wrote:
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> I hope, it may be mitigated to some degree, e.g. loading of 
> `org-modules' and `org-babel-load-languages' may include their 
> activation. Perhaps `org-require-package' should activate the loaded 
> package as well.

We often promise in the manual that simple `require' is sufficient.
Not everybody is using `org-modules' mechanism.

Also, `org-require-package' is unrelated. It is specifically designed to
handle third-party packages where we have no control about side effects.

> If it is possible to avoid user prompt in org-ctags then migration may 
> be done in 2 steps separated by a year: add new require helper and do 
> not activate by default. Unsure if it is possible to add some warnings 
> on first step that activate function is not called.

There is no point discussing how to introduce the breaking change.
Making the transition longer will not make it non-breaking.
We first need to decide if we want to go ahead at all.

>> (defun enable-feature (feature &optional filename noerror)
>>    "Load and enable FEATURE.
>> FILENAME and NOERROR arguments are the same as in `require'."
>>    (when (require feature filename noerror)
>>      (let ((enabler-cmd (intern (format "%s-enable-function" feature))))
>>        (and (fboundp enabler-cmd) (funcall enabler-cmd)))))
>
> I would prefer activating on first call only, subsequent calls should be 
> no op.

Sure. I just wanted to point out that it is an easy part to implement
such functionality.

>> (defun disable-feature (feature)
>
> I had a hope that existing `unload-feature' is enough.

`unload-feature' serves different purpose, no?
I am not sure if mixing the two will be welcome by Emacs devs, if we
really want to pursue inclusion this into Emacs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]


Ihor Radchenko <yantar92@posteo.net> writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

Isn’t the problem that the behavior changed — so that org-ctags gets
loaded in Emacs 30 but not in Emacs 28 is already an incompatible
change?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

>> This is convincing.
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> Isn’t the problem that the behavior changed — so that org-ctags gets
> loaded in Emacs 30 but not in Emacs 28 is already an incompatible
> change?

It is a secondary problem.
In earlier Emacs you would get the same side effects if, for example,
you try C-h f org-ctags- <TAB>.
`help-enable-autoload' is there since Emacs 24.

The root cause of this and similar reported issues (like with org-mouse,
see https://orgmode.org/list/87iliie0j1.fsf@localhost) is optional Org
modules having side effects when loaded.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
convention first.  When the breaking change is a side-effect of fixing
a bug, it is unavoidable.

-- 
 Bastien

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> This is convincing.
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
> convention first.  When the breaking change is a side-effect of fixing
> a bug, it is unavoidable.

The situation is a bit more complex.
Strictly speaking, loading Elisp library _always_ has side effects of
defining new functions. And, for example, Org babel's behavior is
modified when ob-foo.el is loaded because `fboundp' on
'org-babel-execute:foo returns non-nil.

A bit different approach is used for ol-foo.el, where more significant
side effect is triggered by top-level calls to
`org-link-set-parameters'. Similarly, ox-foo.el uses
`org-export-define-derived-backend' or `org-export-define-backend'.

Finally, we have org-mouse.el discussed here, which modifies key
bindings and org-inlinetask.el, which modifies how Org treats headlines
in Org files, modifying syntax.

With the current state of affairs, it is often enough to
(require 'org-library) to get things work. If we get rid of all the
possible side effects, users will have to adapt their configurations
and we will thus violate "I won't force you to update your
configuration."

Of course, we can change babel implementation to use explicit registry
like for export backends and force users to call explicit activation
commands in addition to (require 'library). But I am not sure if we are
not crossing the line with such an approach: "I won't use software
correctness as an excuse.".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Thanks a lot for the detailed clarification.

The Elisp coding convention explicitely targets Emacs "editing
behavior".  The definition of a new function is not a side-effect 
that affects Emacs editing behavior, so Babel and export libs are
OK.

Ihor Radchenko <yantar92@posteo.net> writes:

> Finally, we have org-mouse.el discussed here, which modifies key
> bindings and org-inlinetask.el, which modifies how Org treats headlines
> in Org files, modifying syntax.

org-mouse.el should not modify default Org _editing_ key bindings.
Is it really the case?  If so, can we fix this?

Does org-inlinetask.el modifies the way non-inline headlines are
edited?  If so, can we fix this?  IIRC org-inlinetask.el only adds
editing function for inline tasks, it is an extension, not a
modification of the default Org editing behavior, but the limit
can be thin here.

> With the current state of affairs, it is often enough to
> (require 'org-library) to get things work. If we get rid of all the
> possible side effects, users will have to adapt their configurations
> and we will thus violate "I won't force you to update your
> configuration."
>
> Of course, we can change babel implementation to use explicit registry
> like for export backends and force users to call explicit activation
> commands in addition to (require 'library). But I am not sure if we are
> not crossing the line with such an approach: "I won't use software
> correctness as an excuse.".

Defining new functions is a desirable "side-effect" of all Elisp
library, I don't think we should worry abou this.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 08/08/2023 20:29, Bastien Guerry wrote:
> The definition of a new function is not a side-effect
> that affects Emacs editing behavior, so Babel and export libs are
> OK.

Function definition is not side effect when load library is requested. 
However it is a side effect of hitting TAB in Emacs help prompt. 
Completion of a variable or a function should not modify Org behavior. 
Loading of a file is not explicitly requested by the user in this case.

I would disregard however function definitions, however changes in key 
bindings and recognized plain text links may be surprising to users who 
just tries to read help.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Nick Dokos]

Max Nikulin <manikulin@gmail.com> writes:

> On 08/08/2023 20:29, Bastien Guerry wrote:
>> The definition of a new function is not a side-effect
>> that affects Emacs editing behavior, so Babel and export libs are
>> OK.
>
> Function definition is not side effect when load library is
> requested. However it is a side effect of hitting TAB in Emacs help
> prompt. Completion of a variable or a function should not modify Org
> behavior. Loading of a file is not explicitly requested by the user in
> this case.
>
> I would disregard however function definitions, however changes in key
> bindings and recognized plain text links may be surprising to users
> who just tries to read help.
>
>

A big +1 from me: that's exactly what I was trying to say a few months
ago wrt org-ctags, although I said it badly. Defining functions that
are not used is not much of a problem IMO, but changing behavior behind
the user's back is most definitely a problem. IOW, it's not about
side-effects in general, it's about *specific kinds* of side-effects:
ones that are immediately visible (and confusing) to the user - things
behaving differently from a minute ago even though the only thing the
user did in-between is something as innocuous as asking for help.

One small step forward is to require libraries to have explicit
enable/disable functions[fn:1].  Even if I somehow enable a library by
mistake or misadventure, I should be able to disable it (at least in
the sense described above) without having to restart. Not every
library will need that and it's not even close to a complete solution,
but there is at least the possibility of building something better
(though more complicated) on top of it. If the library could be
organized as a minor mode, it most definitely should be so organized:
enabling/disabling would then be an automatic "requirement satisfied".

I would also recommend that the library *not* call its enable function
in general and leave it to the user to do so explicitly, but that may
be more controversial for "backward compatibility" reasons (with which
I disagree in these particular cases: I view them as bugs that need to
be fixed). And the library should document what changes it unleashes
on the environment (again in the restricted sense discussed above):
changes to "foreign" keymaps/menus/syntax tables/hooks probably
qualify for this kind of documentation, function definitions and
internal-to-the-library changes do not, plus there is probably a swath
of stuff in-between with more ambiguous requirements - all I can say
is start with the obvious things and add as necessary.

[fn:1] E.g. `org-ctags' has `org-ctags-enable' but no `org-ctags-disable', so
my "solution" is to do something like this in my init file:

    ;;; undo org-ctags obnoxiousness
    (with-eval-after-load 'org-ctags (setq org-open-link-functions nil))

It doesn't undo everything but it gets the obnoxious bits out of my
way (at least until *I* decide to call `org-ctags-enable').

My 2-cents/pence/centimes...
-- 
Nick

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Nick Dokos <ndokos@gmail.com> writes:

> I would also recommend that the library *not* call its enable function
> in general and leave it to the user to do so explicitly, but that may
> be more controversial for "backward compatibility" reasons (with which
> I disagree in these particular cases: I view them as bugs that need to
> be fixed).

I think that we all agree on this point.
The main question is where to draw a line between intrusive and
non-intrusive side effects.

For example, before loading ob-emacs-lisp

#+begin_src elisp
 (+ 1 1)
#+end_src

will not be syntax-highlighted, while after loading it will.
Is it intrusive? Somewhat. But maybe not bad enough to justify enable
function.

Similarly, loading ob-lilypond will alter how file containing lilypond
fragments is tangled.

Or loading ox-foo.el may alter export menu.

We have plenty of examples with varying degrees of side effects in Org.
And it is not fully clear to me which side effects are worth eliminating
and which are not.

Yet another option could be forcing certain side effects even without
loading. For example,
  (add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
that sets up tangling of lilypond fragments can be changed to

;;;#autoload
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))

That way, we will consistently get the same tangle configuration even
before ob-lilypond is loaded.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> Finally, we have org-mouse.el discussed here, which modifies key
>> bindings and org-inlinetask.el, which modifies how Org treats headlines
>> in Org files, modifying syntax.
>
> org-mouse.el should not modify default Org _editing_ key bindings.
> Is it really the case?  If so, can we fix this?

Yes, org-mouse modifies the behavior of certain key bindings. Not
directly, but by advising `org-open-at-point'.
Also, org-mouse adds new key bindings, potentially overriding custom
user bindings for mouse keys.

> Does org-inlinetask.el modifies the way non-inline headlines are
> edited?
> ... If so, can we fix this?  IIRC org-inlinetask.el only adds
> editing function for inline tasks, it is an extension, not a
> modification of the default Org editing behavior, but the limit
> can be thin here.

It changes the very notion of that is a headline - the syntax definition
is altered. Very deeply nested headlines may become inlinetasks upon
loading org-inlinetask, touching all aspects of Org, not just editing.

And it is not clear how to fix this. We did not make inlinetasks into
standard Org syntax in the past and now it is in the weird state when we
have (featurep 'org-inlinetask) sprinkled across the code just to
accommodate for this conditional syntax.

Inlinetasks are too similar in syntax with headlines, so it is
impossible to make the change backwards-compatible.

>> With the current state of affairs, it is often enough to
>> (require 'org-library) to get things work. If we get rid of all the
>> possible side effects, users will have to adapt their configurations
>> and we will thus violate "I won't force you to update your
>> configuration."
>
> Defining new functions is a desirable "side-effect" of all Elisp
> library, I don't think we should worry abou this.

Defining new functions by itself is not a big deal. But there are parts
of Org that alter their behavior depending on whether a feature is
loaded (like org-inlinetask) or depending whether certain function
symbol is defined (babel). Similarly, loading new link types re-defines
Org syntax in all the documents, affecting editing of everything that
looks like the loaded link type (org-ctags).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> Yes, org-mouse modifies the behavior of certain key bindings. Not
> directly, but by advising `org-open-at-point'.

IIRC Emacs core libraries should not advise functions.
This is something we should fix.

Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

> It changes the very notion of that is a headline - the syntax definition
> is altered. Very deeply nested headlines may become inlinetasks upon
> loading org-inlinetask, touching all aspects of Org, not just editing.

Same here, I'd be tempted to deny Org citizenship to inline tasks: it
always felt like a nice hack for a niche use-case, but a hack anyway.

If it modifies Org syntax in surprising ways, this is another argument
for removing org-inlinetask.el from Org's core.  Remember: this is not
to say that inline tasks are forbidden, it's just a message for users
that inline tasks are something not maintained by Org's core team.

> And it is not clear how to fix this. We did not make inlinetasks into
> standard Org syntax in the past and now it is in the weird state when we
> have (featurep 'org-inlinetask) sprinkled across the code just to
> accommodate for this conditional syntax.

Yes, this is ugly.

> Inlinetasks are too similar in syntax with headlines, so it is
> impossible to make the change backwards-compatible.
>
>>> With the current state of affairs, it is often enough to
>>> (require 'org-library) to get things work. If we get rid of all the
>>> possible side effects, users will have to adapt their configurations
>>> and we will thus violate "I won't force you to update your
>>> configuration."
>>
>> Defining new functions is a desirable "side-effect" of all Elisp
>> library, I don't think we should worry abou this.
>
> Defining new functions by itself is not a big deal. But there are parts
> of Org that alter their behavior depending on whether a feature is
> loaded (like org-inlinetask) or depending whether certain function
> symbol is defined (babel). Similarly, loading new link types re-defines
> Org syntax in all the documents, affecting editing of everything that
> looks like the loaded link type (org-ctags).

I feel like the stakes are not the same for features like org-mouse.el
and org-inlinetask.el and for core features like Babel libs and links.
For the former, a decision should be made relatively to the usefulness
of the feature; for the latter, loading libs (with side-effects on the
syntax) is required by the design of the core feature at hand (Babel
and links).

I'd focus on solving the problem with org-mouse and org-inlinetasks
first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

may i post a few notes?

i've had tehse previously.

1.

i rely on org-mouse for accessibility, as i often cannot use keyboard
at all, so there is a personal stake in having it be part of org so
that it is fully integrated.  of course i have no problem with having
to enable it instead of only load it.

it has /minor/ limbo status in that, for example, you can't set a
specific todo kw with the mouse, but that does not disturb me as much
as code rot.  see below.

2.

i don't use org-inlinetask enough to have a personal stake [in my case
i could make them siblings], but it seemed to me that it was never
sufficiently integrated into org, or had bugs, at least before parsers
became common.

if anybody does have a strong personal stake in them, like i do in 1.,
it might be desirable to make inline tasks, even breakingly, part of
org, merely to make sure that they fully integrate and test, as
opposed to limbo or code rot.

i would apply that principle to org-mouse, which being smallish and
about bindings is probably not too disruptive to be part of org.  i
defer the measurement of the disruptiveness of inline tasks to the
experts/stakeholders.

3.

istr loading org-id is or was what enables org-ids?  i'd rather have
org-id work by default.  OR maybe require activating.

4.

idk if related, but some settings in org must be done before loading.
i'd want a guideline in which, where possible, settings can be done
after loading.  this is because the user might need to go through
contortions in .emacs.  a user can do with-eval-after-load, but
with-eval-before-load sounds radically grotesque.


On 8/12/23, Bastien Guerry <bzg@gnu.org> wrote:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Yes, org-mouse modifies the behavior of certain key bindings. Not
>> directly, but by advising `org-open-at-point'.
>
> IIRC Emacs core libraries should not advise functions.
> This is something we should fix.
>
> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.
>
>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
>> Inlinetasks are too similar in syntax with headlines, so it is
>> impossible to make the change backwards-compatible.
>>
>>>> With the current state of affairs, it is often enough to
>>>> (require 'org-library) to get things work. If we get rid of all the
>>>> possible side effects, users will have to adapt their configurations
>>>> and we will thus violate "I won't force you to update your
>>>> configuration."
>>>
>>> Defining new functions is a desirable "side-effect" of all Elisp
>>> library, I don't think we should worry abou this.
>>
>> Defining new functions by itself is not a big deal. But there are parts
>> of Org that alter their behavior depending on whether a feature is
>> loaded (like org-inlinetask) or depending whether certain function
>> symbol is defined (babel). Similarly, loading new link types re-defines
>> Org syntax in all the documents, affecting editing of everything that
>> looks like the loaded link type (org-ctags).
>
> I feel like the stakes are not the same for features like org-mouse.el
> and org-inlinetask.el and for core features like Babel libs and links.
> For the former, a decision should be made relatively to the usefulness
> of the feature; for the latter, loading libs (with side-effects on the
> syntax) is required by the design of the core feature at hand (Babel
> and links).
>
> I'd focus on solving the problem with org-mouse and org-inlinetasks
> first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?
>
> --
>  Bastien Guerry
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> 3.
>
> istr loading org-id is or was what enables org-ids?  i'd rather have
> org-id work by default.  OR maybe require activating.

org-id is mostly fine, except that it (1) adds a new link type. (2) adds
a hook that saves ids before exiting Emacs.
In general, it is not too different in its design to other link type
providers. The only difference is better support in other Org core
libraries, but it only plays when a user customized org-id to take
preference over other built-in link types - not a problem for users who
do not use org-id.

> 4.
>
> idk if related, but some settings in org must be done before loading.
> i'd want a guideline in which, where possible, settings can be done
> after loading.  this is because the user might need to go through
> contortions in .emacs.  a user can do with-eval-after-load, but
> with-eval-before-load sounds radically grotesque.

Please, list the settings you have in mind. Some things, like
configuring Org syntax, must be loaded before Org because we have no
other way around.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

unable to do much of a search atm.  but i recall 3-4 org vars that
used to say so in their docstrings but didn't seem to need to be to me
at the time.  perhaps they have been fixed or i was mistaken.

regexp components docstring in bugfix still say reload or restart.
biut mayube that is obsolete.

i found possible examples in appt and ediff bot those are not org.  so
perhaps this is a case where the problem no longer exists?  8if so,
then never mind that comment about guideline for not requiring setting
before org where possible.

perhaps these are unavoidable.

bugfix .el
g set *.el|g before|g load
org-fold-core.el:Important: This variable must be set before loading Org."
org-keys.el:Needs to be set before Org is loaded.
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-persist.el:This variable must be set before loading org-persist library.")
org.el:This variable needs to be set before org.el is loaded.  If you
org.el:This variable needs to be set before org.el is loaded, and you need to


On 8/13/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> 3.
>>
>> istr loading org-id is or was what enables org-ids?  i'd rather have
>> org-id work by default.  OR maybe require activating.
>
> org-id is mostly fine, except that it (1) adds a new link type. (2) adds
> a hook that saves ids before exiting Emacs.
> In general, it is not too different in its design to other link type
> providers. The only difference is better support in other Org core
> libraries, but it only plays when a user customized org-id to take
> preference over other built-in link types - not a problem for users who
> do not use org-id.
>
>> 4.
>>
>> idk if related, but some settings in org must be done before loading.
>> i'd want a guideline in which, where possible, settings can be done
>> after loading.  this is because the user might need to go through
>> contortions in .emacs.  a user can do with-eval-after-load, but
>> with-eval-before-load sounds radically grotesque.
>
> Please, list the settings you have in mind. Some things, like
> configuring Org syntax, must be loaded before Org because we have no
> other way around.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> regexp components docstring in bugfix still say reload or restart.
> biut mayube that is obsolete.

`org-emphasis-regexp-components'? It is no longer a defcustom - you are
not supposed to change it.

> i found possible examples in appt and ediff bot those are not org.  so
> perhaps this is a case where the problem no longer exists?  8if so,
> then never mind that comment about guideline for not requiring setting
> before org where possible.
>
> perhaps these are unavoidable.

> bugfix .el
> g set *.el|g before|g load
> org-fold-core.el:Important: This variable must be set before loading Org."

It is `org-fold-core-style' - must be set before opening file because it
switches between two implementations of folding.
You usually don't need to touch it.

> org-keys.el:Needs to be set before Org is loaded.

`org-mouse-1-follows-link' simply triggers adding/not adding one binding
to `org-mouse-map'. Actually, `org-tab-follows-link' is the same.

These variables are mostly used to avoid forcing users put

(org-defkey org-mouse-map [follow-link] 'mouse-face)
or (org-defkey org-mouse-map (kbd "TAB") #'org-open-at-point)
into their config.

We may alternatively use custom :set function for these variables. That
will not require a restart.

> org-list.el:This variable needs to be set before org.el is loaded.  If you
> org-list.el:This variable needs to be set before org.el is loaded.  If you

`org-plain-list-ordered-item-terminator' and `org-list-allow-alphabetical'
configure Org parser. We should probably remove these variables
eventually. To standardize Org syntax.

> org-persist.el:This variable must be set before loading org-persist library.")

`org-persist--disable-when-emacs-Q' is an internal variable used for debugging.

> org.el:This variable needs to be set before org.el is loaded.  If you

This is `org-export-backends' that literally controls Org loading.
Technically, you don't need to re-load Org here if you set it via
customize interface.

> org.el:This variable needs to be set before org.el is loaded, and you need to

`org-enforce-todo-checkbox-dependencies'. Again, no need to reload Org
if you use customize interface. In both this and previous cases,
docstring explains about customize.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

I'll chime in regarding inlinetasks: I used to use these *a lot* but I
found that drawers do what I needed in almost all cases very
effectively (for my use cases).

I have no strong feelings therefore with respect to either of the
aspects being discussed.
-- 
: Eric S Fraga, with org release_9.6.7-635-gf9e083 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
> found that drawers do what I needed in almost all cases very
> effectively (for my use cases).

It resonates with my experience too and I suspect (and kinda hope)
many inlinetasks users will feel the same once they use drawers.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> "Fraga, Eric" <e.fraga@ucl.ac.uk> writes:
>
>> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
>> found that drawers do what I needed in almost all cases very
>> effectively (for my use cases).
>
> It resonates with my experience too and I suspect (and kinda hope)
> many inlinetasks users will feel the same once they use drawers.

My personal use case is when using Org for authoring long texts.
I often leave inline tasks around the specific paragraph I need to
revise in future:

* Section XX
<paragraph 1>

<paragraph 2>

<...>

************************* TODO Consider explaining more about X
<paragraph N>

<...>

Then, I can easily review the manuscript status using sparse tree or
agenda view.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> My personal use case is when using Org for authoring long texts.
> I often leave inline tasks around the specific paragraph I need to
> revise in future:
>
> * Section XX
> <paragraph 1>
>
> <paragraph 2>
>
> <...>
>
> ************************* TODO Consider explaining more about X
> <paragraph N>
>
> <...>
>
> Then, I can easily review the manuscript status using sparse tree or
> agenda view.

I see -- but what is the real benefit of inline tasks here over normal
tasks?  I understand that <paragraph N> should not be considered as
the details for a task, but rather its "target", but inline task does
not seem to add much here.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> ************************* TODO Consider explaining more about X
>> <paragraph N>
>>
>> <...>
>>
>> Then, I can easily review the manuscript status using sparse tree or
>> agenda view.
>
> I see -- but what is the real benefit of inline tasks here over normal
> tasks?  I understand that <paragraph N> should not be considered as
> the details for a task, but rather its "target", but inline task does
> not seem to add much here.

The benefit is that I do not need to search for that "paragraph N" when
I want to work on the task. I simply jump to the task location and can
immediately see the paragraph it refers to.

Also, pdf export of such inlinetask will nicely mark the TODO item in
the manuscript draft, so that I can print things, and still see what
should be done in that particular location of the manuscript.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.

But this would be the same with a non-inlined task, right?

> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Yes, I see.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> The benefit is that I do not need to search for that "paragraph N" when
>> I want to work on the task. I simply jump to the task location and can
>> immediately see the paragraph it refers to.
>
> But this would be the same with a non-inlined task, right?

No. For non-inlined task, I'd have to put the task somewhere far away
from the paragraph text:

** Section X

<paragraph 1>

<paragraph 2>
<...>
<paragraph N>
<...>
<multiple sreens of text>
<...>

*** TODO Task for paragraph N

Then, if I jump to the TODO, for example, from agenda view, I still need
to somehow find <paragraph N> location, which is awkward when the
section has multiple screens of text.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> ** Section X
>
> <paragraph 1>
>
> <paragraph 2>
> <...>
> <paragraph N>
> <...>
> <multiple sreens of text>
> <...>
>
> *** TODO Task for paragraph N
>
> Then, if I jump to the TODO, for example, from agenda view, I still need
> to somehow find <paragraph N> location, which is awkward when the
> section has multiple screens of text.

And what about this?

   ** Section X
   
   <paragraph 1>
   
   <paragraph 2>
   <...>
   
   *** TODO Task for paragraph N
   
   <paragraph N>
   <...>
   <multiple sreens of text>
   <...>
   
-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> Then, if I jump to the TODO, for example, from agenda view, I still need
>> to somehow find <paragraph N> location, which is awkward when the
>> section has multiple screens of text.
>
> And what about this?
>
>    ** Section X
>    
>    <paragraph 1>
>    
>    <paragraph 2>
>    <...>
>    
>    *** TODO Task for paragraph N
>    
>    <paragraph N>
>    <...>
>    <multiple sreens of text>
>    <...>

This will break export and folding.
Also, I often simply archive inlinetasks once they are done. The above
will archive too much.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

I see.  So not only inline tasks are ugly syntactic-wise, but they
also have a specific behavior when exporting.  All this pleas for an
external module, not for something we support in Org's core IMHO.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> This will break export and folding.
>> Also, I often simply archive inlinetasks once they are done. The above
>> will archive too much.
>
> I see.  So not only inline tasks are ugly syntactic-wise, but they
> also have a specific behavior when exporting.  All this pleas for an
> external module, not for something we support in Org's core IMHO.

I do not think that it would be possible. In order to support
inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
modify the internals. I see no way around that.

Too many aspects of Org are designed for one specific heading syntax.
Even modifying inlinetask *****... syntax will likely require adding
more special support where things "magically" work for now because
inlinetasks often look the same as headings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 12:56:01PM +0000, Ihor Radchenko wrote:
> Bastien Guerry <bzg@gnu.org> writes:
>
> > Ihor Radchenko <yantar92@posteo.net> writes:
> >
> >> This will break export and folding.
> >> Also, I often simply archive inlinetasks once they are done. The above
> >> will archive too much.
> >
> > I see.  So not only inline tasks are ugly syntactic-wise, but they
> > also have a specific behavior when exporting.  All this pleas for an
> > external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.
>
> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *****... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

I hear "we have a bunch of extra complex code for an ill defined
special case". Org's designed around headings, and this special case
was a hack to abuse the threshold for heading detection to support a
nonstandard heading.

Sometimes there are features we just can't support.

Would removing inline tasks in core clean up anything?

Could we normalize the code if some of the features were enabled in a
cookie/flag on a heading?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> I hear "we have a bunch of extra complex code for an ill defined
> special case". Org's designed around headings, and this special case
> was a hack to abuse the threshold for heading detection to support a
> nonstandard heading.

It was a hack to reduce the amount of special cases in the existing
code.

> Sometimes there are features we just can't support.
>
> Would removing inline tasks in core clean up anything?

It will. And it will also break some of my workflows :(

> Could we normalize the code if some of the features were enabled in a
> cookie/flag on a heading?

We would need to put more special cases. Which has pros and cons,
actually. The downside is more special cases. The upside is that most of
inlinetask bugs are originating from the same code handling both
inlinetasks and headings without accounting for their differences.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:33:01PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>
> > I hear "we have a bunch of extra complex code for an ill defined
> > special case". Org's designed around headings, and this special case
> > was a hack to abuse the threshold for heading detection to support a
> > nonstandard heading.
>
> It was a hack to reduce the amount of special cases in the existing
> code.
>
> > Sometimes there are features we just can't support.
> >
> > Would removing inline tasks in core clean up anything?
>
> It will. And it will also break some of my workflows :(

I think that's unfortunate, but perhaps it would improve the health of
the codebase?

> > Could we normalize the code if some of the features were enabled in a
> > cookie/flag on a heading?
>
> We would need to put more special cases. Which has pros and cons,
> actually. The downside is more special cases. The upside is that most of
> inlinetask bugs are originating from the same code handling both
> inlinetasks and headings without accounting for their differences.

It sounds like the code would be cleaner in a single place using a cookie.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> It will. And it will also break some of my workflows :(
>
> I think that's unfortunate, but perhaps it would improve the health of
> the codebase?

Removing most features would improve health of the codebase. Like
getting rid of agenda with its horrible code. But it does not mean that
we should do it.

>> > Could we normalize the code if some of the features were enabled in a
>> > cookie/flag on a heading?
>>
>> We would need to put more special cases. Which has pros and cons,
>> actually. The downside is more special cases. The upside is that most of
>> inlinetask bugs are originating from the same code handling both
>> inlinetasks and headings without accounting for their differences.
>
> It sounds like the code would be cleaner in a single place using a cookie.

The cleanest would be something that does not match `org-outline-regexp-bol'.
Then, we will avoid all the possible confusion between tasks and inlinetasks.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

>> I see.  So not only inline tasks are ugly syntactic-wise, but they
>> also have a specific behavior when exporting.  All this pleas for an
>> external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.

Maybe we are miscommunicating: my suggestion is to _remove_
lisp/org-inlinetask.el from Org's core.

> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *****... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

And that's part of the confusion: inline tasks _look like_ normal
tasks while behaving differently.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> I do not think that it would be possible. In order to support
>> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
>> modify the internals. I see no way around that.
>
> Maybe we are miscommunicating: my suggestion is to _remove_
> lisp/org-inlinetask.el from Org's core.

org-inlinetask.el cannot exist outside Org core without all the extra
support for inlinetasks across Org codebase.

So, what you are suggesting will completely remove inlinetasks feature.

>> Too many aspects of Org are designed for one specific heading syntax.
>> Even modifying inlinetask *****... syntax will likely require adding
>> more special support where things "magically" work for now because
>> inlinetasks often look the same as headings.
>
> And that's part of the confusion: inline tasks _look like_ normal
> tasks while behaving differently.

Yup. That's why I think that we need to make inlinetasks have distinct
syntax.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:36:39PM +0000, Ihor Radchenko wrote:
> > And that's part of the confusion: inline tasks _look like_ normal
> > tasks while behaving differently.
>
> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

Do we have a concrete summary of individual features that inline tasks
have?

I'm hearing exempt from folding, and support for drawers/heading
items.

What else?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> Do we have a concrete summary of individual features that inline tasks
> have?
>
> I'm hearing exempt from folding, and support for drawers/heading
> items.
>
> What else?

Well. Everything normal headings have, except things that cannot be done
the same way due to inlinetasks being surrounded by non-headline
elements.

In particular, export cannot be made the same - "inline" sections are
meaningless in most export backends, like latex or odt. Instead,
inlinetasks are exported as a kind of minipage/box.

Also, folding of inlinetasks is handled like folding of drawers/blocks -
separately from subtree cycling.

Similar story for M-<up>/<down> - handled like drawers/blocks.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> org-inlinetask.el cannot exist outside Org core without all the extra
> support for inlinetasks across Org codebase.

I'm aware of this.

> So, what you are suggesting will completely remove inlinetasks
> feature.

I suggest removing the support for inline tasks *as they are designed
today*, yes.  I suggest reassessing the real problem we are trying to
solve here, and see if we can come up with an approach that does not
complexify Org's core syntax too much.

E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
a heading would fit 90% of what is expected from inline tasks in the
example you gave.

> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

I'm reluctant to supercharge Org's core syntax for this feature.
I may be wrong, but I'd love to see if inline tasks are widely used,
and if so, for what specific purpose.  Again, if the core feature is
to prevent some headings from being exported, then other approaches
can be explored.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[spookygostee]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Bastien Guerry <bzg@gnu.org> writes:
> …
> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.
> …
There is functionality for a `:noexport:'  tag already built in. Do you intend `:noheadingexport:'  to apply only to the top level of the tree it is applied to? If so, that would probably not play nicely with tag inheritance.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

spookygostee@gmail.com writes:

> Bastien Guerry <bzg@gnu.org> writes:
>> …
>> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
>> a heading would fit 90% of what is expected from inline tasks in the
>> example you gave.
>> …
> There is functionality for a `:noexport:'  tag already built in. Do you intend `:noheadingexport:'  to apply only to the top level of the tree it is applied to? If so, that would probably not play nicely with tag inheritance.

Tag inheritance is not a problem. We can always add special tags to `org-tags-exclude-from-inheritance'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

[DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> I suggest removing the support for inline tasks *as they are designed
> today*, yes.

What I have in mind is slightly different: Keep inlinetasks for now and
implement a better alternative, which we can hopefully come up with in
this discussion. Later, promote the alternative, slowly deprecating the
current inlinetask implementation. Eventually, remove inlinetask code
from Org in favour of the new alternative.

> ...  I suggest reassessing the real problem we are trying to
> solve here, and see if we can come up with an approach that does not
> complexify Org's core syntax too much.

> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.

>...  Again, if the core feature is
> to prevent some headings from being exported, then other approaches
> can be explored.

May you elaborate? Is it something similar to :ignore: tag from ox-extra
contributed package?

If so, it is not what the use-cases I have in mind are about:

1. Inlinetasks should be exported as "boxes" - something similar to
   margin or inline notes
   - Can be used as a memo TODO in draft publication printout
   - As Samuel suggested, inlinetasks could be a basis of review
     comments - like what GDocs/Office provides in margin "chat"

2. When folding, I expect inlinetasks to behave like drawers/blocks -
   not hiding the continuation text below.

>> Yup. That's why I think that we need to make inlinetasks have distinct
>> syntax.
>
> I'm reluctant to supercharge Org's core syntax for this feature.
> I may be wrong, but I'd love to see if inline tasks are widely used,
> and if so, for what specific purpose.

I understand and tend to agree that it would be best to avoid extending
Org syntax too much.

Generally, the two points I listed above can be accomplished if we use
ordinary headings with a special tag. However, I am also not fully sold
on such idea. It would be nice if inlinetasks would not require adding
many stars in front, even in deeply nested subtrees.

What about another popular request - people often want to turn plain
lists into a kind of headings? We might introduce a new list type

 ** TODO this is a list, serving just like inlinetask :tag1:tag2:
    :PROPERTIES:
    <...>
    :END:
 *1. DONE numbered list

The idea is that one just needs two stars " **" to create such list -
very convenient and in line with the proper heading syntax.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> 1. Inlinetasks should be exported as "boxes" - something similar to
>    margin or inline notes
>    - Can be used as a memo TODO in draft publication printout
>    - As Samuel suggested, inlinetasks could be a basis of review
>      comments - like what GDocs/Office provides in margin "chat"

I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.

https://en.wikipedia.org/wiki/Dinkus

Best regards,

Juan Manuel 

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I think inlinetasks may also have a use for those sections that are not
> "nested". In typography they are usually called "anonymous sections" and
> they are separated by some symbol (asterisks, dinkus[1], etc.).

This is a very interesting idea. Thanks for sharing!

> ... They
> behave like a true section, except that they are not headed by titles or
> level numbers.

May they contain sub-sections?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

>> ... They
>> behave like a true section, except that they are not headed by titles or
>> level numbers.
>
> May they contain sub-sections?

I think that would not be expected, since an anonymous section is just a
break in the text that has neither a title nor a section number. There
are many possible scenarios. Let's imagine, for example, that an author
is working on a section of an article. And at the end of various
subsections he/she wants to make some text breaks that, for whatever
reason, don't deserve either a title or a subsubsection number.
Anonymous breaks using asterisks or other symbols is usually the applied
remedy. The advantage of enclosing the content of the anonymous section
in an inlinetask is that we have a 'true' section with content (over
which you have control). That would not happen if the author explicitly
added a break symbol and continue writing.

Anonymous breaks are also widely used in essay or narrative texts. An
essay text, published as a blog entry or as an article, can be perfectly
structured into anonymous sections:

contents 1

***

contents 2

***

etc

See:

https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering

https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks


-- 
Juan Manuel Macías

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>>
>> May they contain sub-sections?
>
> I think that would not be expected, since an anonymous section is just a
> break in the text that has neither a title nor a section number.
> ... Anonymous breaks using asterisks or other symbols is usually the applied
> remedy. The advantage of enclosing the content of the anonymous section
> in an inlinetask is that we have a 'true' section with content (over
> which you have control). That would not happen if the author explicitly
> added a break symbol and continue writing.

Do you mean section in LaTeX sense or in Org sense?

> Anonymous breaks are also widely used in essay or narrative texts. An
> essay text, published as a blog entry or as an article, can be perfectly
> structured into anonymous sections:
> ...
> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>
> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks

This one I know. But it can work fine with normal headings, because such
texts are nothing but a sequence of "scenes" - nothing "inline" when we
have one scene, interrupted by other, then coming back to the first one.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:

>> I think that would not be expected, since an anonymous section is just a
>> break in the text that has neither a title nor a section number.
>> ... Anonymous breaks using asterisks or other symbols is usually the applied
>> remedy. The advantage of enclosing the content of the anonymous section
>> in an inlinetask is that we have a 'true' section with content (over
>> which you have control). That would not happen if the author explicitly
>> added a break symbol and continue writing.
>
> Do you mean section in LaTeX sense or in Org sense?

In Org sense, I think. If an author adds an 'anonymous' break (through
some customary symbol) and continues writing, the content that follows
belongs (for Org) to the current section. By using an inlenitask, you
can have control over the inlinetask content, for any purpose, for
example with some export filter, etc.

On the other hand, for my own writing I usually use this:

#+begin_src emacs-lisp
  (defun my-org-latex-format-inlinetask-default-function
      (todo _todo-type priority title tags contents _info)
    (if (string-match-p "anonsec" title)
	(concat
	 "\n\\begin{anonsection}\n"
	 (org-string-nw-p contents)
	 "\n\\end{anonsection}\n")
      (org-string-nw-p contents)))

(defun mi-org-odt-format-inlinetask-default-function
    (todo todo-type  priority name tags contents)
  (if (string-match-p "anonsec" name)
      (concat
       contents
       "<text:p text:style-name=\"OrgCenter\">* * *</text:p>")))
#+end_src

And for LaTeX I have defined this:

#+begin_src latex
\newcommand\dinkus{\mbox{\textasteriskcentered\space\textasteriskcentered\space\textasteriskcentered}}
\newcommand\anonsectionmark{\dinkus}

%% require the needspace package
\newcommand\anonsectionbreak{%
  \nopagebreak[4]
  \bigskip%
  {\centering
  \anonsectionmark\par}
  \Needspace*{2\bigskipamount}
  \bigskip}

\newenvironment{anonsection}{%
\anonsectionbreak%
}
{%
\par}
#+end_src


>> Anonymous breaks are also widely used in essay or narrative texts. An
>> essay text, published as a blog entry or as an article, can be perfectly
>> structured into anonymous sections:
>> ...
>> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>>
>> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
>
> This one I know. But it can work fine with normal headings, because such
> texts are nothing but a sequence of "scenes" - nothing "inline" when we
> have one scene, interrupted by other, then coming back to the first one.

Actually, I think any anonymous text break or sectioning can be
accomplished using Org headings and some trickery to ignore the heading on
export, but I think inlinetasks lends itself quite well to this
constructions and others I've seen discussed in this thread. In general,
for any 'piece' (section = something that is sectioned) of text that
needs to be separated in some way from the main text, without a
hierarchy of levels, inlinetasks are a great, versatile and simple tool
(IMHO).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> Do you mean section in LaTeX sense or in Org sense?
>
> In Org sense, I think. If an author adds an 'anonymous' break (through
> some customary symbol) and continues writing, the content that follows
> belongs (for Org) to the current section. By using an inlenitask, you
> can have control over the inlinetask content, for any purpose, for
> example with some export filter, etc.
>
> On the other hand, for my own writing I usually use this:
>
> #+begin_src emacs-lisp
>   (defun my-org-latex-format-inlinetask-default-function
>       (todo _todo-type priority title tags contents _info)
>     (if (string-match-p "anonsec" title)
> 	(concat
> 	 "\n\\begin{anonsection}\n"
> 	 (org-string-nw-p contents)
> 	 "\n\\end{anonsection}\n")
>       (org-string-nw-p contents)))

Why not simply

#+begin_anonsection
...
#+end_anonsection

?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Why not simply
>
> #+begin_anonsection
> ...
> #+end_anonsection
>
> ?

Because with an inlinetask I can have something like this:

*************** TODO anonsec :tag:
                Content that has neither a title nor a section number.
*************** END

and a construction that for the purposes of parceling out the text
behaves like a section. The problem is the LaTeX side. Since there is no
support for anonymous sections in LaTeX (I seem to remember that some
special class like Koma had some command to introduce anonymous breaks,
but I only use the standard classes), I had to define an environment. It
is not inconvenient, since after all what appears in LaTeX is the
typographical result. For the Org side I can use TODO keywords, tags,
deadlines, etc.


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> Why not simply
>>
>> #+begin_anonsection
>> ...
>> #+end_anonsection
>>
>> ?
> ... The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.

In other words, it is not the section itself, but other
headline/inlinetask features, like todo keywords, tags, planning. Right?

Custom blocks can be exported to anything (not necessarily
\begin{foo}...), similar to how you did custom export for inlinetasks.
There was also an idea to make custom block export more customizeable,
similar to link. Like what
https://github.com/alhassy/org-special-block-extras does.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> In other words, it is not the section itself, but other
> headline/inlinetask features, like todo keywords, tags, planning. Right?

No, it is the section itself (or the concept of "section", with its toys
in Org, of course) that is important to me in this case. I am not
emphasizing so much how or in which way an element can be exported, but
what (semantic) role that element plays in the logical structure of an
Org document. To get a little philosophical, the Org document (where I
work and write) would be the idea, and the export to any format a
possible concrete realization. I mean, I find it comfortable and
productive to view an Org document as agnostic of any format. This use
of inlinetasks that I'm discussing here occurred to me a long time ago
because if I stop to think about an untitled, detached section of the
level hierarchy, this Org element is a perfect candidate. It is true
that you can use a special block, or another element (org is very
versatile, and supports role swapping between elements), but if I have
to think of a logical candidate, inlinetasks are the closest to that
concept. If inlinetasks didn't exist, I'd probably use special blocks
for that purpose. When I'm writing inside Org I'm not thinking about the
export (at least not simultaneously), that is, about the format; I think
more of the structure of the document, as something abstract.


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com
 

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Ihor Radchenko writes:
>
>> In other words, it is not the section itself, but other
>> headline/inlinetask features, like todo keywords, tags, planning. Right?
>
> No, it is the section itself (or the concept of "section", with its toys
> in Org, of course) that is important to me in this case...

So, this is a vote in favour of having a separate syntax element.
Although, the name "inlinetask" is actually awkward in such use case.
Something like inlinesection would fit better. Or inlineheading.

And what about drawers? Don't they fit the idea of "detached" element?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Although, the name "inlinetask" is actually awkward in such use case.
> Something like inlinesection would fit better. Or inlineheading.

Completely agree. I like inlinesection and inlineheading equally.

> And what about drawers? Don't they fit the idea of "detached" element?

But drawers would not serve as a "detached section"... Although they are
certainly very versatile. I usually use drawers to export as small
"containers". And when I don't export them, they are very useful for
temporarily saving all kinds of "things". In Spanish we have the term
"cajón de sastre" (lit.: "a tailor drawer") to refer to something where
you can store everything :-)

As for the inlinetask (or whatever they may be called in the future),
the fact that they are a kind of hybrid between a section (unrelated to
the level hierarchy) and a drawer seems very interesting to me. Apart
from the scenario of the anonymous sections that I mentioned before, I
can think of a few more. For example, something like this:

*************** WORKING Complete this :noexport:
		DEADLINE: <2023-08-27 dom>
                Content 
*************** END

And the combination of org-store-link with org-transclusion can also be
interesting.

Or, for example this other example, which is not possible now, but with
some modification in org-mime-org-subtree-htmlize I think it is:

*************** TODO Email this 
		DEADLINE: <2023-08-27 dom>
		:PROPERTIES:
		:mail_to:  mail address
		:mail_subject: mail subject
		:END:
                Content
*************** END

Well, it's some scattered ideas. In general I think that "inlinesection/-heading"
is an element that could be very productive in certain cases, since it
allows to "locally" suspend the (necessary) rigidity of the tree hierarchy.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> And what about drawers? Don't they fit the idea of "detached" element?
>
> But drawers would not serve as a "detached section"... Although they are
> certainly very versatile. I usually use drawers to export as small
> "containers". And when I don't export them, they are very useful for
> temporarily saving all kinds of "things". In Spanish we have the term
> "cajón de sastre" (lit.: "a tailor drawer") to refer to something where
> you can store everything :-)

I am not sure here. It looks like having a new special block type

#+begin_inlinesection
...
#+end_inlinesection

would be sufficient. Given that we cannot nest inlinesections anyway.

Or special drawer
:inlinesection:
...
:end:

Although, drawers will be less powerful because, unlike special blocks,
you cannot have a different drawer type inside. For special blocks, a
different special block is perfectly fine.

I do not see any clear benefit of having a dedicated, separate markup
for inlinesection, apart from philosophical.

> As for the inlinetask (or whatever they may be called in the future),
> the fact that they are a kind of hybrid between a section (unrelated to
> the level hierarchy) and a drawer seems very interesting to me. Apart
> from the scenario of the anonymous sections that I mentioned before, I
> can think of a few more. For example, something like this:
>
> *************** WORKING Complete this :noexport:
> 		DEADLINE: <2023-08-27 dom>
>                 Content 
> *************** END
>
> And the combination of org-store-link with org-transclusion can also be
> interesting.
>
> Or, for example this other example, which is not possible now, but with
> some modification in org-mime-org-subtree-htmlize I think it is:
>
> *************** TODO Email this 
> 		DEADLINE: <2023-08-27 dom>
> 		:PROPERTIES:
> 		:mail_to:  mail address
> 		:mail_subject: mail subject
> 		:END:
>                 Content
> *************** END

We can get the same functionality if we allow arbitrary properties and
tags assigned to non-headline elements.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Sat, Aug 26, 2023 at 05:31:46PM +0000, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
> *************** TODO anonsec :tag:
>                 Content that has neither a title nor a section number.
> *************** END
>
> and a construction that for the purposes of parceling out the text
> behaves like a section. The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.

Why not just put the TODO heading in a code block with type org?

Then you get all the toys, ignored by the main file.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
> Why not just put the TODO heading in a code block with type org?
>
> Then you get all the toys, ignored by the main file.

If inline tasks are supposed to be Org enabled headings, but NOT
treated like headings in the current file, why not put them in a src block?

Doesn't this allow the same functionality without any new syntax
elements, or silly long *'s?

======================================================================

* Things

** TODO stuff

[2023-08-07 Mon 20:06]

#+begin_src org
  ,*** DONE This is not a heading
  CLOSED: [2023-08-29 Tue 14:57]

  stuff things
#+end_src

** DONE stuff2
CLOSED: [2023-08-07 Mon 20:06]

[2023-08-07 Mon 20:07]
this


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Tue 29 Aug 2023 15:00:
 > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > > Why not just put the TODO heading in a code block with type org?
 > >
 > > Then you get all the toys, ignored by the main file.
 > 
 > If inline tasks are supposed to be Org enabled headings, but NOT
 > treated like headings in the current file, why not put them in a src block?
 > 
 > Doesn't this allow the same functionality without any new syntax
 > elements, or silly long *'s?

Are regular Org tags allowed in this scenario?  If not, I'd be
miserable.

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > > Why not just put the TODO heading in a code block with type org?
>  > >
>  > > Then you get all the toys, ignored by the main file.
>  >
>  > If inline tasks are supposed to be Org enabled headings, but NOT
>  > treated like headings in the current file, why not put them in a src block?
>  >
>  > Doesn't this allow the same functionality without any new syntax
>  > elements, or silly long *'s?
>
> Are regular Org tags allowed in this scenario?  If not, I'd be
> miserable.

It's a source block of type Org. That means *everything* that works in
Org works inside that block. You might open it with C-c C-' to open it
in an indirect buffer to enable everything.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Wed 30 Aug 2023 14:36:
 > On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
 > > Russell Adams writes on Tue 29 Aug 2023 15:00:
 > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > >  > > Why not just put the TODO heading in a code block with type org?
 > >  > >
 > >  > > Then you get all the toys, ignored by the main file.
 > >  >
 > >  > If inline tasks are supposed to be Org enabled headings, but
 > >  > NOT treated like headings in the current file, why not put
 > >  > them in a src block?
 > >  >
 > >  > Doesn't this allow the same functionality without any new syntax
 > >  > elements, or silly long *'s?
 > >
 > > Are regular Org tags allowed in this scenario?  If not, I'd be
 > > miserable.
 > 
 > It's a source block of type Org. That means *everything* that works in
 > Org works inside that block. You might open it with C-c C-' to open it
 > in an indirect buffer to enable everything.

Sorry, that's not enough for me to understand.  What would be the
equivalent of:

   * head :foo:
   *************** inlt :bar:
   *************** END

where the 'bar' tag could be used in exactly the same way as the 'foo'
tag.

Thanks.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:06:51PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 14:36:
>  > On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
>  > > Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > >  > > Why not just put the TODO heading in a code block with type org?
>  > >  > >
>  > >  > > Then you get all the toys, ignored by the main file.
>  > >  >
>  > >  > If inline tasks are supposed to be Org enabled headings, but
>  > >  > NOT treated like headings in the current file, why not put
>  > >  > them in a src block?
>  > >  >
>  > >  > Doesn't this allow the same functionality without any new syntax
>  > >  > elements, or silly long *'s?
>  > >
>  > > Are regular Org tags allowed in this scenario?  If not, I'd be
>  > > miserable.
>  >
>  > It's a source block of type Org. That means *everything* that works in
>  > Org works inside that block. You might open it with C-c C-' to open it
>  > in an indirect buffer to enable everything.
>
> Sorry, that's not enough for me to understand.  What would be the
> equivalent of:
>
>    * head :foo:
>    *************** inlt :bar:
>    *************** END
>
> where the 'bar' tag could be used in exactly the same way as the 'foo'
> tag.

Please give some examples of "bar used in exactly the same way as
foo".

Off the top of my head, I can only think that some agenda views and
collapsing to sparse tree may not recognize :bar: because it's inside
a source block.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Wed 30 Aug 2023 16:31:

 > > What would be the equivalent of:
 > >
 > >    * head :foo:
 > >    *************** inlt :bar:
 > >    *************** END
 > >
 > > where the 'bar' tag could be used in exactly the same way as the 'foo'
 > > tag.

 > Please give some examples of "bar used in exactly the same way as
 > foo".

M-x org-agenda m bar

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:39:50PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 16:31:
>
>  > > What would be the equivalent of:
>  > >
>  > >    * head :foo:
>  > >    *************** inlt :bar:
>  > >    *************** END
>  > >
>  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
>  > > tag.
>
>  > Please give some examples of "bar used in exactly the same way as
>  > foo".
>
> M-x org-agenda m bar

Is bar used across many headings with inline tasks? Then it may not.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 05:08:40PM +0200, Russell Adams wrote:
> On Wed, Aug 30, 2023 at 04:39:50PM +0200, Alain.Cochard@unistra.fr wrote:
> > Russell Adams writes on Wed 30 Aug 2023 16:31:
> >
> >  > > What would be the equivalent of:
> >  > >
> >  > >    * head :foo:
> >  > >    *************** inlt :bar:
> >  > >    *************** END
> >  > >
> >  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
> >  > > tag.
> >
> >  > Please give some examples of "bar used in exactly the same way as
> >  > foo".
> >
> > M-x org-agenda m bar
>
> Is bar used across many headings with inline tasks? Then it may not.

That said, I think the question is would any code for interpreting
embedded org source blocks be cleaner than the existing inline task code.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> That said, I think the question is would any code for interpreting
> embedded org source blocks be cleaner than the existing inline task code.

I disagree. Src blocks are usually excluded from agendas and other
normal Org interactions - they are normally considered verbatim text
from the point of view of Org parser.

Special treatment of org src blocks would still introduce extra special
handling and on top of that interfere with the existing uses of org src
blocks, where the inner Org structure is not expected to have any effect.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 12:40:50PM +0000, Ihor Radchenko wrote:
> Bastien Guerry <bzg@gnu.org> writes:
> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

So just to be clear, we want a method to make a heading with all the
features of headings, but that isn't a heading or treated like a
heading?

Isn't the key feature that the inline task is a heading except it is
exempt from the folding logic (ie: sparse tree)?

Why can't we do this with a flag or cookie in a heading? We already
have priority cookies.

If the inline task also doesn't impact the tree structure of the
parent heading, that's an even taller order. That's where plain lists
are OK, they just lack the extra functionality of a heading (ie: drawers).

I don't see any solution that isn't really hacky.

Shouldn't this be excluded from core and supplied by someone's custom
plugin if they want this ability? Org-mode should focus on the
headings and their data, and if you need to hack in some extra syntax
perhaps Org doesn't need to concern itself.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> So just to be clear, we want a method to make a heading with all the
> features of headings, but that isn't a heading or treated like a
> heading?

> Isn't the key feature that the inline task is a heading except it is
> exempt from the folding logic (ie: sparse tree)?

> Why can't we do this with a flag or cookie in a heading? We already
> have priority cookies.

We might. Adding gazillion of stars is not conceptually different from
adding a spacial cookie.

The only extra thing required is some way to mark inlinetask ending,
because we must be able to continue the containing section below
inlinetask:

* [#inline] Inlinetask
* [#inline] END

> Shouldn't this be excluded from core and supplied by someone's custom
> plugin if they want this ability? Org-mode should focus on the
> headings and their data, and if you need to hack in some extra syntax
> perhaps Org doesn't need to concern itself.

Because it will be feature regression.
And it will not be possible with a custom plugin without significant
changes in how all the headline editing commands, agenda, sparse trees,
etc work - they all assume very specific heading syntax.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:04:10PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
> We might. Adding gazillion of stars is not conceptually different from
> adding a spacial cookie.

True. Just cleaner.

> The only extra thing required is some way to mark inlinetask ending,
> because we must be able to continue the containing section below
> inlinetask:
>
> * [#inline] Inlinetask
> * [#inline] END

I think the multiline aspect is where the concept breaks down.

"I want a special invisible heading inside the content of a heading,
that also supports optional multiline contents". Sounds horrible to code.

> > Shouldn't this be excluded from core and supplied by someone's custom
> > plugin if they want this ability? Org-mode should focus on the
> > headings and their data, and if you need to hack in some extra syntax
> > perhaps Org doesn't need to concern itself.
>
> Because it will be feature regression.
> And it will not be possible with a custom plugin without significant
> changes in how all the headline editing commands, agenda, sparse trees,
> etc work - they all assume very specific heading syntax.

Regressions are not the end of the world. Org does too much and grew
very fast, which is not sustainable.

There were other mails in this thread that agreed this might be an ill
conceived feature hack.

Given limited maintainer time, culling bad features is a fact of life.

My recommendation is cut it out, until someone with more time can make
a rational and compelling case for a clean syntax that isn't a huge
special case or write a separate module.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> * [#inline] Inlinetask
>> * [#inline] END
>
> I think the multiline aspect is where the concept breaks down.
>
> "I want a special invisible heading inside the content of a heading,
> that also supports optional multiline contents". Sounds horrible to code.

It is not. The horrible part is that we rely on some things working
magically without special account for inlinetask existance. Otherwise,
it is just a matter of extra cond.

>> Because it will be feature regression.
>> And it will not be possible with a custom plugin without significant
>> changes in how all the headline editing commands, agenda, sparse trees,
>> etc work - they all assume very specific heading syntax.
>
> Regressions are not the end of the world. Org does too much and grew
> very fast, which is not sustainable.

But they should not be taken lightly either.
https://bzg.fr/en/the-software-maintainers-pledge/

> Given limited maintainer time, culling bad features is a fact of life.

_I_ actively use inlinetasks. And it is not a bad feature by itself. The
current syntax is bad, yes. And the current state with inlinetasks being
optional feature.

> My recommendation is cut it out, until someone with more time can make
> a rational and compelling case for a clean syntax that isn't a huge
> special case or write a separate module.

Is there any hurry to delete things? If we still keep a new syntax open
for discussion, I see no reason to remove anything.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>
> >> * [#inline] Inlinetask
> >> * [#inline] END
> >
> > I think the multiline aspect is where the concept breaks down.
> >
> > "I want a special invisible heading inside the content of a heading,
> > that also supports optional multiline contents". Sounds horrible to code.
>
> It is not. The horrible part is that we rely on some things working
> magically without special account for inlinetask existance. Otherwise,
> it is just a matter of extra cond.

So then, refinement?

> > Given limited maintainer time, culling bad features is a fact of life.
>
> _I_ actively use inlinetasks. And it is not a bad feature by itself. The
> current syntax is bad, yes. And the current state with inlinetasks being
> optional feature.
>
> > My recommendation is cut it out, until someone with more time can make
> > a rational and compelling case for a clean syntax that isn't a huge
> > special case or write a separate module.
>
> Is there any hurry to delete things? If we still keep a new syntax open
> for discussion, I see no reason to remove anything.

Certainly no hurry. Just expressing my opinion. You know the code much
better than I, I'm just trying to defend maintainer time from extra
work.

Maybe start a new email thread for a RFC regarding a potential
replacement inline task syntax that would be cleaner for the code,
parser, and easier to maintain?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> Is there any hurry to delete things? If we still keep a new syntax open
>> for discussion, I see no reason to remove anything.
>
> Certainly no hurry. Just expressing my opinion. You know the code much
> better than I, I'm just trying to defend maintainer time from extra
> work.

I am personally interested to maintain inlinetasks.

> Maybe start a new email thread for a RFC regarding a potential
> replacement inline task syntax that would be cleaner for the code,
> parser, and easier to maintain?

Yup. We are too far away from the subject now. I will start a new thread
in a reply to Bastien.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +0000, Ihor Radchenko wrote:
> > Regressions are not the end of the world. Org does too much and grew
> > very fast, which is not sustainable.
>
> But they should not be taken lightly either.
> https://bzg.fr/en/the-software-maintainers-pledge/

I wouldn't recommend taking them lightly, but I think "never" is too
strong a word.

Org's grown so much and so fast, and has limited maintainer time. If
the choice is between keeping Org up to date in Emacs and working,
versus a problem feature, then it's appropriate to remove problems for
the health of the core.

Let's not remove on a whim.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Thu, Aug 24, 2023 at 02:36:31PM +0200, Bastien Guerry wrote:
> Ihor Radchenko <yantar92@posteo.net> writes:
> 
> > ** Section X
> >
> > <paragraph 1>
> >
> > <paragraph 2>
> > <...>
> > <paragraph N>
> > <...>
> > <multiple sreens of text>
> > <...>
> >
> > *** TODO Task for paragraph N
> >
> > Then, if I jump to the TODO, for example, from agenda view, I still need
> > to somehow find <paragraph N> location, which is awkward when the
> > section has multiple screens of text.
> 
> And what about this?
> 
>    ** Section X
>    
>    <paragraph 1>
>    
>    <paragraph 2>
>    <...>
>    
>    *** TODO Task for paragraph N
>    
>    <paragraph N>
>    <...>
>    <multiple sreens of text>
>    <...>

Ah... it would be nice if Org could "go up one level",
wouldn't it?

;-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

<tomas@tuxteam.de> writes:

>>    <multiple sreens of text>
>>    <...>
>
> Ah... it would be nice if Org could "go up one level",
> wouldn't it?

What do you mean?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:29:22PM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
>
> >>    <multiple sreens of text>
> >>    <...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
>
> What do you mean?

I think Markdown has different levels?

It is interesting to think that Org has only one kind of heading:

********** ...

Has there ever been a reason to diversify the heading syntax to allow
levels or changes in visibility?

** TODO

=== TODO Inline item under todo

--- DONE something else?

### TODO invis to all except interactive editing




------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> What do you mean?
>
> I think Markdown has different levels?

Do you mean # title vs. ## title?

> Has there ever been a reason to diversify the heading syntax to allow
> levels or changes in visibility?
>
> ** TODO
>
> === TODO Inline item under todo
>
> --- DONE something else?
>
> ### TODO invis to all except interactive editing

That's even more features. I feel confused about what you are trying to
convey.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:44:03PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>
> >> What do you mean?
> >
> > I think Markdown has different levels?
>
> Do you mean # title vs. ## title?

https://www.markdownguide.org/basic-syntax

look at the alternate syntax where they under line with different symbols.

> > Has there ever been a reason to diversify the heading syntax to allow
> > levels or changes in visibility?
> >
> > ** TODO
> >
> > === TODO Inline item under todo
> >
> > --- DONE something else?
> >
> > ### TODO invis to all except interactive editing
>
> That's even more features. I feel confused about what you are trying to
> convey.

It is, but it's just brainstorming along the lines of needing an
inline task syntax.

We have a solid heading syntax, with one or more asterisks followed by
keywords and heading metadata. Given we're talking about adding more
flags in the metadata, I'm just asking if we should consider
alternatives to just asterisks to help indicate differences.

An inline task exempt from folding should be eye catching to
differentiate it from other headings. Perhaps something other than
asterisks is appropriate?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[spookygostee]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> On Thu, Aug 24, 2023 at 01:44:03PM +0000, Ihor Radchenko wrote:
>> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>>
>> >> What do you mean?
>> >
>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> <https://www.markdownguide.org/basic-syntax>
>
> look at the alternate syntax where they under line with different symbols.
>
>> > Has there ever been a reason to diversify the heading syntax to allow
>> > levels or changes in visibility?
>> >
>> > ** TODO
>> >
>> > `=' TODO Inline item under todo
>> >
>> > — DONE something else?
>> >
>> > ### TODO invis to all except interactive editing
>>
>> That’s even more features. I feel confused about what you are trying to
>> convey.
>
> It is, but it’s just brainstorming along the lines of needing an
> inline task syntax.
>
> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we’re talking about adding more
> flags in the metadata, I’m just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?
>
> ——————————————————————
> Russell Adams                            RLAdams@AdamsInfoServ.com
>                                     <https://www.adamsinfoserv.com/>

As someone who only uses orgmode, I personally find the logical distinction between inline and normal headings not compelling enough to justify adding new syntax besides asterisks. Frequently I hear orgmode’s extremely simple syntax lauded in comparison to something like markdown. Just some thoughts.

–shortcut

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> https://www.markdownguide.org/basic-syntax
>
> look at the alternate syntax where they under line with different symbols.

Ah. That thing. It will move Org towards more complex syntax. I am not
in favour.

> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we're talking about adding more
> flags in the metadata, I'm just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?

Bastien voiced against adding yet more syntax elements. So, let's try to
find some way that will not involve completely new syntax element and
instead stick closer to the existing syntax.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

On Thu, Aug 24, 2023 at 01:29:22PM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> >>    <multiple sreens of text>
> >>    <...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
> 
> What do you mean?

Not proposing to change anything, Org is what it is. Org's "sections"
are somewhat stepchildren, since the primary structure is the heading.

As a consequence, you "close" a section by "opening" a new one; if
you start a subsection, you can't end it "going back" to the enclosing
section: express this in Org:

  <section heading="Main Section">
    this is some text in the main section
    More text
    <section heading="A Subsection>
      Some text therein
    </section>
    Now we are "back" in the main section
  </section>

(FWIW I cop out of this by declaring that a section name of - means
"going up" like so:

  * Main Section
    this is some text in the main section
    More text
  ** A Subsection
     Some text therein
  * -
    Now we are "back" in the main section

(Note that here, the "-" gets one star, i.e. the level we are going
back to: this way, most things work as they should; and it is not
too hard to hack exporters to do the right thing :)

Back to the case in question: Someone proposed intercalating a
subsection instead of using an inline task, which would work
if there were a way of "closing" that subsection; otherwise the
idea messes with the document structure.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

tomas@tuxteam.de writes:

> Back to the case in question: Someone proposed intercalating a
> subsection instead of using an inline task, which would work
> if there were a way of "closing" that subsection; otherwise the
> idea messes with the document structure.

I see. This has been discussed previously. The main problem is that such
sections cannot be exported to latex/odt easily. So, we will complicate
export substantially.

And it will not be too different from the current approach. Even worse,
actually:

1. Similar to now, we will need to modify the parser, skipping some of
   the headings, that must no longer be considered proper headings, but
   rather "continuations"

2. We will have to allow nested proper headings inside sections, which
   will break logic all over the Org codebase.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 11:44:29AM +0000, Ihor Radchenko wrote:
> Bastien Guerry <bzg@gnu.org> writes:
>
> >> ************************* TODO Consider explaining more about X
> >> <paragraph N>
> >>
> >> <...>
> >>
> >> Then, I can easily review the manuscript status using sparse tree or
> >> agenda view.
> >
> > I see -- but what is the real benefit of inline tasks here over normal
> > tasks?  I understand that <paragraph N> should not be considered as
> > the details for a task, but rather its "target", but inline task does
> > not seem to add much here.
>
> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.
>
> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Interesting. I often will use comments when I need to update things in
a document to be exported.

* Item

Wubba lubba ding dong.

# TODO fix this to pig latin

Arff!!

* Other stuff


Doesn't this really come down to a use case for having headings which
are excluded from operations like comments are?

Could we treat #'s as inline headings? Not sure how that'd handle
drawers.



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> * Item
>
> Wubba lubba ding dong.
>
> # TODO fix this to pig latin
>
> Arff!!
>
> * Other stuff
>
>
> Doesn't this really come down to a use case for having headings which
> are excluded from operations like comments are?

Nope. As I described, I often want inlinetasks to be exported and to be
displayed in my agenda/sparse tree views:

1. On export, I will see

1 Item
══════

  Wubba lubba ding dong.

                                          ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                          TODO fix this to pig latin
                                          ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Arff!!


2 Other staff
═════════════

2. I can also use the inlinetask normally, scheduling it, adding notes
   to it, etc

> Could we treat #'s as inline headings? Not sure how that'd handle
> drawers.

#'s are excluded from export unconditionally. Also, more complex
 inlinetasks may contain normal Org markup and elements, which make no
 sense in comments.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 24/08/2023 19:21, Ihor Radchenko wrote:
> As I described, I often want inlinetasks to be exported and to be
> displayed in my agenda/sparse tree views

It sounds like that if agenda had hooks allowing to gather either 
:inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask 
custom blocks then ************** END would not be necessary.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

iiuc bastien brought up the use of a no export this heading tag as an
alternative to inline tasks.  we have much or all of this capability
in faq.

i was thinking the same thing.  perhaps many use cases could have
inline tasks as siblings below the document heading, and undesired
headers could be just not exported.

i was also wondering if links and/or some type of transclusion could
also obviate inline tasks.  the formerly-inline task would contain a
link to a target above the paragraph.  c-c c-c on that location would
take you back to the task.


On 8/24/23, Max Nikulin <manikulin@gmail.com> wrote:
> On 24/08/2023 19:21, Ihor Radchenko wrote:
>> As I described, I often want inlinetasks to be exported and to be
>> displayed in my agenda/sparse tree views
>
> It sounds like that if agenda had hooks allowing to gather either
> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
> custom blocks then ************** END would not be necessary.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

[p.s.  not saying this will satisfy ardent users, just bringing up the
idea in case it is of use.]


On 8/24/23, Samuel Wales <samologist@gmail.com> wrote:
> iiuc bastien brought up the use of a no export this heading tag as an
> alternative to inline tasks.  we have much or all of this capability
> in faq.
>
> i was thinking the same thing.  perhaps many use cases could have
> inline tasks as siblings below the document heading, and undesired
> headers could be just not exported.
>
> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.
>
>
> On 8/24/23, Max Nikulin <manikulin@gmail.com> wrote:
>> On 24/08/2023 19:21, Ihor Radchenko wrote:
>>> As I described, I often want inlinetasks to be exported and to be
>>> displayed in my agenda/sparse tree views
>>
>> It sounds like that if agenda had hooks allowing to gather either
>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>> custom blocks then ************** END would not be necessary.
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

another idea, at the cost of 3 dumb messages in a row....  there are
annotation packages.  i wonder if integration of those is relevant.

On 8/24/23, Samuel Wales <samologist@gmail.com> wrote:
> [p.s.  not saying this will satisfy ardent users, just bringing up the
> idea in case it is of use.]
>
>
> On 8/24/23, Samuel Wales <samologist@gmail.com> wrote:
>> iiuc bastien brought up the use of a no export this heading tag as an
>> alternative to inline tasks.  we have much or all of this capability
>> in faq.
>>
>> i was thinking the same thing.  perhaps many use cases could have
>> inline tasks as siblings below the document heading, and undesired
>> headers could be just not exported.
>>
>> i was also wondering if links and/or some type of transclusion could
>> also obviate inline tasks.  the formerly-inline task would contain a
>> link to a target above the paragraph.  c-c c-c on that location would
>> take you back to the task.
>>
>>
>> On 8/24/23, Max Nikulin <manikulin@gmail.com> wrote:
>>> On 24/08/2023 19:21, Ihor Radchenko wrote:
>>>> As I described, I often want inlinetasks to be exported and to be
>>>> displayed in my agenda/sparse tree views
>>>
>>> It sounds like that if agenda had hooks allowing to gather either
>>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>>> custom blocks then ************** END would not be necessary.
>>>
>>>
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> another idea, at the cost of 3 dumb messages in a row....  there are
> annotation packages.  i wonder if integration of those is relevant.

Somewhat. The problem is when we want to associate inlinetask with
something more granular than a paragraph.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.

I though about links to target paragraph. But that would require adding
#+name to paragraph in question or creating a long fuzzy search link -
very inconvenient when editing Org as plain text file. I'd prefer some
other approach, if possible.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

On Wednesday, 23 Aug 2023 at 09:33, Ihor Radchenko wrote:
>> "Fraga, Eric" <e.fraga@ucl.ac.uk> writes:
>>
>>> I'll chime in regarding inlinetasks: I used to use these *a lot*
>>> but I
>>> found that drawers do what I needed in almost all cases very
>>> effectively (for my use cases).
>
> My personal use case is when using Org for authoring long texts.
> I often leave inline tasks around the specific paragraph I need to
> revise in future:

For completeness, I will add that I do the same but using drawers at the
point where I want to note a task, where the drawer is ~:todo:~.  I then
have some special formatting for LaTeX export that converts such drawers
into footnotes with a note in the margin.

-- 
: Eric S Fraga, with org release_9.6.6-412-g2f7b35 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

>> My personal use case is when using Org for authoring long texts.
>> I often leave inline tasks around the specific paragraph I need to
>> revise in future:
>
> For completeness, I will add that I do the same but using drawers at the
> point where I want to note a task, where the drawer is ~:todo:~.  I then
> have some special formatting for LaTeX export that converts such drawers
> into footnotes with a note in the margin.

That will indeed work. But then the todo will not appear in agenda.

I think that a combination of drawers/special blocks + ability to assign
todos/tags to paragraphs/tables/drawers/etc may give people what they
usually need when using inlinetasks.
 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

On Saturday, 26 Aug 2023 at 12:30, Ihor Radchenko wrote:
> That will indeed work. But then the todo will not appear in agenda.

Indeed.  Luckily, for me, I don't tend to want the actions within my
long documents to be listed in my agenda. Essentially, I have global
todo items (which appear in my agenda) and document (aka project)
specific ones which I only care about when working on that document
(project).  But...

> I think that a combination of drawers/special blocks + ability to
> assign todos/tags to paragraphs/tables/drawers/etc may give people
> what they usually need when using inlinetasks.

Yes, this capability would give the flexibility people want or need.

-- 
: Eric S Fraga, with org release_9.6.6-412-g2f7b35 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Mon, Aug 14, 2023 at 01:19:07PM +0000, Fraga, Eric wrote:
> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
> found that drawers do what I needed in almost all cases very
> effectively (for my use cases).

Can you give an example?

I always hear the meeting notes with a short tasklist example. That
plain list checkboxes aren't enough, the extra metadata is desired.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

[DISCUSSION] The future of org-mouse.el and org-inlinetask.el (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

org-mouse implements mouse bindings + context menus.
Context menu support is something that major modes generally expect to
provide:

24.2.1 Major Mode Conventions
   • Consider adding mode-specific context menus for the mode, to be
     used if and when users activate the ‘context-menu-mode’ (*note
     (emacs)Menu Mouse Clicks::).  To this end, define a mode-specific
     function which builds one or more menus depending on the location
     of the ‘mouse-3’ click in the buffer, and then add that function to
     the buffer-local value of ‘context-menu-functions’.

And better mouse support is getting more important in a view of recent
native Android port of Emacs, where "mouse" is the main mode of
interaction.

I'd say that we should not remove org-mouse.el, but instead load it by
default. Maybe even fully integrating org-mouse.el into other libraries
like org-keys.el and org.el.

>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.

org-inlinetask, if removed, is bound to break unless we maintain
inlinetask support in the core. And it will be a feature regression for
a number of users (for me, at least - I am a big user of inlinetasks
myself).

However, the current way inlinetasks are implemented is definitely not
great. The clash between headings and inlinetask syntax is getting too
much on the way.

May we re-consider inlinetask syntax and come up with an alternative
syntax that does not clash with headings? This will make things a lot
easier to maintain and allow us to gradually deprecate the existing
<infinite *> syntax.

For example, we can define inlinetasks as

*> TODO inlinetask
***> TODO inlinetask
...

*> TODO inlinetask
Inlinetask contents
*> END

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> I'd say that we should not remove org-mouse.el, but instead load it by
> default. Maybe even fully integrating org-mouse.el into other libraries
> like org-keys.el and org.el.

+1 on that.

> For example, we can define inlinetasks as
>
> *> TODO inlinetask
> ***> TODO inlinetask
> ...

+1 on this one.

> *> TODO inlinetask
> Inlinetask contents
> *> END

-1 on this one -- I'd rather get rid of the

* TODO ...
* END

construct altogether.

-- 
 Bastien Guerry

Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> *> TODO inlinetask
>> Inlinetask contents
>> *> END
>
> -1 on this one -- I'd rather get rid of the
>
> * TODO ...
> * END
>
> construct altogether.

I also don't like it, but have no better idea about a good markup to
identify inlinetask body.

Might be

*> TODO inlinetask
...
*<

but it feels against how other Org markup works.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
> > And it is not clear how to fix this. We did not make inlinetasks into
> > standard Org syntax in the past and now it is in the weird state when we
> > have (featurep 'org-inlinetask) sprinkled across the code just to
> > accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
> > Inlinetasks are too similar in syntax with headlines, so it is
> > impossible to make the change backwards-compatible.

Chiming in here to say that inline tasks make it exceptionally annoying
to specify a sane grammar for org because they require putting a special
case in the headline tokenizer, and/or making it possible to toggle the
behavior of the tokenizer.

As such I strongly support removing them from any official status in
the name of simplifying the syntax (among other things).

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Timothy]

Hi All,

On Sat, Aug 12, 2023, at 1:46 PM, Bastien Guerry wrote:

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.

As I've done the V2 rewrite of org-syntax and written a non-elisp Org parser from scratch, I feel like I'm in a decent position to comment on inline tasks.

They are a syntactic abomination.

If there is any chance of making inlinetasks an extra that is outside core Org/the Org spec, I think that would be for the best. Having a 15+ level headlines sometimes transform into a completely different syntactic element is ... really not nice.

All the best,
Timothy.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Tue, Aug 15, 2023 at 03:10:59PM +0100, Timothy wrote:
> They are a syntactic abomination.
>
> If there is any chance of making inlinetasks an extra that is
> outside core Org/the Org spec, I think that would be for the
> best. Having a 15+ level headlines sometimes transform into a
> completely different syntactic element is ... really not nice.

I've never used inline for exactly this reason, 15x*'s seems like
trying to use an overflow to hide data.

Couldn't we use something like headings using ++'s instead of **'s as
folded by default?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> Couldn't we use something like headings using ++'s instead of **'s as
> folded by default?

I am afraid that +++++++ may actually occur in real Org documents (e.g.
copy-paste from diff files).

Any other ideas? I'd be happy to see some brain-storming.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Any other ideas? I'd be happy to see some brain-storming.

Maybe a #+keyword[options]: that doubles as a dynamic block or
something like that?
#+inline_task[options]: TODO some tiny task
#+inline_task[options]: TODO some small task
DEADLINE: <2023-11-11>
:PROPERTIES:
:SOMETHING: or other
:END:
#+inline_task_end:

Migration path should be straight forward, the exact implementation of
the behavior might need
a bit of work, and I'm not sure that the scheduling line will work in
that context, it is too fart
outside the usual behavior for keywords. However it might be possible
to move the deadline into [options]
the syntax would be a bit different than regular scheduling lines, but
it would at least be consistent
with keyword syntax.

The other question is whether you actually need an #+inline_task_end:
or whether there is another way.

The idea could use a few more iterations.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> Any other ideas? I'd be happy to see some brain-storming.
>
> Maybe a #+keyword[options]: that doubles as a dynamic block or
> something like that?
> #+inline_task[options]: TODO some tiny task
> #+inline_task[options]: TODO some small task
> DEADLINE: <2023-11-11>
> :PROPERTIES:
> :SOMETHING: or other
> :END:
> #+inline_task_end:

I am not sure if I like [options]. If we support property drawer, why
would we need additional options? I'd rather stick closer to the heading
syntax (but without that 15x****... madness).

I also _slightly_ do not like #+... syntax because I expect some
interference with fontification code for "meta lines".

> Migration path should be straight forward, the exact implementation of
> the behavior might need
> a bit of work, and I'm not sure that the scheduling line will work in
> that context, it is too fart
> outside the usual behavior for keywords. However it might be possible
> to move the deadline into [options]
> the syntax would be a bit different than regular scheduling lines, but
> it would at least be consistent
> with keyword syntax.

It would actually be a headache to move planning into options.
A number of places in Org hard-code planning line regexp and will have
to be modified significantly to accommodate [options]. In particular, I
have org-agenda in mind (the place I rarely dare to touch)

> The other question is whether you actually need an #+inline_task_end:
> or whether there is another way.

Another idea might be similar to footnote definitions that mark their
end with double blank line. But I do not like footnote definition syntax
because it makes it impossible to have something like

[fn:1] Footnote definition containing src block
#+begin_src elisp
"This has


two newlines and not an src block anymore because
footnote definition ending takes precedence"
#+end_src

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Or probably just fix the org-ctags hook functions? (was: Should we accept breaking changes ...)

[Jens Schmidt]

On 2023-08-08  10:48, Ihor Radchenko wrote:

> The situation is a bit more complex.

To make it even more complex, here a different point of view.  Sorry,
I don't have any earlier mails ready I could reply to ...

* TL;DR

Probably the problem is not the side-effects done by loading
=org-ctags=, but rather that these hook function from =org-ctags= try
to do their job when the environment is not really ready for them,
i.e. when there is no known tag file around.

* Full Story

I tried to get this thing running.  Some issues and observations I
came across:

1. When I execute function `org-ctags-create-tags' in file
    =org-manual.org= of Org =main=, an empty =TAGS= file gets created.
    Presumably because the asterisk in the generated command line is
    quoted and the warning generated by that (=cannot open source file
    "/home/jschmidt/work/org-mode/doc/*"=) is not shown in Emacs:

    #+begin_example
      ctags-exuberant --langdef=orgmode --langmap=orgmode:.org \
        --regex-orgmode="/<<([^>]+)>>/\1/d,definition/" \
        -f "/home/jschmidt/work/org-mode/doc/TAGS" -e -R \
        "/home/jschmidt/work/org-mode/doc/*"
       ^^^                                ^^^
    #+end_example

    If I execute the statement on the command line w/o the quotes on
    the final parameter, I get a non-empty =TAGS= file.

    Besides that, I somehow doubt that =-R .../*= (=-R= meaning
    recursive operation) makes actually sense, this probably should be
    just =-R ...= instead.

    Besides *that* the following sexps from the function look fishy:

    #+begin_src emacs-lisp
      (expand-file-name (concat dir-name "/TAGS"))
      (expand-file-name (concat dir-name "/*"))
    #+end_src

    Why not =(expand-file-name "TAGS" dir-name)=?

2. When one looks at the =TAGS= file generated thus, one immediately
    notices that the regular expression from parameter
    =--regex-orgmode= used to match these <<targets>> matches also
    non-targets, like in the following example section:

      #+begin_example
        1. one item
        2. <<target>>another item
        Here we refer to item [[target]].
      #+end_example

    But that is probably intentional or not avoidable.  Probably these
    are even valid Org targets?

Ok, that was more or less cheap criticism.  Or a bug report?  Anyway,
what is more interesting is:

3. When one later visits =org-manual.org=,\\
    and there is a =TAGS= file in that directory,\\
    and =org-ctags= previously has been loaded, then,\\
    by virtue of the following snippet from =org-ctags.el=:

    #+begin_src emacs-lisp
      (add-hook 'org-mode-hook
           (lambda ()
             (when (and org-ctags-enabled-p
                        (buffer-file-name))
               ;; Make sure this file's directory is added to default
               ;; directories in which to search for tags.
               (let ((tags-filename
                      (expand-file-name
                       (concat (file-name-directory (buffer-file-name))
                               "/TAGS"))))
                 (when (file-exists-p tags-filename)
                   (visit-tags-table tags-filename))))))
    #+end_src

    that =TAGS= file gets automatically visited, meaning that future
    tag look-ups with =C-c C-o= do not ask about any tag files to load.

    (Yes, there is again that funny =(expand-file-name (concat ...))=
    pattern used above.)

4. From that and also from the header documentation:

    #+begin_example
      ;; When you click on a link "[[foo]]" and org cannot find a
      ;; matching "<<foo>>" in the current buffer, the tags
      ;; facility will take over.  The file TAGS in the active
                                       ^^^^^^^^^^^^^^^^^^^^^^^
      ;; directory is examined to see if the
         ^^^^^^^^^
      ;; tags facility knows about "<<foo>>" in any other files.
      ;; If it does, the matching file will be opened and the
      ;; cursor will jump to the position of "<<foo>>" in that
      ;; file.
    #+end_example

    I conclude that the whole =org-ctags= functionality is based on the
    assumption that a =TAGS= file lives in the working directory of the
    currently visited Org mode file.  Why not test for that condition
    in the hook functions:

    #+begin_src emacs-lisp
      org-ctags-find-tag
      org-ctags-ask-rebuild-tags-file-then-find-tag
      org-ctags-rebuild-tags-file-then-find-tag
      org-ctags-ask-append-topic
      org-ctags-append-topic
      org-ctags-ask-visit-buffer-or-file
      org-ctags-visit-buffer-or-file
      org-ctags-fail-silently
    #+end_src

    in some way or other, probably also testing variable
    =tags-file-name=, and just skip their execution returning =nil=, if
    the environment does not seem to be ready for a tag search.  Then
    regular link operation would kick in.

Of course, that is all based on educated guesses and ad-hoc poking in
the code, not on long-term usage.  Is there a known user of
=org-ctags= who one could ask?

I think the number of people using =org-ctags= is much smaller than
the number of people not using it, in particular because of the issue
described in the first item.  If above assumption is true and hook
functions get wrapped as indicated, we could keep the former happy
without affecting the latter with unexpected and inexplicable tag file
prompts.

Re: Or probably just fix the org-ctags hook functions?

[Nick Dokos]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> On 2023-08-08  10:48, Ihor Radchenko wrote:
>
> ...
> Probably the problem is not the side-effects done by loading
> =org-ctags=, but rather that these hook function from =org-ctags= try
> to do their job when the environment is not really ready for them,
> i.e. when there is no known tag file around.
> ...

I disagree: the changes are done behind my back in an (almost)
invisible manner and leave me surprised and mystified. Even if there
was a TAGS file around, having links behave differently from one
moment to the next, when the only thing I did in-between was ask for
help on a completely unrelated Org mode function, is a nasty surprise.

-- 
Nick

Re: Or probably just fix the org-ctags hook functions?

[Ihor Radchenko]

Nick Dokos <ndokos@gmail.com> writes:

>> ...
>> Probably the problem is not the side-effects done by loading
>> =org-ctags=, but rather that these hook function from =org-ctags= try
>> to do their job when the environment is not really ready for them,
>> i.e. when there is no known tag file around.
>> ...
>
> I disagree: the changes are done behind my back in an (almost)
> invisible manner and leave me surprised and mystified. Even if there
> was a TAGS file around, having links behave differently from one
> moment to the next, when the only thing I did in-between was ask for
> help on a completely unrelated Org mode function, is a nasty surprise.

Sure, but we should not reject Jens' proposal just because of this
argument. We can use the suggestions to improve org-ctags itself, after
it is explicitly loaded.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Or probably just fix the org-ctags hook functions?

[Nick Dokos]

Ihor Radchenko <yantar92@posteo.net> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>>> ...
>>> Probably the problem is not the side-effects done by loading
>>> =org-ctags=, but rather that these hook function from =org-ctags= try
>>> to do their job when the environment is not really ready for them,
>>> i.e. when there is no known tag file around.
>>> ...
>>
>> I disagree: the changes are done behind my back in an (almost)
>> invisible manner and leave me surprised and mystified. Even if there
>> was a TAGS file around, having links behave differently from one
>> moment to the next, when the only thing I did in-between was ask for
>> help on a completely unrelated Org mode function, is a nasty surprise.
>
> Sure, but we should not reject Jens' proposal just because of this
> argument. We can use the suggestions to improve org-ctags itself, after
> it is explicitly loaded.

Absolutely.

My disagreement was only with the part that I quoted, in particular
the "Probably the problem is not the side-effects done by loading
=org-ctags= ..."  part: from my POV, that is *exactly* the problem
which I would like to see addressed.

-- 
Nick

Re: Or probably just fix the org-ctags hook functions?

[Jens Schmidt]

On 2023-08-11  19:01, Nick Dokos wrote:

>> Sure, but we should not reject Jens' proposal just because of this
>> argument. We can use the suggestions to improve org-ctags itself, after
>> it is explicitly loaded.
> 
> Absolutely.
> 
> My disagreement was only with the part that I quoted, in particular
> the "Probably the problem is not the side-effects done by loading
> =org-ctags= ..."  part: from my POV, that is *exactly* the problem
> which I would like to see addressed.

I was trying to provide some facts that could help deciding on this.
And to find some compromise here that would fit all users and sizes.
More notes and another compromise:

- The general discussion in that other branch about all Org libraries,
   ever, is IMO of general interest but doesn't help users that run into
   this issue in short term.  I'd focus on this single library instead to
   get a fix soon, and not only in main.

- I understand both "no-breaking-changes" and "no-side-effects"
   positions.  Personally, I'd even tend to the "no-side-effects"
   position.

- If you run into this issue, the real pain is to understand what's
   going on, since org-ctags might get loaded in surprising ways.  So
   probably we should make that easier.

How about *not* using the current functions

   `org-ctags-find-tag'
   `org-ctags-ask-rebuild-tags-file-then-find-tag'
   `org-ctags-ask-append-topic'

as default value for `org-ctags-open-link-functions', but rather only
function

   `org-ctags-warn-about-enabling-ctags'

defined as follows:

   (defun org-ctags-warn-about-enabling-ctags (&rest _)
     (warn "You enabled (on purpose or by accident) org-ctags.

   If that was not your intention, or if you really only want to open links
   as you always have been used to, use customize to disable function
   `org-ctags-warn-about-enabling-ctags' in variable
   `org-ctags-open-link-functions'.

   Otherwise, you might want to use customize to disable function
   `org-ctags-warn-about-enabling-ctags' in `org-ctags-open-link-functions'
   and instead enable the previous default functions `org-ctags-find-tag',
   `org-ctags-ask-rebuild-tags-file-then-find-tag', and
   `org-ctags-ask-append-topic'.

   Note that in a future Org version automatic enabling of org-ctags might
   be obsoleted, so consider explicitly enabling it by adding

     (require 'org-ctags)
     (org-ctags-enable)

   to your Emacs initialization file if you actually want to use it.")
     (remove-hook 'org-open-link-functions
                  #'org-ctags-warn-about-enabling-ctags))

The last line would take care about getting this warning at most once
per Emacs session.

In addition redefine function `org-ctags-enable' to add a test on
`org-ctags-open-link-functions' as follows:

   (defun org-ctags-enable ()
     (when org-ctags-open-link-functions
       (put 'org-mode 'find-tag-default-function 
'org-ctags-find-tag-at-point)
       (setq org-ctags-enabled-p t)
       (dolist (fn org-ctags-open-link-functions)
         (add-hook 'org-open-link-functions fn t))))

which makes library loading free of side-effect if variable
org-ctags-open-link-functions equals nil.

That way:

- Users who previously have customized the variable are not affected at
   all by the change.

- All others understand better what's going on and can decide either
   way.  If they decide against org-ctags, and customize the variable
   accordingly, they will have no side-effects from org-ctags in the
   future.

- Any future general solution could resolve this in a more beautiful
   and, um, general way.

Re: Or probably just fix the org-ctags hook functions?

[Ihor Radchenko]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> - If you run into this issue, the real pain is to understand what's
>    going on, since org-ctags might get loaded in surprising ways.  So
>    probably we should make that easier.

The quick fix is unsetting `help-enable-completion-autoload'.

And I do not think that we should be in rush pushing workarounds -
org-ctags has been around for a long time in its existing state.
I'd prefer to first figure out the general policy for such situations.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Or probably just fix the org-ctags hook functions?

[Jens Schmidt]

On 2023-08-11  23:48, Ihor Radchenko wrote:

>> - If you run into this issue, the real pain is to understand what's
>>     going on, since org-ctags might get loaded in surprising ways.  So
>>     probably we should make that easier.
> 
> The quick fix is unsetting `help-enable-completion-autoload'.

Unfortunately, that isn't easy to understand, either.

> And I do not think that we should be in rush pushing workarounds -
> org-ctags has been around for a long time in its existing state.
> I'd prefer to first figure out the general policy for such situations.

Right, but even though org-ctags has been stable, something else *has*
changed that let's this issue pop up now.  For Nick it seems to be the
Emacs version, for me I'm pretty sure the recent upgrade from Org 9.5 to
9.6 in Debian testing, with Emacs unchanged on version 28.

Anyway, probably let's just wait whether more complaints on that will
come in.

Re: [DISCUSSION] Re-design of inlinetasks

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Hi, Adams


In an org block:

- You can't use directly the org-mode keybinding.

- Visually, by default, it is different from the other headlines.

- When exporting, by default, it doesn't seem appropriate for reading.

- When inserting, by default, it is not as easy as inlinetasks are.


I will share a use example I proposed in gptel issues forum.  It seemed 
to me useful for inserting a chatgpt response with Properties, in the 
middle of the text:

https://github.com/karthink/gptel/issues/103#issuecomment-1685196575

*************** OpenAI. (2023). /ChatGPT: I apologize for any confusion/ 
(Ago 20 version). In Conquest of Egypt
:PROPERTIES:
:GPTEL_MODEL: gpt-3.5-turbo
:GPTEL_TOPIC: Conquest of Egypt
:GPTEL_SYSTEM: I want you to act as a historian. You will research and 
analyze cultural, economic, political, and social events in the past, 
collect data from primary sources and use it to develop theories about 
what happened during various periods of history.
:END:
I apologize for any confusion, ...
*************** END


Best regards

[-- Attachment #2: Type: text/html, Size: 2228 bytes --]

[DISCUSSION] Re-design of inlinetasks

[Maske]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Hi

I am sorry, I don't know the appropriate terminology.


Could be used

*************** END

or a different special string, to end any headline scope? Like an "end 
parenthesis" for the headline just above it.

Maybe in this way, all headlines would be the same: if the special 
string appears, the headline scope ends there (inlinetask). If no 
special string, the scope would end before the next headline (or at the 
end of the document).





[-- Attachment #2: Type: text/html, Size: 869 bytes --]

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Maske <maske1foro@gmail.com> writes:

> I am sorry, I don't know the appropriate terminology.
>
>
> Could be used
>
> *************** END

> or a different special string, to end any headline scope? Like an "end 
> parenthesis" for the headline just above it.
> ...
> Maybe in this way, all headlines would be the same: if the special 
> string appears, the headline scope ends there (inlinetask). If no 
> special string, the scope would end before the next headline (or at the 
> end of the document).

This is what we already do. Inlinetasks have two forms:

*********************** Single-line inlinetask

or

*********************** Multi-line inlinetask
With some contents inside
*********************** END

There are 3 problems with this, however:

1. Because inlinetasks are currently optional, a number of people rely
   on ******************* being __always__ a heading. So, we are unable
   to integrate inlinetasks into Org syntax properly.

2. The syntax clash is hard to maintain in the code, leading to subtle
   bugs that are hard to notice and fix.

3. We require no less than 15 stars to define inlinetask, which looks
   ugly.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Ihor Radchenko writes on Sun  3 Sep 2023 07:58:

 > 3. We require no less than 15 stars to define inlinetask, which
 >    looks ugly.

With org-indent-mode, only 2 stars are shown (which I don't find
ugly).  Hence an idea: how about an additional
org-indent-mode-just-for-inlinetasks?, for those who want to keep the
default indentation for regular headlines.

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Alain.Cochard@unistra.fr writes:

> Ihor Radchenko writes on Sun  3 Sep 2023 07:58:
>
>  > 3. We require no less than 15 stars to define inlinetask, which
>  >    looks ugly.
>
> With org-indent-mode, only 2 stars are shown (which I don't find
> ugly).  Hence an idea: how about an additional
> org-indent-mode-just-for-inlinetasks?, for those who want to keep the
> default indentation for regular headlines.

We also do not want things to look ugly in plain text (Org mode is plain
text markup at the end). That's why I listed this point.

But maintainability and compatibility reasons are much more important
practically.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>