* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-12 12:46 ` Bastien Guerry
@ 2023-08-12 22:18 ` Samuel Wales
2023-08-13 8:59 ` Ihor Radchenko
2023-08-14 13:19 ` Fraga, Eric
2023-08-13 8:53 ` [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
` (2 subsequent siblings)
3 siblings, 2 replies; 112+ messages in thread
From: Samuel Wales @ 2023-08-12 22:18 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Ihor Radchenko, Max Nikulin, emacs-orgmode
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
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-12 22:18 ` Samuel Wales
@ 2023-08-13 8:59 ` Ihor Radchenko
2023-08-14 0:57 ` Samuel Wales
2023-08-14 13:19 ` Fraga, Eric
1 sibling, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-13 8:59 UTC (permalink / raw)
To: Samuel Wales; +Cc: Bastien Guerry, Max Nikulin, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-13 8:59 ` Ihor Radchenko
@ 2023-08-14 0:57 ` Samuel Wales
2023-08-14 10:34 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Samuel Wales @ 2023-08-14 0:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Bastien Guerry, Max Nikulin, emacs-orgmode
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-14 0:57 ` Samuel Wales
@ 2023-08-14 10:34 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-14 10:34 UTC (permalink / raw)
To: Samuel Wales; +Cc: Bastien Guerry, Max Nikulin, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-12 22:18 ` Samuel Wales
2023-08-13 8:59 ` Ihor Radchenko
@ 2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
2023-08-22 15:40 ` Russell Adams
1 sibling, 2 replies; 112+ messages in thread
From: Fraga, Eric @ 2023-08-14 13:19 UTC (permalink / raw)
To: Samuel Wales
Cc: Bastien Guerry, Ihor Radchenko, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-14 13:19 ` Fraga, Eric
@ 2023-08-22 15:15 ` Bastien Guerry
2023-08-23 9:33 ` Ihor Radchenko
2023-08-22 15:40 ` Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Bastien Guerry @ 2023-08-22 15:15 UTC (permalink / raw)
To: Fraga, Eric
Cc: Samuel Wales, Ihor Radchenko, Max Nikulin, emacs-orgmode@gnu.org
"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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-22 15:15 ` Bastien Guerry
@ 2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
2023-08-26 8:59 ` Fraga, Eric
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-23 9:33 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-23 9:33 ` Ihor Radchenko
@ 2023-08-24 11:39 ` Bastien Guerry
2023-08-24 11:44 ` Ihor Radchenko
2023-08-26 8:59 ` Fraga, Eric
1 sibling, 1 reply; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 11:39 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 11:39 ` Bastien Guerry
@ 2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:11 ` Russell Adams
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 11:44 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 11:44 ` Ihor Radchenko
@ 2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:11 ` Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 12:08 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:08 ` Bastien Guerry
@ 2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:36 ` Bastien Guerry
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 12:15 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:15 ` Ihor Radchenko
@ 2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 13:23 ` tomas
0 siblings, 2 replies; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 12:36 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:36 ` Bastien Guerry
@ 2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:53 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Russell Adams
2023-08-24 13:23 ` tomas
1 sibling, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 12:40 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:40 ` Ihor Radchenko
@ 2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 12:53 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 12:48 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:48 ` Bastien Guerry
@ 2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:01 ` Russell Adams
2023-08-24 13:02 ` Bastien Guerry
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 12:56 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:56 ` Ihor Radchenko
@ 2023-08-24 13:01 ` Russell Adams
2023-08-24 13:33 ` Ihor Radchenko
2023-08-24 13:02 ` Bastien Guerry
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:01 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:01 ` Russell Adams
@ 2023-08-24 13:33 ` Ihor Radchenko
2023-08-24 13:41 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:33 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:33 ` Ihor Radchenko
@ 2023-08-24 13:41 ` Russell Adams
2023-08-24 13:47 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:41 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:41 ` Russell Adams
@ 2023-08-24 13:47 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:47 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:01 ` Russell Adams
@ 2023-08-24 13:02 ` Bastien Guerry
2023-08-24 13:36 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 13:02 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:02 ` Bastien Guerry
@ 2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 13:43 ` Russell Adams
2023-08-24 14:08 ` Bastien Guerry
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:36 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:36 ` Ihor Radchenko
@ 2023-08-24 13:43 ` Russell Adams
2023-08-25 9:16 ` Ihor Radchenko
2023-08-24 14:08 ` Bastien Guerry
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:43 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:43 ` Russell Adams
@ 2023-08-25 9:16 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:16 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 13:43 ` Russell Adams
@ 2023-08-24 14:08 ` Bastien Guerry
2023-08-25 2:59 ` spookygostee
2023-08-25 9:44 ` [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
1 sibling, 2 replies; 112+ messages in thread
From: Bastien Guerry @ 2023-08-24 14:08 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 14:08 ` Bastien Guerry
@ 2023-08-25 2:59 ` spookygostee
2023-08-25 9:53 ` Ihor Radchenko
2023-08-25 9:44 ` [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
1 sibling, 1 reply; 112+ messages in thread
From: spookygostee @ 2023-08-25 2:59 UTC (permalink / raw)
To: emacs-orgmode
[-- 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.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-25 2:59 ` spookygostee
@ 2023-08-25 9:53 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:53 UTC (permalink / raw)
To: spookygostee; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* [DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)
2023-08-24 14:08 ` Bastien Guerry
2023-08-25 2:59 ` spookygostee
@ 2023-08-25 9:44 ` Ihor Radchenko
2023-08-25 17:58 ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
1 sibling, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:44 UTC (permalink / raw)
To: Bastien Guerry
Cc: Fraga, Eric, Samuel Wales, Max Nikulin, emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-25 9:44 ` [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
@ 2023-08-25 17:58 ` Juan Manuel Macías
2023-08-26 10:58 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-25 17:58 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-25 17:58 ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
@ 2023-08-26 10:58 ` Ihor Radchenko
2023-08-26 11:42 ` Juan Manuel Macías
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-26 10:58 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 10:58 ` Ihor Radchenko
@ 2023-08-26 11:42 ` Juan Manuel Macías
2023-08-26 12:33 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-26 11:42 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 11:42 ` Juan Manuel Macías
@ 2023-08-26 12:33 ` Ihor Radchenko
2023-08-26 14:21 ` Juan Manuel Macías
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-26 12:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 12:33 ` Ihor Radchenko
@ 2023-08-26 14:21 ` Juan Manuel Macías
2023-08-26 16:33 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-26 14:21 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 14:21 ` Juan Manuel Macías
@ 2023-08-26 16:33 ` Ihor Radchenko
2023-08-26 17:31 ` Juan Manuel Macías
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-26 16:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 16:33 ` Ihor Radchenko
@ 2023-08-26 17:31 ` Juan Manuel Macías
2023-08-26 17:43 ` Ihor Radchenko
2023-08-26 18:01 ` Russell Adams
0 siblings, 2 replies; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-26 17:31 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 ` Juan Manuel Macías
@ 2023-08-26 17:43 ` Ihor Radchenko
2023-08-26 19:19 ` Juan Manuel Macías
2023-08-26 18:01 ` Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-26 17:43 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:43 ` Ihor Radchenko
@ 2023-08-26 19:19 ` Juan Manuel Macías
2023-08-27 9:21 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-26 19:19 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 19:19 ` Juan Manuel Macías
@ 2023-08-27 9:21 ` Ihor Radchenko
2023-08-27 17:25 ` Juan Manuel Macías
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-27 9:21 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 9:21 ` Ihor Radchenko
@ 2023-08-27 17:25 ` Juan Manuel Macías
2023-08-31 9:15 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Juan Manuel Macías @ 2023-08-27 17:25 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 17:25 ` Juan Manuel Macías
@ 2023-08-31 9:15 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-31 9:15 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 ` Juan Manuel Macías
2023-08-26 17:43 ` Ihor Radchenko
@ 2023-08-26 18:01 ` Russell Adams
2023-08-29 13:00 ` Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-26 18:01 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 18:01 ` Russell Adams
@ 2023-08-29 13:00 ` Russell Adams
2023-08-30 11:49 ` Alain.Cochard
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-29 13:00 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-29 13:00 ` Russell Adams
@ 2023-08-30 11:49 ` Alain.Cochard
2023-08-30 12:36 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Alain.Cochard @ 2023-08-30 11:49 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 11:49 ` Alain.Cochard
@ 2023-08-30 12:36 ` Russell Adams
2023-08-30 14:06 ` Alain.Cochard
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-30 12:36 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 12:36 ` Russell Adams
@ 2023-08-30 14:06 ` Alain.Cochard
2023-08-30 14:31 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Alain.Cochard @ 2023-08-30 14:06 UTC (permalink / raw)
To: emacs-orgmode
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 ]
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 14:06 ` Alain.Cochard
@ 2023-08-30 14:31 ` Russell Adams
2023-08-30 14:39 ` Alain.Cochard
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-30 14:31 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 14:31 ` Russell Adams
@ 2023-08-30 14:39 ` Alain.Cochard
2023-08-30 15:08 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Alain.Cochard @ 2023-08-30 14:39 UTC (permalink / raw)
To: emacs-orgmode
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 ]
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 14:39 ` Alain.Cochard
@ 2023-08-30 15:08 ` Russell Adams
2023-08-30 15:13 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-30 15:08 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 15:08 ` Russell Adams
@ 2023-08-30 15:13 ` Russell Adams
2023-08-30 18:32 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-30 15:13 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-30 15:13 ` Russell Adams
@ 2023-08-30 18:32 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-30 18:32 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
@ 2023-08-24 12:53 ` Russell Adams
2023-08-24 13:04 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 12:53 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:53 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Russell Adams
@ 2023-08-24 13:04 ` Ihor Radchenko
2023-08-24 13:11 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:04 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:04 ` Ihor Radchenko
@ 2023-08-24 13:11 ` Russell Adams
2023-08-24 13:41 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:11 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:11 ` Russell Adams
@ 2023-08-24 13:41 ` Ihor Radchenko
2023-08-24 13:49 ` Russell Adams
2023-08-24 14:20 ` Russell Adams
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:41 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:41 ` Ihor Radchenko
@ 2023-08-24 13:49 ` Russell Adams
2023-08-25 9:18 ` Ihor Radchenko
2023-08-24 14:20 ` Russell Adams
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:49 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:49 ` Russell Adams
@ 2023-08-25 9:18 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:18 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:41 ` Ihor Radchenko
2023-08-24 13:49 ` Russell Adams
@ 2023-08-24 14:20 ` Russell Adams
1 sibling, 0 replies; 112+ messages in thread
From: Russell Adams @ 2023-08-24 14:20 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
@ 2023-08-24 13:23 ` tomas
2023-08-24 13:29 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: tomas @ 2023-08-24 13:23 UTC (permalink / raw)
To: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:23 ` tomas
@ 2023-08-24 13:29 ` Ihor Radchenko
2023-08-24 13:36 ` Russell Adams
2023-08-24 13:50 ` tomas
0 siblings, 2 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:29 UTC (permalink / raw)
To: tomas; +Cc: emacs-orgmode
<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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:29 ` Ihor Radchenko
@ 2023-08-24 13:36 ` Russell Adams
2023-08-24 13:44 ` Ihor Radchenko
2023-08-24 13:50 ` tomas
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 13:36 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:36 ` Russell Adams
@ 2023-08-24 13:44 ` Ihor Radchenko
2023-08-24 14:00 ` Russell Adams
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 13:44 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:44 ` Ihor Radchenko
@ 2023-08-24 14:00 ` Russell Adams
2023-08-25 2:48 ` spookygostee
2023-08-25 9:52 ` Ihor Radchenko
0 siblings, 2 replies; 112+ messages in thread
From: Russell Adams @ 2023-08-24 14:00 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 14:00 ` Russell Adams
@ 2023-08-25 2:48 ` spookygostee
2023-08-25 9:52 ` Ihor Radchenko
1 sibling, 0 replies; 112+ messages in thread
From: spookygostee @ 2023-08-25 2:48 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 14:00 ` Russell Adams
2023-08-25 2:48 ` spookygostee
@ 2023-08-25 9:52 ` Ihor Radchenko
1 sibling, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:52 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:29 ` Ihor Radchenko
2023-08-24 13:36 ` Russell Adams
@ 2023-08-24 13:50 ` tomas
2023-08-25 9:49 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: tomas @ 2023-08-24 13:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 13:50 ` tomas
@ 2023-08-25 9:49 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:49 UTC (permalink / raw)
To: tomas; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
@ 2023-08-24 12:11 ` Russell Adams
2023-08-24 12:21 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-24 12:11 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:11 ` Russell Adams
@ 2023-08-24 12:21 ` Ihor Radchenko
2023-08-24 14:43 ` Max Nikulin
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-24 12:21 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 12:21 ` Ihor Radchenko
@ 2023-08-24 14:43 ` Max Nikulin
2023-08-24 23:07 ` Samuel Wales
0 siblings, 1 reply; 112+ messages in thread
From: Max Nikulin @ 2023-08-24 14:43 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 14:43 ` Max Nikulin
@ 2023-08-24 23:07 ` Samuel Wales
2023-08-24 23:23 ` Samuel Wales
2023-08-25 9:56 ` Ihor Radchenko
0 siblings, 2 replies; 112+ messages in thread
From: Samuel Wales @ 2023-08-24 23:07 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 23:07 ` Samuel Wales
@ 2023-08-24 23:23 ` Samuel Wales
2023-08-24 23:24 ` Samuel Wales
2023-08-25 9:56 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: Samuel Wales @ 2023-08-24 23:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
[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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 23:23 ` Samuel Wales
@ 2023-08-24 23:24 ` Samuel Wales
2023-08-25 9:56 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Samuel Wales @ 2023-08-24 23:24 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-24 23:07 ` Samuel Wales
2023-08-24 23:23 ` Samuel Wales
@ 2023-08-25 9:56 ` Ihor Radchenko
1 sibling, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-25 9:56 UTC (permalink / raw)
To: Samuel Wales; +Cc: Max Nikulin, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
@ 2023-08-26 8:59 ` Fraga, Eric
2023-08-26 12:30 ` Ihor Radchenko
1 sibling, 1 reply; 112+ messages in thread
From: Fraga, Eric @ 2023-08-26 8:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Bastien Guerry, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-26 8:59 ` Fraga, Eric
@ 2023-08-26 12:30 ` Ihor Radchenko
2023-08-27 13:16 ` Fraga, Eric
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-26 12:30 UTC (permalink / raw)
To: Fraga, Eric; +Cc: Bastien Guerry, emacs-orgmode@gnu.org
"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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-26 12:30 ` Ihor Radchenko
@ 2023-08-27 13:16 ` Fraga, Eric
0 siblings, 0 replies; 112+ messages in thread
From: Fraga, Eric @ 2023-08-27 13:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Bastien Guerry, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
@ 2023-08-22 15:40 ` Russell Adams
1 sibling, 0 replies; 112+ messages in thread
From: Russell Adams @ 2023-08-22 15:40 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread
* [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?)
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
@ 2023-08-13 8:53 ` Ihor Radchenko
2023-08-13 9:33 ` [DISCUSSION] The future of org-mouse.el and org-inlinetask.el Bastien Guerry
2023-08-14 7:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Tom Gillespie
2023-08-15 14:10 ` Timothy
3 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-13 8:53 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Max Nikulin, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
2023-08-13 8:53 ` [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
@ 2023-08-14 7:48 ` Tom Gillespie
2023-08-15 14:10 ` Timothy
3 siblings, 0 replies; 112+ messages in thread
From: Tom Gillespie @ 2023-08-14 7:48 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Ihor Radchenko, Max Nikulin, emacs-orgmode
> 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).
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-12 12:46 ` Bastien Guerry
` (2 preceding siblings ...)
2023-08-14 7:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Tom Gillespie
@ 2023-08-15 14:10 ` Timothy
2023-08-15 14:38 ` Russell Adams
3 siblings, 1 reply; 112+ messages in thread
From: Timothy @ 2023-08-15 14:10 UTC (permalink / raw)
To: Bastien Guerry, Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-15 14:10 ` Timothy
@ 2023-08-15 14:38 ` Russell Adams
2023-08-15 15:21 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Russell Adams @ 2023-08-15 14:38 UTC (permalink / raw)
To: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-15 14:38 ` Russell Adams
@ 2023-08-15 15:21 ` Ihor Radchenko
2023-08-15 18:58 ` Tom Gillespie
0 siblings, 1 reply; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-15 15:21 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-15 15:21 ` Ihor Radchenko
@ 2023-08-15 18:58 ` Tom Gillespie
2023-08-16 10:24 ` Ihor Radchenko
0 siblings, 1 reply; 112+ messages in thread
From: Tom Gillespie @ 2023-08-15 18:58 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Russell Adams, emacs-orgmode
> 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.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
2023-08-15 18:58 ` Tom Gillespie
@ 2023-08-16 10:24 ` Ihor Radchenko
0 siblings, 0 replies; 112+ messages in thread
From: Ihor Radchenko @ 2023-08-16 10:24 UTC (permalink / raw)
To: Tom Gillespie; +Cc: Russell Adams, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 112+ messages in thread