Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

Missing word on the key sentence ...

On Mon, Jun 14, 2021 at 7:37 PM Bruce D'Arcus  wrote:

> The example you are highlighlighting here was why I was earlier
> suggesting for a rule that would allow something like this input:
>
> "A quotation ending with a period." [cite: @hoel-71-whole].
>
> ... where the second would be dropped, hence getting the expected output.

Should be "second period would ..."

Bruce

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

On Mon, Jun 14, 2021 at 7:45 AM Denis Maier  wrote:
>
> Below a few examples of what I mean.
>
> WDYT? Am I missing something?
>
> Denis
> ===
> #+cite_export: csl
> #+cite_export: csl 
> "C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"
> #+bibliography: test.bib
>
> * Original source
>
> "A quotation ending with a period."
>
> "A quotation ending without punctuation"
>
> * Author-date style input (= semantically non-strict input)
>
> "A quotation ending with a period" [cite: @hoel-71-whole].
>
> "A quotation ending without punctuation" [cite: @hoel-71-whole].
>
> ** author-date output with language: en-us
> Expected: "A quotation ending with a period" (Hoel 1971).
> Actual:   "A quotation ending with a period" (Hoel 1971).
>
> Expected: "A quotation ending without punctuation" (Hoel 1971).
> Actual:   "A quotation ending without punctuation" (Hoel 1971).
>
> => ok
>
> ** author-date output with language: de
> Expected: "A quotation ending with a period" (Hoel 1971).
> Actual:   "A quotation ending with a period" (Hoel 1971).
>
> Expected: "A quotation ending without punctuation" (Hoel 1971).
> Actual:   "A quotation ending without punctuation" (Hoel 1971).
>
> => ok
>
> ** note style output with language: en-us
> Expected: "A quotation ending with a period."[1]
> Actual:   "A quotation ending with a period."[1]
>
> Expected: "A quotation ending without punctuation."[1]
> Actual:   "A quotation ending without punctuation."[1]
>
> => ok
>
> ** note style output with language: en-gb or de
> Expected: "A quotation ending with a period."[1]
> Actual:   "A quotation ending with a period".[1]
>
> Expected: "A quotation ending without punctuation".[1]
> Actual:   "A quotation ending without punctuation".[1]
>
> => Here, we cannot distinguish between the two cases as we don't know whether 
> punctuation appears in the original source.
>
> * Note style input (=semantically strict input)
>
> "A quotation ending with a period." [cite: @hoel-71-whole]
>
> "A quotation ending without punctuation". [cite: @hoel-71-whole]
>
> As the input preserves the location of punctuation in the original material, 
> I'd say it should be much easier to deal with this. We don't have to add 
> information which isn't in the input, but rather we'll just have to move any 
> punctuation to after the citation object. Maybe I'm missing something, but to 
> me this looks like a much simpler operation than going in the opposite 
> direction.
>
> Maybe we should stop talking about author date vs note style input, but 
> rather about strict vs. non-strict input.

It's definitely not author-date vs note. I see it as in-text citations
vs note citations. As in, the former applies to other styles beyond
author-date.

The example you are highlighlighting here was why I was earlier
suggesting for a rule that would allow something like this input:

"A quotation ending with a period." [cite: @hoel-71-whole].

... where the second would be dropped, hence getting the expected output.

But IDK what Nicolas thinks of considering that now, or deferring for
later consideration.

Bruce

Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Gustavo Barros]

Hi Bhavin,

On Mon, 14 Jun 2021 at 15:01, Bhavin Gandhi  
wrote:



On Mon, 14 Jun 2021 at 19:10, Gustavo Barros wrote:

The marking of repeated tasks as "done" is currently resulting in
duplicate entries in the "LOGBOOK" drawer, which is not expected.  I
don't know exactly when this came to be, but it does not happen in 
the

current built-in version (9.4.4), while it does in the latest release
(9.4.6).


I was able to reproduce this, and here are my findings as well as a
reproducible configuration with only a few settings.


