URL woes that never end

[Rudolf Adamkovič]

Greetings!

I lamented a while ago about URL handling in Org. To provide a concrete 
example, below is a shell script that Org does not export correctly to HTML. 
More specifically, Org considers the script to be a URL. Further, and 
amazingly, even if I change “see .” to “see  to learn more”, Org 
*still* does not parse the URL correctly, even with a valid URL per RFC *and* 
surrounding angle brackets (<>) *and* spaces on both sides.

#+begin_src shell :tangle fetchmail-retry.sh :shebang #!/usr/bin/env sh
# fetchmail-retry.sh -- fetchmail with retry
#
# Author: Rudolf Adamkovič 
# Version: 1.0
#
# This file is free software: you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 3 of the License, or (at
# your option) any later version.
#
# For more information, see .
#

RETRY=0
RETRY_MAX=10

RETURN_OK=0
RETURN_NO_MAIL=1

while [ $RETRY -le $RETRY_MAX ]
do
fetchmail "$@"
RETURN=$?

[ $RETURN -eq $RETURN_OK ] && exit $RETURN
[ $RETURN -eq $RETURN_NO_MAIL ] && exit $RETURN

RETRY=$((RETRY+1))
echo Retry \#$RETRY:
done

echo Failed after $RETRY_MAX retries. >&2
exit $RETURN
#+end_src

--
Logic is a science of the necessary laws of thought, without which no 
employment of the understanding and the reason takes place. -- Immanuel Kant, 
1785

Rudolf Adamkovič 
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

Re: org-attach a directory?

[Henrik Frisk]

Den fre 11 juni 2021 18:37John Kitchin  skrev:

> I discovered another way to do this that is already built in with
> `org-attach-dired-to-subtree` that would help sometimes.
>
> You split your window, open dired in one of them, mark some files, and
> then run that command in the dired window.
>
> John
>
>> Should have thought of this when you first asked if i had understood your
question. This is a very useful function.

/Henrik

>
>>
>>

Adjusting alarms in icalendar export

["Joshua O'Connor"]

Hello!

I would like to have some more control over the alarms created by the
iCalendar export and was wondering if anyone has tried anything like
that, or has any surrounding thoughts?

Namely, I think it would be a nice feature if there could be some markup
(perhaps a property) that allows you to specify the number of
repetitions and delays between them.

I don't think implementing the full VALARM spec is worth it though, some
stuff like the AUDIO action just seems goofy to me.

Joshua

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

[Nicolas Goaziou]

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: org-attach a directory?

[stardiviner]

> On Jun 12, 2021, at 12:35 AM, John Kitchin  wrote:
> 
> I discovered another way to do this that is already built in with 
> `org-attach-dired-to-subtree` that would help sometimes. 
> 
> You split your window, open dired in one of them, mark some files, and then 
> run that command in the dired window.
> 
> John

Thanks John.

I tried your methods. But this need to mark multiple regular files. Instead of 
a directory. It needs to leave Org file buffer. What if I have multiple Org 
buffer presents. It might cause chaos. I don’t think it’s a good solution to 
attach directory. But learn a new command. Still good.

> 
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu 
> 
> 
> 
> On Thu, Jun 10, 2021 at 10:04 PM stardiviner  > wrote:
> I want this feature patch too. Hope Org Mode can add this. I remember old 
> version org-mode can do this. But later delete this feature? I forget what 
> version is.
> 
> I suggest to add this feature.
> 
>> On Jun 8, 2021, at 11:49 PM, John Kitchin > > wrote:
>> 
>> Is it possible to attach a directory to an org heading?
>> 
>> I have only seen how to attach a file so far.
>> 
>> John
>> 
>> ---
>> Professor John Kitchin (he/him/his)
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> @johnkitchin
>> http://kitchingroup.cheme.cmu.edu 
>> 
> 

Re: org-critical-edition (a package for philologists and classicists)

[Juan Manuel Macías]

Hi Christian, thank you very much for your comments.

Christian Moe writes:

> Very neat!
>
> Curious about a design choice: If I understand correctly,
> org-critical-edition puts the hidden notes in the description and the
> visible annotated text in the target of an org link. This is the reverse
> of the out-of-the-box link appearance (description visible, target
> hidden if description present). Why take the extra trouble to do it this
> way?
>

Indeed, the decision to reverse the order of the link appearance may
seem somewhat shocking :-) I did it like this to keep a syntactic
structure similar to the reledmac command \edtext, when the user (the
reledmac user) views the links full displayed. In LaTeX/reledmac the
structure is:

...some text... \edtext{annotated passage}{critical notes} ...some text...

The annotated passage is part of the text and is also the "lemma" in the
critical note.

In org-critical-edition I define a new link type called `edtext', using
`org-link-set-parameters', and the identifying string (`edtext:') must be
placed in the target part.

Best regards,

Juan Manuel 

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
>

Solved: One habit malfunctioning

[Ypo]

Solved: It was a problem with the LOGBOOK. There were 2 days for the 
same week, instead of 1.


Sorry I didn't show the whole LOGBOOK in the previous message.

- State "HECHO"  from ""   [2021-04-07 mi. 09:02]
- State "HECHO"  from ""   [2021-04-06 ma. 10:14]

Best regards

Re: [wip-cite-new] experimental citeproc-el based activation processor

[András Simonyi]

Dear All,

thanks for the positive feedback, and sorry for the late reply.

On Sat, 12 Jun 2021 at 16:46, Nicolas Goaziou  wrote:

> It may make sense to merge it with "oc-csl.el" at some point. If that
> suits you,

Absolutely, thanks for the suggestion!

> In addition, I have a couple of comments:
>
> - As suggested by Bruce D'Arcus, we might move `org-cite-get-boundaries'
>   in `oc.el' proper, since it is also used elsewhere (at least in
>   "oc-basic.el").

sure, it makes more sense there, especially because I took the
fragment from your code IIRC (apologies for the lack of explicit
attribution)

> - Nitpick: (car element) => (org-element-type element)

I was actually wondering about this when I wrote the code and if I may
nitpick on the nitpick, I find the documentation a bit confusing in
this respect. If the list representation is meant to be
internal/private only (I guess that is the case), then maybe this
should be more explicit in the docstrings, because now the docstring
of `org-element-context' says

"Return smallest element or object around point.

Return value is a list like (TYPE PROPS) [...]"

Omitting the second part or having something like "Internally, return
value is [...]" would go a long way toward conveying the message that
one shouldn't rely on the list representation.

> - I think it is inefficient to call `org-element-context' in
>   `org-cite-csl-activate--sensor-fun'. You may as well store the parsed
>   object as a text property on the citation during fontification, and
>   read the property in the function above to know where you are.

Thanks for the suggestion, I'll certainly implement this!

> - I am also wondering about the call of `org-element-parse-buffer' in
>   `org-cite-csl-activate-render-all'. It is not wrong per se, but it is
>   only optimal when citation density in every part of the document is
>   not low. This might not be the most common case. The other option is
>   to `re-search-forward' for `org-element-citation-prefix-re' and then
>   call `org-element-context' at point.

>   Of course, optimizing `org-cite-csl-activate-render-all' may not be
>   the top priority, since some latency is to be expected anyway.

Thanks for this as well, I'll switch to the more efficient approach
you suggested.

Best regards,
András

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

[Nicolas Goaziou]

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