Re: [PATCH] New LaTeX code export option: engraved

[Ihor Radchenko]

Timothy  writes:

>> Let me learn a bit about the different code highlighting options in
>> order to understand what you offer.
>
> Sure. If it’s any help, here’s a comparison example I whipped up:
> 

Timothy, could you please not use 0x0 to share not-so-large images? 0x0
deletes uploaded files within ~1year time and this link will no longer
be valid if someone tries to read this discussion years later.

Also, this illustration makes me wonder if engrave-faces can provide a
color scheme that is mimicking minted. Generally, easy customisation of
highlight schemes could be useful. On per-src-block basis or even on
per-language basis if document contains course blocks with different
programming languages.

Best,
Ihor

Re: Concatenate properties

[John Kitchin]

I believe this is hard coded in org-entry-get-with-inheritance. The fastest
option would be an override advice with your own function that
replaces (and value " ") with (and value ""), and maybe the two other " "
with "".

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



On Thu, May 5, 2022 at 6:38 PM Tyler Grinn  wrote:

>
> I'm exporting sub-trees as pdf files for some classes I'm taking:
>
> # -*- org-use-property-inheritance: t; -*-
>
> * Class A
>   :PROPERTIES:
>   :EXPORT_FILE_NAME: support/Class A
>   :END:
> ** Assignment 1
>:PROPERTIES:
>:EXPORT_FILE_NAME+: /assignment-1
>:END:
>Some assignment for Class A
> ** Assignment 2
>:PROPERTIES:
>:EXPORT_FILE_NAME+: /assignment-2
>:END:
>Some other assignment for Class A
> * Class B
>   :PROPERTIES
>   :EXPORT_FILE_NAME: support/Class B
>   :END:
> ** Assignment 1
>:PROPERTIES:
>:EXPORT_FILE_NAME+: /assignment-1
>:END:
>Some assignment for Class B
> ** Assignment 2
>:PROPERTIES:
>:EXPORT_FILE_NAME+: /assignment-2
>:END:
>Some other assignment for Class B
>
> And this works great, except there's always a space between
> 'support/Class A' and '/assignment-1.pdf'. Is there any way to
> concatenate the two properties rather than join them with spaces?
>
> Best,
>
> Tyler
>
>

Concatenate properties

[Tyler Grinn]

I'm exporting sub-trees as pdf files for some classes I'm taking:

# -*- org-use-property-inheritance: t; -*-

* Class A
  :PROPERTIES:
  :EXPORT_FILE_NAME: support/Class A
  :END:
** Assignment 1
   :PROPERTIES:
   :EXPORT_FILE_NAME+: /assignment-1
   :END:
   Some assignment for Class A
** Assignment 2
   :PROPERTIES:
   :EXPORT_FILE_NAME+: /assignment-2
   :END:
   Some other assignment for Class A
* Class B
  :PROPERTIES
  :EXPORT_FILE_NAME: support/Class B
  :END:
** Assignment 1
   :PROPERTIES:
   :EXPORT_FILE_NAME+: /assignment-1
   :END:
   Some assignment for Class B
** Assignment 2
   :PROPERTIES:
   :EXPORT_FILE_NAME+: /assignment-2
   :END:
   Some other assignment for Class B
   
And this works great, except there's always a space between
'support/Class A' and '/assignment-1.pdf'. Is there any way to
concatenate the two properties rather than join them with spaces?

Best,

Tyler

Re: Citation glitch

[Alan Tyree]

Thanks, Bruce. 0.9 is the current version from Melpa-stable and appears to
have been released last August.

I'll update as you suggest.
Cheers,
Alan

On Thu, 5 May 2022 at 23:32, Bruce D'Arcus  wrote:

> You don't need citeproc-org, which is deprecated AFAIK.
>
> Do update citeproc-el. I'm not sure when he tagged v0.9, but this is
> the commit that should have fixed it.
>
>
> https://github.com/andras-simonyi/citeproc-el/commit/a702e73dcbd34cbda3a7465cf0cace7529f41dcd
>
> If you still have problems, you might report it to that project?
>
> On Wed, May 4, 2022 at 8:45 PM Alan Tyree  wrote:
> >
> > I'm not sure.
> >
> > citeproc-0.9
> > citeproc-org-0.2.4
> >
> > On Thu, 5 May 2022 at 10:34, Bruce D'Arcus  wrote:
> >>
> >> It seems this should have been fixed late in citeproc-el in 2021:
> >>
> >> https://github.com/andras-simonyi/citeproc-el/issues/72
> >>
> >> Are you using the most up-to-date code?
> >>
> >> On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:
> >>>
> >>> G'day,
> >>> I have a citation problem. The bibtex entry is:
> >>> @TechReport{name32:_some,
> >>>   author = {{Some Company Name}},
> >>>   title = {Some silly internal document},
> >>>   institution =  {Some Company Name Ltd},
> >>>   year = 1832}
> >>>
> >>> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
> >>>
> >>> Org exports to html: Name, Some Company, Some Silly Internal Document
> (Some Company Name Ltd, 1832).
> >>>
> >>> I thought it was a CSL problem, but pandoc exports it correctly as
> Some Company Name, etc.
> >>>
> >>> Any help appreciated,
> >>> Alan
> >>>
> >>>
> >>> --
> >>> Alan L Tyreehttp://www2.austlii.edu.au/~alan
> >>>
> >
> >
> > --
> > Alan L Tyreehttp://www2.austlii.edu.au/~alan
> >
>