Thank you for taking the time to try this out and for confirming you are 
able to reproduce the issue.


(I'm marking this bug confirmed.  I'd normally refrain from "self 
confirming" but, since Bhavin was able to reproduce and I consider this 
one to be particularly relevant, I made an exception.)


Best regards,
Gustavo.

Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Bhavin Gandhi]

On Mon, 14 Jun 2021 at 19:10, Gustavo Barros wrote:
> The marking of repeated tasks as "done" is currently resulting in
> duplicate entries in the "LOGBOOK" drawer, which is not expected.  I
> don't know exactly when this came to be, but it does not happen in the
> current built-in version (9.4.4), while it does in the latest release
> (9.4.6).

I was able to reproduce this, and here are my findings as well as a
reproducible configuration with only a few settings.

=test.org= file:

#+begin_src org
* TODO First

* TODO Read book
SCHEDULED: <2021-06-15 Tue +1d>
#+end_src

Start emacs -Q and open the test.org file.

Go to the 'First' entry, and do C-c C-t. This adds an a timestamp record
(this does not happen with 9.4.4, not sure if the default behavior has
been changed).

Changed test.org file:

#+begin_src org
* DONE First

- State "DONE"   from "TODO"   [2021-06-14 Mon 23:23]
* TODO Read book
SCHEDULED: <2021-06-15 Tue +1d>
#+end_src

Now, load this configuration:

#+begin_src elisp
(add-to-list 'load-path "~/src/org-mode/lisp/")

(setq org-todo-keywords
  '((sequence "TODO(t)" "|" "DONE(d!)")))
#+end_src

Open the test.org again, and go to the "Read book" entry, mark it done
with C-c C-t. Now, there are two timestamp changes getting recorded.

#+begin_src org
[…]
* TODO Read book
SCHEDULED: <2021-06-16 Wed +1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-14 Mon 23:26]
:END:
- State "DONE"   from "TODO"   [2021-06-14 Mon 23:26]
- State "DONE"   from "TODO"   [2021-06-14 Mon 23:26]
#+end_src

-- 
Bhavin Gandhi (bhavin192) | https://geeksocket.in

Re: BUG: Logging habits to LOGBOOK results in double entered time stamp.

[Carlo Tambuatco]

Here's the value:

Its value is
((sequence "TODO(t)" "IN_PROGRESS(i)" "|" "DONE(d!)" "POSTPONED(p@)"
"CANCELLED(c@)")
 (sequence "TEST(e)" "TESTING(s)" "|" "PASS(p!)" "FAIL(f@)"))
Original value was
((sequence "TODO" "DONE"))




On Mon, Jun 14, 2021 at 1:22 PM Bhavin Gandhi  wrote:

> Hello Carlo
>
> On Wed, 9 Jun 2021 at 10:42, Carlo Tambuatco wrote:
> > When I mark the task as DONE for the day, it logs the task as:
> >
> > :LOGBOOK:
> > - State "DONE"   from "TODO"   [2021-06-08 Tue 22:20]  <--
> Repeated entry
> > - State "DONE"   from "TODO"   [2021-06-08 Tue 22:20]
> > […]
> >
>
> I'm not able to reproduce this issue with emacs -q and the latest
> master. But I think that this issue is similar to
> https://orgmode.org/list/877diwbm6a@gmail.com/T/#u
>
> Can you share the value of org-todo-keywords variable? (C-h v
> org-todo-keywords).
>
> --
> Bhavin Gandhi (bhavin192) | https://geeksocket.in
>

Re: BUG: Logging habits to LOGBOOK results in double entered time stamp.

[Bhavin Gandhi]

Hello Carlo

On Wed, 9 Jun 2021 at 10:42, Carlo Tambuatco wrote:
> When I mark the task as DONE for the day, it logs the task as:
>
> :LOGBOOK:
> - State "DONE"   from "TODO"   [2021-06-08 Tue 22:20]  <-- Repeated 
> entry
> - State "DONE"   from "TODO"   [2021-06-08 Tue 22:20]
> […]
>

I'm not able to reproduce this issue with emacs -q and the latest
master. But I think that this issue is similar to
https://orgmode.org/list/877diwbm6a@gmail.com/T/#u

Can you share the value of org-todo-keywords variable? (C-h v
org-todo-keywords).

-- 
Bhavin Gandhi (bhavin192) | https://geeksocket.in

Re: [BUG] org babel fails with matlab+python kernel on MacOS-10.15 [9.4.6 (release_9.4.6-541-g52b097 @ /Users/oub/emacs/site-lisp/packages/org/)]

[Nick Dokos]

Uwe Brauer  writes:

>
>>> |   ob-ipython--dump-error("Traceback (most recent call last):\n  File 
>>> \"/Users/...")
>
>
>
>> This line seems to be the critical one in the error output. If you can
>> expand out the full error message, it may elucidate what the problem is.
>
> This message drives my crazy since the most important information is
> just not shown.
>

IIUC, clicking on the three dots should expand the message to its full
glory. You'll probably need to cut-n-past it to another buffer and
replace "\n" with "real" newlines to make it readable.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Gustavo Barros]

