Re: multipage html output

[Rudolf Adamkovič]

Orm Finnendahl  writes:

> [...] Let me know how to proceed.

CC: Ihor :)

Rudy
-- 
"Chop your own wood and it will warm you twice."  --- Henry Ford;
Francis Kinloch, 1819; Henry David Thoreau, 1854

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Re: org-element--cache: Added org-data parent to non-headline element

[martyhiatt]

On 8/17/24 08:12, Ihor Radchenko wrote:

Ihor Radchenko  writes:


i had another go:

- i made a purely lorem ipsum org file (can share if needed)
- loaded a minimal emacs config (the one i use for testing/debugging 
mastodon.el, can share)
- loaded a really minimal org config (can share if needed)
- loaded the org file
- repeated the already mentioned steps, triggering the error.

with this test file, when the error is triggered, the way the file breaks is 
that a second-level TODO heading is split after the first star, becoming a 
top-level heading with a single star on a previous line (often, not sure if 
always, i think other breakages happen also, with my original file other 
breakages happened).


A full reproducer I can follow from emacs -Q (or make repro) would be very nice.


May I know if you had a time to look into creating a reproducer?



Hi Ihor,

i don't know what that is, nor how to do that, and i don't know org's codebase 
at all. I'm not a professional programmer. I thought if I reproduced it with a 
lorem ipsum file and minimal config it would be reproducible outside my own 
setup.

M

Re: org-element--cache: Added org-data parent to non-headline element

[martyhiatt]

On 8/17/24 08:12, Ihor Radchenko wrote:

Ihor Radchenko  writes:


i had another go:

- i made a purely lorem ipsum org file (can share if needed)
- loaded a minimal emacs config (the one i use for testing/debugging 
mastodon.el, can share)
- loaded a really minimal org config (can share if needed)
- loaded the org file
- repeated the already mentioned steps, triggering the error.

with this test file, when the error is triggered, the way the file breaks is 
that a second-level TODO heading is split after the first star, becoming a 
top-level heading with a single star on a previous line (often, not sure if 
always, i think other breakages happen also, with my original file other 
breakages happened).


A full reproducer I can follow from emacs -Q (or make repro) would be very nice.


May I know if you had a time to look into creating a reproducer?



Hi Ihor,

i don't know what that is, nor how to do that, and i don't know org's codebase 
at all. I'm not a professional programmer. I thought if I reproduced it with a 
lorem ipsum file and minimal config it would be reproducible outside my own 
setup.

M

[orgmode] Better recurrence for SCHEDULED and DEADLINE

[Moakt Temporary Email]

Greetings,

I want to suggest that SCHEDULED and DEADLINE support things like "first Monday 
of the month" like cron.

Thanks

Re: multipage html output

[Ihor Radchenko]

Orm Finnendahl  writes:

>> I do not feel like :multipage-split-function is supposed to be export
>> _option_. It is more internal. That's why :translate-alist, where the
>> internals like templates and transcoders lie.
>
> That's how I had it before, but I reasoned it is not a transcoding
> function either, so I was unsure. Anyway I reversed it.

Thanks!

>> This is not a transcoder's job to export its contents.
>> Please move special handling of org-page AST nodes to `org-export-data'.
>
> done.

> + ((and (eq (org-element-type data) 'org-data)
> +   (plist-get info :multipage))
> +  (mapcar (lambda (org-page)
> +(org-export-data org-page info))
> +  (org-element-contents data)))
> + ;; Element/Object with contents.

I am looking at this, and it feels like a wrong direction to go,
especially if we want to generalize multi-file export to non-pages as
well (e.g. formula exported as mathml file and as a link inside actual
exported .odt file).

Let's try to do it differently:

1. Introduce a new INFO plist field :multipage-pages - a list of extra
   pages to be exported in addition to the main document
2. Transocders can populate the list as needed, in addition to their
   normal return value, which may be a link to the page, for example
3. "pages" in the list, can be constructed using
   `org-export-with-backend' or other usual means to export data.