-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: Recent changes in org-fold regarding emphasize visibility

[Daniel Fleischer]

Ihor Radchenko  writes:

> Fixed on main by d2a459d25

I've tried the commit. I think there are still issues. E.g. given a
folded headline

* Introduction...|
* Section

Inserting text at that point will do the following thing depending on
`org-fold-catch-invisible-edits':

- error : it inserts the text without unfolding; most dangerous.
- show : unfold, insert the text without displaying it; dangerous.
- show-and-error: unfold but inserts the text anyways.


Thanks,

-- 

Daniel Fleischer

org-fold documentation

[Vikas Rawal]

After upgrading to 9.5.3, I am getting warnings such as this, which I
suspect are due to org-fold.et.

Warning (comp): org-fold.el:834:27: Warning: Unused lexical variable
`org-hide-macro-markers' Disable showing Disable logging
Warning (comp): org.el:76:30: Warning: Package cl is deprecated Disable
showing Disable logging
Warning (comp): ox.el:79:1: Warning: the function ‘org-back-to-heading’
might not be defined at runtime. Disable showing Disable logging
Warning (comp): ox.el:79:1: Warning: the function
‘org-next-visible-heading’ might not be defined at runtime. Disable showing
Disable logging
Warning (comp): ox.el:79:1: Warning: the function ‘org-at-heading-p’ might
not be defined at runtime. Disable showing Disable logging

Is org-fold.el documented already? Any pointers to what might be causing
the above?

Thanks,

V.

Re: [PATCH] New LaTeX code export option: engraved

[Max Nikulin]

On 05/05/2022 22:17, Timothy wrote:

