[FR] Make notion of "modification time" configurable during publishing

[Suhail Singh]

Ihor Radchenko  writes:

> - weary-traveler asked to add a new feature to Org publishing system.
>
>   The use case is publishing using CI tasks, where a new, fresh image
>   is created every time a website is re-published. Such image does
>   not preserve the original modification times of the source Org
>   files, making Org publish re-generate everything every single time.
>
>   The new suggested feature is (optionally) using last git commit time
>   instead of file modification time.

>   - Conclusion: the feature request is to be submitted to mailing list
> for more detailed discussion.

The requested feature is for the notion of "modification time" to be
configurable by the user. Even in the specific situation quoted above,
different users may desire different alternative notions of
"modification time". For instance,

- the value of the DATE keyword
- if using git as vc, the "git author date"
- if using git as vc, the "git commit date"

It would help for the notion of "modification time" (currently
hard-coded as file-attribute-modification-time ) to be configurable in
the following functions:

- org-publish-cache-mtime-of-src: this is used to decide whether or not
  a particular file needs to be republished. I.e., the function at the
  heart of the motivating situation discussed during the meetup.
  
- org-publish-find-date: this is used during the publishing of sitemaps
  where the modification time is used as the default value (for
  directories the filesystem modification time is the only value ever
  used).

The user-supplied "modification time" function would take the FILE as an
input and its output would be in the style of `current-time'.  A default
value could be provided for above cases which preserves current
semantics.  Additional inputs to such a "modification time" function
that may be helpful (though may not be necessary) are the PROJECT-PLIST
and the PUB-DIR.

>   - Org already has somewhat similar functionality in a form of
> ={{{modification-time ...}}}= macro. See
> [[info:org#Macro Replacement][org#Macro Replacement]] section
> of Org manual.

I believe the modification-time macro for git uses the "author date".
This may not always be the desirable "vc-modification-time" notion.
However, when it's not, the user has the freedom to create (and use)
their own macro.

>   - Also, several other places in Org are relying on file modification
> time and might need to be considered.

org-html-format-spec is one such place that may additionally benefit.
However, in that case it may be sufficient to simply mirror what's done
for the modification-time macro. I.e., consider only one notion of
"vc-modification-time" and have it be the "author date" semantics.

-- 
Suhail

Re: [BUG] tikz latex figures don't render properly in the html output. [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[chris]

On Tuesday, September 19, 2023 10:07:07 AM UTC Ihor Radchenko wrote:
> Rudolf Adamkovič  writes:
> > tusharhero--- via "General discussions about Org-mode."
> > 
> >  writes:
> >> \begin{tikzpicture}
> >> \draw (0,0) circle [radius=2cm];
> >> \end{tikzpicture}
> > 
> > ... But, but, but!  There
> > is a new LaTeX preview system in works [2],
> > and it fixes a lot of problems out of the
> > box, including yours!
> 

At some point in the past I've experimented with
https://tikzjax.com/
So I changed something somewhere in the org-mode config and it just worked, it 
was quite straightforward to do. I however probably don't have notes on how I 
did it.
I didn't insist in that direction because it wasn't working with TikZ libs, 
specifically tikzcd.
But it was really nice.
This however is implementing many TikZ libraries, I don't know if it's usable 
with org-mode, but it looks totally great, it's from Obsidian but it's on 
Github
https://github.com/artisticat1/obsidian-tikzjax
IMO this sort of solution is very nice.

> Fist, for the record...
> Confirmed.
> 
> I can also confirm that TEC's feature branch does not have this bug.

What is TEC?

> 
> On main, the bug is caused by horrible heuristics in
> `org-html--latex-environment-numbered-p' and
> `org-html--unlabel-latex-environment', which make a naive assumption
> that \begin{foo*} is always available and codifies unnumbered version of
> environment.
> 
> However, \begin{tikzpicture*} environment is not valid. Moreover,
> \begin{tikzpicture} is not numbered either (just as many other
> non-equation environments).
> 
> That said, I am not sure what is going on with numbering in TEC's branch
> - the above two functions are left in the code, __unused__. Which
> indicates that we might also have some feature regression on that branch.
> Timothy, any comments?

Re: [PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom)

[Leo Butler]

On Wed, Sep 20 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
> May you clarify the purpose of "linenum"?
>>> Do I understand correctly that the above will simply affect debug output
>>> when maxima references where a problematic line is located in the source?
>>
>> No, it affects how output labels are printed. With this value, the
>> "first" line in the source block receives the line number 1; without it,
>> it would get 2.
>
> Ok. This should be documented in the commit message and possibly in the
> code itself.

I think it makes most sense to put in a source-code comment, explaining
the why. That is what I have done.

>
>>>
>>(unless (or (string-match "batch" line)
>>(string-match "^rat: replaced 
>> .*$" line)
>>(string-match "^;;; Loading 
>> #P" line)
>> +  (string-match "^read and 
>> interpret" line)
>> +  (string-match 
>> "^(%\\([io]-?[0-9]+\\))[ ]+$" line)
>
> May you explain why you added these two conditions?

>>
>> 
>>
>>>
>>> May empty lines be intentional in some maxima code?
>>
>> A blank line is simply skipped by the maxima reader; an empty input line
>> is a syntax error.
>>
>> However, "empty" output may appear, so I have modified that filter.
>
>+  (string-match 
> "^(%\\([io]-?[0-9]+\\))[ ]+$" line)
>
> It would be nice to add a comment line explaining what this regexp
> matches against.

Ok. I think it makes the most sense to explain the purpose of each
regexp, new and old, and to make this somewhat extensible.

What I have done is cut out that undocumented filter, put the regexps
into a new variable (`org-babel-maxima--output-filter-regexps'), added
source-code comments to explain what each one does and added a new
function (`org-babel-maxima--output-filter') that replaces the old
filter in `org-babel-execute:maxima'.


>
>> * (org-babel-maxima--graphic-package-options): an alist of Maxima
>> graphics packages and the Maxima code to set up that package.
>
> This is a bit confusing. I'd say "A new variable storing alist of Maxima ..."
>
>> * (org-babel-maxima--default-epilogue): an alist of the clean-up code
>> that is run at end of a `graphical-output' or `non-graphical-output'
>> source block.
>
> Same here.
> Basically, it should be clear from the commit message when you add new
> variables and when you modify existing.

Points taken.

>
>> * (org-babel-maxima-expand): prepare the source block for
>> execution.
>
> This is vague. Please explain what is changed in more details.

Done.

>
>> * (org-babel-execute:maxima): use the :batch header argument and
>> `org-babel-maxima--command-arguments-default' to execute the source
>> block.  Add a couple extra regexps to filter the output of a batch-ed
>> source block.
>
> This reads better compared to the above.
>
>> +(defconst org-babel-header-args:maxima
>> +  '((batch   . :any)
>
> Why :any? Only two values are allowed here.
>
>> +(graphics-pkg. :any))
>
> Same. The value is a closed list.

I have made the change requested.

However, beyond the documentation value, I don't see this variable's
values being used.

>
>> +(defvar org-babel-maxima--command-arguments-default
>> +  "--very-quiet"
>> +  "Command-line arguments sent to Maxima by default.  If the
>
> Please keep the first line as a single sentence.
> See 
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html
>
>> +(defvar org-babel-maxima--default-epilogue
>> +  '((graphical-output . "gnuplot_close ()$")
>> +(non-graphical-output . ""))
>> +  "The final Maxima code executed in a source block.  An alist with
>
> Same problem with the first line.

Fixed. I don't use `apropos', so I didn't see the problem (and I had
failed to absorb everything in §D.6).

Please see the attached, revised patch. It fixes the problems that you
have identified–except for the way that the gnuplot terminal is
determined. I would like to leave that for a subsequent patch, mainly
because this one has become quite large.

Best regards,
Leo

From 078e29f13f15305e291b1c0e46e306d633a8b93a Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 19 Sep 2023 13:36:06 -0500
Subject: [PATCH] * lisp/ob-maxima.el: enable use of `batch' loader and `draw'

* (org-babel-header-args:maxima): Document the two new header
arguments (batch and graphics-pkg) that are specific to ob-maxima.
* (org-babel-maxima--command-arguments-default): A new variable
storing the default command-line argument(s).  This value was
hard-coded in `org-babel-maxima:execute'.
* (org-babel-maxima--graphic-package-options): A new variable that
stores an alist of Maxima graphics packages and the Maxima code to set
up that package.
* (org-babel-maxima--default-epilogue): A new variable that 

Re: Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

Some new information about Babel that may be of interest to the topic of
this thread.

I have received an email from Javier Bezos (whom I know from the
Spanish-speaking TeX users' mailing list), who is the current babel
mantainer, as well as the person responsible for all the improvements
and new features of the package. Although he is not currently an
Emacs/Org user, he has been following this thread with great interest,
so I am transmitting here, with his permission, some interesting
comments from him:

#+begin_quote

[...] I am very interested in all possible improvements in babel so that
it integrates as best as possible with automatically generated files.
Among them are the possibility of using BCP47 codes or using a language
(at least basically) without the need for a prior declaration. These are
things already done, but there are others that can still be improved.

[...] any suggestion for improvement is very welcome [...]

Among the things I agree on is name issue. I am unifying the dice in the
CLDR as much as possible, and already, in fact, it is very advanced:

https://latex3.github.io/babel/guides/locale-naming.html

[...]

The ini files contain information that is not actually used by babel,
but that could be useful in other packages or even external
applications. One of them is the name of the language in English and in
the vernacular form, as they are in the Unicode CLDR. As I explain in
the link I gave you, the purpose is that the babel name is based on the
CLDR name with mechanical changes. Anyway, CLDR names are also included
in the ini files, to establish correspondences more easily.

#+end_quote

Re: org id link to arbitrary place in an org file

[Max Nikulin]

On 20/09/2023 19:15, Ihor Radchenko wrote:

Samuel Wales writes:


i'd like to have an org-id link to a place in a different file.  a
paragraph or even more arbitrary.

is this possible with current org technology?  [i think recent
discussion did not mention id markers.]


It is currently not possible.
ID links only work on headings and inlinetasks now.


I think, Samuel expect support of id: anchors for "#+name:" or 
<>.


I remember discussions of search part of id links, but it is more 
questionable feature from my point of view.

Re: org id link to arbitrary place in an org file

[Ihor Radchenko]

Samuel Wales  writes:

> i know we talked about something like this recently, perhaps related
> to inline tasks, perhaps not.  apologies redundancy.
>
> i'd like to have an org-id link to a place in a different file.  a
> paragraph or even more arbitrary.
>
> is this possible with current org technology?  [i think recent
> discussion did not mention id markers.]

It is currently not possible.
ID links only work on headings and inlinetasks now.

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

Re: [PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom)

[Ihor Radchenko]

Leo Butler  writes:

 May you clarify the purpose of "linenum"?
>> Do I understand correctly that the above will simply affect debug output
>> when maxima references where a problematic line is located in the source?
>
> No, it affects how output labels are printed. With this value, the
> "first" line in the source block receives the line number 1; without it,
> it would get 2.

Ok. This should be documented in the commit message and possibly in the
code itself.

>>
>(unless (or (string-match "batch" line)
>(string-match "^rat: replaced 
> .*$" line)
>(string-match "^;;; Loading 
> #P" line)
> +  (string-match "^read and 
> interpret" line)
> +  (string-match 
> "^(%\\([io]-?[0-9]+\\))[ ]+$" line)

 May you explain why you added these two conditions?
>>>
>
> 
>
>>
>> May empty lines be intentional in some maxima code?
>
> A blank line is simply skipped by the maxima reader; an empty input line
> is a syntax error.
>
> However, "empty" output may appear, so I have modified that filter.

   +  (string-match 
"^(%\\([io]-?[0-9]+\\))[ ]+$" line)

It would be nice to add a comment line explaining what this regexp
matches against.

> * (org-babel-maxima--graphic-package-options): an alist of Maxima
> graphics packages and the Maxima code to set up that package.

This is a bit confusing. I'd say "A new variable storing alist of Maxima ..."

> * (org-babel-maxima--default-epilogue): an alist of the clean-up code
> that is run at end of a `graphical-output' or `non-graphical-output'
> source block.

Same here.
Basically, it should be clear from the commit message when you add new
variables and when you modify existing.

> * (org-babel-maxima-expand): prepare the source block for
> execution.

This is vague. Please explain what is changed in more details.

> * (org-babel-execute:maxima): use the :batch header argument and
> `org-babel-maxima--command-arguments-default' to execute the source
> block.  Add a couple extra regexps to filter the output of a batch-ed
> source block.

This reads better compared to the above.

> +(defconst org-babel-header-args:maxima
> +  '((batch   . :any)

Why :any? Only two values are allowed here.

> +(graphics-pkg. :any))

Same. The value is a closed list.

> +(defvar org-babel-maxima--command-arguments-default
> +  "--very-quiet"
> +  "Command-line arguments sent to Maxima by default.  If the

Please keep the first line as a single sentence.
See 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html

> +(defvar org-babel-maxima--default-epilogue
> +  '((graphical-output . "gnuplot_close ()$")
> +(non-graphical-output . ""))
> +  "The final Maxima code executed in a source block.  An alist with

Same problem with the first line.

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

Re: [PATCH] Re: Description list with " :: " in the tag.

[Ihor Radchenko]

"Tom Alexander"  writes:

> Sorry for the delay, I've been busy in the IRLs. I've updated the patch to 
> reflect that the parser grabs the text before the last " :: " and then parses 
> it as objects. The new patch is attached.

Thanks!
Applied, onto master, with minor amendments (fixed "of of").
https://git.sr.ht/~bzg/worg/commit/ae64e1a5

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

Re: [BUG] Warning (org-element-cache): org-element--cache: Org parser error in google.org::263. Resetting. The error was: (wrong-type-argument listp 6990) [9.7 (9.7-??-e90a8a69a @ /Users/buter/.emacs.

[Ihor Radchenko]

Renald Buter  writes:

> Offending line is 263:
> 261 * Some headline
> 262 :PROPERTIES:
> 263 :DATE: [2023-08-16 Wed]
> 264 :END:
> 265
>

Thanks for reporting!
May you please add (setq debug-on-error t) to your config and post a
backtrace next time you see parser error?

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