4. org-export-as will process all the pages from :multipage-pages in
   addition to the one returned by `org-export-data'.

I believe that this approach should be the least breaking and the most flexible.

WDYT?   

>> >(info (cl-list* ;; add :tl-headline and :tl-headline-number to 
>> info
>> >   :tl-headline headline
>> >   :tl-headline-number
>> >   (alist-get
>> >headline
>> >(plist-get info :headline-numbering))
>> >   info))
>> 
>> May you please explain what is the purpose of constructing custom INFO
>> plist, what all these parameters do, and why you re-do the export again
>> in the transcoder discarding the CONTENTS argument provided?
>> ...
> :tl-headline and :tl-headline-numbering are needed for constructing
> the side toc and the footnote section on each page. They are needed in
> org-html-multipage-toc, called by org-html-multipage-template and in
> org-html-footnote-section called from
> org-html-multipage-inner-template. At that stage there is no
> information about the page, the templates are on. Let me know if you
> have a better idea how to provide/access that information, I found a
> temporary addition to info the most natural way. As it will be needed
> by any multipage backend which wants to determine the footnotes for a
> page, I think there should be a generic solution in ox.el.
>
> As :tl-headline-numbering can be determined from the tl-headline
> within org-html-multipage-toc, I can get rid of that if you
> prefer. Let me know how to proceed.

With my idea above, we handle the actual page rendering to a custom
backend, which can reuse the normal TOC machinery, possibly encapsulated
into sub-backend parameters. We can provide any additional info that is
necessary within such sub-backend.

Do note that we should not assume that each page corresponds to a
headline in ox.el. It may be anything.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Summation of effort estimates in columnview dblock

[General discussions about Org-mode.]

Ihor Radchenko  writes:

> [...]
> I agree that the manual can be improved. It would be nice if someone
> actively using column views contributed such an improvement ;)
> [...]

Ok, I've given it a try.

>From 4bb89a24269ee2ef42ed2b1c5713faa37b33f72d Mon Sep 17 00:00:00 2001
From: Alexander Adolf 
Date: Sat, 17 Aug 2024 18:29:51 +0200
Subject: [PATCH] doc/org-manual.org: better explain columnview column summary
 types

* doc/org-manual.org (Column attributes): Shed more words on how
summary types for columnview columns work, which property values are
taken into account, and which property values get updated in the
buffer under what circumstances.
---
 doc/org-manual.org | 39 +++
 etc/ORG-NEWS   |  6 ++
 2 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6cf51ebca..b435a4526 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -5734,10 +5734,8 @@ optional.  The individual parts have the following meaning:
 
 - {{{var(SUMMARY-TYPE)}}} ::
 
-  The summary type.  If specified, the column values for parent nodes
-  are computed from the children[fn:: If more than one summary type
-  applies to the same property, the parent values are computed
-  according to the first of them.].
+  The summary type.  If specified, the column and property values for
+  ancestor nodes are computed from their descendants.
 
   Supported summary types are:
 
@@ -5810,6 +5808,39 @@ children have been checked.  The =CLOCKSUM= and =CLOCKSUM_T= columns
 are special, they list the sums of CLOCK intervals in the subtree,
 either for all clocks or just for today.
 
+When using summary types for non-special properties like the
+=Time_Estimate= column in the example, the collection of data for the
+summary in each subtree within scope will start at the furthest
+descendant nodes which have the respective property.  When any of
+their sibling nodes also have the property in question, all the
+siblings' values of the property are used to compute the summary
+result according to the summary type specified.  Then the closest
+ancestor node which also has the respective property is located, and
+the buffer is modified as the value of that node's property is updated
+with the summary result of its descendant nodes.  This process is
+repeated starting from each updated node, until the top of each
+subtree has been reached, and all branches of the subtree have been
+traversed.  Since the property values of ancestor nodes get updated in
+this process, only the furthest descendant nodes which have the
+respective property along each subtree axis will contribute to the
+summary results.
+
+When a non-special property appears more than once in a columns
+definition, and with different summary type specifications (including
+with none), the values of that property present on any ancestor nodes
+will be updated according to the summary type specification (if any)
+of the first instance of the property in the columns definition.
+Hence, when the first occurrence of a property in a columns definition
+has no summary type specification, the property values of ancestor
+nodes will not be updated.
+
+When using summary types with columns for the special properties
+=CLOCKSUM= and =CLOCKSUM_T=, the summary process will be different.
+First, as these are special properties that are not stored in property
+drawers, no updates will be made to any nodes involved.  Secondly, the
+summary value will be computed not just from the furthest descendant
+nodes, but from the special property values of all nodes in a subtree.
+
 *** Using column view
 :PROPERTIES:
 :DESCRIPTION: How to create and use column view.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6f858f3ca..3e81f0f46 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -187,6 +187,12 @@ This way, attachments will remain accessible when opening symlinked Org file.
 When no attach dir exists, Org mode will still prefer creating it in
 the "default" directory - where the symlink is located.
 
+*** improved description of how summary types in column definitions for columnview work
+
+Made the manual more explicit about how summary types work for
+non-special and special properties, and when which property's value
+gets updated in the buffer when a columnview is updated.
+
 * Version 9.7
 
 ** Important announcements and breaking changes
-- 
2.39.3 (Apple Git-146)

Re: org-latex-preview, pNiceArray (running latex twice)

[Karthik Chikmagalur]

> Karthik, may you please check if this is going to work with latex
> preview branch?

Tested: It does not work, since LaTeX only runs once in the new LaTeX preview
system as well.

We can adapt the async process chain to run LaTeX twice (or more), but
we can't figure out when this should happen based on the LaTeX contents.

I'll look into adapting the new system to run latexmk, but I'm not
hopeful.

Karthik

Re: [RFC] latex preview and pdflatex-only packages (was: org-latex-preview, pNiceArray (running latex twice))

[Karthik Chikmagalur]

>> Well, there are a couple of packages that explicitly state that they
>> only work with pdflatex, nicematrix, todonotes and ocgx for example
>
> This is a surprise.
>
> Are there packages that are an opposite - do not work with pdflatex, but
> work with bare latex?
>
> Karthik, any thoughts on this?

A surprise to me as well.  I think it is outside the purview of
org-latex-preview to handle org-latex-compiler + LaTeX package
incompatibilities.

I am making a note to add support for latexmk to the async process
chain though.

Karthik

Re: org-latex-preview, pNiceArray (running latex twice)

[Uwe Brauer]

>>> "KC" == Karthik Chikmagalur  writes:

>> Karthik, may you please check if this is going to work with latex
>> preview branch?

> Tested: It does not work, since LaTeX only runs once in the new LaTeX preview
> system as well.

> We can adapt the async process chain to run LaTeX twice (or more), but
> we can't figure out when this should happen based on the LaTeX contents.

> I'll look into adapting the new system to run latexmk, but I'm not
> hopeful.

I am a bit confused. I managed to tweak the configuration for the
imagemagick to satisfy my needs.

Is this not good enough?



-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 



smime.p7s
Description: S/MIME cryptographic signature