Subject: [PATCH 1/4] ox-latex: Refactor `org-latex-src-block'


When I was trying to fix an issue with caption, I was not brave enough 
for massive changes. I do not like the original code of the function.


There are some unit tests for exporting of src blocks. Maybe the new 
option should be tested as well.



+(defun org-latex-src-block--verbatim
+(src-block info _lang caption caption-above-p _label
+   _num-start _retain-labels _attributes float)


On the one hand I have no a better suggestion, but on the other hand 10 
arguments is too much for straightforward code from my point of view. 
Unsure that getting parameters in each function or passing a property 
list would not be worse however.


It reminds me a case when a colleague failed in despair trying to figure 
out what was wrong with his 15 argument fortran function. I do not 
remember exactly whether it was a missed argument or an extra one. The 
last one was assumed to be a parameter (constant) and the identifier was 
not available in debugger since compiler just substituted the number 
without creation of a symbol and it added even more confusion.


My other notes are rather loosely related to your patches. The issues 
may be postponed till someone will start a new thread for them. My hope 
is that some of them might be easily addressed so that they will not 
need separate testing.


A problem with percent sign in captions is tracked on 
updates.orgmode.org. Some environments has not fixed yet:

https://list.orgmode.org/yt2pr01mb45101e27dc6251d8f8b7b366f6...@yt2pr01mb4510.canprd01.prod.outlook.com/

That time I was puzzled why the option is named "multicolumn" while only 
regular "figure" is added:



+(cond ((string= "multicolumn" float)
+   (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"


If language is added to "#+begin_example:" than the block content is 
properly fontified in the Emacs buffer. It would be great to treat such 
example similar to source block during export. When some code is not 
supposed to be executed, it is natural to use example block. I am 
curious if new functions may be reused.

Re: [PATCH] New LaTeX code export option: engraved

[Timothy]

> [5. text/x-patch; 0004-ox-latex-Introduce-engraved-code-highlighting.patch]…

Ooops, I had some ucommited changes. The correct version is attached.

Timothy
>From b66c291b1f0d1419742449bcde42bf0c4d620c23 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 21 Nov 2021 20:04:12 +0800
Subject: [PATCH] ox-latex: Introduce "engraved" code highlighting

* lisp/ox-latex.el (org-latex-src-block, org-latex-src-block--engraved,
org-latex-inline-src-block, org-latex-inline-src-block--engraved,
org-latex-template, org-latex-listings): Make use of the engraved-faces
package (available on ELPA) to provide an alternative LaTeX code
highlighting backend which functions similarly to htmlize.el for HTML
exports.

(org-latex-engraved-preamble, org-latex-engraved-options): Introduce
variables to construct the preamble for engraved code blocks.

* lisp/ox-beamer.el (org-beamer-template): Modify to add engrave-faces
preamble when applicable.
---
 lisp/ox-beamer.el |   9 ++
 lisp/ox-latex.el  | 273 --
 2 files changed, 272 insertions(+), 10 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 6be73c91e..73bd95539 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -857,6 +857,15 @@ (defun org-beamer-template (contents info)
  (let ((template (plist-get info :latex-hyperref-template)))
(and (stringp template)
 	(format-spec template (org-latex--format-spec info
+ ;; engrave-faces-latex preamble
+ (when (eq org-latex-listings 'engraved)
+   (let ((src-p (org-element-map (plist-get info :parse-tree)
+'(src-block inline-src-block) #'identity))
+ (fixedw-p
+  (org-element-map (plist-get info :parse-tree)
+  '(example-block fixed-width) #'identity)))
+ (when (or src-p fixedw-p)
+   (org-latex-generate-engraved-preamble info src-p
  ;; Document start.
  "\\begin{document}\n\n"
  ;; Title command.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 4181db175..83bb6f078 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -37,6 +37,8 @@ (defvar org-latex-default-packages-alist)
 (defvar org-latex-packages-alist)
 (defvar orgtbl-exp-regexp)
 
+(declare-function engrave-faces-latex-gen-preamble "ext:engrave-faces-latex")
+(declare-function engrave-faces-latex-buffer "ext:engrave-faces-latex")
 
 
 ;;; Define Back-End
@@ -125,6 +127,8 @@ (org-export-define-backend 'latex
 (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
 (:latex-default-table-mode nil nil org-latex-default-table-mode)
 (:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
+(:latex-engraved-options nil nil org-latex-engraved-options)
+(:latex-engraved-preamble nil nil org-latex-engraved-preamble)
 (:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
 (:latex-footnote-separator nil nil org-latex-footnote-separator)
 (:latex-format-drawer-function nil nil org-latex-format-drawer-function)
@@ -937,22 +941,48 @@ (defcustom org-latex-listings nil
   "Non-nil means export source code using the listings package.
 
 This package will fontify source code, possibly even with color.
-If you want to use this, you also need to make LaTeX use the
-listings package, and if you want to have color, the color
-package.  Just add these to `org-latex-packages-alist', for
-example using customize, or with something like:
+There are four implementations of this functionality you may
+choose from (ordered from least to most capable):
+1. Verbatim (nil)
+2. Listings (t)
+3. Minted (minted)
+4. Engraved (engraved)
+
+The first two options provide basic syntax
+highlighting (listings), or none at all (verbatim).
+
+When using listings, you also need to make use of the LaTeX
+\"listings\" package. The \"color\" package is also needed if you
+would like color too.  These can simply be added to
+`org-latex-packages-alist', using customise or something like:
 
   (require \\='ox-latex)
   (add-to-list \\='org-latex-packages-alist \\='(\"\" \"listings\"))
   (add-to-list \\='org-latex-packages-alist \\='(\"\" \"color\"))
 
-Alternatively,
+There are two options for more comprehensive fontification. The
+first can be set with,
+
+  (setq org-latex-listings \\='engraved)
+
+which causes source code to be run through
+`engrave-faces-latex-buffer', which generates colorings using
+Emacs' font-lock information.  This requires the engrave-faces
+package (availible from ELPA), and the fvextra LaTeX package be
+installed.
+
+The styling of the engraved result can customised with
+`org-latex-engraved-preamble' and `org-latex-engraved-options'.
+The default preamble also uses the tcolorbox LaTeX package in
+addition to fvextra.
+
+The second more comprehensive option can be used with,
 
   (setq org-latex-listings \\='minted)
 
-causes source code to be exported using the minted package as
-opposed to listings.  If 

Re: Organice with local WebDAV server on PinePhone

[Eric S Fraga]

On Wednesday,  4 May 2022 at 20:24, TRS-80 wrote:
> I keep thinking that the keyboard is going to be the key[0] to achieving
> Emacs / Org Mode editing nirvana on my PinePhone.  But I will have let
> you know if that's true or not, after it arrives.  :)

My Planet Computers Gemini (mobile "phone" with keyboard) is a fantastic
little org + Emacs on the move device.  Having the keyboard completely
changes the feel of such a device.

-- 
: Eric S Fraga, with org release_9.5.2-426-gf6813d in Emacs 29.0.50

Re: [PATCH] New LaTeX code export option: engraved

[Timothy]

Hi Daniel,

> Hi Timothy, thank you very much for your work!

Thanks for the kind words 

> Let me learn a bit about the different code highlighting options in
> order to understand what you offer.

Sure. If it’s any help, here’s a comparison example I whipped up:


All the best,
Timothy

[Style] Shouldn’t the macros in org-fold-core have (indent 0)

[Anders Johansson]

Hi,
When looking through the code in org-fold-core (while debugging a tricky
problem that seems to be an interaction with org-modern, I may get back to
it) I noticed that all the macros that wrap a “body” argument have (indent
1), but I gather that they should have (indent 0), similar to for example
`with-silent-modifications`.

I didn’t want to create a patch, since it would involve whitespace changes
on quite a lot of places, but I thought it could be good to highlight now
that org-fold just got merged.

Best,
Anders Johansson

Re: [PATCH] New LaTeX code export option: engraved

[Timothy]

Hi Ihor,

> Thanks!
> Implementing fontification using Emacs capabilities is certainly a step
> in the right direction. LaTeX support for fontification has always been
> tricky.

I’m glad to hear you’re of a similar mind to me with this.

> - I tried to test your patch, and it only works partially. There is some
>   stray text caused by LaTeX errors:
>
> [2. application/vnd.lotus-organizer; test.org]…
> [3. application/pdf; test.pdf]…

Ah. I thought that hyperref loaded xcolor, but it seems my assumption was
incorrect. I’ve added `\usepackage{xcolor}' to the default
`org-latex-engraved-preamble', but maybe I should ask people to modify
`org-latex-packages-alist'. I’m not sure.

> - You did not add a NEWS entry and did not update the manual in your patch.

I’m waiting till the functional content of these packages is settled/accepted,
and then I’ll write NEWS and manual entries.

> - There are many compiler warnings emitted when compiling Org with your patch

Oops, I keep on forgetting to check byte compilation. These should all be fixed 
now.

> The docstrings are missing in the above.

Docstrings have been added.

> I am not sure why, but the word fancy feels slightly annoying here.

Docsting rewritten.

> Since engraved is not entirely relying on LaTeX options, a lot of
> customisation is not mentioned in this docstring. AFAIU, color
> customisation is only possible by changing defcustoms from engrave-faces
> package.
>
> Another related note is what is going to happen in beamer export with
> dark background. The default face mapping in engrave-faces is using some
> kind of light theme, which may lose all the contrast on not-light
> background.

Modifying the style of engraved-faces-latex’s output is indeed done by
customising a engraved-faces variable. I don’t think we should attempt to do
anything further with this within Org.

To elaborate a bit, the generated LaTeX uses the styling information given in
`engrave-faces-preset-styles'. Changing this to use the current Emacs theme is 
as
simple as `(setq engrave-faces-preset-styles (engrave-faces-generate-preset))'.

> It feels that codebackground, codeborder, and EFD should be customizable
> by org-latex-engraved-options.

Hmm. I don’t think so. They are entirely self-contained within the preamble
variable. Should there be a nice existing `org-latex-user-colors' variable or
such, it would make a lot of sense to shove this there, but since no such
variable exists I’m not sure we can really do much better than just asking users
to modify `org-latex-engraved-preamble'.

> Docstring?

Added.

>> +(message “Cannot engrave inline src block, `engrave-faces-latex’ is 
>> unavailible.”)
>
> Why message instead of error?