Hi All,

The marking of repeated tasks as "done" is currently resulting in 
duplicate entries in the "LOGBOOK" drawer, which is not expected.  I 
don't know exactly when this came to be, but it does not happen in the 
current built-in version (9.4.4), while it does in the latest release 
(9.4.6).


An ECM to reproduce the issue is the following.

Start 'emacs -Q' and do an initial setup:

#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.4.6")
(setq org-log-into-drawer t)
(setq org-log-done 'time)
(setq org-todo-keywords
 '((sequence "TODO(t)" "SOMEDAY(s)" "|" "DONE(d!)")
   (sequence "NEXT(n)" "WAIT(w@/!)" "|" "CANCELED(c@/!)")))
#+end_src

Visit file =test.org= with contents:
#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-13 Sun +1d>
#+end_src

Now call "C-c C-t" (`org-todo'), and call the key "d" for "DONE", as per 
the above settings.  The resulting buffer is:


#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-15 Tue +1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-14 Mon 10:27]
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2021-06-14 Mon 10:27]
- State "DONE"   from "TODO"   [2021-06-14 Mon 10:27]
:END:
#+end_src


Best regards,
Gustavo.



Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20, cairo version 1.16.0)

of 2021-03-25
Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ 
/home/gustavo/.emacs.d/elpa/org-9.4.6/)


current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
		   [add-hook change-major-mode-hook org-show-all append 
		   local]

   5]
 #[0 "\300\301\302\303\304$\207"
		   [add-hook change-major-mode-hook 
		   org-babel-show-result-all

append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
org-log-done 'time
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-hide-drawers

  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "SOMEDAY(s)" "|" "DONE(d!)")
		 (sequence "NEXT(n)" "WAIT(w@/!)" "|" 
		 "CANCELED(c@/!)"))

org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
		   ("eww" :follow org-eww-open :store 
		   org-eww-store-link)

   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
		   ("mhe" :follow org-mhe-open :store 
		   org-mhe-store-link)
		   ("irc" :follow org-irc-visit :store 
		   org-irc-store-link

:export org-irc-export)
		   ("info" :follow org-info-open :export 
		   org-info-export

:store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
			org-docview-export :store 
			org-docview-store-link)

   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
		   ("bbdb" :follow org-bbdb-open :export 
		   org-bbdb-export

:complete org-bbdb-complete-link :store
org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
		   ("file+emacs") ("shell" :follow 
		   org-link--open-shell)

   ("news" :follow
#[514 "\301\300\302Q\"\207"
  ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
   ("mailto" :follow
#[514 "\301\300\302Q\"\207"
			  ["mailto" browse-url ":"] 6 "\n\n(fn URL 
			  ARG)"]

)
   ("https" :follow
 

Re: literate programming, development log -- ideas?

[Greg Minshall]

Samuel,

> I just wanted to put this here in the Literate Programming thread, DistroTube 
> just did a video on why Emacs rules, but the following timestamps are pretty 
> dang useful for literate programming for still-always learning newbies like 
> myself, just wanted to mention them here for reference:
> Timestamps:
> 7:20
> 11:46
> 15:35
> 17:36

thanks, that's very nice.

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Just one addition: I think it will be perfectly fine if the current 
suggestion is added now. I guess adding additional features later will 
be always possible, right? I don't know what the plans are for the next 
org release, and I don't want this question here to stand in the way.


Denis

Am 14.06.2021 um 13:45 schrieb Denis Maier:

Below a few examples of what I mean.

WDYT? Am I missing something?

Denis
===
#+cite_export: csl
#+cite_export: csl 
"C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"

#+bibliography: test.bib

* Original source

"A quotation ending with a period."

"A quotation ending without punctuation"

* Author-date style input (= semantically non-strict input)

"A quotation ending with a period" [cite: @hoel-71-whole].

"A quotation ending without punctuation" [cite: @hoel-71-whole].

** author-date output with language: en-us
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** author-date output with language: de
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** note style output with language: en-us
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period."[1]

Expected: "A quotation ending without punctuation."[1]
Actual:   "A quotation ending without punctuation."[1]

=> ok

** note style output with language: en-gb or de
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period".[1]

Expected: "A quotation ending without punctuation".[1]
Actual:   "A quotation ending without punctuation".[1]

=> Here, we cannot distinguish between the two cases as we don't know 
whether punctuation appears in the original source.


* Note style input (=semantically strict input)

"A quotation ending with a period." [cite: @hoel-71-whole]

"A quotation ending without punctuation". [cite: @hoel-71-whole]

As the input preserves the location of punctuation in the original 
material, I'd say it should be much easier to deal with this. We don't 
have to add information which isn't in the input, but rather we'll just 
have to move any punctuation to after the citation object. Maybe I'm 
missing something, but to me this looks like a much simpler operation 
than going in the opposite direction.


Maybe we should stop talking about author date vs note style input, but 
rather about strict vs. non-strict input. And, I think that's the whole 
issue: going from strict to non-strict is easy while the other way is 
more complicated; at least, it would require some more efforts to 
support the last case (going from non-strict input to note style output 
with a language that requires strict output.

=

Am 14.06.2021 um 00:47 schrieb Bruce D'Arcus:

I'll let you two sort it out; I don't have a position.

On Sun, Jun 13, 2021, 3:23 PM Denis Maier > wrote:




Bruce D'Arcus mailto:bdar...@gmail.com>> hat
am 14.06.2021 00:04 geschrieben:


Nicolas explained the reverse is out of scope,

IIRC, it was out of scope ATM.

and gave a reasonable explanation why (because much harder to
reconstruct missing information IIRC).

That's where I disagree. I think the opposite is true.


On Sun, Jun 13, 2021, 2:54 PM Denis Maier mailto:denisma...@mailbox.org>> wrote:

Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> Hello,
>
> Denis Maier mailto:denisma...@mailbox.org>> writes:
>
>> Yes, good this is coming.
>
> As a step forward, I rebased wip-cite-new branch with more
support for
> note numbers handling.
>
> I added three customizable variables:
>
> - org-cite-adjust-note-numbers, which simply allows the
user to toggle
>    punctuation and note number moving (on by default).
>
> - org-cite-note-rules, which defines what rules to apply
according to
>    locale, expressed as a language tag, as in RFC 4646.
>
> - org-cite-punctuation-marks, which lists strings
recognized as
>    punctuation in the process.
>
> `csl' and `basic' processors now both make use of this.
>
> I'd appreciate some feedback, in particular about the
docstrings of the
> variables above. I focused on the "note numbers" topic
instead of
> "punctuation" since I found the latter too generic.
>
> Also, there are some points 

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Below a few examples of what I mean.

WDYT? Am I missing something?

Denis
===
#+cite_export: csl
#+cite_export: csl 
"C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"

#+bibliography: test.bib

* Original source

"A quotation ending with a period."

"A quotation ending without punctuation"

* Author-date style input (= semantically non-strict input)

"A quotation ending with a period" [cite: @hoel-71-whole].

"A quotation ending without punctuation" [cite: @hoel-71-whole].

** author-date output with language: en-us
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** author-date output with language: de
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** note style output with language: en-us
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period."[1]

Expected: "A quotation ending without punctuation."[1]
Actual:   "A quotation ending without punctuation."[1]

=> ok

** note style output with language: en-gb or de
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period".[1]

Expected: "A quotation ending without punctuation".[1]
Actual:   "A quotation ending without punctuation".[1]

=> Here, we cannot distinguish between the two cases as we don't know 
whether punctuation appears in the original source.


* Note style input (=semantically strict input)

"A quotation ending with a period." [cite: @hoel-71-whole]

"A quotation ending without punctuation". [cite: @hoel-71-whole]

As the input preserves the location of punctuation in the original 
material, I'd say it should be much easier to deal with this. We don't 
have to add information which isn't in the input, but rather we'll just 
have to move any punctuation to after the citation object. Maybe I'm 
missing something, but to me this looks like a much simpler operation 
than going in the opposite direction.


Maybe we should stop talking about author date vs note style input, but 
rather about strict vs. non-strict input. And, I think that's the whole 
issue: going from strict to non-strict is easy while the other way is 
more complicated; at least, it would require some more efforts to 
support the last case (going from non-strict input to note style output 
with a language that requires strict output.

=

Am 14.06.2021 um 00:47 schrieb Bruce D'Arcus:

I'll let you two sort it out; I don't have a position.

On Sun, Jun 13, 2021, 3:23 PM Denis Maier > wrote:




Bruce D'Arcus mailto:bdar...@gmail.com>> hat
am 14.06.2021 00:04 geschrieben:


Nicolas explained the reverse is out of scope,

IIRC, it was out of scope ATM.

and gave a reasonable explanation why (because much harder to
reconstruct missing information IIRC).

That's where I disagree. I think the opposite is true.


On Sun, Jun 13, 2021, 2:54 PM Denis Maier mailto:denisma...@mailbox.org>> wrote:

Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> Hello,
>
> Denis Maier mailto:denisma...@mailbox.org>> writes:
>
>> Yes, good this is coming.
>
> As a step forward, I rebased wip-cite-new branch with more
support for
> note numbers handling.
>
> I added three customizable variables:
>
> - org-cite-adjust-note-numbers, which simply allows the
user to toggle
>    punctuation and note number moving (on by default).
>
> - org-cite-note-rules, which defines what rules to apply
according to
>    locale, expressed as a language tag, as in RFC 4646.
>
> - org-cite-punctuation-marks, which lists strings
recognized as
>    punctuation in the process.
>
> `csl' and `basic' processors now both make use of this.
>
> I'd appreciate some feedback, in particular about the
docstrings of the
> variables above. I focused on the "note numbers" topic
instead of
> "punctuation" since I found the latter too generic.
>
> Also, there are some points that may need to be discussed:
>
> - I'm not sure about the `org-cite-punctuation-marks'
variable being
>    global, i.e., not locale-specific.
>
> - There is no support for this in LaTeX-derived back-ends,
because
>    I don't know when a citation is going to become a

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
>

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

[Christian Moe]

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?

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> I have uploaded the (very) initial version of my package
> org-critical-edition:
>
> https://gitlab.com/maciaschain/org-critical-edition
>
> This package lets you prepare a philological critical edition in Org
> Mode. The natural output is LaTeX with the reledmac package
> (https://www.ctan.org/pkg/reledmac).
>
> (For those who are not philologists, this is an example of critical
> edition that I typesetted recently: https://imgur.com/a/drqCib5)
>
> Feedback welcome!
>
> Best regards,
>
> Juan Manuel

Re: literate programming, development log -- ideas? (ominbus reply)

[Greg Minshall]

Tim,, again thanks for your workflow/org-growth, and also for the git
tutorial in your separate reply to S Banya.  cheers, Greg