Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

I understand your view. From the user perspective inline task are still
more a specialization of a task, which is a specialisation of a heading.

Here is my implementation of how I see it that it should behave:
(defun pm-cut-special ()
  "Like org-cut-special but also works on inlinetask."
  (interactive)
  (if (not (eq 'inlinetask (save-excursion (org-back-to-heading t)
(org-element-type (org-element-context)
  (funcall-interactively 'org-cut-special)
(org-inlinetask-goto-beginning)
(let ((begin (point)))
  (org-inlinetask-goto-end)
  (kill-region begin (point))
  (message "Cut: Inline Task"

(defun pm-copy-special ()
  "Like org-copy-special but also works on inlinetask."
  (interactive)
  (if (not (eq 'inlinetask (save-excursion (org-back-to-heading t)
(org-element-type (org-element-context)
  (funcall-interactively 'org-cut-special)
(org-inlinetask-goto-beginning)
(let ((begin (point)))
  (org-inlinetask-goto-end)
  (copy-region-as-kill begin (point))
  (message "Copied: Inline Task"

(defun pm-paste-special (arg)
  "Like org-paste-special but also works on inlinetask."
  (interactive "P")
  (if (not (eq 'inlinetask
   (with-temp-buffer
 (org-mode)
 (insert (current-kill 0 t))
 (goto-char (point-min))
 (org-element-type (org-element-context)
  (funcall-interactively 'org-paste-special arg)
(unless (eq (point) (pos-bol))
  (forward-line))
(yank)))

There is a fine-tuning outstanding: The criteria whether to paste before or
after the current line should not be the point on the begin-of-line but the
beginning of the actual heading (after the asterisks).



Am Do., 17. Aug. 2023 um 13:30 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I probably mis-interpreted the code. Because then I would also fail for
> > normal headings. Just thinking about the symptoms I think the issue Is
> that
> > (org-end-of-subtree) works with type 'headline. And inlinetask is a
> > different type, right?
>
> Yes. Inlinetask is not considered a subtree of its own.
> Just like other foldable elements (lists/drawers/blocks) are not
> considered subtrees.
>
> > IMO org-mode should consistently treat inlinetasks including the END line
> > as a branch. Then org-cut-special would do something useful on them, i.e.
> > cutting the inlinetask includinging its contents and the END line.
>
> It would not be consistent. We already do not treat, for example, lists
> special in `org-cut-special'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

I probably mis-interpreted the code. Because then I would also fail for
normal headings. Just thinking about the symptoms I think the issue Is that
(org-end-of-subtree) works with type 'headline. And inlinetask is a
different type, right?

IMO org-mode should consistently treat inlinetasks including the END line
as a branch. Then org-cut-special would do something useful on them, i.e.
cutting the inlinetask includinging its contents and the END line.

Am Do., 17. Aug. 2023 um 10:42 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> I looked directly into the code and I think I found the issue:
> (org-copy-subtree) calls (org-end-of-subtree) without providing an
> element. But without an element this function just jumps to (point-max).
> I would expect a different behavior or (org-end-of-subtree). Since element
> is optional it should take the element at point.
>
>
> Am Mi., 16. Aug. 2023 um 18:02 Uhr schrieb Ihor Radchenko <
> yanta...@posteo.net>:
>
>> Michael Dauer  writes:
>>
>> > No. Here also * h2 gets killed by org-cut-special.
>>
>> You may need to pull the latest main.
>>
>> > What is REPRO_ARGS? org-onlinetask.el is included org repo anyway?
>>
>> See https://orgmode.org/manual/Feedback.html#Feedback
>> REPRO_ARGS are just extra arguments passed to Emacs when opening it in a
>> clean environment in current Org git repo.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

I looked directly into the code and I think I found the issue:
(org-copy-subtree) calls (org-end-of-subtree) without providing an element.
But without an element this function just jumps to (point-max).
I would expect a different behavior or (org-end-of-subtree). Since element
is optional it should take the element at point.


Am Mi., 16. Aug. 2023 um 18:02 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > No. Here also * h2 gets killed by org-cut-special.
>
> You may need to pull the latest main.
>
> > What is REPRO_ARGS? org-onlinetask.el is included org repo anyway?
>
> See https://orgmode.org/manual/Feedback.html#Feedback
> REPRO_ARGS are just extra arguments passed to Emacs when opening it in a
> clean environment in current Org git repo.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

No. Here also * h2 gets killed by org-cut-special.

What is REPRO_ARGS? org-onlinetask.el is included org repo anyway?

Ihor Radchenko  schrieb am Mi., 16. Aug. 2023, 14:11:

> Michael Dauer  writes:
>
> > Put the point on the second line - the inlinetask "ilt".
>
> I tried the following:
>
> 1. make repro REPRO_ARGS="/tmp/bug.org"
> 2. Move to **... ilt line
>
> * h1
> *** ilt
> *** END
> ** h11
> * h2
>
>
> 3. M-x org-cut-special
>
> * h1
> *** END
> ** h11
> * h2
>
> As expected.
>
> Then, I also tried
>
> 1. make repro REPRO_ARGS="-l org-inlinetask /tmp/bug.org"
> 2. Move to **... ilt line
>
> * h1
> *** ilt
> *** END
> ** h11
> * h2
>
>
> 3. M-x org-cut-special
>
> * h1
> * h2
>
> Is it what you are seeing?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

Put the point on the second line - the inlinetask "ilt".

Am Mi., 16. Aug. 2023 um 13:47 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> >>>>
> > * h1
> > *** ilt
> > *** END
> > ** h11
> > * h2
> > <<<
> > org-cut-special somewhere on the send line kills all but the first line.
>
> I am unable to reproduce.
> May you please provide more detailed steps?
> In particular, which line are you referring to?
>
> --
> 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>
>

BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

>>>
* h1
*** ilt
*** END
** h11
* h2
<<<
org-cut-special somewhere on the send line kills all but the first line.

Org mode version 9.7-pre (release_9.6.7-594-gf03b83
I don't think that this bug existed in the previous versions.

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

Maybe it helps to share you other fix there?

Am Mi., 9. Aug. 2023 um 11:14 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> I don't know how to get swiper activated in a "clean" manner from there.
> In my operational set-up everything is based on straight.
>
> But anyhow it seems to be a known issue in the swiper community:
> https://github.com/abo-abo/swiper/issues/3015
>
> Am Di., 8. Aug. 2023 um 19:09 Uhr schrieb Ihor Radchenko <
> yanta...@posteo.net>:
>
>> Michael Dauer  writes:
>>
>> > The issue is still easy to reproduce:
>> >>>>
>> > * h1
>> > a
>> > * h2
>> > b
>> > * h3
>> > b
>> > * h4
>> > c
>> > <<<
>> > Fold all. On * h1 call swiper-isearch, enter bbb and select the first
>> > match. -> h2 cannot be unfold anymore.
>> > If you repeat it and select the second match then h3 cannot be unfold
>> > anymore, but h2 works again.
>> > (org-fold-core--clear-isearch-overlays) still fixes the buffer.
>>
>> Sorry, but I cannot reproduce.
>> May you please provide more detailed steps starting from emacs -Q?
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

I don't know how to get swiper activated in a "clean" manner from there. In
my operational set-up everything is based on straight.

But anyhow it seems to be a known issue in the swiper community:
https://github.com/abo-abo/swiper/issues/3015

Am Di., 8. Aug. 2023 um 19:09 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > The issue is still easy to reproduce:
> >>>>
> > * h1
> > a
> > * h2
> > b
> > * h3
> > b
> > * h4
> > c
> > <<<
> > Fold all. On * h1 call swiper-isearch, enter bbb and select the first
> > match. -> h2 cannot be unfold anymore.
> > If you repeat it and select the second match then h3 cannot be unfold
> > anymore, but h2 works again.
> > (org-fold-core--clear-isearch-overlays) still fixes the buffer.
>
> Sorry, but I cannot reproduce.
> May you please provide more detailed steps starting from emacs -Q?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

The issue is still easy to reproduce:
>>>
* h1
a
* h2
b
* h3
b
* h4
c
<<<
Fold all. On * h1 call swiper-isearch, enter bbb and select the first
match. -> h2 cannot be unfold anymore.
If you repeat it and select the second match then h3 cannot be unfold
anymore, but h2 works again.
(org-fold-core--clear-isearch-overlays) still fixes the buffer.

Am Fr., 4. Aug. 2023 um 16:11 Uhr schrieb William Denton :

> On 4 August 2023, Michael Dauer wrote:
>
> > I'm on main (Org mode version 9.7-pre (release_9.6.7-594-gf03b83), and
> it's
> > not fixed. Am I missing something?
>
> The fix did fix it for me, and the problem went away.  It did seem to
> introduce
> a new problem with searching in a buffer with Swiper, where the search
> would
> fail or throw an error or require me to collapse headings before it would
> work,
> but that hasn't happened in a while and I didn't try to debug it.
>
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
> CO₂: 421.92 ppm (Mauna Loa Observatory, 2023-08-03)

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

I'm on main (Org mode version 9.7-pre (release_9.6.7-594-gf03b83), and it's
not fixed. Am I missing something?

Am Do., 1. Juni 2023 um 13:33 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I think I found a way to consistently reproduce the issue:
> > ...
>
> Thanks!
> I now came up with another, more reliable, workaround.
> Since `query-replace', evil, and swiper all arrange the call of
> `isearch-clean-overlays', I can advice it to make sure that we clean
> everything at the end.
>
> Fixed, hopefully, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7dee2c07f
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-protocol broken

[Michael Dauer]

Sorry, my mistake. >>>org-protocol://store-link?url=foo=bar<<< works.

Am Di., 1. Aug. 2023 um 15:38 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> Just look at the first examples, which are 1-to-1 copied from org-protocol
> code/documentation.
>
> org-protocol://store-link?url=foo=bar
> is not working. And this is exactly what store-link is for.
>
> Am Di., 1. Aug. 2023 um 14:01 Uhr schrieb Ihor Radchenko <
> yanta...@posteo.net>:
>
>> Michael Dauer  writes:
>>
>> > emacsclient "org-protocol://store-link?url=http:123=t: w: q -
>> r-s
>> > (a)"
>> > shows *ERROR*: Wrong type argument: arrayp, nil
>> >
>> > IMO the last example is a fully plausible link. I actually need it to
>> > create a link which then calsl e.g. the outlook protocol.
>>
>> "&" in title is ambiguous - it interferes with "&" in the protocol URI
>> scheme. You need to URL-encode "&" to escape the "&" that are actually
>> parts of key values.
>>
>> > ~2 months ago the same links worked fine.
>>
>> We did not have any significant changes in org-protocol for years.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>

Re: BUG: org-protocol broken

[Michael Dauer]

Just look at the first examples, which are 1-to-1 copied from org-protocol
code/documentation.

org-protocol://store-link?url=foo=bar
is not working. And this is exactly what store-link is for.

Am Di., 1. Aug. 2023 um 14:01 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > emacsclient "org-protocol://store-link?url=http:123=t: w: q - r-s
> > (a)"
> > shows *ERROR*: Wrong type argument: arrayp, nil
> >
> > IMO the last example is a fully plausible link. I actually need it to
> > create a link which then calsl e.g. the outlook protocol.
>
> "&" in title is ambiguous - it interferes with "&" in the protocol URI
> scheme. You need to URL-encode "&" to escape the "&" that are actually
> parts of key values.
>
> > ~2 months ago the same links worked fine.
>
> We did not have any significant changes in org-protocol for years.
>
> --
> 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>
>

BUG: org-protocol broken

[Michael Dauer]

Org mode version 9.7-pre (release_9.6.4-327-gf81ba4

org-protocol://store-link?url=http:%2F%2Flocalhost%2Findex.html=The%20title
stores http://localhost/index.html

org-protocol://store-link?url=val=val2
stores val

org-protocol://store-link?url=val?key2=val2
stores val?key2

org-protocol://store-link?url=val?key2?val2
stores val?key2?val2

org-protocol://store-link?url=http:123=t: w: q - r-s (a)
stores nothing

emacsclient "org-protocol://store-link?url=http:123=t: w: q - r-s
(a)"
shows *ERROR*: Wrong type argument: arrayp, nil

IMO the last example is a fully plausible link. I actually need it to
create a link which then calsl e.g. the outlook protocol.

~2 months ago the same links worked fine.

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

I think I found a way to consistently reproduce the issue:
>>>
* h1
a
* h2
b
* h3
b
* h4
c
<<<
Collapse all. All is fine at this time.
At pos-min call (query-replace) bbb -> zzz: Already when asking whether to
replace it cannot expand. h2 and h3 are expansion is broken.
(org-fold-core--clear-isearch-overlays) repairs it.
At pos-max (query-replace) bbb -> zzz does not find a match, and does not
break the expansion.


Am Do., 11. Mai 2023 um 11:47 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> William Denton  writes:
>
> >> Does it also help if you run M-:
> (org-fold-core--clear-isearch-overlays)?
> >
> > That worked!  I just had the problem.  I ran that, and the tree popped
> open!
>
> Do you use evil-mode?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: BUG: (org-insert-subheading) fails when on true begin of line (first star) of heading

[Michael Dauer]

I understand that it's behavior is derived from org-insert-heading. But IMO
that does not make sense for this function, advice all that it is taking
the current indentation level as basis to devote the new heading as child
of the previous heading. It e.g. created a "orphan" grand child instead of
a child.

Not important for me, just strangely non-intuitive.

Ihor Radchenko  schrieb am Do., 11. Mai 2023, 12:11:

> Michael Dauer  writes:
>
> > Example
> > * h1
> > <>** h11
> >
> > brings:
> > * h1
> > *** <>
> > ** h11
>
> This is expected. `org-insert-subheading' inherits what
> `org-insert-heading' does:
>
> Insert a new heading or an item with the same depth at point.
>
> ***
> If point is at the beginning of a heading, insert a new heading
> or a new headline above the current one.  When at the beginning
> of a regular line of text, turn it into a heading.
> ***
>
> If point is in the middle of a line, split it and create a new
> headline with the text in the current line after point (see
> org-M-RET-may-split-line on how to modify this behavior).  As
> a special case, on a headline, splitting can only happen on the
> title itself.  E.g., this excludes breaking stars or tags.
>
> With a C-u prefix, set org-insert-heading-respect-content to
> a non-nil value for the duration of the command.  This forces the
> insertion of a heading after the current subtree, independently
> on the location of point.
>
> With a C-u C-u prefix, insert the heading at the end of the tree
> above the current heading.  For example, if point is within a
> 2nd-level heading, then it will insert a 2nd-level heading at
> the end of the 1st-level parent subtree.
>
> --
> 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>
>

BUG: (org-insert-subheading) fails when on true begin of line (first star) of heading

[Michael Dauer]

Example
* h1
<>** h11

brings:
* h1
*** <>
** h11

expected:
* h1
** h11
*** <>

Org mode version 9.7-pre (release_9.6.4-327-gf81ba4

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

Just another check on my side for any appearance of "org-fold-": Nothing in
my code, only org related packages use it.

$ grep -r -l org-fold- .
./org/.git/index
./org/doc/org-manual.org
./org/etc/ORG-NEWS
./org/lisp/ob-core.el
./org/lisp/ob-exp.el
./org/lisp/ob-lilypond.el
./org/lisp/ob-ref.el
./org/lisp/ol.el
./org/lisp/org-agenda.el
./org/lisp/org-archive.el
./org/lisp/org-capture.el
./org/lisp/org-clock.el
./org/lisp/org-colview.el
./org/lisp/org-compat.el
./org/lisp/org-crypt.el
./org/lisp/org-cycle.el
./org/lisp/org-element.el
./org/lisp/org-feed.el
./org/lisp/org-fold-core.el
./org/lisp/org-fold.el
./org/lisp/org-footnote.el
./org/lisp/org-goto.el
./org/lisp/org-id.el
./org/lisp/org-inlinetask.el
./org/lisp/org-keys.el
./org/lisp/org-lint.el
./org/lisp/org-list.el
./org/lisp/org-loaddefs.el
./org/lisp/org-loaddefs.el~
./org/lisp/org-macs.el
./org/lisp/org-mobile.el
./org/lisp/org-mouse.el
./org/lisp/org-refile.el
./org/lisp/org-src.el
./org/lisp/org-table.el
./org/lisp/org.el
./org/lisp/ox-org.el
./org/lisp/ox.el
./org/testing/lisp/test-org-fold.el
./org/testing/lisp/test-org-list.el
./org/testing/lisp/test-org.el


Am Di., 9. Mai 2023 um 09:58 Uhr schrieb Thomas S. Dye :

>
> Ihor Radchenko  writes:
>
> > "Thomas S. Dye"  writes:
> >
> >>> You can try
> >>> M-x debug-on-variable-change  org-fold-core-style 
> >>
> >> In case it's helpful, I set debug-on-variable-change as you
> >> suggested but was bitten by the bug without triggering the
> >> debugger.
> >
> > Which likely means that something is calling folding functions
> > from
> > outline.el instead of Org-native folding.
>
> Excellent!
>
> Would it be useful for me to search for calls to the folding
> functions from outline.el in the source code of the Org packages
> that Spacemacs and I load?
>
> If so, tips on how to do this efficiently are welcome.
>
> All the best,
> Tom
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

What could be called. It's not org-fold-core-style.

Can I be just a data corruption of the text properties? I've no idea what
they are exactly, and what other parts use them. Maybe a conflicting key,
or failed optimization, or side effect on the regions they apply to. I just
want to give ideas from somebody who is free of knowledge.

My guess is that the issue is within org-mode. But tell us, what functions
we should look for in our code and the used packages.

Am Di., 9. Mai 2023 um 08:23 Uhr schrieb Ihor Radchenko :

> "Thomas S. Dye"  writes:
>
> >> You can try
> >> M-x debug-on-variable-change  org-fold-core-style 
> >
> > In case it's helpful, I set debug-on-variable-change as you
> > suggested but was bitten by the bug without triggering the
> > debugger.
>
> Which likely means that something is calling folding functions from
> outline.el instead of Org-native folding.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

I'm not doing anything with org-fold-core-style directly. The only maybe
relevant thing I do after (org-mode) is:
(straight-use-package 'org-modern)
(global-org-modern-mode)
(setq org-pretty-entities t)
(setq org-pretty-entities-include-sub-superscripts nil)
(setq org-ellipsis "…")
(setq org-modern-hide-stars nil) ; somehow fixes indentation of body

And I think that I can only do it after loading org-mode.

Am Sa., 6. Mai 2023 um 09:36 Uhr schrieb Ihor Radchenko :

> Michael Dauer  writes:
>
> > This sibling branch works:
> > Text content at position 27007:
> >
> >
> > There are text properties here:
> >   fontifiedt
> >   isearch-open-invisible org-fold-core--isearch-show
> >   isearch-open-invisible-temporary org-fold-core--isearch-show-temporary
> >   org-fold--spec-org-fold-outline-1035805047878762682 org-fold-outline
>
> If you have both Org fold overlay and text properties at the same time,
> you are doing something funny with `org-fold-core-style'. If you do set
> it, please only do it before Org is loaded.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

This sibling branch works:
Text content at position 27007:


There are text properties here:
  fontifiedt
  isearch-open-invisible org-fold-core--isearch-show
  isearch-open-invisible-temporary org-fold-core--isearch-show-temporary
  org-fold--spec-org-fold-outline-1035805047878762682 org-fold-outline

Am Sa., 6. Mai 2023 um 09:18 Uhr schrieb Michael Dauer :

> Got another observation:
> Text content at position 30248:
>
>
> There is an overlay here:
>  From 30248 to 30442
>   evaporatet
>   invisibleorg-fold-outline
>   isearch-open-invisible delete-overlay
>   org-invisibleorg-fold-outline
>   priority 5
>
>
> There are text properties here:
>   fontifiedt
>   isearch-open-invisible org-fold-core--isearch-show
>   isearch-open-invisible-temporary org-fold-core--isearch-show-temporary
>
> Am Sa., 6. Mai 2023 um 08:24 Uhr schrieb Ihor Radchenko <
> yanta...@posteo.net>:
>
>> "Christopher M. Miles"  writes:
>>
>> > I meet an unfold-able headline now. Then I record a video to show this
>> > unfold-able headline. I executed command "describe-text-properties".
>>
>> Please put the cursor right before the fold ("..."), execute M-x
>> describe-text-properties and share the properties description text.
>> You don't need video to share the property details buffer contents.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

Got another observation:
Text content at position 30248:


There is an overlay here:
 From 30248 to 30442
  evaporatet
  invisibleorg-fold-outline
  isearch-open-invisible delete-overlay
  org-invisibleorg-fold-outline
  priority 5


There are text properties here:
  fontifiedt
  isearch-open-invisible org-fold-core--isearch-show
  isearch-open-invisible-temporary org-fold-core--isearch-show-temporary

Am Sa., 6. Mai 2023 um 08:24 Uhr schrieb Ihor Radchenko :

> "Christopher M. Miles"  writes:
>
> > I meet an unfold-able headline now. Then I record a video to show this
> > unfold-able headline. I executed command "describe-text-properties".
>
> Please put the cursor right before the fold ("..."), execute M-x
> describe-text-properties and share the properties description text.
> You don't need video to share the property details buffer contents.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

This is with the cursor on the first asterisk:
Text content at position 299:


There are text properties here:
  display  [Show]
  face org-level-1
  fontifiedt

I could not test more positions because I accidentally cut it, and even an
undo fixed it. I would have to wait until it happens again.

Am Fr., 5. Mai 2023 um 19:43 Uhr schrieb Ihor Radchenko :

> Michael Dauer  writes:
>
> > Based on my analyses it's not the cycle functions, but must come from
> > broken text attributes. Even (org-fold-core-region (point-min)
> (point-max)
> > nil) does not unfold the affected subtrees then. Assuming that
> > (org-fold-core-region) is the only place where the folding and
> > hiding happens, I expect the problem there. But I understand too little
> > about the emacs internals to debug this function.
>
> May you please put a point right before the problematic fold, run
> M-x describe-text-properties , and share the contents of the newly
> displayed buffer listing all the text properties?
>
> --
> 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>
>

BUG: org-cycle does not unfold some subtrees

[Michael Dauer]

Maybe I missed a known bug when doing the research. But all the other
reports describe different and reproducible behaviour.

Sometimes (often) I cannot unfold a subtree. It then affects only one or
more subtrees while others in the same buffer or even the same branch still
work. The only fix then is to either cut and paste the affected branches,
or to close and reopen the file.

While quite frequent I have not achieved to reproduce the issue. It just
happens after a while of using multiple files navigating with search, tab
from agenda, org-refile, and cycle.

Based on my analyses it's not the cycle functions, but must come from
broken text attributes. Even (org-fold-core-region (point-min) (point-max)
nil) does not unfold the affected subtrees then. Assuming that
(org-fold-core-region) is the only place where the folding and
hiding happens, I expect the problem there. But I understand too little
about the emacs internals to debug this function.

I hope this helps to fix the issue.

Org mode version 9.7-pre (release_9.6.4-327-gf81ba4

Re: (org-element-parse-buffer) and (org-with-wide-buffer)

[Michael Dauer]

Yes, but the missing headings are within the narrowed subtree.

Am Mi., 11. Jan. 2023 um 12:22 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > But within (org-with-wide-buffer) the collapsed branches should be
> visible.
>
> You have `org-narrow-to-subtree' inside `org-with-wide-buffer':
> 1. `org-with-wide-buffer' widens the buffer
> 2. `org-narrow-to-subtree' narrows it to subtree
> 3. `org-element-parse-buffer' gets executed on the narrowed buffer
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: (org-element-parse-buffer) and (org-with-wide-buffer)

[Michael Dauer]

But within (org-with-wide-buffer) the collapsed branches should be visible.

Ihor Radchenko  schrieb am Mi., 11. Jän. 2023, 11:02:

> Michael Dauer  writes:
>
> > I would expect both output rows to be identical. But it seems
> > that (org-with-wide-buffer) has no effect on (org-element-parse-buffer)
> > with VISIBLE-ONLY argument.
>
> > While I believe this is a bug, I would also appreciate hearing about
> > possible work-arounds.
>
> This behaviour is documented in the docstring of
> `org-element-parse-buffer':
>
> If narrowing is in effect, only parse the visible part of the
> buffer.
>
> --
> 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>
>

(org-element-parse-buffer) and (org-with-wide-buffer)

[Michael Dauer]

I see a potential bug here: (org-element-parse-buffer) with VISIBLE-ONLY
does not include regions made visible with (org-with-wide-buffer).

Test (Have h2.2.1 collapsed before running it.):
>>>
* h1
** h2
*** h2.1
*** h2.2
#+begin_src elisp
(org-with-wide-buffer
 (org-narrow-to-subtree)
 (goto-char (point-min))
 (list
  (--map (cadr it)
 (s-match-strings-all "^\\*+ \\(.*\\)$"
  (buffer-substring-no-properties
   (point-min) (point-max
  (org-element-map (caddr (org-element-parse-buffer 'object t)) 'headline
(lambda (it) (org-element-property :raw-value it
)
#+end_src

#+RESULTS:
| h2.2 | h2.2.1 | h2.2.1.1 |
| h2.2 | h2.2.1 |  |

 h2.2.1
* h2.2.1.1
a
*** h2.3
* h3
<<<

I would expect both output rows to be identical. But it seems
that (org-with-wide-buffer) has no effect on (org-element-parse-buffer)
with VISIBLE-ONLY argument.

While I believe this is a bug, I would also appreciate hearing about
possible work-arounds.

thx

Re: Expand macros in links

[Michael Dauer]

Agree. How do you run such feature polls?

Ihor Radchenko  schrieb am Di., 27. Dez. 2022, 17:20:

> Michael Dauer  writes:
>
> > I'm aware of this theoretical conflict. But I see the risk as very low
> > compared to the value of not having to make a lot of customizations for
> > export and internal link handling. It should just work out of the box.
>
> Even low risk does not justify impossible-to-use links when such problem
> occurs.
>
> > If you deem necessary there would still be the possibility to define a
> > global switch for this. This could then still have the 100% save default,
> > while still being easy to "configure".
>
> > If you want to go so far you could mitigate the risk of a conflict by
> > "escaping" the macro brackets. {{not-a-macro}} would be treated
> as
> > {{{not-a-marco}}} without expansion. Or any other escape sequence to
> bring
> > the conflict probability to 0.001.
>
> This is all indeed possible. The main question if whether it is
> justified to introduce all these complexities given the provided
> alternatives.
>
> Basically, we need more votes in favour to consider such feature.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: Expand macros in links

[Michael Dauer]

I'm aware of this theoretical conflict. But I see the risk as very low
compared to the value of not having to make a lot of customizations for
export and internal link handling. It should just work out of the box.

If you deem necessary there would still be the possibility to define a
global switch for this. This could then still have the 100% save default,
while still being easy to "configure".

If you want to go so far you could mitigate the risk of a conflict by
"escaping" the macro brackets. {{not-a-macro}} would be treated as
{{{not-a-marco}}} without expansion. Or any other escape sequence to bring
the conflict probability to 0.001.

Am Di., 27. Dez. 2022 um 16:51 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I mean something like:
> > * Heading
> > [[http:abc{{{input-file}}}]
> >
> > When exporting it to html then the link is not replaced.
>
> This is to be expected, and I do think that Org is doing it right by not
> replacing macros in links.
>
> You cannot exactly control what is inside link path - if an actual
> website link happens to contain {{{...}}} pattern, you will have no
> options left how to prevent Org from replacing that pattern.
>
> If you want to generate link paths programmatically, you can instead
> define custom links types or link abbreviations. See
> https://orgmode.org/manual/Link-Abbreviations.html and
> https://orgmode.org/manual/Adding-Hyperlink-Types.html
>
> You can control custom link export as well.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: Expand macros in links

[Michael Dauer]

I mean something like:
* Heading
[[http:abc{{{input-file}}}]

When exporting it to html then the link is not replaced.

I'm talking about expansion when exporting.

But I also implemented macro expansion for following links within emacs
quite a while ago. Different story but also very powerful especially for
action links and deep links into other applications.


Am Di., 27. Dez. 2022 um 16:30 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I do not understand why links are excluded from macro expansion. I would
> > see it as very valuable to have macros for links too.
>
> Are they? Could you please provide an example?
>
> --
> 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>
>

Expand macros in links

[Michael Dauer]

Hi,

I do not understand why links are excluded from macro expansion. I would
see it as very valuable to have macros for links too.

The change would be as simple as inserting
(eq type 'link)
into org-macro-replace-all.

May I recommend this patch.

Thanks,
Michael

Re: BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Michael Dauer]

It's this fixed? How can I track myself?

Ihor Radchenko  schrieb am Mo., 17. Okt. 2022, 15:11:

> Michael Dauer  writes:
>
> > Org mode version 9.5.5 (9.5.5-geeae6e
> >
> > #+CALL: test1()
> >
> > #+RESULTS:
> > : 1
> >
> > #+CALL: test2()
> >
> > Fails with: Format specifier doesn’t match argument type
> >
> > * Test
> > #+name: test1
> > #+begin_src elisp
> > 1
> > #+end_src
> > #+NAME: test2
> > #+begin_src elisp
> > (org-sbe "test1")
> > #+end_src
>
> Thanks for reporting.
> Confirmed.
>
> Timothy, it is caused by your
>
> 392ccbbf5d450ad47cd5952ed2f4ef35e454648e
> Author: TEC 
> ob-core: Display position of executed babel blocks
>
> (nth 5 info) is nil in the above scenario.
>
> Could you please take a look?
>
> I can "fix" this by using "%S" formatter, but maybe we can do better?
>
> --
> 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>
>

BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Michael Dauer]

Org mode version 9.5.5 (9.5.5-geeae6e

#+CALL: test1()

#+RESULTS:
: 1

#+CALL: test2()

Fails with: Format specifier doesn’t match argument type

* Test
#+name: test1
#+begin_src elisp
1
#+end_src
#+NAME: test2
#+begin_src elisp
(org-sbe "test1")
#+end_src

BUG: (org-up-element) does not work from inlinetask

[Michael Dauer]

(org-up-element) does not jump up when cursor is on inlinetask.
 From within the inlinetask it jumps to the inlinetask heading, but from
there not higher in the hierarchy.

Org mode version 9.5.5 (9.5.5-geeae6e

Re: Issue with export of inlinetasks

[Michael Dauer]

org-version reports the same version, but now the same code (posted before)
works. So it's fixed.

But shouldn't org-version report 9.5.5 instead of 9.5?

Ihor Radchenko  schrieb am Fr., 30. Sep. 2022, 10:22:

> Michael Dauer  writes:
>
> > This is the latest commit on main, isn't it?
> > Head: main fixup! org-fold-core: Respect 'ignore-indirect
> optimization
> > better
> > Merge:origin/main fixup! org-fold-core: Respect 'ignore-indirect
> > optimization better
> > Tag:  release_9.5.5 (852)
>
> Yes, it is.
>
> Org repo is at https://git.savannah.gnu.org/cgit/emacs/org-mode.git/
> Also referenced at https://orgmode.org/
>
> --
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92
>

Re: Issue with export of inlinetasks

[Michael Dauer]

This is the latest commit on main, isn't it?
Head: main fixup! org-fold-core: Respect 'ignore-indirect optimization
better
Merge:origin/main fixup! org-fold-core: Respect 'ignore-indirect
optimization better
Tag:  release_9.5.5 (852)

Am Fr., 30. Sept. 2022 um 05:10 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > There seems to be an issue with export of inlinetasks, at least with
> > customizing it. Org mode version 9.5 (9.5-gced2b3
>
> Can you try the latest bugfix or main branch instead?
>
> --
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92
>

Issue with export of inlinetasks

[Michael Dauer]

There seems to be an issue with export of inlinetasks, at least with
customizing it. Org mode version 9.5 (9.5-gced2b3
Please see the POC below:

* heading 1
** heading 1.1
* heading 2
*** TODO inline task
*** END
* heading 3
** heading 3.1
* Direct is fine
#+begin_src elisp
(let ((parsetree (org-element-parse-buffer)))
  (org-element-map parsetree '(headline inlinetask)
(lambda (e) (org-element-property :title e
#+end_src

#+RESULTS:
| heading 1  |
| heading 1.1|
| heading 2  |
| inline task|
| heading 3  |
| heading 3.1|
| Direct is fine |
| Issue is at export |
* Issue is at export
#+begin_src elisp
(let ((mist-output "")
  (org-export-with-inlinetasks t))
  (defun mist--html-format-inlinetask-function (todo todo-type priority
text tags contents info)
(setq mist-output (format "%s\niii %s" mist-output text))
"iii")
  (setq org-html-format-inlinetask-function
'mist--html-format-inlinetask-function)

  (defun mist-html-format-headline-function (todo todo-type priority text
tags info)
(setq mist-output (format "%s\nhhh %s" mist-output text))
"hhh")
  (setq org-html-format-headline-function
'mist-html-format-headline-function)
  (kill-buffer (org-export-to-buffer 'html "mist.html"))
  mist-output)
#+end_src

#+RESULTS:
#+begin_example

hhh heading 1.1
hhh heading 1
hhh inline task
hhh END
hhh heading 2
hhh heading 3.1
hhh heading 3
hhh heading 4
hhh Direct is fine
hhh Issue is at export
#+end_example

Re: org-element API does not identify inlinetasks (correctly)

[Michael Dauer]

There is a (require 'org-inlinetask), and I use inlinetasks a lot.

Am Do., 29. Sept. 2022 um 13:18 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > Inlinetasks are always interpreted to be of type heading. This causes
> > multiple issues e.g with export.
> >
> > I think that I could track it to the function
> org-element--current-element,
> > where the check for headings is before the one for inlinetasks, while
> > inlinetask is just a sub-type of heading.
>
> Inlinetasks are not parsed by Org by default. You must first load
> org-inlinetask module to enable the parsing.
>
> Without org-inlinetask being loaded, inlinetasks are treated as ordinary
> headings.
>
> --
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92
>

org-element API does not identify inlinetasks (correctly)

[Michael Dauer]

Inlinetasks are always interpreted to be of type heading. This causes
multiple issues e.g with export.

I think that I could track it to the function org-element--current-element,
where the check for headings is before the one for inlinetasks, while
inlinetask is just a sub-type of heading.

Hence the (custom-) formatting of inlinetasks at export does not work.

Org mode version 9.5 (9.5-gced2b3

BUG: org-show-context 'lineage not showing direct parent of inlinetask

[Michael Dauer]

This e.g. affects pressing TAB on an inlinetask in the agenda view.

Org mode version 9.5 (9.5-gced2b3

Re: Root heading when exporting sub-trees

[Michael Dauer]

Sorry, please ignore. The problem was in front of the screen.

Am Di., 15. Feb. 2022 um 14:16 Uhr schrieb Sébastien Miquel <
sebastien.miq...@posteo.eu>:

> Hi,
>
> Michael Dauer writes:
> > When I export a subtree I normally want to produce a document for the
> > topic of the subtree. So I would expect that the contents of the
> > subtree would be exported with the heading as title (and maybe file
> > name) and the children promoted to level 1.
>
> This is the expected behaviour (except for the file name), and what I
> get when I run C-c C-e C-s l o.
>
> > What I receive is something like this:
> > [...]
> > The whole first level of this outline is pointless.
>
> Looking at the code, I don't understand how you can get this outcome.
>
> Regards,
>
> --
> Sébastien Miquel
>
>

Root heading when exporting sub-trees

[Michael Dauer]

Org mode version 9.5.2 (9.5.2-ge7ea95

When I export a subtree I normally want to produce a document for the topic
of the subtree. So I would expect that the contents of the subtree would be
exported with the heading as title (and maybe file name) and the children
promoted to level 1.

What I receive is something like this:
Title: Title of all topics
1. Topic
1.1
1.2
1.2.1
1.2.3
1.3

The whole first level of this outline is pointless.

What is the best way to change this behavior? I mean in
configuration/patching not by putting the same export properties
everywhere. But identifying the relevant export properties would be of help
of course.

Thanks, m

Re: BUG?: Link to inline-task not working

[Michael Dauer]

>
> > Where are the links/href are built? There should be the error that
> excludes
> > inline-tasks.
>
> A quick search through the code yields: org-export-resolve-id-link
> It explicitly check headlines, but not inlinetasks.
>

Shouldn't be org-export-resolve-fuzzy-link the relevant function, at least
for my use case?

But there it looks like it is searching through all elements including
inlinetasks, which is in org-element-all-elements:
(append pseudo-types '(target) org-element-all-elements)

Am Sa., 4. Dez. 2021 um 04:18 Uhr schrieb Ihor Radchenko :

> Michael Dauer  writes:
>
> > Where are the links/href are built? There should be the error that
> excludes
> > inline-tasks.
>
> A quick search through the code yields: org-export-resolve-id-link
> It explicitly check headlines, but not inlinetasks.
> The fix should not be too hard. Feel free to send a patch ;)
>
> Best,
> Ihor
>

Re: BUG?: Link to inline-task not working

[Michael Dauer]

Ihor, thank you for the quick workaround.

Unfortunately storing links is not much of an issue for me. The real issue
is how I can get the internal links working in the exported html.

I could not find the right places to deactivate and
re-activate inline-tasks during export.

I have a custom org-html-format-inlinetask-function. If I
deactivate inline-tasks outside this formatter is never called, otherwise
the links are not generated.

Where are the links/href are built? There should be the error that excludes
inline-tasks.

thx,
m

Am Fr., 3. Dez. 2021 um 11:50 Uhr schrieb Ihor Radchenko :

> Michael Dauer  writes:
>
> > Before (require 'org-inlinetask) all is fine. But after executing
> (require
> > 'org-inlinetask) the following happens:
> > 1. With point on/in t1 (org-store-link) stores *h2.
> > 2. The manually created link below h1 works in the buffer. But it is
> > exported as BROKEN LINK.
>
> Confirmed.
>
> > Any ideas how to get fully working links to inline-tasks?
>
> I have the following in my config to mitigate this problem:
>
> (defun org-inlinetask-store-link (oldfun  args)
>   "Store link to inlinetask at point."
>   (if (and (derived-mode-p 'org-mode)
>(org-inlinetask-in-task-p))
>   (let ((org-inlinetask-min-level 1000))
> (apply oldfun args))
> (apply oldfun args)))
>
> (advice-add 'org-store-link :around #'org-inlinetask-store-link)
>
> Best,
> Ihor
>

BUG?: Link to inline-task not working

[Michael Dauer]

Is there a setting that excludes inline-tasks from internal links?
I actually want to link to inline-tasks. BUT:
emacs -Q
>>>
* h1
  [[*t1][t1]]
* h2
*** TODO t1
*** END

(require 'org-inlinetask)
<<<
Before (require 'org-inlinetask) all is fine. But after executing (require
'org-inlinetask) the following happens:
1. With point on/in t1 (org-store-link) stores *h2.
2. The manually created link below h1 works in the buffer. But it is
exported as BROKEN LINK.

Org mode version 9.4.4 (release_9.4.4 @
c:/msys64/mingw64/share/emacs/27.2/lisp/org/)

Any ideas how to get fully working links to inline-tasks?
thx

Re: Visibility cycling with inline tasks 2

[Michael Dauer]

Hi Ihor,

Thanks for the clarification.

I wanted to help you with testing. But I could not find a branch dev in
that repo.

Anyway, I'll wait for it to be populated into the main repo. When should I
retry there?

Regards,
Michael

Am Mi., 29. Sept. 2021 um 17:08 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > Hi,
> >
> > Was something wrong with my previous report or is nobody interested in
> > inline tasks?
>
> Your report is fine, but please note the following
> (https://orgmode.org/worg/org-mailing-list.html):
>
> >> What to do if you don't receive an answer
>
> >> If your email is referenced on updates.orgmode.org, it will get the
> >> attention of the maintainers when they have enough time. (Remember
> >> they work on a volunteer basis.)
> >>
> >> If your email is not referenced there and you think it deserves more
> >> attention, you can do this:
> >>
> >> If it is a bug report, check that you provided enough information,
> >> especially the Org and Emacs versions and a step-by-step recipe to
> >> reproduce the bug.
> >>
> >> If it is a question, give more information on what you tried, why you
> >> still have the question and why the answer may be of interest for
> >> other subscribers.
> >>
> >> If you have nothing special to add to your first message and just
> >> want to "bump" the thread, please wait at least one month before
> >> doing so.
>
> Your issue is probably fixed in my personal dev branch at
> https://github.com/yantar92/org
>
> Best,
> Ihor
>

Visibility cycling with inline tasks 2

[Michael Dauer]

Hi,

Was something wrong with my previous report or is nobody interested in
inline tasks?

Inline tasks are a great feature of org-mode, very useful to include tasks
in all sorts of documents without interfering with the document structure.

I resend my report with now hopefully all information to reproduce it
quickly.

0. emacs -Q
1. Insert the below snippet into scratch buffer.
>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
x
*** END
** heading 4
x

(org-mode)
(require 'org-inlinetask)
<<<

2. Execute each of the 2 elisp statements at the bottom (C-x C-e)
3. Cycle Example to show children
4. Cycle heading 2

This should show the issue: Parts of heading 3 are expanded too. This is
also true for the next to cycling steps. Then comes a correct full cycle
and the issue repeats.

This garbage shown from the next heading(s) can become huge in more complex
structures.

Org mode version 9.4.6 (9.4.6-gcf30f7

Please confirm the issue.

Regards,
Michael
AntwortenWeiterleiten

BUG Visibility Cycling with inline tasks

[Michael Dauer]

Hi,

I resend my report with now hopefully all information to reproduce it
quickly.

Inline tasks are a great feature of org-mode, very useful to include tasks
in all sorts of documents without interfering with the document structure.

0. emacs -Q
1. Insert the below snippet into scratch buffer.
>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
x
*** END
** heading 4
x

(org-mode)
(require 'org-inlinetask)
<<<

2. Execute each of the 2 elisp statements at the bottom (C-x C-e)
3. Cycle Example to show children
4. Cycle heading 2

This should show the issue: Parts of heading 3 are expanded too. This is
also true for the next to cycling steps. Then comes a correct full cycle
and the issue repeats.

This garbage shown from the next heading(s) can become huge in more complex
structures.

Org mode version 9.4.6 (9.4.6-gcf30f7

Please confirm the issue.

Regards,
Michael

Re: BUG Visibility Cycling with inline tasks

[Michael Dauer]

Hi Ihor,

Thanks for checking.

I could narrow down on the issue. It happens after (require
'org-inlinetask) is executed.

So to reproduce:
1. emacs -Q
2. paste the following snipped (right into the scratch buffer)
3. execute the two commands at the end C-x C-e for each
4. collapse all (TAB TAB)
5. expand Example (TAB)
5. go to heading 2 and expand it (TAB)

This should surface the issue.

>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
:@CB:
x
*** END
** heading 4
x

(org-mode)
(require 'org-inlinetask)
<<<

Am Mo., 20. Sept. 2021 um 10:21 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > What I get after the first org-cycle is:
> > * Example
> > ** heading 1
> > ** heading 2
> > *  ** TODO Test access with provided credentials
> > ** heading 3
> > x
> > *  ** END
> > ** heading 4
> > x
> >
>
> I cannot reproduce on latest master and with Org 9.4.4. What I am seeing
> is:
>
> * Example
> ** heading 1...
> ** heading 2
> *  ** TODO Test access with provided credentials...
> *  ** END
> * heading 3...
> * heading 4
>
> Another cycle reveals the inlinetask contents:
>
> * Example
> ** heading 1...
> ** heading 2
> *  ** TODO Test access with provided credentials
> x
> *  ** END
> * heading 3...
> * heading 4
>
> Maybe something with your config? Can you reproduce starting from emacs -Q?
>
> Best,
> Ihor
>

Re: BUG Visibility Cycling with inline tasks

[Michael Dauer]

What I get after the first org-cycle is:
* Example
** heading 1
** heading 2
*  ** TODO Test access with provided credentials
** heading 3
x
*  ** END
** heading 4
x

So it also shows part of the following heading. This "garbage" can be max
more if the following subtree is more complex.

it stays after the 2nd and 3rd cycle. Cycles 4 to 6 are OK, then the
problem comes again.

Am Mo., 20. Sept. 2021 um 07:01 Uhr schrieb Ihor Radchenko <
yanta...@gmail.com>:

> Michael Dauer  writes:
>
> > Stating collapsed, pressing TAB on the heading 2 already shows the issue.
>
> Could you describe what is the issue you observe and how it differs from
> your expectations? I do not see any problem with visibility on my side.
>
> Best,
> Ihor
>

Re: BUG Visibility Cycling with inline tasks

[Michael Dauer]

Sorry, I forgot:
Org mode version 9.4.6 (9.4.6-gcf30f7

Am Sa., 18. Sept. 2021 um 10:27 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> Hi,
>
> Inline tasks are a great feature of org-mode, very useful to include tasks
> in all sorts of documents without interfering with the document structure.
>
> But it seems that there are multiple issues with multiple org commands and
> inline tasks (visibility, navigation, selection).
>
> For that reason I already suggested a while ago that the * END line would
> be indented 1 level more then the * start of the inline task. By that it
> would behave like a normal subtree for all org-commands.
>
> Here a minimal example of an issue with visibility cycling:
> >>>
> * Example
> ** heading 1
> x
> ** heading 2
> *** TODO Test access with provided credentials
> x
> *** END
> ** heading 3
> *** TODO State "high value" targets
> :@CB:
> x
> *** END
> ** heading 4
> x
> <<<
>
> Stating collapsed, pressing TAB on the heading 2 already shows the issue.
>
> IMO the suggested simple (but breaking (but easy to fix)) design change
> would make inline tasks more compatible and stable, and even more intuitive
> in the expanded visualization.
>
> Regards,
> Michael
>

BUG Visibility Cycling with inline tasks

[Michael Dauer]

Hi,

Inline tasks are a great feature of org-mode, very useful to include tasks
in all sorts of documents without interfering with the document structure.

But it seems that there are multiple issues with multiple org commands and
inline tasks (visibility, navigation, selection).

For that reason I already suggested a while ago that the * END line would
be indented 1 level more then the * start of the inline task. By that it
would behave like a normal subtree for all org-commands.

Here a minimal example of an issue with visibility cycling:
>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
:@CB:
x
*** END
** heading 4
x
<<<

Stating collapsed, pressing TAB on the heading 2 already shows the issue.

IMO the suggested simple (but breaking (but easy to fix)) design change
would make inline tasks more compatible and stable, and even more intuitive
in the expanded visualization.

Regards,
Michael

BUG: org-lint false missing arguments for macro with optional arguments

[Michael Dauer]

Hi,

If I did not miss it there is no way to specify arguments as optional for a
macro definition.

I've the following:
(defun ct-action-plan ( up recently-done)
...
(push '("action_plan" . "(eval (ct-action-plan $1 $2))")
org-export-global-macros)

The arguments of the function are specified as optional. The macro just
call it with $1 and $2, which are nil if not stated like in the following:
{{{action_plan}}}

But here org-lint reports:
327 low   Missing arguments in macro "action_plan"

Is this a bug? Any ideas for a work-around to avoid confusion for my users.

BTW: I came to this after working around the other reported bug of lint to
ignore org-export-global-macros.

thx,
m

BUG: org-lint reports macros defined in org-export-global-macros as undefined

[Michael Dauer]

Hi,

I have a lot of global macros defined in org-export-global-macros. Wherever
they are used in my org files org-lint reports them as undefined.

It seems that org-lint just checks against org-macro-templates (collected
with (org-macro-initialize-templates)) and a few default macros.

I'm going to work around this with a temporary advice filter-return on
(org-macro-initialize-templates). Any better ideas or even a fix?

thx
m

Re: misaligned tab and spaces in src block

[Michael Dauer]

Hi Tim,

indent-tabs-mode was exactly what I was looking for.

Thank you,
Michael

Am Di., 25. Mai 2021 um 04:39 Uhr schrieb Tim Cross :

>
> Michael Dauer  writes:
>
> > Hi,
> >
> > #+begin_src elisp :results output
> > (aaa
> >  bbb (
> > #x09#x09#x09ccc))
> >   ccc
> > #+end_src
> > looks like this in the editor
> > (aaa
> >  bbb (
> > ccc))
> >   ccc
> >
> > Line 1-3 were indented automatically by pressing Tab. In line 4 I
> inserted 6 spaces manually. This is what I would expect to find in line 3
> too. But at my
> > surprise there are 3 tab chars in line 3. Line 2 was indented
> automatically with 1 space.
> >
> > 1. So why is line 3 indented with 3 tabs instead of 6 spaces?
> > 2. How can I prevent this?
> > 3. Why does a tab have a width between 1 and 2 spaces?
> > 4. How can I prevent this misalignment?
> >
> >I don't understand what  org-block face has fixed-pitch.
> >
> > Org mode version 9.4.6 (9.4.6-gcf30f7
> > (setq-default tab-width 2)
> > (setq org-src-fontify-natively t
> > org-src-window-setup 'current-window
> > org-src-strip-leading-and-trailing-blank-lines t
> > org-src-preserve-indentation t
> > org-src-tab-acts-natively t)
> >
>
> Are you editing the source block using org-edit-special (C-c ,)? If not,
> then you are not editing the source block with the correct syntax for
> elisp and this will throw out auto formatting.
>
> Your example block is invalid elisp code which is
> #+begin_src elisp :results output
>   (aaa
>bbb (
> #x09#x09#x09ccc))
>   ccc
> #+end_src
>
> but I don't see how you can get any output as it is not valid elisp. It
> is not clear to me what you are trying to do. You have 3 tab characters
> (#x09), so don't see why you would expect them to be spaces?
>
> If what you want is for hitting tab to insert only spaces, have a look
> at the variable indent-tab-mode. You can, for example, do
>
> (setq-default indent-tab-mode nil)
>
> to force use of spaces instead of tabs. However, be careful about doing
> this globally if you also want to contribute to projects where tabs are
> used as this will cause havoc with diffs and git. You can also set this
> on a per language (via mode hooks) or per project (via local variables).
>
> To get a better feel for how language modes align code etc, you really
> need to make sure the code you are trying to align is syntactically
> valid and you are using the correct coding style for the language.
> --
> Tim Cross
>
>
> --
> Confidentiality Notice:This email and any attachments it may contain are
> intended for the individual or entity above and may be confidential and
> protected by legal privilege. SmartPM Technologies, Inc. makes no
> warranties, express or implied, concerning the accuracy of the information
> contained herein, which is subject to change without notice. Unintended
> recipients should be aware that use of this e-mail or any of its
> attachments in any way is forbidden.
>

Re: BUG: export options properties drawer position and planning dates

[Michael Dauer]

Yes, you're right. The problem was with my sample. Forget about my 2.

Any ideas how I can specify the inclusion of planning dates specifically on
sub-tree level (not just once for the whole export) without custom exporter
or export filter?

thx
m


Am Di., 15. Juni 2021 um 17:05 Uhr schrieb Nicolas Goaziou <
m...@nicolasgoaziou.fr>:

> Hello,
>
> Michael Dauer  writes:
>
> >>>>
>
> [...]
>
> >>>>
>
> I think we are mis-communicating. I saw the document you're re-posting.
> My question, however, is about the specific part demonstrating the
> following:
>
> >> > 2. This actually works when the scheduled date is (incorrectly) placed
> >> > below the drawer. It is not just treated as the first paragraph, but
> >> > omitted when the with-planning property of its node is nil, while
> normal
> >> > text would be exported.
>
> I'm trying to reproduce this, so I need minimal example, with
> instruction.
>
> Regards,
> --
> Nicolas Goaziou
>

Re: BUG: export options properties drawer position and planning dates

[Michael Dauer]

>>>
* TODO export options
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
SCHEDULED: <2021-06-08 Di.>
normal text
** TODO l1
:PROPERTIES:
:EXPORT_OPTIONS: p:t
:END:
SCHEDULED: <2021-06-08 Di.>
normal text
*** TODO l2
SCHEDULED: <2021-06-08 Di.>
normal text
 TODO l3
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
SCHEDULED: <2021-06-08 Di.>
normal text
* TODO l4
SCHEDULED: <2021-06-08 Di.>
normal text
<<<

>>>
SCHEDULED: <2021-06-08>
normal text


TODO l1
===

  SCHEDULED: <2021-06-08>
  normal text


TODO l2
~~~

  normal text


TODO l3
---

  SCHEDULED: <2021-06-08>
  normal text


* TODO l4

  normal text
<<<

Am Di., 15. Juni 2021 um 08:07 Uhr schrieb Nicolas Goaziou <
m...@nicolasgoaziou.fr>:

> Hello,
>
> Michael Dauer  writes:
>
> > I would understand that the export would take the export settings of the
> > current heading to control the export of the complete subtree.
>
> That's correct.
>
> > 1. The much better logic would be that each node determines e.g. the
> > with-planning by its own (or inherited) properties.
>
> This is not how it is implemented. Export options are per export
> process, not per node. Besides, the above would not make sense for
> one-off items, like title:nil.
>
> I guess the much better logic would first need to distinguish global
> from local export options. But I don't think this is worth the trouble.
>
> > 2. This actually works when the scheduled date is (incorrectly) placed
> > below the drawer. It is not just treated as the first paragraph, but
> > omitted when the with-planning property of its node is nil, while normal
> > text would be exported.
>
> Would you mind providing an ECM for it? I'm not sure what example you're
> referring to.
>
> Regards,
> --
> Nicolas Goaziou
>

Re: BUG: export options properties drawer position and planning dates

[Michael Dauer]

Hi Nicolas,

I would understand that the export would take the export settings of the
current heading to control the export of the complete subtree. This would
be the case for the second example, where the scheduled date is (correctly)
placed above the properties drawer.

BUT:
1. The much better logic would be that each node determines e.g. the
with-planning by its own (or inherited) properties.
2. This actually works when the scheduled date is (incorrectly) placed
below the drawer. It is not just treated as the first paragraph, but
omitted when the with-planning property of its node is nil, while normal
text would be exported.

I did not check the code. I assume that the better logic was actually
implemented with the mistake of assuming an incorrect order of planning
line and properties drawer.

Regards,
Michael

Am Di., 8. Juni 2021 um 22:22 Uhr schrieb Nicolas Goaziou <
m...@nicolasgoaziou.fr>:

> Hello,
>
> Michael Dauer  writes:
>
> > There seems to be a bug in Org mode version 9.4.6 (9.4.6-gcf30f7:
> > EXPORT_OPTIONS (at least p for with-planning) is only respected if there
> is
> > no planning date placed above the properties drawer.
> >
> >>>>
> > * TODO export options
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:nil
> > :END:
> > SCHEDULED: <2021-06-08 Di.>
> > ** TODO l1
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:t
> > :END:
> > SCHEDULED: <2021-06-08 Di.>
> > *** TODO l2
> > SCHEDULED: <2021-06-08 Di.>
> >  TODO l3
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:nil
> > :END:
> > SCHEDULED: <2021-06-08 Di.>
> > * TODO l4
> > SCHEDULED: <2021-06-08 Di.>
> > <<<
> >
> > produces the somehow expected behavior:
> >>>>
> > SCHEDULED: <2021-06-08>
> >
> >
> > TODO l1
> > ===
> >
> >   SCHEDULED: <2021-06-08>
> >
> >
> > TODO l2
> > ~~~
> >
> > TODO l3
> > ---
> >
> >   SCHEDULED: <2021-06-08>
> >
> >
> > * TODO l4
> > <<<
> >
> > But it is syntactically incorrect since the planning dates have to be the
> > first line below the heading.
>
> This is correct, because the SCHEDULED lines are exported as paragraphs,
> which is what they are.
>
> > For the following syntactically correct
> > snippet the export_options are ignored:
> >>>>
> > * TODO export options
> > SCHEDULED: <2021-06-08 Di.>
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:nil
> > :END:
> > ** TODO l1
> > SCHEDULED: <2021-06-08 Di.>
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:t
> > :END:
> > *** TODO l2
> > SCHEDULED: <2021-06-08 Di.>
> >  TODO l3
> > SCHEDULED: <2021-06-08 Di.>
> > :PROPERTIES:
> > :EXPORT_OPTIONS: p:nil
> > :END:
> > * TODO l4
> > SCHEDULED: <2021-06-08 Di.>
> > <<<
>
> >>>>
> > TODO l1
> > ===
> >
> > TODO l2
> > ~~~
> >
> > TODO l3
> > ---
> >
> > * TODO l4
> > <<<
> >
> > Same behavior I see with HTML export.
>
> Did you use subtree export? Where was the point when you exported it?
>
> For example, if I use a subtree export in the first section above, I get
> no planning line, you if I subtree-export from the second section, i.e.,
> "l1", all subsequent planning lines appear.
>
> IOW, I cannot reproduce your issue.
>
> Regards,
> --
> Nicolas Goaziou
>

BUG: export options properties drawer position and planning dates

[Michael Dauer]

Hi,

There seems to be a bug in Org mode version 9.4.6 (9.4.6-gcf30f7:
EXPORT_OPTIONS (at least p for with-planning) is only respected if there is
no planning date placed above the properties drawer.

>>>
* TODO export options
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
SCHEDULED: <2021-06-08 Di.>
** TODO l1
:PROPERTIES:
:EXPORT_OPTIONS: p:t
:END:
SCHEDULED: <2021-06-08 Di.>
*** TODO l2
SCHEDULED: <2021-06-08 Di.>
 TODO l3
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
SCHEDULED: <2021-06-08 Di.>
* TODO l4
SCHEDULED: <2021-06-08 Di.>
<<<

produces the somehow expected behavior:
>>>
SCHEDULED: <2021-06-08>


TODO l1
===

  SCHEDULED: <2021-06-08>


TODO l2
~~~

TODO l3
---

  SCHEDULED: <2021-06-08>


* TODO l4
<<<

But it is syntactically incorrect since the planning dates have to be the
first line below the heading. For the following syntactically correct
snippet the export_options are ignored:
>>>
* TODO export options
SCHEDULED: <2021-06-08 Di.>
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
** TODO l1
SCHEDULED: <2021-06-08 Di.>
:PROPERTIES:
:EXPORT_OPTIONS: p:t
:END:
*** TODO l2
SCHEDULED: <2021-06-08 Di.>
 TODO l3
SCHEDULED: <2021-06-08 Di.>
:PROPERTIES:
:EXPORT_OPTIONS: p:nil
:END:
* TODO l4
SCHEDULED: <2021-06-08 Di.>
<<<

>>>
TODO l1
===

TODO l2
~~~

TODO l3
---

* TODO l4
<<<

Same behavior I see with HTML export.

Re: BUG: eval macros not working anymore

[Michael Dauer]

Hi,

I can confirm that macros work a little bit differently (incompatible with
some custom code) in 9.4.6 than 9.4.5, but still fine and better.

The #+marco keyword behaviour seems unchanged. For programmatically added
macros the proposed lambda form works fine.

Please excuse my false report.

Thanks,
Michael

Am Di., 25. Mai 2021 um 20:32 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> Sorry, maybe I did not test thoroughly enough. I'll do, and come back if
> still necessary. thx
>
> Nicolas Goaziou  schrieb am Di., 25. Mai 2021,
> 17:51:
>
>> Michael Dauer  writes:
>>
>> > How do you do this with a #+macro keyword with arguments?
>>
>> As before, with "(eval ..."
>>
>> I might be able to give you a more specific answer when your question is
>> more specific, i.e., with an ECM.
>>
>> Regards,
>>
>

Re: BUG: eval macros not working anymore

[Michael Dauer]

Sorry, maybe I did not test thoroughly enough. I'll do, and come back if
still necessary. thx

Nicolas Goaziou  schrieb am Di., 25. Mai 2021,
17:51:

> Michael Dauer  writes:
>
> > How do you do this with a #+macro keyword with arguments?
>
> As before, with "(eval ..."
>
> I might be able to give you a more specific answer when your question is
> more specific, i.e., with an ECM.
>
> Regards,
>

Re: BUG: eval macros not working anymore

[Michael Dauer]

How do you do this with a #+macro keyword with arguments?

The old implementation checked the string for a "(eval" prefix.

Nicolas Goaziou  schrieb am Di., 25. Mai 2021,
11:14:

> Hello,
>
> Michael Dauer  writes:
>
> > at least not compatible with before.
> >
> > Probably caused by commit 8abdbbee395f284f2262a89187d662eaf40080b1.
> >
> > originally correct macro ("macroA" . "(eval
> > do-something-dynamically-at-macro-expansion)")
> >
> > How should this be achieved now? (functionp "any-string") is nil
>
> I think you need to write
>
>   ("macroA" . (lambda ( _)
> (do-something-dynamically-at-macro-expansion)))
>
> Regards,
> --
> Nicolas Goaziou
>

BUG: eval macros not working anymore

[Michael Dauer]

at least not compatible with before.

Probably caused by commit 8abdbbee395f284f2262a89187d662eaf40080b1.

originally correct macro ("macroA" . "(eval
do-something-dynamically-at-macro-expansion)")

How should this be achieved now? (functionp "any-string") is nil

misaligned tab and spaces in src block

[Michael Dauer]

Hi,

#+begin_src elisp :results output
(aaa
 bbb (
#x09#x09#x09ccc))
  ccc
#+end_src
looks like this in the editor
(aaa
 bbb (
ccc))
  ccc

Line 1-3 were indented automatically by pressing Tab. In line 4 I inserted
6 spaces manually. This is what I would expect to find in line 3 too. But
at my surprise there are 3 tab chars in line 3. Line 2 was indented
automatically with 1 space.

1. So why is line 3 indented with 3 tabs instead of 6 spaces?
2. How can I prevent this?
3. Why does a tab have a width between 1 and 2 spaces?
4. How can I prevent this misalignment?

org-block face has fixed-pitch.

Org mode version 9.4.6 (9.4.6-gcf30f7
(setq-default tab-width 2)
(setq org-src-fontify-natively t
org-src-window-setup 'current-window
org-src-strip-leading-and-trailing-blank-lines t
org-src-preserve-indentation t
org-src-tab-acts-natively t)

Thanks,
Michael

Re: Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]

[Michael Dauer]

The main advantage is that all org-mode actions on subtrees would work
without any specific handling of inline tasks. e.g. visibility cycling,
hiding of none context, cut/copy, moving. With many of these actions I
experience some issues with inline tasks. And even from my personal user
perception I would like to have just the task headings on the same level,
not also the END marks.

Bastien  schrieb am Sa., 15. Mai 2021, 11:02:

> Hi Michael,
>
> Michael Dauer  writes:
>
> > Wouldn't it be the much better approach to change inline tasks so
> > that the END line is one level below the "begin" line?
>
> I'm not sure how this would be better, and I would rather find this
> more confusing.  What is the expected benefit?
>
> --
>  Bastien
>

BUG: org-agenda-entry-text-cleanup-hook not working

[Michael Dauer]

Hi,

org-agenda-entry-text-cleanup-hook is not called when agenda is produced.
Org mode version 9.3.6 (release_9.3.6-471-g9e385d

Prove:
  (defun ct-clean-agenda-entry ()
(message "XXX1"))
  (add-hook 'org-agenda-entry-text-cleanup-hook 'ct-clean-agenda-entry)

But there is no output while agenda is displayed with a lot of entries.

I don't know why because in org-agenda-get-some-entry-text there is an
unconditional
(run-hooks 'org-agenda-entry-text-cleanup-hook)

Re: Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]

[Michael Dauer]

Hi,

Wouldn't it be the much better approach to change inline tasks so that the
END line is one level below the "begin" line?

I did not think it through. But IMO it would make IT more compatible with
normal org behavior, and also more visually appealing.

With the END notation it would still be unambiguous.

I'm aware that this change would have an impact on existing documents. But
worth a simple migration command the improvement would be worth the little
pain.

Regards,
m


Am Do., 13. Mai 2021 um 15:08 Uhr schrieb Bastien :

> Hi Christian,
>
> Bastien  writes:
>
> > Christian Hemminghaus  writes:
> >
> >> I ran into an error message while composing structured text with
> >> org-mode using org-inline-tasks. The error appears when moving around
> >> inline tasks in my document.
> >
> > yes, I confirm this bug.
>
> Carsten proposed a patch that I adapted a little bit and pushed to the
> maint branch.  We now throw an error saying that dragging inline tasks
> is not supported.
>
> Thanks,
>
> --
>  Bastien
>
>
> --
> Confidentiality Notice:This email and any attachments it may contain are
> intended for the individual or entity above and may be confidential and
> protected by legal privilege. SmartPM Technologies, Inc. makes no
> warranties, express or implied, concerning the accuracy of the information
> contained herein, which is subject to change without notice. Unintended
> recipients should be aware that use of this e-mail or any of its
> attachments in any way is forbidden.
>