User errors are now thrown.

Thanks for the feedback!
Timothy
>From d231437e2c9f96bf70520d9ddda810a95667fcdd Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 1/4] ox-latex: Refactor `org-latex-src-block'

* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
 lisp/ox-latex.el | 339 ++-
 1 file changed, 185 insertions(+), 154 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..c2f728a1c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
 	   (float (plist-get attributes :float))
 	   (listings (plist-get info :latex-listings)))
   (cond
-   ;; Case 1.  No source fontification.
((or (not lang) (not listings))
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
-  (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
-  (if caption-above-p caption-str "")
-  verbatim
-  (if caption-above-p "" (concat "\n" caption-str
-(t verbatim
-   ;; Case 2.  Custom environment.
+(org-latex-src-block--verbatim src-block info lang caption caption-above-p label
+   num-start retain-labels attributes float))
(custom-env
-	(let ((caption-str 

Re: [PATCH v4] org-encode-time compatibility and convenience helper

[Max Nikulin]

On 04/05/2022 16:56, Ihor Radchenko wrote:

Max Nikulin writes:

1 unexpected results:
FAILED  test-org-clock/clocktable/ranges


Resetting timezone to UTC should be fixed in timestamps generated by a 
testing helper function. I was disappointed that `mapcar' can not be 
used with multiple lists, but I have found an old function created 
namely for zeroing nils in timestamps.



Since it is expected to fail in some Emacs versions, you can just wrap
the call into with-no-warnings:

(ignore-errors (with-no-warnings (encode-time '(0 0 0 1 1 1971


Thank you, I have added this trick.

I have created one more patch with tests quite close to the case caused 
this series.


It seems, no tests fail even in Australia/Eucla timezone famous for its 
45 min offset.From 485cd21366b651093c9c9c75e7398d662c99e92f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 9 Apr 2022 00:17:09 -0700
Subject: [PATCH 1/7] Use unknown DST instead of standard time in timestamps

* lisp/ol.el (org-store-link): Prefer plain (encode-time ...)
to (apply 'encode-time ...), for speed.
* lisp/org-macs.el (org-parse-time-string): Return unknown DST,
not standard time.
* lisp/org.el (org-read-date-analyze): Return a timestamp with a DST
flag of -1 (unknown) rather than nil (standard time).

Max Nikulin:
A larger patch "Improve Org usage of timestamps" was suggested in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#10

Changes selected for this patch normalizes timestamp format:
if it is a list than it should contain 9 elements to be compatible
with Emacs-27 and Emacs-28 `encode-time' single argument, nil should not
be used for DST field since it means standard time while actual value
is unknown and should be guessed.

Ignacio Casso reported a problem with agenda
https://list.orgmode.org/paxpr06mb7760238f410cbe3203f78ee0c6...@paxpr06mb7760.eurprd06.prod.outlook.com
due to Emacs commit dd0727e1ec1 changing Org code.  It was mostly reverted
by 8ef37913d3 (bug#54731).  Code in the Org repository did not have
the bug, but it safer to add protection against similar refactoring.
---
 lisp/ol.el   | 4 +---
 lisp/org-macs.el | 2 +-
 lisp/org.el  | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index d4bd0e40c..0de9c921b 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1618,9 +1618,7 @@ non-nil."
 	  (setq link
 		(format-time-string
 		 (car org-time-stamp-formats)
-		 (apply 'encode-time
-			(list 0 0 0 (nth 1 cd) (nth 0 cd) (nth 2 cd)
-			  nil nil nil
+		 (encode-time 0 0 0 (nth 1 cd) (nth 0 cd) (nth 2 cd
 	  (org-link-store-props :type "calendar" :date cd)))
 
((eq major-mode 'w3-mode)
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 8535bf2cd..241155064 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1412,7 +1412,7 @@ This should be a lot faster than the `parse-time-string'."
 	(string-to-number (match-string 4 s))
 	(string-to-number (match-string 3 s))
 	(string-to-number (match-string 2 s))
-	nil nil nil))
+	nil -1 nil))
 
 (defun org-matcher-time (s)
   "Interpret a time comparison value S as a floating point time.
diff --git a/lisp/org.el b/lisp/org.el
index 1d5fc3903..165c83609 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13663,7 +13663,7 @@ user."
 	 (setq year (nth 5 org-defdecode))
 	 (setq org-read-date-analyze-forced-year t
 (setq org-read-date-analyze-futurep futurep)
-(list second minute hour day month year)))
+(list second minute hour day month year nil -1 nil)))
 
 (defvar parse-time-weekdays)
 (defun org-read-date-get-relative (s today default)
-- 
2.25.1

From 3a6d7320be7f56949be968fa49e1fb6a7fcb0732 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 3 May 2022 17:59:11 +0700
Subject: [PATCH 2/7] Fix tests for `org-parse-time-string' and `org-clock'

* testing/lisp/test-org.el (ert-deftest test-org/org-parse-time-string):
Update test expectations to use DST of -1 (guess) after fix of
`org-parse-time-string'.
* testing/lisp/test-org-clock.el (org-test-clock-create-timestamp):
Do not change timezone from nil to 0.  Prevent test failures in zones
other than UTC.
---
 testing/lisp/test-org-clock.el |  6 +++---
 testing/lisp/test-org.el   | 10 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/testing/lisp/test-org-clock.el b/testing/lisp/test-org-clock.el
index d2179e1ec..89e0e2ade 100644
--- a/testing/lisp/test-org-clock.el
+++ b/testing/lisp/test-org-clock.el
@@ -27,9 +27,9 @@ Return the timestamp as a string."
   (org-element-interpret-data
(let ((time (decode-time
 (apply #'encode-time
-   (mapcar (lambda (el) (or el 0))
-   (org-read-date-analyze
-input nil (decode-time (current-time
+   (org-fix-decoded-time
+(org-read-date-analyze
+ input nil (decode-time (current-time
  (list 'timestamp
   

Re: Citation glitch

[Bruce D'Arcus]

You don't need citeproc-org, which is deprecated AFAIK.

Do update citeproc-el. I'm not sure when he tagged v0.9, but this is
the commit that should have fixed it.

https://github.com/andras-simonyi/citeproc-el/commit/a702e73dcbd34cbda3a7465cf0cace7529f41dcd

If you still have problems, you might report it to that project?

On Wed, May 4, 2022 at 8:45 PM Alan Tyree  wrote:
>
> I'm not sure.
>
> citeproc-0.9
> citeproc-org-0.2.4
>
> On Thu, 5 May 2022 at 10:34, Bruce D'Arcus  wrote:
>>
>> It seems this should have been fixed late in citeproc-el in 2021:
>>
>> https://github.com/andras-simonyi/citeproc-el/issues/72
>>
>> Are you using the most up-to-date code?
>>
>> On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:
>>>
>>> G'day,
>>> I have a citation problem. The bibtex entry is:
>>> @TechReport{name32:_some,
>>>   author = {{Some Company Name}},
>>>   title = {Some silly internal document},
>>>   institution =  {Some Company Name Ltd},
>>>   year = 1832}
>>>
>>> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>>>
>>> Org exports to html: Name, Some Company, Some Silly Internal Document (Some 
>>> Company Name Ltd, 1832).
>>>
>>> I thought it was a CSL problem, but pandoc exports it correctly as Some 
>>> Company Name, etc.
>>>
>>> Any help appreciated,
>>> Alan
>>>
>>>
>>> --
>>> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>>>
>
>
> --
> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>

Re: org-startup-folded does not work with directory local variables

[Max Fujimoto]

 Thanks for the info, 

I will look into reporting the issue with the emacs bug-tracker and for now use 
the per file "STARTUP:" option.
thanks again

On Wednesday, May 4, 2022, 11:04:42 a.m. EDT, Robert Pluim 
 wrote:  
 
 > On Wed, 04 May 2022 22:46:56 +0800, Ihor Radchenko  
 > said:

    Ihor> Robert Pluim  writes:
    Ihor> This is no different. org-startup-folded controls loading of Org mode.
    Ihor> However, Emacs applies directory-local variables and file-local
    Ihor> variables _after_ loading Org mode. Org cannot do much about it 
without
    Ihor> hacking Emacs defaults.
    >> 
    >> Weʼre in agreement there. My point is that itʼs not a bug (although I
    >> guess you could ask for a feature to apply local/directory variables
    >> before applying the mode

    Ihor> It's not exactly a bug, but feature request to Emacs is exactly what I
    Ihor> was implying.

Right. My predictatron says itʼs unlikely to be greeted
enthusiastically.

    >> , but in this case thereʼs an easy
    >> workaround).

    Ihor> I am not sure which workaround you are referring to.
    Ihor> Setting org-startup-folded globally? On per-file basis? the former is
    Ihor> global and will apply to broader scope than a directory-local 
variable.
    Ihor> The latter only works in a single file (and works instead of 
file-local
    Ihor> variable).

I was talking about #+STARTUP: (Iʼm assuming #+SETUPFILE: also works,
but I haven't tried it).

Robert
-- 
  

Re: [BUG] - Statistics cookie is part of the org heading title

[Ignacio Casso]

I've replied to this email in the original thread about the COMMENT
keyword to continue the discussion there, since it may be a little
off-topic here. --Ignacio


>> Still, I think it might be interesting to compare this topic with the
>> one I linked in my reply,
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html,
>> which it's basically the same bug report but about COMMENT keywords. In
>> that regard, I have tested that org-capture targets do work regardless
>> of statistcs cookies. Could not something equivalent be done so that
>> they also work regardless of COMMENT keywords? Feel free to reply in
>> that other thread if you feel this is off-topic here.
>
>> This bug is related with the issue I reported in
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The
>> problem is that `org-heading-components' uses
>> `org-complex-heading-regexp', which does not consider statistics
>> cookies, and neither COMMENT keywords as I reported. I think it should be
>> updated to consider both.
>
> Note that org-complex-heading-regexp-format does consider statistics
> cookies, but only at the beginning/end of the headline title.
> Unfortunately, it is impossible to provide generic printf format to
> match a headline title with arbitrary statistics cookies inserted in the
> middle of it.
>
> As for your other report, it is a hard one - org-complex-heading-regexp
> is hard to modify because we guarantee certain match groups and its hard
> to fit COMMENT in there without breaking backward-compatibility.
>
> I generally dislike the idea of the available plethora of analytic
> regexps with numbered match groups. I am currently working on
> generalised Org element matcher that provides named groups for arbitrary
> Org syntax elements, including headlines.
>
> Best,
> Ihor

[Some news (nngnorb "UCMgmail")?] (was: [BUG] In recent GNU emacs master org-capture hangs [9.5.3 (release_9.5.3-465-gd7dc62 @ /home/oub/emacs/site-lisp/packages/org/)])

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> Here is one of the templates
>> ("mt" "Tutorias Headings"
>> entry (file+headline "~/ALLES/HGs/tex/vorlesungen/Tutorias/tutorias.org" 
>> "Tutorials")
>> "* TODO %^{Task} %T : %:from %:subject %^G\n- From :: %:from\n- Subject :: 
>> %:subject\n- Date :: %:date\n- Email :: %a\n\n%?\n%i")
>> 
>> So I in my gnus message 
>> 
>> 1. I fire up org-capture
>> 
>> 2. I am asked to the Task, I type but then Emacs hangs, and I have
>> to abort the operation. That did not happen with git master
>> 1f78ca45f8d534e51c1e30e9225d1da8b2e50650

> Could you please provide detailed steps how to reproduce starting from
> emacs -Q?

> I am unable to trigger the hang using your template doing the following

> 1. cd path/to/org/repo/main/branch
> 2. make cleanall; make autoloads; emacs -Q -L ./lisp/ -l org -l /tmp/bug.el 
> with bug.el:
> (setq org-capture-templates '(("m" "Tutorias Headings"
>entry (file+headline "/tmp/tutorias.org" "Tutorials")
>"* TODO %^{Task} %T : %:from %:subject %^G\n- From :: %:from\n- 
> Subject :: %:subject\n- Date ::
> %:date\n- Email :: %a\n\n%?\n%i")))

> 3. M-x gnus
> 4. m
> 5. Fill To and Subject fields of the message
> 6. M-x org-capture  m
> 7. test 
> 8. 1:test: 
> 9. C-c C-c

I did 

/opt/emacs29/bin/emacs -Q -L ./lisp/ -l org -l bug.el

With bug.el containing:

(setq org-capture-templates '(("m" "Tutorias Headings"
 entry (file+headline "/tmp/tutorias.org" "Tutorials")
 "* TODO %^{Task} %T : %:from %:subject %^G\n- From :: %:from\n- 
Subject :: %:subject\n- Date ::
%:date\n- Email :: %a\n\n%?\n%i")))

(setq gnus-select-method (list 'nnnil "")) ;Jan  1, 2005 18:21
(setq gnus-secondary-select-methods nil)
(setq gnus-secondary-select-methods
  '(
(nntp  "news.gmane.io") 
(nngnorb "UCMgmail")
(nnimap "UCMgmail"
(nnimap-address "imap.gmail.com")
(nnimap-server-port 993)
(nnimap-authinfo-file "~/.authinfo")
(nnimap-stream ssl)
;;(nnimap-stream starttls)
(nnimap-fetch-partial-articles "text/")
(nnir-search-engine imap))
(nnimap "gmail"
(nnimap-address "imap.gmail.com")
(nnimap-server-port 993)
(nnimap-stream ssl)
(nnimap-authinfo-file "~/.authinfo")
;;(nnimap-stream starttls))
(nnimap-fetch-partial-articles "text/")
;(nnimap-fetch-partial-articles t)
(nnimap-stream ssl))
(nnimap "Gisi"
(nnimap-address "imap.gmail.com")
(nnimap-server-port 993)
(nnimap-stream ssl)
(nnimap-authinfo-file "~/.authinfo")
;;(nnimap-stream starttls))
(nnimap-stream ssl))
(nnimap "gmx"
(nnimap-address "imap.gmx.de")
(nnimap-server-port 993)
(nnimap-stream ssl)
(nnimap-authinfo-file "~/.authinfo")
(nnimap-stream ssl))
(nnimap "GmxUwe"
(nnimap-address "imap.gmx.net")
(nnimap-server-port 993)
(nnimap-stream ssl)
(nnimap-authinfo-file "~/.authinfo")
(nnimap-stream ssl))
))

That did not work, however when removing 

(nngnorb "UCMgmail")
it worked.

I also removed this from my gnus-init file and for the moment everything seems 
to work.

Good @Eric (Eric Abrahamsen)

When you read this, any idea what is going on here?

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

[BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

This topic was brought up again in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
I continue the discussion here:

>> Still, I think it might be interesting to compare this topic with the
>> one I linked in my reply,
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html,
>> which it's basically the same bug report but about COMMENT keywords. In
>> that regard, I have tested that org-capture targets do work regardless
>> of statistcs cookies. Could not something equivalent be done so that
>> they also work regardless of COMMENT keywords? Feel free to reply in
>> that other thread if you feel this is off-topic here.
>
>> This bug is related with the issue I reported in
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The
>> problem is that `org-heading-components' uses
>> `org-complex-heading-regexp', which does not consider statistics
>> cookies, and neither COMMENT keywords as I reported. I think it should be
>> updated to consider both.
>
> Note that org-complex-heading-regexp-format does consider statistics
> cookies, but only at the beginning/end of the headline title.
> Unfortunately, it is impossible to provide generic printf format to
> match a headline title with arbitrary statistics cookies inserted in the
> middle of it.
>

Could not something equivalent be done for COMMENT keywords and
optionally match them at the beginning of the headline in
`org-complex-heading-regexp-format'? Something like this:

  (setq org-complex-heading-regexp-format
(concat "^\\(\\*+\\)"
  "\\(?: +" org-todo-regexp "\\)?"
  "\\(?: +\\(\\[#.\\]\\)\\)?"
  "\\(?: +"
+ ;; Headline might be commented
+ "\\(COMMENT \\)?
  ;; Stats cookies can be stuck to body.
  "\\(?:\\[[0-9%%/]+\\] *\\)*"
  "\\(%s\\)"
  "\\(?: *\\[[0-9%%/]+\\]\\)*"
  "\\)"
  "\\(?:[ \t]+\\(:[[:alnum:]_@#%%:]+:\\)\\)?"
  "[ \t]*$"))

This would fix the problem I really cared about: being able to use a
headline as capture target regardless of whether it is commented or
not. Getting the headline text was never important to me, so I don't
really care that much about `org-complex-heading-regexp'.

> As for your other report, it is a hard one - org-complex-heading-regexp
> is hard to modify because we guarantee certain match groups and its hard
> to fit COMMENT in there without breaking backward-compatibility.
>
> I generally dislike the idea of the available plethora of analytic
> regexps with numbered match groups.

Do you mean that there is no way to specify an optional string in a
regular expression without wrapping it in a parenthesized group, which
would break the match group numbering backwards compatibility? I'm not
that familiar with regular expressions, but if that's the case I
completely agree with your last statement.

--Ignacio

#4 Org mode profiling meetup on Sat, May 7

[Ihor Radchenko]

Dear All,

I am continuing my experiment with Org mode meetups and online
debugging.

Anyone who wants to discuss and/or debug Org-related issues is welcome.

If you want to provide improvements to Org, but feel overwhelmed about
the contribution process or the vast Org codebase, we can touch on that
as well.

This time, I plan to talk about some Org mode internals. Specifically,
the newly added folding engine org-fold.el

Note that using microphone and/or camera should not be required. Jitsi
does have chat.

The time will be the same: 9pm SG time (4pm Kyiv; 2pm London; 9am New
York). Sat, May 7

I will post the link to the meeting one hour before the meeting start.

Best,
Ihor

Re: coq related error when exporting to latex.

[Ihor Radchenko]

abdullah uyu  writes:

> i get the following error when i try to export to latex:
>
> org-babel-coq-initiate-session: ‘run-coq’ not defined, load
> coq-inferior.el

Most likely, ob-coq expects you to have coq major-mode installed. Note
that ob-coq is currently not maintained and might be outdated.

Best,
Ihor

Re: [PATCH] New LaTeX code export option: engraved

[Ihor Radchenko]

Timothy  writes:

> This patchset accomplishes two things:
> 1. It refactors the overly large `org-latex-src-block' function, and makes a 
> few
>other improvements to pre-existing code
> 2. It adds a new option for exporting code, named (you guessed it!) “engraved”
>
> What is this new option, and why do we want it?
>
> About a year ago I started work on a package that generalises the 
> functionality
> of `htmlize.el', termed `engrave-faces'
> (). It provides the ability 
> to
> extract font-lock information and export it to a number of formats: html, 
> ansi,
> and (crucially) LaTeX! Since the LaTeX export is built on the `fvextra' 
> (LaTeX)
> package (like pygments), the vast majority of the Minted options you’re used 
> to
> just carry over.
>
> This allows for a result that is, I think, straight up better than all the
> pre-existing options. For starters, you can now apply syntax highlighting to 
> any
> language you have a major mode for.

Thanks!
Implementing fontification using Emacs capabilities is certainly a step
in the right direction. LaTeX support for fontification has always been
tricky.

Some comments:

- I tried to test your patch, and it only works partially. There is some
  stray text caused by LaTeX errors:


test.org
Description: Lotus Organizer


test.pdf
Description: Adobe PDF document

- You did not add a NEWS entry and did not update the manual in your patch.
- There are many compiler warnings emitted when compiling Org with your patch

> +(defun org-latex-inline-src-block--minted (info code lang)
> +  (let ((mint-lang (or (cadr (assq (intern lang)
> +
> +(defun org-latex-inline-src-block--listings (info code lang)
> +  (let* ((lst-lang (or (cadr (assq (intern lang)

The docstrings are missing in the above.

> -Alternatively,
> +There are two fancier options for fontification.
> +
> +The first fancy alternative,

I am not sure why, but the word fancy feels slightly annoying here.

> +
> +The styling of the engraved result can customised with
> +`org-latex-engraved-preamble' and `org-latex-engraved-options'.
> +The default preamble also uses the tcolorbox LaTeX package in
> +addition to fvextra.

Since engraved is not entirely relying on LaTeX options, a lot of
customisation is not mentioned in this docstring. AFAIU, color
customisation is only possible by changing defcustoms from engrave-faces
package.

Another related note is what is going to happen in beamer export with
dark background. The default face mapping in engrave-faces is using some
kind of light theme, which may lose all the contrast on not-light
background.

> +\\renewcommand\\theFancyVerbLine{\\footnotesize\\color{black!40!white}\\arabic{FancyVerbLine}}
> +
> +\\providecolor{codebackground}{HTML}{f7f7f7}
> +\\providecolor{codeborder}{HTML}{f0f0f0}
> +\\providecolor{EFD}{HTML}{28292e}

> +(defcustom org-latex-engraved-options
> +  '(("commandchars" . "\\{\\}")
> +("highlightcolor" . "white!95!black!80!blue")
> +("breaklines" . "true")
> +("breaksymbol" . 
> "\\color{white!60!black}\\tiny\\ensuremath{\\hookrightarrow}"))
> +  "Association list of options for the latex fvextra package when engraving 
> code.

It feels that codebackground, codeborder, and EFD should be customizable
by org-latex-engraved-options.

> +(defun org-latex-generate-engraved-preamble (info syntax-colours-p)

Docstring?

> +(defun org-latex-inline-src-block--engraved (info code lang)
> +  (if (require 'engrave-faces-latex nil t)
> ...
> +(message "Cannot engrave inline src block, `engrave-faces-latex' is 
> unavailible.")
> +(insert (org-latex--text-markup code 'code info

Why message instead of error?

Best,
Ihor

Re: [PATCH] New LaTeX code export option: engraved

[Daniel Fleischer]

Timothy [2022-05-04 Wed 23:59] wrote:

> I’ve been fairly busy as of late (hence my recent silence on this ML), 
> however I have a patchset that’s been in the
> works for a while that I’ve finally polished up. 

Hi Timothy, thank you very much for your work!

Let me learn a bit about the different code highlighting options in
order to understand what you offer.

Best,

-- 

Daniel Fleischer

Re: [PATCH] New LaTeX code export option: engraved

[Daniel Fleischer]

Timothy [2022-05-04 Wed 23:59] wrote:

> I’ve been fairly busy as of late (hence my recent silence on this ML), 
> however I have a patchset that’s been in the
> works for a while that I’ve finally polished up. 

Hi Timothy, thank you very much for your work!

Let me learn a bit about the different code highlighting options in
order to understand what you offer.

Best,

-- 

Daniel Fleischer

org-capture problems again, the evil %from, %subject

[Uwe Brauer]

Hi 

I am again facing the problem that org-capture hangs even with my
recovered old setting.

I investigated it a bit, org-capture is mostly ok, but not for those
templates that contain gnus specific commands like %from %subject etc

How can I debug this?

Regards

Uwe Brauer

-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.