Re: After years without issues, Orgmode now fails to apply agenda filters to preset templates

[Pedro]

Hi Tory,

I use the same version emacs and orgmode version as you, and I have 
similar needs as you: filtering org-agenda by tags, etc.


I will share my whole section of org-agenda-custom-commands as it is, I 
hope you can followup it nicely. Find it attached in file: 
agenda-filters.org


Cheers,
Pedro

On 5/25/24 21:26, Ihor Radchenko wrote:

web...@toryanderson.com (Tory S. Anderson) writes:


After years without issue where I could choose, for example, to see my
daily work agenda, the filters are now failing to be applied. This is
in org 9.6.15, as shipped with my emacs 29.3. I have verified that
this problem is the same in =emacs -Q= without any other packages:
when I choose my agenda view, such as "C-a w d" for my daily work
agenda, I still get an agenda buffer named "Org_Agenda(wd)", but none
of my preset filters have applied. I skimmed the documentation and I
haven't seen any changed syntax. Here is my definition from my
=use-package org= =:custom= section:

#+begin_src lisp
   (org-agenda-custom-commands
'(("w" . "Work")
  ("wd" "Work Day"
   ((agenda ""
((org-agenda-span 1)
 (org-agenda-start-on-weekday nil)
 (org-agenda-regexp-filter-preset
  '("+ODH\\|AGENDA\\|CONFERENCE" 
"-TSA\\|PRIESTHOOD")
   nil)))
#+end_src

According to the docstring of `org-agenda-regexp-filter-preset',

 ...The preset filter is a global property of
 the entire agenda view.  In a block agenda, it will not work reliably to
 define a filter for one of the individual blocks.  You need to set it in
 the global options and expect it to be applied to the entire view.

So, you should set this variable as a part of global agenda command
settings, not inside individual block.

Not a bug.
Canceled.


Why has this stopped applying my filter when it worked for so long? Is
it a bug, or do I need to change something to make it up-to-date?

I have no idea because you did not tell which Org mode version had your
settings working. I suspect that it could have happened around the time
Org mode switched from dynamic binding to lexical binding, but it is
just a blind guess.



(setq my/org-agenda_pro-filter ":2024_12_masked:\\|:2024_29_masked:\\|:2024_16_masked:\\|:2023_101_masked:\\|:2024_17_masked:")
(setq my/org-agenda_org-filter ":2023_47_masked:\\|:2023_53_masked:\\|:2024_8_masked:\\|:2024_9_masked:\\|:2024_13_masked:\\|:2024_20_masked:\\|:2024_10_masked:\\|:2024_11_masked:")
(setq my/org-agenda_home-filter ":2024_2_masked:\\|:2024_1_masked:\\|:2024_4_masked:\\|:2024_3_masked:\\|:2022_39_masked:")
(setq my/org-agenda_vol-filter ":2023_47_masked:\\|:2023_53_masked:\\|:2024_8_masked:\\|:2024_9_masked:\\|:2024_13_masked:\\|:2024_20_masked:\\|:2024_10_masked:\\|:2024_11_masked:")
(setq my/org-agenda_exp-filter ":2022_9_masked:\\|:2024_25_masked:\\|:2022_83_masked:\\|:2024_24_masked:\\|:2024_23_masked:\\|:2023_57_masked:\\|:2024_7_masked:\\|:2024_15_masked:\\|:2024_14_masked:")
(setq my/org-agenda_mus-filter ":2024_22_masked:\\|:2024_21_masked:")
(setq my/org-agenda_viaje-filter ":2023_114_masked:\\|:2022_74_masked:")

(defun my/org-agenda-skip-with-filter (filter)
  (or
   (org-agenda-skip-entry-if 'todo '("DONE" "CLOSED"))
   (org-agenda-skip-entry-if 'notregexp (concat ":appt:\\|" filter))
   ))

;; by default I only want a list of the todo items
(setq org-agenda-custom-commands
  '(("t" "list all TICKLER items" todo "TICKLER")
("n" "list all NEXT items" todo "NEXT")
("h" "list all HOLD items" todo "HOLD")
("b" "Agenda for board.org"
 agenda ""
 ((org-agenda-span 'day)
  (org-agenda-files '("~/org/board.org"
;; thanks chatgpt
("d" "Daily agenda without DONE and CLOSED (responde a pregunta: qué queda por hacer hoy)"
 agenda ""
 ((org-agenda-span 'day)
  (org-agenda-skip-function
   (lambda ()
 (or (org-agenda-skip-entry-if 'todo '("DONE" "CLOSED")))
;; trabajos profesionales
;;   https://emacs.stackexchange.com/questions/18179/org-agenda-command-with-org-agenda-filter-by-tag-not-working/78066#78066
("w" "Context 1: pro/Work"
 agenda ""
 ((org-agenda-span 'day)
  (org-agenda-skip-function '(my/org-agenda-skip-with-filter (concat ":pro:\\|" my/org-agenda_pro-filter)))
   ))
("o" "Context 2: Org

Re: [SUMMARY] #8 [[bbb:OrgMeetup]] on Wed, June 12, 19:00 UTC+3

[Pedro]

On 6/22/24 10:32, Ihor Radchenko wrote:

- Tim continued his struggle with an elusive bug he experiences when
   setting tags (C-c C-q) in large Org buffers - setting tags takes
   forever for him. (There is infinite loop likely lurking somewhere)


I have the same bug, but I said nothing because I don't have right now 
time to report. When I read it, I just wanted to share that this also 
happens to me.


I work with huge diary files and I discovered that since the cache is 
activated by default, when I remove or move certain subtrees/parts looks 
like makes the cache corrupted (I could not reproduce exactly how), not 
only affects tag completion, that yeah, it takes forever, it also works 
weird on org-captures applied to huge buffer files. So I have a current 
diary, that tries to get a record of last weeks. When I could not 
archive it (like right now), it has 5 weeks from now, that means 24k 
lines in a file, when I can clean it up, goes to an archive file (so 
then, alleviates org-agenda-files processing), the 2023, which is pretty 
archived, is 263k lines.


From user-view perspective, it was uncomfortable to see it enabled by 
default, specially when you have problems, specially, when you try to 
deal with a solution, and is not really documented on the workarounds, 
etc [0]. It took me nearly 2 hours to stabilize again my workflow so I 
agree that some information should be explained as stated in a recent 
conversation [1]


My vicious workflow regretably involves opening a lot of duplicated 
buffers through emacsclient, and at some point, it becomes slow, so I do 
this [2]


Being said all, I am very happy with how emacs and orgmode are getting 
progress done on managing large files, etc. I just wanted to let you 
know about a problem that I am experimenting, and maybe other people too.


I will note in my agenda on the #9 meeting [3] and I will try to join

Cheers,
pinmacs

[0] In my notes it says:

#+name: sourceblock_created_2024-06-27_14-32-44
#+begin_src text
how to disable Element cache? I am having warnings but I don't have time 
to do bug reporting ( https://orgmode.org/Changes.html )


found the solution (setq org-element-use-cache nil)  src 
https://emacs.stackexchange.com/questions/42006/trouble-with-org-mode-cache-find-error


[ I don't remember where I got this, but I think it should appear in the 
manual saying that this is a workaround until it is fixed 
https://orgmode.org/org.html ]

org-element-cache-reset
#+end_src

[1] email Subject: Please document the caching and its user options, 
From: Eli Zaretskii, Date: 2024-06-12 11:38:05 AM CEST


[2]

#+name: sourceblock_created_2024-06-27_14-33-28
#+begin_src emacs-lisp
;; I use this program when it works slow
(defun kill-duplicate-frames ()
  "Kills duplicate frames of buffers."
  (interactive)
  (let ((buffers '()))
    (dolist (frame (frame-list))
  (with-selected-frame frame
    (let ((buffer (current-buffer)))
  (when (member buffer buffers)
    (delete-frame))
  (add-to-list 'buffers buffer)
  ;; after doing stuff, cache goes slow, but with this, it improves
  ;; so this is arbitrary program, that my brain has associated with 
"make emacs faster again"

  (org-element-cache-reset)
  (message "Killed duplicate frames of buffers."))
#+end_src

[3] email Subject: #9 ((bbb:OrgMeetup)) on Wed, July 10, 19:00 UTC+3, 
From: Ihor Radchenko , Date: 2024-06-26 5:48:46 PM CEST


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [SUMMARY] #8 [[bbb:OrgMeetup]] on Wed, June 12, 19:00 UTC+3

[Pedro]

Thanks Ihor

I am experiencing it since end of July 2023 when I upgraded to the 
version 9.6.15, but my situation now is stable with that workaround and 
I have no time now for reporting the problem right now.


I expect to have some time at the end of July 2024, and I hope to 
upgrade again orgmode and/or emacs to the latest stable version, then I 
will try again to see if I stop getting cache errors without regularly 
running =(org-element-cache-reset)=


Cheers,
pinmacs


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

help: howto aggregate several properties in one column

[Pedro]

Hi,

I am a heavy user of propview [1] and I am very happy with it, but looks 
like now I reached a limitation, or maybe someone founds a magical 
workaround. I am open to use another solution outside of propview.


Find attached in file aggregate-props.org that serves as a playground 
environment and as an example of what I am struggling with, it is posed 
as a generic example: I want to "merge" two properties into one, no 
matter if the property exists or no. I am trying to use concat, concat 
works only when the properties on an item exist, if one of them does not 
exist, fails, which is unfortunate to what I am trying to achieve, 
because on one side, I would like to report (with a propview table) the 
frequency of appearance of each test_a, test_b, test_c, etc. on all 
nodes with tag :test:, and with another propview table, a summary of all 
test properties.


There is a workaround based on a precalculation strategy that I kind of 
hate: do an org-map-entries of all targeted items with tag "test", and 
update SUMMARY property through an adhoc elisp function all the 
properties related to test (I am happy with just enumerating all of the 
involved subproperties, but I recognize, having a regex on property such 
as test_* or that "starts with" test, would be amazing), then, it is 
just as easy as adding the new column SUMMARY, but I would like to avoid 
this solution


Extra note: related to propview, it is not a problem to concat 100 
elements, because you can do it in an extra shortnamed function, so the 
column name can be short


So this is what happens, concat of TEST_A and TEST_B is 0

#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |

|-+++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  0 | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b 
|  0 | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 
|  0 | 0  |

|-+++++|
| |    |    | |    
|    |

#+END:

What I would expect to happen is that in the concat result of TEST_A and 
TEST_B would appear a or b, maybe that could be done with another function?


#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |

|-+++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  a | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b 
|  b | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 
|  0 | 0  |

|-+++++|
| |    |    | |    
|    |

#+END:

Cheers,
pedeb

[1] https://orgmode.org/worg/org-contrib/org-collector.html

* my test
:PROPERTIES:
:CREATED:  [2024-08-10 Sat 13:48]
:END:

#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM| CREATED| TEST_A | TEST_B | (concat TEST_A TEST_B) | (or TEST_A TEST_B) | (or TEST_B TEST_A) | (concat TEST_C TEST_D) |
|-+++++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 |  0 |  a |  0 | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b |  0 |  0 |  b | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 |  0 |  0 |  0 | 0  |
|-+++++++|
| ||||||||
#+END:

** mytest  :test:
:PROPERTIES:
:CREATED:  [2024-08-09 Fri 23:53]
:CUSTOM

Re: help: howto aggregate several properties in one column

[Pedro]

Thank you Thierry!

Even better, just initializing it the empty properties with an empty 
string works great and then I don't need the valof macro.


I updated the aggregate-props.org file and find it attached

Here is the result I am getting with just ~(progn(setq TEST_A "") (setq 
TEST_B ""))~


#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |

|-+++++|
| mytest  | [2024-08-09 Fri 23:53] | a  |    | 
a  | cd |
| mytest2 | [2024-08-09 Fri 23:53] |    | b  | 
b  | cd |
| mytest3 | [2024-08-09 Fri 23:53] |    | |    | 
0  |

|-+++++|
| |    |    | |    
|    |

#+END:

Oooh, I am so happy, thank you again!

Cheers,
Pedro

On 2024-08-11 22:27, tbanelwebmin wrote:

Two quick-and-dirty workarounds:

1. Eval that prior to using propview:

(setq
 TEST_A "<>"
 TEST_B "<>"
 TEST_C "<>"
 TEST_D "<>")

2. Define this helper macro:

(defmacro valof (symbol)
  `(if (boundp ',symbol)
  ,symbol
    "()"))

Then specify columns like that:

(concat (valof TEST_A) (valof TEST_B))


Have fun
Thierry


On 24-08-11 10:49, Pedro wrote:

Hi,

I am a heavy user of propview [1] and I am very happy with it, but 
looks like now I reached a limitation, or maybe someone founds a 
magical workaround. I am open to use another solution outside of 
propview.


Find attached in file aggregate-props.org that serves as a playground 
environment and as an example of what I am struggling with, it is 
posed as a generic example: I want to "merge" two properties into 
one, no matter if the property exists or no. I am trying to use 
concat, concat works only when the properties on an item exist, if 
one of them does not exist, fails, which is unfortunate to what I am 
trying to achieve, because on one side, I would like to report (with 
a propview table) the frequency of appearance of each test_a, test_b, 
test_c, etc. on all nodes with tag :test:, and with another propview 
table, a summary of all test properties.


There is a workaround based on a precalculation strategy that I kind 
of hate: do an org-map-entries of all targeted items with tag "test", 
and update SUMMARY property through an adhoc elisp function all the 
properties related to test (I am happy with just enumerating all of 
the involved subproperties, but I recognize, having a regex on 
property such as test_* or that "starts with" test, would be 
amazing), then, it is just as easy as adding the new column SUMMARY, 
but I would like to avoid this solution


Extra note: related to propview, it is not a problem to concat 100 
elements, because you can do it in an extra shortnamed function, so 
the column name can be short


So this is what happens, concat of TEST_A and TEST_B is 0

#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |
|-+++++| 

| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  0 | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b 
|  0 | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 
|  0 | 0  |
|-+++++| 

| |    |    | 
|    |    |

#+END:

What I would expect to happen is that in the concat result of TEST_A 
and TEST_B would appear a or b, maybe that could be done with another 
function?


#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |
|-+++++| 

| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  a | cd |
| mytest2 | [2024-08-09 

help: howto aggregate several properties in one column

[Pedro]

Hi,

I am a heavy user of propview [1] and I am very happy with it, but looks 
like now I reached a limitation, or maybe someone founds a magical 
workaround. I am open to use another solution outside of propview.


Find attached in file aggregate-props.org that serves as a playground 
environment and as an example of what I am struggling with, it is posed 
as a generic example: I want to "merge" two properties into one, no 
matter if the property exists or no. I am trying to use concat, concat 
works only when the properties on an item exist, if one of them does not 
exist, fails, which is unfortunate to what I am trying to achieve, 
because on one side, I would like to report (with a propview table) the 
frequency of appearance of each test_a, test_b, test_c, etc. on all 
nodes with tag :test:, and with another propview table, a summary of all 
test properties.


There is a workaround based on a precalculation strategy that I kind of 
hate: do an org-map-entries of all targeted items with tag "test", and 
update SUMMARY property through an adhoc elisp function all the 
properties related to test (I am happy with just enumerating all of the 
involved subproperties, but I recognize, having a regex on property such 
as test_* or that "starts with" test, would be amazing), then, it is 
just as easy as adding the new column SUMMARY, but I would like to avoid 
this solution


Extra note: related to propview, it is not a problem to concat 100 
elements, because you can do it in an extra shortnamed function, so the 
column name can be short


So this is what happens, concat of TEST_A and TEST_B is 0

#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |

|-+++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  0 | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b 
|  0 | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 
|  0 | 0  |

|-+++++|
| |    |    | |    
|    |

#+END:

What I would expect to happen is that in the concat result of TEST_A and 
TEST_B would appear a or b, maybe that could be done with another function?


#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM 
CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM    | CREATED    | TEST_A | TEST_B | (concat TEST_A 
TEST_B) | (concat TEST_C TEST_D) |

|-+++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 
|  a | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b 
|  b | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 
|  0 | 0  |

|-+++++|
| |    |    | |    
|    |

#+END:

Cheers,
pedeb

[1] https://orgmode.org/worg/org-contrib/org-collector.html
* my test
:PROPERTIES:
:CREATED:  [2024-08-10 Sat 13:48]
:END:

#+BEGIN: propview :scope tree :match "+test" :noquote all :cols (ITEM CREATED TEST_A TEST_B (concat TEST_A TEST_B) (concat TEST_C TEST_D))
| ITEM| CREATED| TEST_A | TEST_B | (concat TEST_A TEST_B) | (or TEST_A TEST_B) | (or TEST_B TEST_A) | (concat TEST_C TEST_D) |
|-+++++++|
| mytest  | [2024-08-09 Fri 23:53] |  a |  0 |  0 |  a |  0 | cd |
| mytest2 | [2024-08-09 Fri 23:53] |  0 |  b |  0 |  0 |  b | cd |
| mytest3 | [2024-08-09 Fri 23:53] |  0 |  0 |  0 |  0 |  0 | 0  |
|-+++++++|
| ||||||||
#+END:

** mytest  :test:
:PROPERTIES:
:CREATED:  [2024-08-09 Fri 23:53]
:CUSTOM_

Re: ox-latex: help: LATEX_HEADER from different subtrees collision

[Pedro]

Hi Rudy,

You nailed it!! Using property EXPORT_LATEX_HEADER exactly solves my 
problem, thank you very much. For completeness, I will re-attach the 
file with the solution


How did you know that, should that be mentioned in the corresponding 
section? (I could not find another one) [1] [2]. Maybe that two links 
together should be more linked and more explained the subtree case.


Serve at least this discussion as a pre-documentation

Regarding the attached file: I thought it was minimal enough, 94 lines 
that runs on vanilla emacs (emacs-30 branch); but maybe I missed a 
little summary: it is two subtree exports handled with a ~#+begin_src 
emacs-lisp~, and there was a clash using the LATEX_HEADER


Cheers,
Pedro

[1] https://orgmode.org/manual/LaTeX-header-and-sectioning.html

[2] https://orgmode.org/manual/Export-Settings.html
* ox-latex-problem
** [2024-09-02 Mon]
*** report #1 (landscape)
:PROPERTIES:
:EXPORT_LANGUAGE: en
:EXPORT_TITLE:
:EXPORT_SUBTITLE:
:EXPORT_AUTHOR:
:EXPORT_DATE:
:EXPORT_OPTIONS: toc:nil timestamp:nil num:nil
:EXPORT_TOC: headlines 2
:EXPORT_FILE_NAME: /tmp/report2.pdf
:EXPORT_LATEX_HEADER: \usepackage[a4paper, landscape, margin=0.5cm]{geometry}
:CLICK_TO_SEE_REPORT: file:/tmp/report2.pdf
:END:

#+name: sourceblock_created_2024-09-02_23-36-05
#+begin_src emacs-lisp :exports none :results none
(defun my/export-pdf ()
  "renders the PDF"
  (org-narrow-to-subtree)
  (org-show-subtree)

  (org-latex-export-to-pdf nil t t nil)

  (widen)
)
(my/export-pdf)
#+end_src

# do not use this LATEX_HEADER because is buffer scoped!
# #+LATEX_HEADER: \usepackage[a4paper, landscape, margin=0.5cm]{geometry}

 My report #2

* Introduction

Introduction text

* The report #2

Report #2 text

* Conclusions

Conclusions text

** [2024-09-01 Sun]

*** report #2 (portrait)
:PROPERTIES:
:EXPORT_LANGUAGE: ca
:EXPORT_TITLE:
:EXPORT_SUBTITLE:
:EXPORT_AUTHOR:
:EXPORT_DATE:
:EXPORT_OPTIONS: toc:nil timestamp:nil num:nil
:EXPORT_TOC: headlines 2
:EXPORT_FILE_NAME: /tmp/report1.pdf
:CLICK_TO_SEE_REPORT: file:/tmp/report1.pdf
:EXPORT_LATEX_HEADER: \usepackage[a4paper, margin=3cm]{geometry}
:END:

#+name: sourceblock_created_2024-09-02_23-36-07
#+begin_src emacs-lisp :exports none :results none
(defun my/export-pdf ()
  "renders the PDF"
  (org-narrow-to-subtree)
  (org-show-subtree)

  (org-latex-export-to-pdf nil t t nil)

  (widen)
)
(my/export-pdf)
#+end_src

# do not use this LATEX_HEADER because is buffer scoped!
# #+LATEX_HEADER: \usepackage[a4paper, margin=3cm]{geometry}

 My report #1

* Introduction

Introduction text

* The report #1

Report #1 text

* Conclusions

Conclusions text


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

BUG (regression): clocktable with ~:link t~ looks visually inconsistent

[Pedro]

Hi,

On a clocktable with hierarchy (see attached file 
clocktable-link-bug.org), when ~:link t~ is used, it does not look 
visually good; that was not an issue with the previous versions of orgmode


Find attached screenshot 2024-09-01_23-05_clocktable-detail.png, that 
shows the inconsistency in my ~emacs -Q~ with orgmode 9.7.10 and 
emacs-30 branch with commit 44c2614


Cheers,
pinmacs
* [2024-08-31 Sat]
:PROPERTIES:
:CREATED:  [2024-09-01 Sun 23:00]
:CUSTOM_ID: clocktable-link-bug_2
:END:

** DONE task1
:LOGBOOK:
CLOCK: [2024-08-31 Sat 22:45]--[2024-08-31 Sat 22:56] =>  0:11
:END:

* [2024-09-01 Sun]
:PROPERTIES:
:CREATED:  [2024-09-01 Sun 23:00]
:CUSTOM_ID: clocktable-link-bug_1
:END:

** DONE task2
:LOGBOOK:
CLOCK: [2024-09-01 Sun 22:30]--[2024-09-01 Sun 22:56] =>  0:26
:END:

clocktable with ~:link nil~ shows it fine

#+NAME: my_clocktable_without_link
#+BEGIN: clocktable :maxlevel 4 :scope file :link nil
#+CAPTION: Clock summary at [2024-09-01 Sun 23:03]
| Headline | Time |  |
|--+--+--|
| Total time   | 0:37 |  |
|--+--+--|
| [2024-08-31 Sat] | 0:11 |  |
| \_  task1|  | 0:11 |
| [2024-09-01 Sun] | 0:26 |  |
| \_  task2|  | 0:26 |
#+END

clocktable with ~:link nil~ shows it bad

#+NAME: my_clocktable
#+BEGIN: clocktable :maxlevel 4 :scope file :link t
#+CAPTION: Clock summary at [2024-09-01 Sun 23:03]
| Headline  | Time |  |
|---+--+--|
| Total time| 0:37 |  |
|---+--+--|
| [[file:/home/music/clocktable-link-bug.org::*\[2024-08-31 Sat\]][[2024-08-31 Sat]​]] | 0:11 |  |
| \_  [[file:/home/music/clocktable-link-bug.org::*task1][task1]] |  | 0:11 |
| [[file:/home/music/clocktable-link-bug.org::*\[2024-09-01 Sun\]][[2024-09-01 Sun]​]] | 0:26 |  |
| \_  [[file:/home/music/clocktable-link-bug.org::*task2][task2]] |  | 0:26 |
#+END


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Playing RPG game with org-mode

[Pedro]

Some time ago I saw this, which might inspire you this talk in the 
emacsconf from 2023 [0]


While researching it, I also found a 2-hour streaming from the great 
David Wilson (2021)


[0] https://emacsconf.org/2023/talks/adventure/

[1] System Crafters Live! - Text Adventuring in Emacs 
https://www.youtube.com/watch?v=gl_Hz2YmdfY


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Playing RPG game with org-mode

[Pedro]

Now I found this, a roll dice with hydra interface 4:39 and many more 
ideas: https://emacsconf.org/2023/talks/solo/


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [FR] yank media: allow customization of absolute path a filter for type candidates

[Pedro]

On 2024-09-22 10:01, Visuwesh wrote:

I am leaning towards doing it in the Emacs side since it would get rid
of similar annoyance(s) in other yank-media handlers, not just Org.

If no one beats me to it before the end of this week, I will propose a
patch to take care of (1).  It would be preferable pinmacs if can take
care of (2) if we decide to take care of it from the Emacs side since I
will probably not be able to describe the situation well.


Took care of 2. Done, see 
https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00685.html


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Documentation and examples about using Org mode to write content for a static web-site

[Pedro]

Hi Thomas,

Thanks for sharing how you do your stuff related to static website 
generation.


When I see things like this, it comes to me this expression:

    I love this community!!


By the way, on the page, this link is incorrect:

> you might want to download the extended ZIP file trgensit-org.zip

it should be 
https://web222.webclient5.de/prj/content/trgensit/trgensit-org.zip


Cheers,
pinmacs


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: insert a header and automatically a timestamp with date/time

[Pedro]

On 2025-02-01 18:43, Uwe Brauer via General discussions about Org-mode. 
wrote:

(BTW do you speak Spanish , since there is some Spanish text in the
files that are attached)

Anyhow.

Let me see if I understand that correctly

 - Your code does not insert
* <2025-02-01>
 But instead
* Some heading
:PROPERTIES:
:CREATED:  [2023-11-17 Fri 19:32]
:END:
that is also ok, but for the moment I prefer the timestamp in the
heading, because if I use outline-hide-body I obtain a nice overview
with the dates.


 - Another problem is that I don't get your code to work for example
   the one in the file  auto-insert-created-timestamp-as-property.org
   gives me


Yes, I speak Spanish :)

To generate dates as you said, you can use the following code [0], on 
~man date~ you can find other strftime format constructions, or 
alternatively, visit this [1]


The scheduled thing [2] had an if for certain conditions where you want 
that hook to get triggered (that uses specific buffer names that in my 
case are [2]), for a more simple approach, you might want to experiment 
with a simpler function [3]


I attach again the script migrate-from-ts-header-to-created-property.org 
because I got confused; I hope "soon" I could have a git public repo 
with my emacs config


[0]
#+begin_src emacs-lisp
(defun my/org-add-timestamp-on-heading ()
  (save-excursion
    (org-back-to-heading)
    (org-edit-headline (format-time-string "<%F>"))
    (my/set-property-with-inactive-timestamp "CREATED")))

(add-hook 'org-insert-heading-hook 'my/org-add-timestamp-on-heading 'append)
;; to remove it
;; (remove-hook 'org-insert-heading-hook 'my/org-add-timestamp-on-heading)
#+end_src

[1] https://strftime.org/

[2]

#+begin_src emacs-lisp
(setq my/diary-file "1activity.org")
(setq my/board-file "board.org")
(setq my/proj-file "projects.org")
(setq my/proj-candidates-file "projects-candidates.org")
#+end_src

[3]
#+begin_src emacs-lisp
(defun my/org-heading-insert-scheduled ()
  (save-excursion
    ;; src 
https://emacs.stackexchange.com/questions/72147/org-mode-adding-creation-date-property-upon-heading-creation

    (org-schedule nil (format-time-string "[%Y-%m-%d %a]" nil

(add-hook 'org-insert-heading-hook 'my/org-heading-insert-scheduled 'append)
#+end_src
 script: migrate from old heading format
:PROPERTIES:
:CREATED:  [2023-07-24 Mon 03:38]
:CUSTOM_ID: emacsconf_51
:END:

#+name: created on [2023-07-24 Mon 03:38:47]
#+begin_src emacs-lisp
(defun my/migrate-legacy-created-format ()
  (interactive)
  (org-map-entries
   (lambda ()
 (let* ((title (org-entry-get nil "ITEM"))
(regexp "^\\(.*\\) <\\(20.*\\)>")
(current-created (org-entry-get (point) "CREATED")))
   (when (string-match regexp title)
 (let ((new-title (match-string 1 title))
   (new-created (match-string 2 title)))
   (if current-created
   (message "Warning: \"%s\" not added as created property" title)
 (progn
   ;; move match to CREATED property
   (org-entry-put (point) "CREATED" (format "[%s]" new-created))
   ;; delete heading text
   (org-edit-headline new-title)))
   nil 'file))
#+end_src


OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[O] sectioning depth limit on export

[Pedro Silva]

I'm having problems over a document with headings down to a depth of 5
export the levels 4 and 5 as \paragraph and \subparagraph, respectively.

My org-export-latex-classes includes the following:
("article" "\\documentclass[11pt]{article}"
 ("\\section{%s}" . "\\section*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))

My source document includes the following:
#+LaTeX_CLASS: article, my org-export-latex-class is "article", and my
org-export-latex-sectioning-depth is locally set to 6 (default is 3).

According to the "More Highly-Structured Documents" subsection of "Latex
Export" worg tutorial
<http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-3>

This setup should produce the following document structure, when
exported to LaTeX:

* section
** subsection
*** subsubsection
 paragraph
* subparagraph

However, this is what is produced:

* section
** subsection
*** subsubsection
 itemize
* sub-itemize, etc

This happens with all export types I've tried, namely LaTeX, HTML, and
plain text.  Any ideas about how to force export of 4 and 5-level deep
headings as paragraph and subparagraph headings in LaTeX?
-- 
Pedro

Re: [O] sectioning depth limit on export

[Pedro Silva]

Nick Dokos  writes:

> Try setting org-export-headline-levels to 6 or use the equivalent in-buffer 
> setting
>
> #+OPTIONS: H:6
>

Ah, that did it.  Thanks for your help!
-- 
Pedro

[O] Latex export postamble

[Pedro Silva]

Is it possible to insert text just before \end{document} on export,
similarly to org-export-html-postamble?

I'd like to do this on a capture target file that contains the following
at the end:

\bibliography{references}

New capture entries keep getting inserted below it, which makes the
references section appear in the middle of the document if I forget to
move it to the end again.

Or maybe there is another way to make this work?

Pedro
-- 
Don't try to have the last word. You might get it.
-- Lazarus Long

Re: [O] Latex export postamble

[Pedro Silva]

Pedro Silva  writes:

> Is it possible to insert text just before \end{document} on export,
> similarly to org-export-html-postamble?
>
> I'd like to do this on a capture target file that contains the following
> at the end:
>
>   \bibliography{references}
>
> New capture entries keep getting inserted below it, which makes the
> references section appear in the middle of the document if I forget to
> move it to the end again.
>
> Or maybe there is another way to make this work?

Looking at the relevant code in contrib/org-exp-bibtex.el, I managed to
produce the following, which *almost* works:

(defun org-export-bibliography-preprocess ()
"Insert \bibliography and \bibliographystyle commands at end
of buffer if keyword `#+BIBLIOGRAPHY  

[O] [PATCH] summarize timestamps in column view

[Pedro Silva]

* org-colview.el (org-columns-compile-map):
(org-columns-number-to-string):
(org-columns-string-to-number): Handle timestamp summaries.

* org.texi (Column attributes): Document timestamp summaries.

TINYCHANGE
---
 contrib/lisp/org-colview-xemacs.el | 11 ++-
 doc/org.texi   |  3 +++
 lisp/org-colview.el| 11 ++-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-colview-xemacs.el 
b/contrib/lisp/org-colview-xemacs.el
index 63c0238..c2cff84 100644
--- a/contrib/lisp/org-colview-xemacs.el
+++ b/contrib/lisp/org-colview-xemacs.el
@@ -901,7 +901,12 @@ around it."
 ("@mean" mean_age
  (lambda (&rest x) (/ (apply '+ x) (float (length x
  (lambda (x) (- org-columns-time x)))
-("est+" estimate org-estimate-combine))
+("est+" estimate org-estimate-combine)
+(" format,function,calc  map.
 Used to compile/uncompile columns format and completing read in
 interactive function `org-columns-new'.
@@ -1190,6 +1195,9 @@ Don't set this, this is meant for dynamic scoping.")
 (defun org-columns-number-to-string (n fmt &optional printf)
   "Convert a computed column number to a string value, according to FMT."
   (cond
+   ((memq fmt '(timestamp))
+(format-time-string
+ (or printf (car org-time-stamp-formats)) (seconds-to-time n)))
((memq fmt '(estimate)) (org-estimate-print n printf))
((not (numberp n)) "")
((memq fmt '(add_times max_times min_times mean_times))
@@ -1218,6 +1226,7 @@ Don't set this, this is meant for dynamic scoping.")
   "Convert a column value to a number that can be used for column computing."
   (if s
   (cond
+   ((memq fmt '(timestamp)) s)
((memq fmt '(min_age max_age mean_age))
(cond ((string= s "") org-columns-time)
  ((string-match
diff --git a/doc/org.texi b/doc/org.texi
index 6d5eca0..8b1c49d 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5497,6 +5497,9 @@ optional.  The individual parts have the following 
meaning:
 @{@@min@}@r{Minimum age (in days/hours/mins/seconds).}
 @{@@max@}@r{Maximum age (in days/hours/mins/seconds).}
 @{@@mean@}   @r{Arithmetic mean of ages (in 
days/hours/mins/seconds).}
+@{ format,function,calc  map.
 Used to compile/uncompile columns format and completing read in
 interactive function `org-columns-new'.
@@ -1055,6 +1060,9 @@ Don't set this, this is meant for dynamic scoping.")
 (defun org-columns-number-to-string (n fmt &optional printf)
   "Convert a computed column number to a string value, according to FMT."
   (cond
+   ((memq fmt '(timestamp))
+(format-time-string
+ (or printf (car org-time-stamp-formats)) (seconds-to-time n)))
((memq fmt '(estimate)) (org-estimate-print n printf))
((not (numberp n)) "")
((memq fmt '(add_times max_times min_times mean_times))
@@ -1083,6 +1091,7 @@ Don't set this, this is meant for dynamic scoping.")
   "Convert a column value to a number that can be used for column computing."
   (if s
   (cond
+   ((memq fmt '(timestamp)) s)
((memq fmt '(min_age max_age mean_age))
 (cond ((string= s "") org-columns-time)
   ((string-match
-- 
1.8.3

Re: [O] [PATCH] summarize timestamps in column view

[Pedro Silva]

Hi Bastien,

Bastien  writes:

> It hardly counts as a tiny change, though, as I count 25 lines...
> I'm afraid the patch is larger than what we can accept without
> paperwork.  Would you mind signing the FSF copyright assignment
> (or telling me if you did so already for Emacs)?

I don't mind assigning copyright to FSF at all. I've not done so until now.

>   http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt
>
> That'll leave some time so that someone else can test the patch
> and report about it :)

Sounds good. I'll email  after I write this. Should I
revive this thread when the assignment is acknowledged?

Thanks for looking at the patch,
-- 
Pedro

Re: Custom TODO states for one item

[João Pedro]

Greetings, Bastien!

On 28 March 2022 14:39, Bastien  wrote:

>> I have a file with custom TODO states:
>>
>> #+TODO: FOO(f@/@) | BAR(b@/@)
>>
>> I have one item (heading) within that file that I'd like to have
>> different TODO states. Is this possible?
>
> No, and I don't think it's a good idea to support this.

Could you elaborate on why not? I have been in situations where having
the ability to define a heading-wise TODO keyword would be useful, but I
managed to get around using different ways of achieving the same
end-goal.

Best regards,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: About 'inline special blocks'

[João Pedro]

On Tue, May 24 2022 11:56, Ihor Radchenko  wrote:

> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:

On that note, I think that allowing for inline special blocks would make
that more readable. It would work wonderfully with
org-special-block-extras [1], where the user could define complex blocks
with formatting configuration and what-not, and just use that as an
inline block.

> #+attr_latex[name]: 
> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
>
> "<>" will be treated as "" during
> export/parsing.

Although I do agree that this sort of solves the same problem as the
other approach, but I, personally, find that defining new special blocks
is not only easier to reuse, but more readable as well. But I'm thinking
in terms of org-special-block-extras here, so take my 2 cents with a
grain of salt.


[1] https://github.com/alhassy/org-special-block-extras

Best,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: About 'inline special blocks'

[João Pedro]

On Thu, May 26 2022 12:56, Ihor Radchenko  wrote:

> I agree. But it is a known problem on defining new specific command vs.
> running a new generic command with arguments. You can indeed define a
> new command (block in our case), but if you just need to adjust some
> parameter once in the whole document, there is no point creating a whole
> new block type just for that purpose. Think about defun vs. lambda.

Oh, got it. Well, as I said, I'd be more than happy using the #+attr_X
solution though!

> I am not sure if I mentioned this earlier, but org-special-block-extras
> could be a good addition to Org core.

Has anyone tried reaching out to the author? I think it would be a great
addition! It is a seemingly simple idea that opens up some many
possibilities in Org-mode.

Best,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: About 'inline special blocks'

[João Pedro]

On Thu, May 26 2022 20:20, Ihor Radchenko  wrote:

> I think that you can simply open an issue in his Github repo.

I reached out to him on e-mail, if he doesn't reply there I'll create
the issue. Thanks!

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: About opening issues vs email [Was: About 'inline special blocks']

[João Pedro]

Hey Kaushal! Thanks for your insight.

On Thu, May 26 2022 17:22, Kaushal Modi  wrote:

> - Issues section is there for a reason. If the repo owner did not like
> people opening Issues, they would disable that section.

I agree with Ihor's response for this point.

> - Conversations and discussions are better formatted and readable in
> the issue threads.

I disagree with this one, I find mailing lists much more well-formatted,
readable and conversation/discussion friendly than PRs on GitHub (it
mostly has to do it the web UI, TBH [1]).

> - If the feature is implemented, I like to link that commit or PR to
> that issue so that the entire history and reasoning behind a feature
> addition (esp. if it's a breaking one) can be followed through
> hyperlinks from the commit log to the issue thread.

But it isn't this particular case. I only emailed asking if he would
have interest on merging his work on Org-mode core, which isn't really a
feature or a modification on the codebase. Nonetheless, one of the first
things I said was that I could open an issue on the public repo if he'd
rather have it documented there as well. I just felt more inclined to
send him an e-mail because 1. he made it public, and 2. I feel more
comfortable using e-mails for communicating such things.

[1] https://asylum.madhouse-project.org/blog/2018/07/24/on-git-github-and-email/

Regards,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Org and Hyperbole

[João Pedro]

Hey Robert. Thanks for coming here to offer to clarify any doubts people
have regarding Hyperbole.

I haven't been interacting with the thread, but I've been lurking about
and I've tried Hyperbole in the past, but couldn't precisely figure out
its use case in my particular workflow, so I gave up on it.

Now, according to your description, the main feature of Hyperbole looks
a lot like what Embark [1] does sort of the same thing, albeit in
different contexts, complexity (not a bad thing) and workflow. Would you
be able to compare them? I think it would help me understand where
exactly Hyperbole fits, and what is the problem it tries to solve.

[1] https://github.com/oantolin/embark

Best regards,

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Pedro Bruel]

Hi,

Could you please share which versions of julia, emacs, and orgmode you are
running?
I believe the ob-julia version we have on orgmode does not support sessions.

Thanks,
Pedro

On Mon, Oct 17, 2022 at 9:45 PM Ihor Radchenko  wrote:

> [CCing the maintainer]
>
> Ihor Radchenko  writes:
>
> > Christian Köstlin  writes:
> >
> >> I am trying to run the ob-julia tests but `make test` is prompting me
> >> for a project folder. Has anybody the tests (or the ob-julia setup) in
> >> a working state? (Simple ob-julia evaluations (without session) do
> >> work for me).
> >
> > Some more data.
> >
> > I just tried to run test-ob-julia/colnames-yes-header-argument
> > interactively and the test fails. Trying to execute example source block
> > raises the following error:
> >
> > ERROR: syntax: cannot juxtapose string literal
>
> Pedro, could you please take a look
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: [PATCH] LSP support in org-src buffers

[João Pedro]

Hey there, Karthik!

I've had a similar idea, though not tied to LSP or anything. I created a
=org-contextual-src-mode= [1] ir order to have completion working on
Ledger and LaTeX source buffers. It also handles tangling! I have made a
Gist explaining, in a literate style, my process of building such a
mode.

I think the contextual src block could be split from the LSP
functionality, since it could be used in other contexts other than
dealing with language servers. My iteration is not tied to anything in
particular and simply creates a source buffer with the whole context for
that tangled file.

Hope this can help you in some way!

[1] https://gist.github.com/bigodel/15599f3c1da23d1008b7d7d4ff8bff77

Cheers,

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [PATCH] LSP support in org-src buffers

[João Pedro]

On Tue, November 22 2022 02:23, Ihor Radchenko  wrote:

> It looks like you have done something very close to what we are
> discussing. Would you be interested to create a patch against Org core
> instead of relying on advises?

That would be wonderful! That code has some ugly hacks, some of which
gave me a little bit of headache when I was using it, but I think that
it could become something polished and well-behaved, specially taking
inspiration on Karthik's approach to it as well (I can, from a quick
glance, see some improvements that could be made. And who knows maybe we
make it work even with noweb...). Were you thinking of having a
=:context {yes|no}= option on src blocks?

Also, I will have more free time to work on it starting on the second
week of December. Before that I'll be incredibly busy, unfortunately.

Best regards,

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [PATCH] LSP support in org-src buffers

[João Pedro]

On Mon, December 12 2022 13:16, Ihor Radchenko  wrote:

> If an src block has :tangle option, it is probably reasonable to display
> it together with other tangled blocks.
> If an src blocks does not have a :tangle option, :context might be used
> as the means to group blocks together. But then, the value should be
> some kind of string - blocks with the same :context name will be grouped
> together.

That makes much more sense. Though I still think the user should be able
to, even with a :tangle option, be able to choose whether they want to
edit that particular source block with the whole context or not, cause
it might be slow for some huge tangled files, for example.

> And, of course, the whole thing may be behind a defcustom switch. Or
> file option.

Yup! I prefer to have both options, a file option and a defcustom. This
allows me to have a global configuration, but change it to a particular
file without having to deal with the local variables block in Org files.

> We are not in hurry. Any progress will be appreciated as long as there
> is some.

All right. I'll keep you posted on it.

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

[João Pedro]

On Thu, February 09 2023 11:51, Ihor Radchenko  wrote:

> Hi,

Hello Ihor!

> If you are ok with sharing the statistics, and you are running Emacs
> session for at least few hours (using Org mode, obviously), please reply
> sharing the output of

Definitely OK with it! Here it goes

>  M-x org-element-cache-hash-show-statistics 

22.63% of cache searches hashed, 1.71% non-hashable.

>  M-x emacs-uptime 

2 days, 3 hours, 19 minutes, 31 seconds

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

[DOC] Mismatch on doc regarding position of src block switches

[João Pedro]

Hi Org folks,

I've noticed that in (org)Literal Examples[0], when documenting the switches 
for example and source blocks, it is mentioned that they should be placed at 
the *end* of the #+BEGIN line, while both in (org)Structure of Code Blocks[1] 
and the Org Syntax document[2] the switches are documented to be placed right 
after the language (when appropriate), which is the correct placement for it.

I've also noticed that the Org Syntax for blocks (greater or lesser) don't 
mention example blocks having optional switches.

[0] https://orgmode.org/manual/Literal-Examples.html
[1] https://orgmode.org/manual/Structure-of-Code-Blocks.html
[2] https://orgmode.org/worg/org-syntax.html#Blocks

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [DOC] Mismatch on doc regarding position of src block switches

[João Pedro]

Em segunda, 22/04/2024 às 18:12 (GMT), Ihor Radchenko  
escreveu:

> Thanks for reporting!
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a9275d5fd

Wonderful, thanks for the quick fix as well!

> We deliberately limit the number of details in the syntax spec.
> For now, we just say that lesser blocks can have arbitrary DATA at the
> begin line.

Ah ok, I was wondering whether that was intentional or not!

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Possible to set block switches "globally"?

[João Pedro]

Hi Org-mode!

Is there a way to set =src= and =example= switches (as documented in
"(org) Literal Examples"[0]) file- or heading-wide? I tried using

#+property: header-args:emacs-lisp -n -r

but they aren't really header arguments and that doesn't get picked up
as it should (it does, but as if `-n' is a key and `-r' is a value for a
header argument).

Ideally, I would be able to set those as a file properties like that, or
per heading under the =:PROPERTIES:= drawer.

[0] https://orgmode.org/manual/Literal-Examples.html

Thanks in advance,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Possible to set block switches "globally"?

[João Pedro]

Hi Org-mode!

Is there a way to set =src= and =example= switches (as documented in
"(org) Literal Examples"[0]) file- or heading-wide? I tried using

#+property: header-args:emacs-lisp -n -r

but they aren't really header arguments and that doesn't get picked up
as it should (it does, but as if `-n' is a key and `-r' is a value for a
header argument).

Ideally, I would be able to set those as a file properties like that, or
per heading under the =:PROPERTIES:= drawer.

Thanks in advance,

[0] https://orgmode.org/manual/Literal-Examples.html

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [ANN] lisp/ob-tangle-sync.el

[João Pedro]

Hey Mehmet and Org!

I'd like to ask if I could contribute to this. I have followed the
discussion to a point, but would be more than happy to try and
contribute to this so it gets merged for the next Org major version, as
I've been waiting for this for quite a while now. It solves the major
gripe I had with your original org-tangle-sync.el package, which is the
ability to sync blocks that aren't whole files.

So, what still needs to be done and where is development happening (I
assumed it was on the main Org-mode git repository, but I see no branch
there)?

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [ANN] lisp/ob-tangle-sync.el

[João Pedro]

Em segunda, 29/04/2024 às 09:43 (+02), Mehmet Tekman  
escreveu:

> The development is happening chaotically on my own repo
> (gitlab.com/mtekman/org-mode) across several incomplete branches.
>
> I've actually been working on it on and off for the last two weeks, but
> I've been facing some rebasing issues that I need to tackle first before
> I actually push anything to a branch that anyone can work on.
>
> Can you wait until Sunday for me to resolve this, and then we can
> discuss?

Yeah, of course!

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Possible to set block switches "globally"?

[João Pedro]

Em segunda, 29/04/2024 às 17:34 (GMT), Ihor Radchenko  
escreveu:

> Yes. This is the plan.
>
> Citing earlier syntax discussion in
> https://list.orgmode.org/orgmode/877d08bkze.fsf@localhost/
>
> > Can we drop switch support? This seems like a fairly good idea. The 
> functionality can simply be shifted to
> > ARGUMENTS with the well-established :key val forms.
> > “For the love of all that is sane” — Tom G

All right so if I understand correctly, we'd like to deprecate switches
from the parser and introduce :key val pairs for each switch, but no one
has gotten to it yet?

If that's the case, I'd propose something like

- (-|+)n => :number-lines (yes|*no*|continue)
^ +n
- -r => :labels (link|keep|*remove*) ("label string")?
 ^ -k ^ -l "label string"

and could give it a try. What do you think?

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Possible to set block switches "globally"?

[João Pedro]

Em sexta, 03/05/2024 às 10:12 (-07), Tom Gillespie  escreveu:

> Hi,
>Thanks for getting things going on this again João.

No problem! I've been meaning to get my feet wet on some Org-mode
hacking for a while now.

> Based on what is in org-element-example-block-parser
> and org-element-src-block-parser I think
>
> :number-lines (yes|no|continue) as João proposes
> :indent   (preserve|align|???) not sure about naming
> :labels  (link|keep|remove|remove-whitespace)
> :label-format  regexp-string

Yeah, as Ihor pointed out I did forget about -i, though I'm not really
sure what that does.

> Defaults would be :number-lines no, :indent align,
> :labels remove-whitespace and :label-format would
> inherit from the default.
>
> The remove-whitespace option would remove the label
> itself along with any whitespace leading up to it, this
> avoids the user needing to specify the leading whitespace
> in :label-format. The remove option by itself is retained
> in the event that someone has aligned their labels and
> wants to retain the whitespace. This may be too complex
> though and remove-whitespace is not needed because
> :label-format can be modified as needed.
>
> Header arguments need to have a single value, so I think
> we should split :labels and :label-format, that way users
> can also specify :label-format without having to specify
> :labels first (otherwise there is ambiguity about what a single
> argument :labels means.

Sure, makes sense to separate it.

I tried searching for where switches are parsed in the code, but
couldn't find much. Could you provide me with some pointers and files I
should be looking at?

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

[Q/Bug?] Comment for noweb reference comments content

[João Pedro]

Hi,

Ok so I don't know whether this is a bug or intended behaviour (though
if its the latter I propose we reconsider), but if I have the following

#+begin_src emacs-lisp :noweb yes :comments noweb :tangle /tmp/foo.el
(progn
  <>)
#+end_src

#+name: foo
#+begin_src emacs-lisp
(message "foo")
#+end_src

the resulting foo.el will have a syntax error, since the closing ) for
`progn' will have been commented like so

;; [[file:...][No heading:1]]
(progn
  ;; [[file:...][foo]]
  (message "foo")
  ;; foo ends here)
  ^
;; No heading:1 ends here

It seems like some macro let-bound in `org-babel-expand-noweb-refereces'
is doing this, but I couldn't pinpoint exactly what or where. What I
could achieve though, is to add a newline after the second call to
`c-wrap' inside `expand-body''s definition, which at least solve the
problem of throwing syntax errors, but I don't think that would be the
best solution.

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [ANN] lisp/ob-tangle-sync.el

[João Pedro]

Em domingo, 05/05/2024 às 18:47 (+02), Mehmet Tekman  
escreveu:

> Hello João and org!

Hi Mehmet!

> This will be a long email summarizing what's been done so far, where the
> pitfalls were, where we are now, and what needs to be done:

Thank you for the summary. Albeit long, it was quite important to
understand all of the discussions and decisions so far. I tried keeping
track of every thing on this long, long thread, but couldn't follow up
with everything, so it was incredibly helpful of you to give such a
complete summary.

> So, my code is hosted at =https://gitlab.com/mtekman/org-mode= and with
> the exception of the =header-reform= branch, is about 1 year behind
> upstream.

So, if I understand correctly, =header-reform= is where we're at right
now and after we're done with this overhauling of the parsing of
(mutually exclusive) header params, we'll get back to the actual syncing
logic, which should be mostly done.

> * Where we are now
>
> The branch I have most recently worked on (I rebased it earlier this
> week) is called =header-reform=. It splits a :tangle header such as
>
> this =:tangle filename with space.txt export=
> into =:tangle-params ("filename with space.txt" "export")=
>
> such that it does not interfere with the rest of org headers.
>
> This is where I would greatly need you help, João.
>
> The work still to be done from my perspective:
>
> 1. Implement tests  <<- we are here
>
>We need to know what the desired behaviour of :tangle and
>:tangle-params will be in different contexts.
>
>I have written 12 test cases as a start, but some contexts are
>still unclear to me and I cannot do this alone.
>
>Please see the second and third patches attached to this email.

Ok I'll start here as I think writing tests could give me some more
insights on the core problems that still need solution.

> 2. Unified merge function

I do have a couple of questions regarding this:

>Something that handles tangle-params and result-params,

1. So the idea is to continue parsing multi-option header arguments into
   their separate components, but have a common place to, after parsing
   it into their components, handle them all in a single place? I mean,
   what does "handle" mean in this context?

>as well
>something that can handle mutually exclusive groups such as tangle
>and results, especially when the :any keyword is involved.

2. Isn't that the same as the previous point? If we can handle any
   *-params doesn't that solve the problem of handling mutually
   exclusive groups? We can just define a pattern of parsing them into
   individual *-params and handling that in a unified manner.

> I've attached the two working patches from the =header-reform= branch to
> this mail, and one floating WIP inline patch which should get things
> started.

Are these patches also on the branch (apart from the WIP one)?

> Apologies for the length, I just wanted to summarize the efforts and
> show where you could come in.

As I said in the beginning, I'm actually quite grateful for the
summarizing!

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: What's up with ob-template.el? It seems heavily outdated

[Pedro Bruel]

I would be interested in an updated ob-template.el file.
I have never added support for a new language, but I started working with
ob-julia.el, and I essentially read ob-R.el to learn how it all fits
together and how to add missing features to ob-julia.

Le ven. 21 mai 2021 à 10:34, dalanicolai  a écrit :

> I am trying to improve org-babel support for maxima.
> However, when starting from ob-template.el
> ,
> which is advised in the section "develop support for new languages" in the 
> org-mode
> docs ,
> it seems that the code within that template file is heavily incorrect.
>
> I can write a whole list with "bugs", but it already starts with most of
> the params in the `org-babel-execute` function getting processed
> incorrectly.
>
> So I am wondering, am I missing something here? Or is this documentation
> just heavily outdated?
>
> Would you be interested in some updated ob-template.el file?
>
> You have any experience with adding language support? Then how did you
> approach it?
>
> Also, I could not really find a (recent) bug-report about this issue. So
> nobody mentioned this before?
>
> I can already find my way, using edebug and checking out other ob-...el
> files. I am just interested in (and surprised about) the current situation
> and why it is like that. And I am wondering if maybe there is some more
> recent documentation available.
>
> Thanks!
>

Re: [ORG] Moving the org-mode.git repo to savannah.gnu.org

[Pedro Bruel]

Hello,

I'm already registered at the Emacs Savannah group with access to the
org-mode repository, but it seems to be a month behind
https://code.orgmode.org/bzg/org-mode.

I'm new and I don't have an account on code.orgmode.org, but I'm ready to
submit a new version of ob-julia.el. Should I wait for the complete move to
Savannah?

Thanks,
Pedro

Le sam. 5 juin 2021 à 07:09, stardiviner  a écrit :

> Thanks for quick reply and solving this problem. :smile:
>
> > On Jun 5, 2021, at 3:55 PM, Bastien  wrote:
> >
> > Hi Stardiviner,
> >
> > stardiviner  writes:
> >
> >> I have a big problem. After I registered savannah account, I open
> >> profile page at first 3 days. Then I have not touched it anymore. Now
> >> Savannah emailed me that my account has been removed because of idle.
> >
> > I'm sorry for this.  This happened to Timothy too, and perhaps others.
> > I was not aware of this policy.
> >
> > I was waiting to get all Savannah user names before asking the Emacs
> > maintainers to add them to the Emacs project (where the org-mode.git
> > Savannah repo lives), so that I ask only once, but it was a mistake.
> >
> > I will ask them to add all usernames I have today, hoping this will
> > avoid problems.
> >
> > Please write me in private so that we can sort this out for you.
> >
> > Thanks,
> >
> > --
> > Bastien
>
>
>

Re: Plotting with R

[Pedro Bruel]

Hi Roger,

There's a typo on your source block header, it should be "output graphics",
this would probably produce the output you're getting now.

Thanks,
Pedro


Le dim. 15 août 2021 à 10:17, Roger Mason  a écrit :

> Hello,
>
> I want graphics output from R:
>
> #+begin_src R :results output grahics file :file coa_vs_a.pdf :exports
> results
> library(tidyverse)
> library(RPostgreSQL)
> drv <- dbDriver("PostgreSQL")
> con <- dbConnect(drv, user="rmason",dbname="test")
> rs <- dbSendQuery(con,"with CTE as (select
> split_part(split_part(lattice_out, E'\n', 13), ' ', 18) as c,
>  split_part(split_part(lattice_out, E'\n', 11), ' ', 11) as a
>  from results where timestamp like '20210814-071%' order by a)
>  select cast(a as double precision), cast(c as double precision)/ cast(a
> as float) as coa from CTE;")
> df <- fetch(rs)
> theplot <- ggplot(df,aes(x=a,y=coa)) + geom_point()
> theplot
> #+end_src
>
> What I expect is a file 'coa_vs_a.pdf' on my filesystem & a link to it
> in the org buffer.  What I get is a file 'Rplots.pdf' and an empty file
> 'coa_vs_a.pdf' with a link to the latter in the org buffer.
>
> I've searched this topic and I _think_ the invocation above, one of many
> I've tried, should work.
>
> GNU Emacs 27.2 (build 1, amd64-portbld-freebsd11.4, X toolkit, cairo
> version 1.16.0, Xaw3d scroll bars)
>
> Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @
> /home/rmason/.emacs.d/org-git/lisp/)
>
> Thanks for your help.
>
> Roger
>
>

Re: Plotting with R

[Pedro Bruel]

No problem!

Le dim. 15 août 2021 à 11:14, Roger Mason  a écrit :

> Hello Pedro,
>
> Pedro Bruel writes:
>
> > There's a typo on your source block header, it should be "output
> graphics",
> > this would probably produce the output you're getting now.
>
> Thank you!  You saved my sanity!
>
> Roger
>
>

[PATCH] Include support for evaluating julia code

[Pedro Bruel]

Hi,

This patch includes ob-julia.el from org-contrib, and a tentative
test-ob-julia.el test file.
This is my first attempt at a patch, so please let me know if there's
anything wrong!

Thanks,
Pedro
From c002f541cad175573b102720e3880ba98d05bf67 Mon Sep 17 00:00:00 2001
From: Pedro Bruel 
Date: Fri, 24 Sep 2021 16:31:40 -0300
Subject: [PATCH] Include support for evaluating julia code

* lisp/ob-julia.el: included from org-contrib
* testing/lisp/test-ob-julia.el: start adapting from testing/lisp/test-ob-python.el
---
 lisp/ob-julia.el  | 344 ++
 testing/lisp/test-ob-julia.el | 274 +++
 2 files changed, 618 insertions(+)
 create mode 100644 lisp/ob-julia.el
 create mode 100644 testing/lisp/test-ob-julia.el

diff --git a/lisp/ob-julia.el b/lisp/ob-julia.el
new file mode 100644
index 0..cbc58d665
--- /dev/null
+++ b/lisp/ob-julia.el
@@ -0,0 +1,344 @@
+;;; ob-julia.el --- org-babel functions for julia code evaluation
+
+;; Copyright (C) 2013, 2014, 2021 G. Jay Kerns
+;; Authors: G. Jay Kerns, based on ob-R.el by Eric Schulte and Dan Davison
+;; Maintainer: Pedro Bruel 
+;; Keywords: literate programming, reproducible research, scientific computing
+;; Homepage: https://github.com/phrb/ob-julia
+
+;; This file is not part of GNU Emacs.
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Org-Babel support for evaluating julia code
+
+;;; Code:
+(require 'cl-lib)
+(require 'ob)
+
+(declare-function orgtbl-to-csv "org-table" (table params))
+(declare-function julia "ext:ess-julia" (&optional start-args))
+(declare-function inferior-ess-send-input "ext:ess-inf" ())
+(declare-function ess-make-buffer-current "ext:ess-inf" ())
+(declare-function ess-eval-buffer "ext:ess-inf" (vis))
+(declare-function ess-wait-for-process "ext:ess-inf"
+		  (&optional proc sec-prompt wait force-redisplay))
+
+(defvar org-babel-header-args:julia
+  '((width		 . :any)
+(horizontal		 . :any)
+(results . ((file list vector table scalar verbatim)
+			(raw org html latex code pp wrap)
+			(replace silent append prepend)
+			(output value graphics
+  "julia-specific header arguments.")
+
+(add-to-list 'org-babel-tangle-lang-exts '("julia" . "jl"))
+
+(defvar org-babel-default-header-args:julia '())
+
+(defcustom org-babel-julia-command "julia"
+  "Name of command to use for executing julia code."
+  :version "24.3"
+  :package-version '(Org . "8.0")
+  :group 'org-babel
+  :type 'string)
+
+(defvar ess-current-process-name) ; dynamically scoped
+(defvar ess-local-process-name) ; dynamically scoped
+(defun org-babel-edit-prep:julia (info)
+  (let ((session (cdr (assq :session (nth 2 info)
+(when (and session
+	   (string-prefix-p "*"  session)
+	   (string-suffix-p "*" session))
+  (org-babel-julia-initiate-session session nil
+
+(defun org-babel-expand-body:julia (body params &optional _graphics-file)
+  "Expand BODY according to PARAMS, return the expanded body."
+  (mapconcat 'identity
+	 (append
+	  (when (cdr (assq :prologue params))
+		(list (cdr (assq :prologue params
+	  (org-babel-variable-assignments:julia params)
+	  (list body)
+	  (when (cdr (assq :epilogue params))
+		(list (cdr (assq :epilogue params)
+	 "\n"))
+
+(defun org-babel-execute:julia (body params)
+  "Execute a block of julia code.
+This function is called by `org-babel-execute-src-block'."
+  (save-excursion
+(let* ((result-params (cdr (assq :result-params params)))
+	   (result-type (cdr (assq :result-type params)))
+   (session (org-babel-julia-initiate-session
+		 (cdr (assq :session params)) params))
+	   (graphics-file (and (member "graphics" (assq :result-params params))
+			   (org-babel-graphical-output-file params)))
+	   (colnames-p (unless graphics-file (cdr (assq :colnames params
+	   (rownames-p (unless graphics-file (cdr (assq :rownames params
+	   (full-body (org-babel-expand-body:julia body params graphics-file))
+	   (result
+	(org-babel-julia-evaluate
+	 s

Re: [PATCH] Include support for evaluating julia code

[Pedro Bruel]

Hi Timothy,

Thanks for the reply! I am submitting a modded version the of the original
ob-julia.el, where I had fixed the bugs I encountered and updated the
interface with org-mode.
I've been using the version on https://github.com/phrb/ob-julia for a while
now, mainly to write programming classes using julia.

Yours and Nicolò's version seems good though, I think you should submit it
when you consider it ready. In the meantime, what do we do?

Thanks,
Pedro

Le ven. 24 sept. 2021 à 17:08, Timothy  a écrit :

> Hi Pedro,
>
> Thanks for your patch, it’s great to see the interest in Julia support and
> it’s something that I absolutely think should be in org-core 🙂. However,
> ob-julia.el was moved into org-contrib because it was not well maintained,
> and very buggy. I’m actually currently working on a successor with Nicolò
> (see the linked repo) in my free time, and intend to submit that to Org
> when I feel it is mature enough. See https://github.com/nico202/ob-julia/
> for more information.
>
> All the best,
> *Timothy*
>
> * From*: Pedro Bruel <%22pedro+bruel%22+%3cpedro.br...@gmail.com%3E>
> * Subject*: [PATCH] Include support for evaluating julia code
> * To*: Org-mode <%22org-mode%22+%3cemacs-orgm...@gnu.org%3E>
> * Date*: Sat, 25 Sep 2021 03:56:43 +0800
> Hi,
>
> This patch includes ob-julia.el from org-contrib, and a tentative
> test-ob-julia.el test file.
> This is my first attempt at a patch, so please let me know if there's
> anything wrong!
>
> Thanks,
> Pedro
>
>
>

[Orgmode] lists and quoted latex

[Joao Pedro Pedroso]

Hello,

I am a happy new user of Org-mode version 6.17trans.
When processing lists in this mode, it seems that Org-mode gets
trapped if in the list there is some quoted latex texts, as in:

 1. My first option

 2. My second option
#+BEGIN_LaTeX
some difficult latex here
#+END_LaTeX

 1. <--- Should be my third option, but Org-mode resets the list
   counter here...

Any comments on this?
Thank you,

Pedro


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[O] Bug: Tables not aligning properly [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/MacPorts/EmacsMac.app/Contents/Resources/lisp/org/)]

[Joao Pedro Pedroso]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Since some versions ago, org-mode stopped aligning tables properly.
This has been commented in StackExchange:
  
https://emacs.stackexchange.com/questions/37828/org-mode-doesnt-align-column-bars-properly

Sincerely,

João Pedro Pedroso

--

Emacs  : GNU Emacs 26.1 (build 1, x86_64-apple-darwin17.6.0, Carbon Version 158 
AppKit 1561.4)
 of 2018-06-11
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ 
/Applications/MacPorts/EmacsMac.app/Contents/Resources/lisp/org/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-timer-default-timer 25
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-agenda-files '("~/private/GTD/work.org" "~/private/GTD/gtd.org" 
"~/private/GTD/home.org")
 org-modules '(org-timer org-w3m org-bbdb org-bibtex org-docview org-gnus 
org-info org-irc org-mhe org-rmail)
 org-mode-hook '((lambda nil (flyspell-mode) (visual-line-mode))
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-show-block-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 t
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-support-shift-select 'always
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-replace-disputed-keys t
 org-return-follows-link t
 org-clock-in-hook '((lambda nil (if (not org-timer-current-timer) 
(org-timer-set-timer (quote (16))
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("id" :follow org-id-open) ("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)
   ("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") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link) ("file" :complete 
org-file-complete-link)
   ("ftp" :follow (lambda (path) (browse-url (concat "ftp:" 
path ("help" :follow org--open-help-link)
   ("http" :follow (lambda (path) (browse-url (concat 
"http:" path
   ("https" :follow (lambda (path) (browse-url (concat 
"https:" path
   ("mailto" :follow (lambda (path) (browse-url (concat 
"mailto:"; path
   ("news" :follow (lambda (path) (browse-url (concat 
"news:"; path
   ("shell" :follow org--open-shell-link))
 org-image-actual-width '(400)
 org-agenda-custom-commands '(("w" todo "WAITING" nil) ("n" todo "NEXT" nil)
  ("d" "Agenda + Next Actions" ((agenda) (todo 
"NEXT"
 org-directory "~/private/ORG"
 org-default-notes-file "~/private/ORG/notes.org"
 org-list-allow-alphabetical t
 )

Re: [O] Bug: Tables not aligning properly [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/MacPorts/EmacsMac.app/Contents/Resources/lisp/org/)]

[Joao Pedro Pedroso]

This bug seems to be related to the presence
of TAB characters in the table.

Thanks,

J.P.Pedroso

[BUG] Error when using Org with emacsplus on MacOS with native comp [9.6 (9.6-??-27edae8 @ /Users/pedroabelleiraseco/.emacs.d/.local/straight/build-28.0.90/org/)]

[Pedro Abelleira Seco]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.




Emacs  : GNU Emacs 28.0.90 (build 1, aarch64-apple-darwin21.1.0, NS 
appkit-2113.00 Version 12.0.1 (Build 21A559))
of 2021-12-12
Package: Org mode version 9.6 (9.6-??-27edae8 @ 
/Users/pedroabelleiraseco/.emacs.d/.local/straight/build-28.0.90/org/)

current state:
==
(setq
org-link-elisp-confirm-function nil
org-directory "~/org/"
org-after-refile-insert-hook '(save-buffer)
org-indirect-buffer-display 'current-window
org-crypt-key nil
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h
 +org-init-attachments-h +org-init-babel-h 
+org-init-babel-lazy-loader-h
 +org-init-capture-defaults-h +org-init-capture-frame-h 
+org-init-custom-links-h
 +org-init-export-h +org-init-habit-h +org-init-hacks-h 
+org-init-keybinds-h
 +org-init-popup-rules-h +org-init-protocol-h 
+org-init-protocol-lazy-loader-h
 +org-init-smartparens-h)
org-startup-folded nil
org-babel-after-execute-hook '(org-redisplay-inline-images)
org-link-abbrev-alist '(("doom-repo" . 
"https://github.com/hlissner/doom-emacs/%s";)
 ("wolfram" . "https://wolframalpha.com/input/?i=%s";)
 ("wikipedia" . "https://en.wikipedia.org/wiki/%s";)
 ("duckduckgo" . "https://duckduckgo.com/?q=%s";)
 ("gmap" . "https://maps.google.com/maps?q=%s";)
 ("gimages" . "https://google.com/images?q=%s";)
 ("google" . "https://google.com/search?q=";)
 ("youtube" . "https://youtube.com/watch?v=%s";)
 ("github" . "https://github.com/%s";))
org-agenda-files '("~/org/")
org-capture-templates '(("t" "Personal todo" entry (file+headline 
+org-capture-todo-file "Inbox")
  "* [ ] %?\n%i\n%a" :prepend t)
 ("n" "Personal notes" entry
  (file+headline +org-capture-notes-file "Inbox") "* %u 
%?\n%i\n%a"
  :prepend t)
 ("j" "Journal" entry (file+olp+datetree 
+org-capture-journal-file)
  "* %U %?\n%i\n%a" :prepend t)
 ("p" "Templates for projects")
 ("pt" "Project-local todo" entry
  (file+headline +org-capture-project-todo-file "Inbox")
  "* TODO %?\n%i\n%a" :prepend t)
 ("pn" "Project-local notes" entry
  (file+headline +org-capture-project-notes-file 
"Inbox")
  "* %U %?\n%i\n%a" :prepend t)
 ("pc" "Project-local changelog" entry
  (file+headline +org-capture-project-changelog-file 
"Unreleased")
  "* %U %?\n%i\n%a" :prepend t)
 ("o" "Centralized templates for projects")
 ("ot" "Project todo" entry 
#'+org-capture-central-project-todo-file
  "* TODO %?\n %i\n %a" :heading "Tasks" :prepend nil)
 ("on" "Project notes" entry 
#'+org-capture-central-project-notes-file
  "* %U %?\n %i\n %a" :heading "Notes" :prepend t)
 ("oc" "Project changelog" entry
  #'+org-capture-central-project-changelog-file "* %U 
%?\n %i\n %a"
  :heading "Changelog" :prepend t)
 )
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "/Users/pedroabelleiraseco/org/notes.org"
org-refile-use-outline-path 'file
org-archive-hook '(org-attach-archive-delete-maybe)
org-file-apps '((remote . emacs) (auto-mode . emacs) (directory . emacs) 
("\\.mm\\'" . default)
 ("\\.x?html?\\'" . default) ("\\.pdf\\'" . default))
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)
org-catch-invisible-edits 'smart
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-font-lock-set-keywords-hook '(doom-themes-enable-org-fontification)
org-modules '(ol-bibtex)
org-image-actual-width nil
org-attach-use-inheritance t
org-mode-local-vars-hook '(+org-init-gifs-h eldoc-mode)
org-mode-hook '(er/add-org-mode-expansions

[BUG] ox-latex does not read EXPORT_LATEX_CLASS property from subtree [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Pedro Prieto Alarcón]

Hi,

I can't make ox-latex use a different class for a subtree using
EXPORT_LATEX_CLASS, as stated in the docs:
https://orgmode.org/manual/LaTeX-header-and-sectioning.html

I am trying to change a specific subtree to a different layout (using
tcolorbox) than the one provided in the main document class (sections)

Thanks for your help!!

Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/share/emacs/29.1/lisp/org/)

Re: [BUG] ox-latex does not read EXPORT_LATEX_CLASS property from subtree [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Pedro Prieto Alarcón]

Yeah, I learned it later. Sorry, and thanks for your answer!

Best,

Pedro Prieto

El mar, 10 oct 2023 17:57, Ihor Radchenko  escribió:

> Pedro Prieto Alarcón  writes:
>
> > I can't make ox-latex use a different class for a subtree using
> > EXPORT_LATEX_CLASS, as stated in the docs:
> > https://orgmode.org/manual/LaTeX-header-and-sectioning.html
> >
> > I am trying to change a specific subtree to a different layout (using
> > tcolorbox) than the one provided in the main document class (sections)
>
> I am not sure if Latex class is what you want. LATEX_CLASS defines how
> Org parses the document structure and what to put into \documentclass -
> it is defined once at the beginning of export. When you set
> EXPORT_LATEX_CLASS for a subtree, it will be used when you export that
> subtree as a separate document.
>
> If you want to change the latex environment used during export, I
> recommend using special block instead.
>
> Not a bug.
> Canceled.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Pedro A. Aranda]

Hi again

As stated, this was only a PoC. If you find it useful, I would give it a 
go in the free window. I'm also playing with 
org-latex-default-packages-alist, refining it to use fontspec in 
lualatex and xetex and restricting inputenc and fontenc to pdflatex only.


Best, /PA

On 24/1/24 17:25, Ihor Radchenko wrote:

Pedro Andres Aranda Gutierrez  writes:


Attached is a _proof of concept_ for supporting AUTO in
\usepackage{fontenc}. Just an idea of how things could evolve.
This only uses a variable you can define as directory or file local to
control what is generated in the LaTeX file.
Could be expanded in the future to check #+language:

Thanks!


+(defcustom org-latex-fontenc "T1"
+  "The fontenc for the file. Customise to LGR,T1 when including
+Greek, etc."
+  :group 'org-export-latex
+  :type 'string
+  :safe #'stringp)

Is there a list of available values somewhere?
https://latexref.xyz/fontenc-package.html only lists OT1, OMS, OML, T1,
and TS1. However, many more are clearly available.

Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Pedro A. Aranda]

Hi

I've been reading a bit. What I propose is an alternative way to handle 
all the tricky parts of font and character handling with fontspec in 
lualatex and xetex. This package restricts the use of the ams* packages 
to pdflatex, because fontenc handles that internally and produces 
package collisions.


Attached is the final version of the patch.

Best, /PA

On 25/1/24 14:41, Ihor Radchenko wrote:

"Pedro A. Aranda"  writes:


As stated, this was only a PoC. If you find it useful, I would give it a
go in the free window.

I understand.
My question is to clarify how useful it is.
Because I am not deeply familiar with how fontenc works for non-English
languages, it is hard to judge how useful it will be in practice.


... I'm also playing with
org-latex-default-packages-alist, refining it to use fontspec in
lualatex and xetex and restricting inputenc and fontenc to pdflatex only.

Aren't inputenc and fontenc already restricted to pdflatex only?
From 481a35750fcb4098fe469efc80623c5c289b6f9f Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Thu, 25 Jan 2024 17:47:15 +0100
Subject: [PATCH] Refine font management for lualatex and xetex

---
 lisp/org.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

 lisp/org.el: switch to fontspec for character and font management
   in lualatex and xetex. This implies explicitly importing the
   ams* packages is only needed with pdflatex.

diff --git a/lisp/org.el b/lisp/org.el
index cf9abafac..f50531e7e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3402,15 +3402,16 @@ header, or they will be appended."
 	  (default-value var)))

 (defcustom org-latex-default-packages-alist
-  '(("AUTO" "inputenc"  t ("pdflatex"))
+  '(("" "fontspec"  t ("lualatex" "xetex"))
+("AUTO" "inputenc"  t ("pdflatex"))
 ("T1"   "fontenc"   t ("pdflatex"))
 ("" "graphicx"  t)
 ("" "longtable" nil)
 ("" "wrapfig"   nil)
 ("" "rotating"  nil)
 ("normalem" "ulem"  t)
-("" "amsmath"   t)
-("" "amssymb"   t)
+("" "amsmath"   t ("pdflatex"))
+("" "amssymb"   t ("pdflatex"))
 ("" "capt-of"   nil)
 ("" "hyperref"  nil))
   "Alist of default packages to be inserted in the header.
@@ -3421,6 +3422,7 @@ incompatibility with another package you are using.
 The packages in this list are needed by one part or another of
 Org mode to function properly:

+- fontspec: for font ans character selection in lualatex and xetex
 - inputenc, fontenc:  for basic font and character selection
 - graphicx: for including images
 - longtable: For multipage tables
--
2.34.1

Reproducible work with natively compiled Emacs

[Pedro A. Aranda]

Hi,

I have been experiencing some inconsistencies with org-mode, which I 
have been able to trace own to using native compilation and not knowing 
where the files from main were.


Attached is a patch in four parts to make natively compiled orgmode more 
consistent.


This is a first step and I would like reactions to it, before submitting 
a unified patch.


I hope that splitting it up helps understanding the different parts of 
my "solution". Maybe some parts can be cherry picked better this way...


best /PA
From e47289a60f225a0fa6d05efec9d38119d886f4a3 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 10 Mar 2024 11:23:09 +0100
Subject: [PATCH 1/4] Add 'native' option to 'make help'

---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index f476a3ea7..35250eed0 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,7 @@ help helpall::
 	$(info make all- ditto)
 	$(info make compile- build Org ELisp files)
 	$(info make single - build Org ELisp files, single Emacs per source)
+	$(info make native - build Org natively compiled ELisp)
 	$(info make autoloads  - create org-loaddefs.el to load Org in-place)
 	$(info make test   - build Org ELisp files and run test suite)
 	$(info make vanilla- run Emacs with this Org-mode and no personal config)
-- 
2.34.1

From 2d3c6b45d435a6356f198c421d71743d9b09efca Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 10 Mar 2024 11:26:46 +0100
Subject: [PATCH 2/4] Store .eln files alongside the lisp files

---
 mk/default.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mk/default.mk b/mk/default.mk
index b75aac345..312dbc6aa 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -158,6 +158,7 @@ ELC	= $(BATCHL) \
 
 # How to native-compile a single file
 ELN	= $(BATCHL) \
+	  --eval "(startup-redirect-eln-cache \"$(PWD)/lisp\")" \
 	  --eval '(batch-native-compile)'
 
 # How to make a pdf file from a texinfo file
-- 
2.34.1

From 34787b58add09decbf31e0e583fd315a207ce88d Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 10 Mar 2024 11:44:38 +0100
Subject: [PATCH 3/4] A short doc for reproducible native compilations when
 developing

---
 doc/native-devel.org | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 doc/native-devel.org

diff --git a/doc/native-devel.org b/doc/native-devel.org
new file mode 100644
index 0..0cc18a6fe
--- /dev/null
+++ b/doc/native-devel.org
@@ -0,0 +1,33 @@
+#+title: A reproducible natively compiled org-mode
+#+subtitle:  Release {{{version}}}
+#+author:The Org Mode Developers
+#+language:  en
+
+* Introduction
+
+In order to develop and test ~org-mode~ when your Emacs editor
+supports native compilation, there are two things to take into
+account:
+
+1. you will need to =make native= to generate the =.eln= files. These
+   will be stored under the ~lisp/~ directory of your development
+   ~org-mode~ directory.
+2. Add the following code in your Emacs ~early-init.el~ file:
+
+#+BEGIN_SRC emacs-lisp
+(let ((org-devel-path (expand-file-name "/lisp")))
+  (when (file-directory-p org-devel-path)
+(when (native-comp-available-p)
+  (let ((first (pop native-comp-eln-load-path)))
+;; put in second place
+(add-to-list 'native-comp-eln-load-path org-devel-path t)
+(add-to-list 'native-comp-eln-load-path first t)))
+(add-to-list 'load-path  org-devel-path)))
+#+END_SRC
+
+putting the correct path for your org-mode development directory. In
+my case, it is =~/Devel/org-mode=, so the first =let= looks like this:
+
+#+BEGIN_SRC emacs-lisp
+(let ((org-devel-path (expand-file-name "~/Devel/org-mode/lisp")))
+#+END_SRC
-- 
2.34.1

From 0f10451eef8d826ffb31f70f8a6c2db36ebc16a5 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 10 Mar 2024 12:06:28 +0100
Subject: [PATCH 4/4] Add cleaning native compilation

---
 lisp/Makefile | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/lisp/Makefile b/lisp/Makefile
index c570d9cfa..1f03539c2 100644
--- a/lisp/Makefile
+++ b/lisp/Makefile
@@ -10,13 +10,16 @@ LISPB 	:= $(LISPA:%el=%elc) org-install.elc
 LISPF 	:= $(filter-out $(LISPA),$(sort $(wildcard *.el)))
 LISPC 	:= $(filter-out $(LISPB) $(LISPN:%el=%elc),$(LISPF:%el=%elc))
 LISPN 	:= $(filter-out $(LISPB) $(LISPN:%el=%eln),$(LISPF:%el=%eln))
+# Should not be empty if lisp//org-lint.eln exists
+# like after a make native
+ELNDIR  := $(shell find . -name org-lint\*.eln -exec dirname {} \;)
 _ORGCM_ := dirall single native source slint1 slint2
 -include local.mk
 
 .PHONY:	all compile compile-dirty \
 	$(_ORGCM_) $(_ORGCM_:%=compile-%) \
 	autoloads \
-	install clean cleanauto cleanall cleanelc clean-install
+	install clean cleanauto cleanall cleanelc cleaneln cl

Re: Re: [FR] Please add custom command variable to org-latex-footnote-refere

[Pedro A. Aranda]

/Hi, Alexander Gogl  writes: /> ox-latex: New option 
to customize LaTeX footnote command

I hope you are aware that with your patch you are not going to be aware to pass
extra options to your foot or side notes, right? And since I'm not familiar with
kaobook, just a question. Are you sure that the foot and side notes will not 
choke
at a \label{} inside the text?
//> PS: I have a hard time to setup an environment to test the patch because

my Spacemacs configuration conflicts with the Org mode development
version. Can anyone provide me a link to a ressource that describes the
procedure?


I'm running on a vanilla Emacs and

---cut here --
(let ((org-devel-path (expand-file-name "~/Devel/org-mode/lisp")))
  (when (file-directory-p org-devel-path)
;; (message "Adding %s to load-path" org-devel-path)
(add-to-list 'load-path  org-devel-path)))
---cut here --

in my .emacs.d/early-init.el does the job. I have a general Devel directyl for 
my development jobs.

Hope it helps, /PA

PS: Cool kaobook. I've used koma-script for most of my LaTeX work in the last 
15 years +/- ;-) though.

PATCH: Add tip to integrate spellchecking with #+LANGUAGE:

[Pedro A. Aranda]

 doc/org-manual.org: Add tip to integrate spellchecking with #+LANGUAGE:

* doc/org-manual.org: Show how to watch ~org-export-default-language~ in
your ELISP code to automatically adjust your spell-checker.

---

 doc/org-manual.org | 12 
 1 file changed, 12 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6cf51ebca..020fd061f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14075,6 +14075,18 @@ general options (see [[*Export Settings]]).
    '("AUTO" "polyglossia" t ("xelatex" "lualatex")))
   #+end_src

+  *TIP*: you can watch this variable in your ELISP code to interface
+  with your spellchecker:
+
+  #+begin_src emacs-lisp
+    (defun org-export-default-language-watcher (_ newval _ _)
+  ;; newval will hold the value defined in #+LANGUAGE:
+  )
+
+    (add-variable-watcher 'org-export-default-language
+  #'org-export-default-language-watcher))
+  #+end_src
+
 - =LATEX_CLASS= ::

   #+cindex: @samp{LATEX_CLASS}, keyword
--
2.34.1

Re: Re: Org-cite: Replace basic follow-processor with transient menu?

[Pedro A. Aranda]

>Message: 7
>Date: Mon, 11 Nov 2024 15:52:03 +
>From: Ihor Radchenko 
>To: Tor-björn Claesson 
>Cc: Jonas Bernoulli , emacs-orgmode@gnu.org
>Subject: Re: Org-cite: Replace basic follow-processor with transient
>    menu?
>Message-ID: <87jzd9ojj0.fsf@localhost>
>Content-Type: text/plain; charset=utf-8
>
>Tor-björn Claesson  writes:
>
>> Here is my first attempt.
>> I have read the commit guidelines, but it is very possible that I have
>> misunderstood or just missed something, so I'm grateful for any
>> feedback!
>
>Thanks for the patch!
>
>See my comments below.
>
>> * lisp/oc-basic.el (require 'transient): Pull in transient.
>
>Technically, we still support Emacs 27, which does not have
>transient. But accounting for this would be a pain and Emacs 30 is
>probably going to be released some time around the beginning of the next
>year. So, let's not worry about this and accept that Org 9.8-pre (next
>release) no longer supports Emacs 27.
>
>If you are a user of Emacs 27 + Org main branch, and have strong
>objections, please chime in.

Maybe we don't need to be so drastic ;-) transient is in elpa and melpa. 
Including a note in the docs for emacs-27 to install it from either 
(they are also installing org from a package repo, I guess) may 
circumvent this "issue".


Just My .2 cents

[PATCH]: make ox-latex obey global export title/author settings

[Pedro A. Aranda]

Second patch attached as promised...

Best, /PA
From b6d68bcd626f5f09881893e3f07031517c4bab6b Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Mon, 3 Feb 2025 16:48:45 +0100
Subject: [PATCH 2/2] ox-latex.el: obey with-author and with-title


* lisp/ox-latex.el (org-latex-template): Add checks to suppress title or
author when `org-export-with-title' or `org-export-with-author' are `nil'.
* testing/lisp/test-ox-latex.el (test-ox-latex/with-title-nil): Check
that title is suppressed when `org-export-with-title' is `nil'.
(test-ox-latex/with-author-nil): Checkthat author is suppressed when
`org-export-with-author' is `nil'.
* etc/ORG-NEWS: Anoounce bug fix

Reported by: Antero Mejr 
Link: https://list.orgmode.org/87a5bbwwcz@antr.me/

---
 etc/ORG-NEWS  |  7 ++
 lisp/ox-latex.el  | 32 ++---
 testing/lisp/test-ox-latex.el | 44 +++
 3 files changed, 70 insertions(+), 13 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7fc85ae79..63b5d373b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -532,6 +532,13 @@ matching the rest of the ecosystem, including BibTeX and LaTeX.
 Globat settings controlled by ~org-export-with-title~ and
 ~org-export-with-author~ are now honoured when exporting to Beamer.

+*** =ox-latex=: fixed =:with-title= and =:with-author= handling
+
+The LaTeX exporter will not include the author in the resulting
+document if the =:with-author= property is ~nil~; the same will happen
+for =:with-title=. These properties are set with the
+~org-export-with-author~ and ~org-export-with-title~ global variables.
+
 * Version 9.7

 ** Important announcements and breaking changes
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index bc31df6f5..061de9835 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2041,21 +2041,27 @@ holding export options."
  (let ((date (and (plist-get info :with-date) (org-export-get-date info
(format "\\date{%s}\n" (org-export-data date info)))
  ;; Title and subtitle.
- (let* ((subtitle (plist-get info :subtitle))
-	(formatted-subtitle
-	 (when subtitle
-	   (format (plist-get info :latex-subtitle-format)
-		   (org-export-data subtitle info
-	(separate (plist-get info :latex-subtitle-separate)))
-   (concat
-	(format "\\title{%s%s}\n" title
-		(if separate "" (or formatted-subtitle "")))
-	(when (and separate subtitle)
-	  (concat formatted-subtitle "\n"
+ (when (plist-get info :with-title)
+   (let* ((subtitle (plist-get info :subtitle))
+	  (formatted-subtitle
+	   (when subtitle
+	 (format (plist-get info :latex-subtitle-format)
+		 (org-export-data subtitle info
+	  (separate (plist-get info :latex-subtitle-separate)))
+ (concat
+	  (format "\\title{%s%s}\n" title
+		  (if separate "" (or formatted-subtitle "")))
+	  (when (and separate subtitle)
+	(concat formatted-subtitle "\n")
  ;; Hyperref options.
  (let ((template (plist-get info :latex-hyperref-template)))
-   (and (stringp template)
-(format-spec template spec)))
+   (when (stringp template)
+ (unless (plist-get info :with-author)
+   (setq template (replace-regexp-in-string "%a" "" template)))
+ (unless (plist-get info :with-title)
+   ;; Replace title *and* subtitle
+   (setq template (replace-regexp-in-string "%[ts]" "" template)))
+ (format-spec template spec)))
  ;; engrave-faces-latex preamble
  (when (and (eq (plist-get info :latex-src-block-backend) 'engraved)
 (org-element-map (plist-get info :parse-tree)
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index b75921ae7..a90d9a306 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -154,5 +154,49 @@ Column & Column 
  (search-forward
   "\\href{https://orgmode.org/worg/images/orgmode/org-mode-unicorn.svg}{\\includegraphics[width=.9\\linewidth]{/wallpaper.png}}";

+(ert-deftest test-ox-latex/with-title-nil ()
+  "Test suppressing title in exported LaTeX"
+  (let ((org-export-with-title nil))
+(org-test-with-exported-text
+ 'latex
+ "#+AUTHOR: me
+#+TITLE: Supressed
+
+* A test
+A wonderful text"
+ (goto-char (point-min))
+ (should-not
+  (search-forward "\\maketitle" nil t))
+ (goto-char (point-min))
+ (should-not
+  (search-forward "\\title{Suppressed}" nil t))
+ (goto-char (point-min))
+ (should-not
+  (search-forward "pdftitle={Suppressed}," nil t))
+ (goto-char (point-min))
+ (should
+  (search-forward "pdftitle={},"))
+ )))
+
+(ert-deftest 

[PATCH]: make ox-beamer obey global export title/author settings

[Pedro A. Aranda]

Hi,

Attached is the patch for ox-beamer.el for the bug reported in

https://list.orgmode.org/87a5bbwwcz@antr.me/

Unified patch for ox-latex.el following.

Best, /PA
From 2bc2a27b31dc51b66f597f19a076330c35ad7022 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Mon, 3 Feb 2025 12:47:38 +0100
Subject: [PATCH] Honour export-with in ox-beamer

ox-beamer: Honour `org-export-with-title' and `org-export-with-author'

* lisp/ox-beamer.el (org-beamer--frame-level): Add checks to suppress title or
author when `org-export-with-title' or `org-export-with-author' are `nil'.
* testing/lisp/test-ox-beamer.el (test-ox-beamer-with-author): Test fix when
`org-export-with-author' is `nil'.
(test-ox-beamer-with-author): Test fix when `org-export-with-author' is `nil'.
* etc/ORG-NEWS: Announce bug fix

Reported by: Antero Mejr 
Link: https://list.orgmode.org/87a5bbwwcz@antr.me/

---
 etc/ORG-NEWS   |  5 
 lisp/ox-beamer.el  | 35 +++---
 testing/lisp/test-ox-beamer.el | 45 ++
 3 files changed, 71 insertions(+), 14 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index cb2c16da8..7fc85ae79 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -527,6 +527,11 @@ were tangled into a file named =NAME.bibtex=.  Now, they are tangled
 into a file named =FILE.bib=, using the standard extension =.bib=,
 matching the rest of the ecosystem, including BibTeX and LaTeX.

+*** Fixed beamer export control via ~org-export-with-title~ and ~org-export-with-author~
+
+Globat settings controlled by ~org-export-with-title~ and
+~org-export-with-author~ are now honoured when exporting to Beamer.
+
 * Version 9.7

 ** Important announcements and breaking changes
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index e862da99d..56ef91f3d 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -900,30 +900,37 @@ holding export options."
  (let ((sec-num (plist-get info :section-numbers)))
(when (integerp sec-num)
 	 (format "\\setcounter{secnumdepth}{%d}\n" sec-num)))
- ;; Author.
- (let ((author (and (plist-get info :with-author)
-			(let ((auth (plist-get info :author)))
-			  (and auth (org-export-data auth info)
-	   (email (and (plist-get info :with-email)
-		   (org-export-data (plist-get info :email) info
-   (cond ((and author email (not (string= "" email)))
-	  (format "\\author{%s\\thanks{%s}}\n" author email))
-	 ((or author email) (format "\\author{%s}\n" (or author email)
+ (when (plist-get info :with-author)
+   ;; Author.
+   (let ((author (and (plist-get info :with-author)
+			  (let ((auth (plist-get info :author)))
+			(and auth (org-export-data auth info)
+	 (email (and (plist-get info :with-email)
+		 (org-export-data (plist-get info :email) info
+ (cond ((and author email (not (string= "" email)))
+	(format "\\author{%s\\thanks{%s}}\n" author email))
+	   ((or author email) (format "\\author{%s}\n" (or author email))
  ;; Date.
  (let ((date (and (plist-get info :with-date) (org-export-get-date info
(format "\\date{%s}\n" (org-export-data date info)))
  ;; Title
- (format "\\title{%s}\n" title)
- (when (org-string-nw-p subtitle)
-   (concat (format (plist-get info :beamer-subtitle-format) subtitle) "\n"))
+ (when (and (plist-get info :with-title) title)
+   (format "\\title{%s}\n" title)
+   ;; Subtitle only makes sense if title is generated
+   (when (org-string-nw-p subtitle)
+ (concat (format (plist-get info :beamer-subtitle-format) subtitle) "\n")))
  ;; Beamer-header
  (let ((beamer-header (plist-get info :beamer-header)))
(when beamer-header
 	 (format "%s\n" (plist-get info :beamer-header
  ;; 9. Hyperref options.
  (let ((template (plist-get info :latex-hyperref-template)))
-   (and (stringp template)
-	(format-spec template (org-latex--format-spec info
+   (when (stringp template)
+ (unless (plist-get info :with-author) ;; produce empty pdfauthor
+   (setq template (replace-regexp-in-string "%a" "" template)))
+ (unless (plist-get info :with-title)  ;; produce empty pdftitle
+   (setq template (replace-regexp-in-string "%t" "" template)))
+	 (format-spec template (org-latex--format-spec info
  ;; engrave-faces-latex preamble
  (when (and (eq (plist-get info :latex-src-block-backend) 'engraved)
 (org-element-map (plist-get info :parse-tree)
diff --git a/testing/lisp/test-ox-beamer.el b/testing/lisp/test-ox-beamer.el
index f5743409f..5fcfa4a52 100644
--- a/testing/lisp/test-ox-beamer.el
+++ b/testing/lisp/test-ox-beam

[PATCH]: Add font specifications when exporting to LaTeX

[Pedro A. Aranda]

Hi,


as a result of our discussions, I have prepared a four part patch.

0001 is a trivial way to clarify the warning about unsupported fonts 
with a more 'blunt' language. This is what I said could go as a bug fix.


The rest is the whole mechanism to generate the \set..font{} commands in 
what I feel is the right place in the header.


Best, /PA
From b77250a91783e81502cef2fc6d332b6aa29f1e75 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Thu, 3 Apr 2025 08:05:57 +0200
Subject: [PATCH 1/4] Quick fix: explain unicode problems with pdflatex more
 accurately

* ox-latex.el: change warning when unsupported Unicode characters are detected
by pdflatex. Advise to use lualatex or xelatex instead.

---
 etc/ORG-NEWS | 4 
 lisp/ox-latex.el | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 982bac4e9..faf7bfca2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -2270,6 +2270,10 @@ available as =\para=.
 It does no longer use regexps.

 It is also faster. Large tables can be read quickly.
+*** Warning message changed in ~ox-latex.el~
+
+When ox-latex detects that pdflatex chocked at a Unicode character, it
+now suggests to change ~org-latex-compiler~ to ~lualatex~ or ~xelatex~.

 * Version 9.6

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index af3ac308b..2867cc695 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1524,7 +1524,7 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
 ("Underfull \\hbox" . "[underfull hbox]")
 ("Overfull \\hbox" . "[overfull hbox]")
 ("Citation.*?undefined" . "[undefined citation]")
-("^!.+Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+("^!.+Unicode character" . "[unicode character(s) not supported by pdflatex. Set org-latex-compiler to lualatex or xelatex instead]")
 ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
 ("Undefined control sequence" . "[undefined control sequence]"))
   "Alist of regular expressions and associated messages for the user.
--
2.34.1
From bab13999ee69a0d3b3c10c9f52d4c646eaf706be Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Thu, 3 Apr 2025 12:42:55 +0200
Subject: [PATCH 2/4] Add customisations and support function for font-list
 management

* ox-latex.el: org-latex-add-default-fonts: new customisation to control
whether ox-latex should emit a set of default font specifications when
using lualatex or xelatex.
org-latex-default-fonts-alist: an alist with the default font specifications
(org-latex--fontspec): create a string with the \\set..font{} commands
for the preamble.
---
 lisp/ox-latex.el | 44 
 1 file changed, 44 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2867cc695..c6e809847 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -646,6 +646,25 @@ precedence over this variable."
 		 (string :tag "Format string"))
   :safe #'string-or-null-p)

+(defcustom org-latex-add-default-fonts nil
+  "When non-nil and if `org-latex-compiler' is NOT \"pdflatex\",
+add the default font specifications from `org-latex-default-fonts-alist'
+below."
+  :group 'org-export-latex
+  :type 'boolean)
+
+(defcustom org-latex-default-fonts-alist
+  '(("main" . "FreeSerif")
+("sans" . "FreeSans")
+("mono" . "FreeMono"))
+  "An alist with the cont mappings for lualatex or xelatex when
+`org-latex-add-default-fonts' is non-nil"
+  :group 'org-export-latex
+:type '(repeat
+	(cons
+	 (string :tag "font in \\setxxfont")
+	 (string :tag "Font name"
+
  Headline

 (defcustom org-latex-format-headline-function
@@ -1992,6 +2011,31 @@ INFO is a plist used as a communication channel."
 
 ;;; Template

+(defun org-latex--fontspec ()
+  "This function creates a font specification for a LaTeX document.
+It returns a string with 0 or more font specifications in the format
+
+\\setfont{FontName}
+
+expected by the fontspec package.
+It has to be placed before the LATEX_HEADER, to allow extra refinements
+to take place with
+#+LATEX_HEADER:
+directives"
+   ;;
+ ;; for lualatex and xelatex, we use the fontspec package
+ ;; to specify a default set of fonts that produce a
+ ;; PDF with all UTF8 characters, when
+ ;; `org-latex-add-default-fonts' is not nil.
+ ;; The specification is stored in `org-latex-default-fonts-alist'.
+ ;;
+ (if (or (string= org-latex-compiler "pdflatex")
+ (not org-latex-add-

`org-next-link' skips links inside PROPERTIES drawer

[Pedro R . M . Júnior]

Hello,

I am testing Emacs 28 (Org 9.3) from the Git repository and I have
noticed that, compared to version 26.3 (Org 9.1.9), `org-next-link'
function is skipping links located inside the PROPERTIES drawer.  (I
have not tested version 27.)  The same does not happen for the links
outsize drawers or links inside a drawer other than PROPERTIES one,
e.g., LOGBOOK drawer.

As an example, consider the Org file between "=" lines
below.  Set the cursor at the beginning of the file.  Then call
`org-next-link'.

=
* Heading
  :PROPERTIES:
  :MYLINK:   https://orgmode.org/
  :END:
  Another link: https://duckduckgo.com/
=

I would expect `org-next-link' to find the link inside the drawer (i.e.,
https://orgmode.org/) as in version 26.3.  Instead, it goes directly to
the second link (i.e., https://duckduckgo.com/).

The same happens with `org-previous-link'.

Let me know if this is an intentional behavior for newer versions of Org
mode.  If so, I think it could receive a customization option for this
behavior.

Bests,
Pedro R.M. Júnior

Re: `org-next-link' skips links inside PROPERTIES drawer

[Pedro R . M . Júnior]

Hello Kyle,

> This behavior came up in a previous thread.  Quoting Nicolas:
>
> ,[ https://lists.gnu.org/archive/html/emacs-orgmode/2019-04/msg00075.html 
> ]
> | This is expected.
> |
> | The value in a properties drawer cannot be a link, even though
> | `org-open-at-point' would normally open it, as is done for comments.
> |
> | In addition to no being syntactically a valid link, I think it is
> | undesirable for an interactive command to display hidden internal data.
> |
> | If you want to reach it, just write a function calling
> |
> |(re-search-forward org-any-link-re nil t)
> `

In fact, this have passed unobserved to me.  Thanks for the
clarification and quoted suggestion.

Bests,
Pedro

`org-next-link' skips links inside PROPERTIES drawer

[Pedro Ribeiro Mendes Júnior]

Hello,

I am testing Emacs 28 (Org 9.3) from the Git repository and I have
noticed that, compared to version 26.3 (Org 9.1.9), `org-next-link'
function is skipping links located inside the PROPERTIES drawer.  (I
have not tested version 27.)  The same does not happen for the links
outsize drawers or links inside a drawer other than PROPERTIES one,
e.g., LOGBOOK drawer.

As an example, consider the Org file between "=" lines
below.  Set the cursor at the beginning of the file.  Then call
`org-next-link'.

=
* Heading
  :PROPERTIES:
  :MYLINK:   https://orgmode.org/
  :END:
  Another link: https://duckduckgo.com/
=

I would expect `org-next-link' to find the link inside the drawer (i.e.,
https://orgmode.org/) as in version 26.3.  Instead, it goes directly to
the second link (i.e., https://duckduckgo.com/).

Let me know if this is an intentional behavior for newer versions of Org
mode.  If so, I think it could receive a customization option for this
behavior.

Bests,
Pedro R.M. Júnior

Re: Problems generating the org-mode documentation

[Pedro Andres Aranda Gutierrez]

Let’s hope then this makes its way to Emacs-28 sooner than later ;-)

/PA

Enviado desde mi iPhone

> El 23 oct 2021, a las 6:06, Kyle Meyer  escribió:
> 
> Hoffmann, Jobst writes:
> 
>> But I think I found the culprit:
>> 
>> Line 17568 of org.texi reads:
>> 
>> @kindex C-c C-x @
>> 
>> and @ starts a command, which leads to the stack overflow.
>> 
>> Line 17568 of org.texi should read
>> 
>> @kindex C-c C-x @@
>> 
>> witha doubled @ at the end of the line and after applying this change
>> org.texi the documentation org.pdf can be generated without any error.
> 
> Marco Wahl fixed this entry a few days ago on the bugfix branch:
> 37791bb4f (org-manual: Fix one kindex entry, 2021-10-18).

Re: Problems generating the org-mode documentation

[Pedro Andres Aranda Gutierrez]

Hi

> I think the trouble with "TeX capacity exceeded" is not a trouble with "make 
> doc", Emacs or Org.
> Probably a trouble with make or TeX environment as for example the size of 
> available RAM.
> I have already met that on Virtual machine with not enough memory for 
> compilation but just enough for installation of the OS.

I have checked on a MacBook Pro with 16G running non-virtualised and I
met the problem at the same place as on a Ubuntu Linux VM with 2, 4 or
8 GBytes of memory

Best, /PA


On Fri, 22 Oct 2021 at 08:16, Vincent Breton 
wrote:

> >* On Oct 18, 2021, at 20:51, Pedro Andres Aranda Gutierrez 
> >  *
> >* wrote:
> *>* I'm trying to generate the documentation
> *>* ./org.texi:17579: TeX capacity exceeded, sorry [input stack size=5000].
> **Jean-Christophe Helary reported too the location of the source of trouble 
> identified by *Takesi Ayanokoji.
>
> I think the trouble with "TeX capacity exceeded" is not a trouble with "make 
> doc", Emacs or Org.
> Probably a trouble with make or TeX environment as for example the size of 
> available RAM.
> I have already met that on Virtual machine with not enough memory for 
> compilation but just enough for installation of the OS.
>
> On my system "make doc" generate an error but I found a temporary solution to 
> generate the documentation in PDF.
>
> 1) I start to make a git clone:
> git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
> 2) I used make
> cd org-mode
> make cleanall
> make all
> 3) I generate the pdf files inside the doc directory without using make file:
> cd doc
> makeinfo --pdf org.texi
> makeinfo --pdf orgguide.texi
> 4) You can find the files generated in 
> http://www.presentiel.com/org/orgguide.pdf and  in 
> http://www.presentiel.com/org/org.pdf
>
>
> About "make doc":
> "make doc" don't work on my environment:
> "make info" and "make html" are working fine but "make pdf", a part of "make 
> doc", is not working on my environment.
>
> I reproduce below the error and I suppose there is something wrong with the 
> initial path:
>
> entering extended mode
> (../../../org.t2d/pdf/src/org.texi)
> *
> ! Emergency stop.
> <*> \input ../../../org.t2d/pdf/src/org.texi
>
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on org.log.
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

A question/bug report(?)

[Pedro Andres Aranda Gutierrez]

Hi,

I'm using org-mode mainly to generate LaTEX (both documents and
presentations). I'd like to know if there is any way to flag that the
contents of an EXAMPLE block should be passed RAW to LaTEX.
I need this to be able to include my colouring commands in some listings,
which otherwise break because some things like '...' are translated to
\ldots, etc.

An example:

#+ATTR_LATEX: :options [fontsize=\small,frame=single,commandchars=\\!|]
#+BEGIN_verbatim
\GreenLst!student@juju|:~$ sudo usermod -aG lxd $(whoami)
student@juju:~$ newgrp lxd
student@juju:~$ lxd init --auto
student@juju:~$ lxc network set lxdbr0 ipv6.address none
#+END_verbatim

Translates into:

\begin{verbatim}[fontsize=\small,frame=single,commandchars=\\!|]
\GreenLst!student@juju|:\textasciitilde{}\$ sudo usermod -aG lxd \((whoami)
student@juju:~\) newgrp lxd
student@juju:\textasciitilde{}\$ lxd init --auto
student@juju:\textasciitilde{}\$ lxc network set lxdbr0 ipv6.address none
\end{verbatim}

Where
\((whoami)
is obviously wrong.

Emacs 28.0.92 built yesterday.

GNU Emacs 28.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0) of 2022-03-23

Thanks a ton, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: A question/bug report(?)

[Pedro Andres Aranda Gutierrez]

Hi Eric,

Thanks for answering :-) I'm currently solving the issue with

#+BEGIN_export LaTeX
\begin{verbatim}[commandchars=\\\{\}]
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
\end{verbatim}
#+END_export

What I was wondering is whether we could have something like:

#+ATTR_LATEX :raw t :attributes [commandchars=\\\{\}]
#+BEGIN_verbatim
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
#+END_verbatim

With that ":raw t" the text between the BEGIN_ and END_ would not go
through the protecttexttt function. (of course, without the :raw t
everything would work as today).

Again, it's just because it would be a cleaner to read. I have an yasnippet
in place, so it wouldn't actually mean more or less typing.

Best, /PA


On Tue, 29 Mar 2022 at 15:12, Eric S Fraga  wrote:

> I'm not sure but maybe you want to use a src block,
>
> #+begin_src latex :exports results
> ...
> #+end_src
>
> ?  I am not entirely clear how you wish org to know what is "raw" and
> what is "LaTeX".
>
> --
> : Eric S Fraga, with org release_9.5.2-420-g971eb6 in Emacs 29.0.50
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re:Re: [DISCUSSION] Refactoring fontification system

[Pedro Andres Aranda Gutierrez]

Max Niulin writes:
>> On 03/06/2022 16:45, Ihor Radchenko wrote:
>>
>>  From my point of view exporters may reuse code block formatters for
>> examples. It would allow to pass options to e.g. LaTeX verbatim
environment:
>> Pedro Andres Aranda Gutierrez. Re: A question/bug report(?) Wed, 30 Mar
>> 2022 07:14:54 +0200
>>
https://list.orgmode.org/orgmode/CAO48Bk_dJs1=5zgpczwodatsrqyrskq1alj6wpaxcc4bdjw...@mail.gmail.com/
>
> Among other goals, the new fontification is aiming to avoid such bad
> surprises.

OK, just to add to the discussion. The original intent of my message was to
give _me_ control over what I want to colour, not delegating that to the
fontifying engine in Emacs.

I need limited and controlled colouring for text-books and lab manuals
where colouring elements of a listing goes against the publishing
standards. I only need custom colouring to "emulate" terminal output, not
for the code as such. And I could do that with the #+ATTR: if supported.

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Juju and real life:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Org.texi (the Org Manual) in ePub format

[Pedro Andres Aranda Gutierrez]

Perry Smith writes:

> For Apple losers like me, ePub is so much nicer than PDFs in Apple
Books.  All the features come to life such as book marks, notes,
highlighting, etc.  And they are saved.  Almost like we rocketed into 1990.

You don't have to be an Apple loser to think ePub is nice. There are ePub
reader programs in Linux which allow all you say :-)
And yes, is convenient for almost anything (except printing).
And yes, you can have your ebook reader on the side, almost as you had the
printed programming manuals in times passed.

To get from texinfo to ePub, the easiest way is, I guess, to converto to
split (x)HTML files, pack the result in a 'sofisticated' ZIP
file,(sophisticated in the sense that you have to add a couple more XML
files to it) and rename it to .epub

Wouldn't be too difficult to come up with a smallish program to do that...

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log (and in real life):
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: [PATCH] ob-latex: Added support for including files with a relative path

[Pedro Andres Aranda Gutierrez]

>Message-ID: <87fsjfn7jw.fsf@localhost>
>emacs--- via "General discussions about Org-mode."
> writes:
>
>>> Hi, adding an "input" type of header is one option. What about adding a
>>> call to resolve relative file names instead, thus solving maybe other
>>> needs in addition?
>>>
>> That was my second approach. I was concerned that forcing all imports
with
>> an absolute path could break existing exports? Correct me if I'm wrong.
>> Using the :header syntax external files can be loaded in via the old way,
>> whereas using :inputs all relative paths are resolved.
>> The downside of course is that we clutter the export settings with a new
>> parameter.
>
>Rather than changing paths to absolute, we can simply play with the
>working directly for latex process and set it to the directory of the
>.org file (unless :dir argument is passed to the latex source block).
>This is probably the most expected behavior.
>
>Best,
>Ihor

Just my .01 cents...

For Latex stuff I'm using just
#+HEADER: \input{preamble}
and have my preamble.tex in the working directory. (For Beamer stuff it
goes in a LATEX_HEADER).

Changing that to
#+HEADER :inputs '("preamble")
well, would be a matter of taste.

However, adding the :dir option to the equation could be a game-changer for
me (at least)

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [PATCH] ob-latex: Added support for including files with a relative path

[Pedro Andres Aranda Gutierrez]

First time to hear that. 
I wasn’t aware of it 8-0. 
Will need to recheck my projects and settings to see what I was accidentally 
doing right… in the sense that it was working as intended…

Thx/PA

PS: once again I’ll go to sleep and will have learnt something new (as the 
Spanish proverb goes)

Enviado desde mi iPhone

> El 6 jul 2022, a las 9:49, em...@vergauwen.me escribió:
> 
> 
> 
> >>> Hi, adding an "input" type of header is one option. What about adding a
> >>> call to resolve relative file names instead, thus solving maybe other
> >>> needs in addition?
> >>>
> >> That was my second approach. I was concerned that forcing all imports with
> >> an absolute path could break existing exports? Correct me if I'm wrong. 
> >> Using the :header syntax external files can be loaded in via the old way,
> >> whereas using :inputs all relative paths are resolved. 
> >> The downside of course is that we clutter the export settings with a new 
> >> parameter. 
> >
> >Rather than changing paths to absolute, we can simply play with the
> >working directly for latex process and set it to the directory of the
> >.org file (unless :dir argument is passed to the latex source block).
> >This is probably the most expected behavior.
> >
> >Best,
> >Ihor
> 
> Just my .01 cents...
> 
> For Latex stuff I'm using just
> 
> #+HEADER: \input{preamble} 
> 
> and have my preamble.tex in the working directory. (For Beamer stuff it goes 
> in a LATEX_HEADER).
> 
> Changing that to
> 
> #+HEADER :inputs '("preamble")
> 
> well, would be a matter of taste. 
> Ox-beamer (ox-latex) executes all latex commands at the current directory of 
> your org file, whereas ob-latex uses a temporary file to do its thing. 
> (with-temp-file FILE &rest BODY)
> I think this is mostly done to prent metafiles from cluttering your current 
> directory. 
> 
> Different export types, or different user included packages, generate 
> different
> metafiles. This makes an automated cleanup process afterwards a bit more
> complicated I think, if not impossible. 
> 
> The temporary file makes it hard to add files to the working directory. 
> 
> 
> 
> 
> 
> 
> 

Re: error org export to pdf when latex letter class has been added to org-latex-classes

[Pedro Andres Aranda Gutierrez]

Hi,

for what it may help...

my emacs version:

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
 of 2022-09-12

Adding
#+OPTIONS: toc:nil
to your MWE

I have this small file to export to latex:
```
(require 'org)
(require 'ox-latex)

(eval-after-load "org"
  (progn
;; Add KOMA script based books
(add-to-list 'org-latex-classes
 '("letter"
   "\\documentclass{letter}"))

(setq org-latex-pdf-process '("latexmk -bibtex -f %f")
  org-babel-python-command "python3")))

```
And I use it as:

```
emacs -Q --batch test.org -l org-export.el -f org-latex-export-to-pdf
```

And I see no errors...

Maybe you could try from here and start stripping things further from it to
narrow the problem

Hope it helps...
/PedroAAranda
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Pedro Andres Aranda Gutierrez]

HI Juan Manuel,

Looks cool and would be a +1 from my side, since I need that too...

Can it be extended to add properties to a
#BEGIN_example
#END_example
snippet?

I already suggested that some time ago...

/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Pedro Andres Aranda Gutierrez]

Ihor writes;

> More concretely, I mean something like
>
> * Section
>   :PROPERTIES:
>   :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
>   :attr_latex+: :prepend "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>   :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
>   :attr_latex+: :append "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
>   :END:

Could do if it where for the 'little' detail that a section is not an
environment in Latex
The ORG document structure mimics the LaTEX document structure. To control
headers, we need the \At... commands Juan Manuel suggests IMv(^n)HO [n>10]

My 10^-10 cents, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Pedro Andres Aranda Gutierrez]

Ihor writes:
> * headline
> :PROPERTIES:
> :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
> :ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
> :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound
to: " *this*)
> :ATTR_BACKEND+: babel_block_name(exported=*this*)
> :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
> :ATTR_BACKEND+: "just like the usual approach in
`org-export-read-attribute'"
> :END:
>
> #+ATTR_BACKEND: :export_template "can also work on non-headings"
> Paragraph.

That looks nice :-) If ypu could you do something like:

#+ATTR_BACKEND: :export_template  "\begin{myenv}[myopts]\n%s\n\end{myenv}"
#+ATTR_BACKEND+: :export_template raw_text(exported="this")
#+BEGIN_example
...
#+END_example

I would be able to do what I asked for some time ago :-)

Thanks for the patience, /PA
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: Create in Org a bilingual book with facing pages

[Pedro Andres Aranda Gutierrez]

Ihor writes:
> Message: 12
> Date: Tue, 27 Sep 2022 20:29:25 +0800
> From: Ihor Radchenko 
> To: Juan Manuel Macías 
> Cc: orgmode 
> Subject: Re: Create in Org a bilingual book with facing pages
> Message-ID: <87bkr1ngpm.fsf@localhost>
> Content-Type: text/plain; charset=utf-8
>
>
> I notice two things here:
>
> 1. \clearpage command, which reminds me about
>https://orgmode.org/list/87mtamjrft.fsf@localhost
>May it be useful to have page break syntax element in Org?

I'm currently using the \clearpage too. So having a "native" element in ORG
may be superconvenient

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [off-topic] E-readers and Org-Mode

[Pedro Andres Aranda Gutierrez]

Hi Juan Manuel

My workflow is to create an HTML from the org file(s) and then generate an
EPUB2 file forthe reader (in my case Kobo or Cervantes Light) I have always
felt the rendition is much more confortable than PDF. Other readers may be
better suited for PDF.

Just my experience,
/Pedro A. Aranda

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Pedro Andres Aranda Gutierrez]

Max Nikulin  writes:
>On 27/11/2022 07:06, Ihor Radchenko wrote:
>>
>> (defcustom org-clock-clocktable-language-setup
>>'(("en" "File" "L"  "Timestamp"  "Headline" "Time"  "ALL"
 "Total time"   "File time" "Clock summary at")
>>  ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO"
"Tiempo total" "Tiempo archivo" "Clock summary at")
>>  ("fr" "Fichier"  "N"  "Horodatage" "En-tête"  "Durée" "TOUT"
"Durée totale" "Durée fichier" "Horodatage sommaire à")
>>  ("nl" "Bestand"  "N"  "Tijdstip"   "Hoofding" "Duur"  "ALLES"
"Totale duur"  "Bestandstijd" "Clock summary at")
>>  ("de" "Datei""E"  "Zeitstempel" "Kopfzeile" "Dauer" "GESAMT"
"Gesamtdauer"  "Dateizeit" "Erstellt am"))
>>"Terms used in clocktable, translated to different languages."
>>...)

I'd rather go for

 ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Duración" "TODO" "Duración
total" "Tiempo archivo" "Generado el")

To be in line with the ("de" ...) line

My .02c,
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

LaTeX src block export

[Pedro Andres Aranda Gutierrez]

Hi

I was wondering if there is a way to control which parameters are exported
when translating a src block to LaTeX in a document-wide fashion. I.e. with
a directive at the beginning of the .org file.

The background:

I have 'listings' to export src and example blocks and use
```
#+LATEX_HEADER: \\usepackage{upquote}
#+LATEX_HEADER: \\RequirePackage{fancyvrb}
#+LATEX_HEADER:
\\DefineVerbatimEnvironment{verbatim}{Verbatim}{fontsize=\footnotesize}
#+LATEX_HEADER:
\\DefineVerbatimEnvironment{lstlisting}{Verbatim}{fontsize=\scriptsize}
```
because this greatly improves the copy-and-paste behaviour of my PDFs. Now,
when exporting to laTeX, there are some extra parameters included, which
are not supported by fancyvrb. namely
`language=`
and
`caption.*= (take .* as a regexp)`

I have included a filter to get rid of the offending parameters in my
.emacs.d org configuration, but this is difficult to port to other emacs
setups (e.g. other co-workers).

Thanks, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

PATCH: don't emit empty attributes for lstlistings in LaTeX listings backend

[Pedro Andres Aranda Gutierrez]

Hi,

attached is a small patch for the Latex export backend that suppresses
emitting empty labels and captions when exporting src blocks using
'listings. This cleans up the emitted LaTeX.

BR,/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 5b29a284c..1291aff95 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3594,11 +3594,11 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
  `(("language" ,lst-lang))
- (if label
- `(("label" ,(org-latex--label src-block info)))
-   '(("label" " ")))
- (if caption-str `(("caption" ,caption-str)) '(("caption" " ")))
- `(("captionpos" ,(if caption-above-p "t" "b")))
+ (when label; label= w/o label makes little sense
+ `(("label" ,(org-latex--label src-block info
+ (when caption-str  ; caption= w/o caption makes little sense
+   `(("caption" ,caption-str))
+   `(("captionpos" ,(if caption-above-p "t" "b" ; as does captionpos w/o caption
  (cond ((assoc "numbers" lst-opt) nil)
((not num-start) '(("numbers" "none")))
(t `(("firstnumber" ,(number-to-string (1+ num-start)))

PATCH: include controlling language= in my previous patch

[Pedro Andres Aranda Gutierrez]

Hi,

I have a second version of my previous patch, inlcuing and extra variable
to control whether you want to include the language= or not. It is made in
a backwards-compatible way. Default is to include it and you have to

(setq org-latex-listings-src-omit-language t)

to omit language=

I guess this full patch would go (if accepted) in the next release...

Thx, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 5b29a284c..a319fa830 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1021,6 +1021,16 @@ in this list - but it does not hurt if it is present."
 	   (symbol :tag "Major mode   ")
 	   (string :tag "Listings language"
 
+(defcustom org-latex-listings-src-omit-language nil
+  "Set this option to t to omit the
+\"language=\"
+in the parameters to \\begin{lstlisting} when exporting a src block"
+  :group 'org-export-latex
+  :version "30.0"
+  :package-version '(Org . "9.7")
+  :type 'boolean
+  )
+
 (defcustom org-latex-listings-options nil
   "Association list of options for the latex listings package.
 
@@ -3593,12 +3603,13 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((string= "multicolumn" float) '(("float" "*")))
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
- `(("language" ,lst-lang))
- (if label
- `(("label" ,(org-latex--label src-block info)))
-   '(("label" " ")))
- (if caption-str `(("caption" ,caption-str)) '(("caption" " ")))
- `(("captionpos" ,(if caption-above-p "t" "b")))
+ (unless org-latex-listings-src-omit-language
+   `(("language" ,lst-lang)))
+ (when label; label= w/o label makes little sense
+ `(("label" ,(org-latex--label src-block info
+ (when caption-str  ; caption= w/o caption makes little sense
+   `(("caption" ,caption-str))
+   `(("captionpos" ,(if caption-above-p "t" "b" ; as does captionpos w/o caption
  (cond ((assoc "numbers" lst-opt) nil)
((not num-start) '(("numbers" "none")))
(t `(("firstnumber" ,(number-to-string (1+ num-start)))

Re: PATCH: include controlling language= in my previous patch

[Pedro Andres Aranda Gutierrez]

Hi Ihor,

thanks for the patience. I have a comment on the message you refer to... If
comes from 2014.

So I have resorted to my fresh Emacs29, opened it with emacs -Q for a clean
environment.

With the MWE
```
#+CAPTION: caption of block 1
#+BEGIN_SRC asm
vmpovapd %%zmm0, %zmm1
#+END_SRC


#+LABEL: lst:second
#+BEGIN_SRC asm
vmpovapd %%zmm0, %zmm1
#+END_SRC

# Local Variables:
# org-latex-listings: 'listings
# End:
```
I get the following:
```
\begin{lstlisting}[language=asm,label= ,caption={caption of block
1},captionpos=b,numbers=none]
vmpovapd %%zmm0, %zmm1
\end{lstlisting}


\begin{lstlisting}[language=asm,label=lst:org2f3fc09,caption=
,captionpos=b,numbers=none]
vmpovapd %%zmm0, %zmm1
\end{lstlisting}

```

In my most humble opinion, I looks like the global \lstset{} isn't used and
that the caption/label is set locally. And this makes me believe that
label= or caption= are not very useful.

I have extended my research to a SRC block without language and that
results in a \begin{verbatim}--\end{verbatim}

I'm attaching the patch generated with git diff -p.
Mea culpa, I should have RTFM before sending anything :-)

Best, /PA


On Sun, 11 Dec 2022 at 11:05, Ihor Radchenko  wrote:

> Note: This email thread is a followup for
> https://orgmode.org/list/cao48bk_6bqkgp1mgnzaaryku2+st6r1d4bziq5nzmwnewqf...@mail.gmail.com
>
> Pedro Andres Aranda Gutierrez  writes:
>
> > I have a second version of my previous patch, inlcuing and extra variable
> > to control whether you want to include the language= or not. It is made
> in
> > a backwards-compatible way. Default is to include it and you have to
> >
> > (setq org-latex-listings-src-omit-language t)
> >
> > to omit language=
>
> Makes sense from a first glance.
>
> > + (when label; label= w/o label makes little
> sense
> > + `(("label" ,(org-latex--label src-block info
> > + (when caption-str  ; caption= w/o caption makes
> little sense
> > +   `(("caption" ,caption-str))
> > +   `(("captionpos" ,(if caption-above-p "t" "b" ; as does
> captionpos w/o caption
>
> This is not true. We do need that empty caption/label.
> See
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=eaaa5c2e4
> and
> https://orgmode.org/list/534beafb.4080...@gmx.de
>
> Also, if you can, please create a proper patch instead of diff. See
> https://orgmode.org/worg/org-contribute.html#first-patch
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 5b29a284c..a319fa830 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1021,6 +1021,16 @@ in this list - but it does not hurt if it is present."
 	   (symbol :tag "Major mode   ")
 	   (string :tag "Listings language"
 
+(defcustom org-latex-listings-src-omit-language nil
+  "Set this option to t to omit the
+\"language=\"
+in the parameters to \\begin{lstlisting} when exporting a src block"
+  :group 'org-export-latex
+  :version "30.0"
+  :package-version '(Org . "9.7")
+  :type 'boolean
+  )
+
 (defcustom org-latex-listings-options nil
   "Association list of options for the latex listings package.
 
@@ -3593,12 +3603,13 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((string= "multicolumn" float) '(("float" "*")))
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
- `(("language" ,lst-lang))
- (if label
- `(("label" ,(org-latex--label src-block info)))
-   '(("label" " ")))
- (if caption-str `(("caption" ,caption-str)) '(("caption" " ")))
- `(("captionpos" ,(if caption-above-p "t" "b")))
+ (unless org-latex-listings-src-omit-language
+   `(("language" ,lst-lang)))
+ (when label; label= w/o label makes little sense
+ `(("label" ,(org-latex--label src-block info
+ (when caption-str  ; caption= w/o caption makes little sense
+   `(("caption" ,caption-str))
+   `(("captionpos" ,(if caption-above-p "t" "b" ; as does captionpos w/o caption
  (cond ((assoc "numbers" lst-opt) nil)
((not num-start) '(("numbers" "none")))
(t `(("firstnumber" ,(number-to-string (1+ num-start)))

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Pedro Andres Aranda Gutierrez]

This is why I'm using "Duración"...
Being bilingual ES/DE I tried to align the Spanish translation to the
German translation

My .02c /PA

On Mon, 12 Dec 2022 at 13:18, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > I'd rather go for
> >
> >  ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Duración" "TODO" "Duración
> > total" "Tiempo archivo" "Generado el")
> >
> > To be in line with the ("de" ...) line
>
> So, we have two suggested variants now: yours and from Esteban Ordóñez.
>
>("en" "File" "L"  "Timestamp"  "Headline" "Time"  "ALL"
> "Total time"   "File time" "Clock summary at")
>
> can be translated as
>
> (your version)
>
> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Duración" "TODO"
>  "Duración total" "Tiempo archivo" "Generado el")
>
> or
>
> (Esteban's version)
>
> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO"
>  "Tiempo total" "Tiempo de archivo" "Resumen de tiempos en")
>
> Note that "time" in English version refers to clocked time, which is
> probably closer in its meaning to "duration" or "time spent".
>
> Pedro, Esteban, any comments?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: PATCH: include controlling language= in my previous patch

[Pedro Andres Aranda Gutierrez]

Hi,

I've (finally) followed the procedure and broken up the patch in two. One
for the labels= ,caption=  and one for the language= control.

FYI, I have already cleared the FSF paperwork for an emacs patch.

Best, /PA

On Mon, 12 Dec 2022 at 11:11, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > thanks for the patience. I have a comment on the message you refer to...
> If
> > comes from 2014.
> >
> > So I have resorted to my fresh Emacs29, opened it with emacs -Q for a
> clean
> > environment.
> > ...
> > In my most humble opinion, I looks like the global \lstset{} isn't used
> and
> > that the caption/label is set locally. And this makes me believe that
> > label= or caption= are not very useful.
>
> I guess it is after
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6ef33b6dd
>
> If the cited issue is no longer need to be accounted for, your version
> should be fine.
>
> > I'm attaching the patch generated with git diff -p.
> > Mea culpa, I should have RTFM before sending anything :-)
>
> For the final version of the patch, you may better follow
> https://orgmode.org/worg/org-contribute.html#orgbc683f3 to create a
> .patch file. The .patch file will include your authorship. Do not forget
> the changelog entry.
>
> > +(defcustom org-latex-listings-src-omit-language nil
> > +  "Set this option to t to omit the
> > +\"language=\"
> > +in the parameters to \\begin{lstlisting} when exporting a src block"
> > +  :group 'org-export-latex
> > +  :version "30.0"
> > +  :package-version '(Org . "9.7")
> > +  :type 'boolean
> > +  )
>
> Please do not leave handing ")" on separate lines. It is against common
> Elisp style conventions. See D.1 Emacs Lisp Coding Conventions section
> of Elisp manual:
>
>• Don’t make a habit of putting close-parentheses on lines by
>  themselves; Lisp programmers find this disconcerting.
>
> > + (when label; label= w/o label makes little
> sense
> > + `(("label" ,(org-latex--label src-block info
> > + (when caption-str  ; caption= w/o caption makes
> little sense
> > +   `(("caption" ,caption-str))
> > +   `(("captionpos" ,(if caption-above-p "t" "b" ; as does
> captionpos w/o caption
>
> These comments are not really needed. Actually, it is that `if' that
> deserved explanation. Not putting empty caption/label is intuitive.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From 3a4705f454ed5f692ce9d04f81d3ae9bc2efad56 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Mon, 12 Dec 2022 13:51:49 +0100
Subject: [PATCH 2/2] Allow to suppress language= in SRC blocks

---
 lisp/ox-latex.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index f03903605..924afb399 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1021,6 +1021,15 @@ in this list - but it does not hurt if it is present."
 	   (symbol :tag "Major mode   ")
 	   (string :tag "Listings language"
 
+(defcustom org-latex-listings-src-omit-language nil
+  "Set this option to t to omit the
+\"language=\"
+in the parameters to \\begin{lstlisting} when exporting a src block"
+  :group 'org-export-latex
+  :version "30.0"
+  :package-version '(Org . "9.7")
+  :type 'boolean)
+
 (defcustom org-latex-listings-options nil
   "Association list of options for the latex listings package.
 
@@ -3593,7 +3602,8 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((string= "multicolumn" float) '(("float" "*")))
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
- `(("language" ,lst-lang))
+ (unless org-latex-listings-src-omit-language
+   `(("language" ,lst-lang)))
  (when label
  `(("label" ,(org-latex--label src-block i

Re: PATCH: include controlling language= in my previous patch

[Pedro Andres Aranda Gutierrez]

Hi,

thanks for the patience. I hope to have implemented all suggestions by now.

BR,/PA

On Tue, 13 Dec 2022 at 10:24, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > I've (finally) followed the procedure and broken up the patch in two. One
> > for the labels= ,caption=  and one for the language= control.
>
> Thanks!
> You also need to provide etc/ORG-NEWS entry since we are adding a new
> feature here.
>
> > FYI, I have already cleared the FSF paperwork for an emacs patch.
>
> Bastien, could you kindly confirm?
>
> > Subject: [PATCH 2/2] Allow to suppress language= in SRC blocks
>
> Please also provide changelog entries. See
> https://orgmode.org/worg/org-contribute.html#commit-messages
>
> > +(defcustom org-latex-listings-src-omit-language nil
> > +  "Set this option to t to omit the
> > +\"language=\"
> > +in the parameters to \\begin{lstlisting} when exporting a src block"
>
> Please describe in the docstring when this kind of setting is needed.
>
> > +  :group 'org-export-latex
> > +  :version "30.0"
>
> :version is not necessary. See 15.1 Common Item Keywords section of
> Elisp manual:
>
> ‘:version VERSION’
>  This keyword specifies that the item was first introduced in Emacs
>  version VERSION, or that its default value was changed in that
>  version.  The value VERSION must be a string.
>
> ‘:package-version '(PACKAGE . VERSION)’
>  This keyword specifies that the item was first introduced in
>  PACKAGE version VERSION, or that its meaning or default value was
>  changed in that version.  This keyword takes priority over
>
>  ‘:version’.
>  ^^^
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From 3bc08d0ccabb2d3f4a0ea09bec5bc6a896c351ac Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Mon, 12 Dec 2022 13:49:35 +0100
Subject: [PATCH 1/4] Don't emit empty labels and captions in SRC blocks

---
 lisp/ox-latex.el | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a2d60d5db..f03903605 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3594,11 +3594,14 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
  `(("language" ,lst-lang))
- (if label
- `(("label" ,(org-latex--label src-block info)))
-   '(("label" " ")))
- (if caption-str `(("caption" ,caption-str)) '(("caption" " ")))
- `(("captionpos" ,(if caption-above-p "t" "b")))
+ (when label
+ `(("label" ,(org-latex--label src-block info
+ (when caption-str
+   `(("caption" ,caption-str)))
+ (when caption-str
+   ;; caption-above-p means captionpos is t(op)
+   ;; else b(ottom)
+   `(("captionpos" ,(if caption-above-p "t" "b"
  (cond ((assoc "numbers" lst-opt) nil)
((not num-start) '(("numbers" "none")))
(t `(("firstnumber" ,(number-to-string (1+ num-start)))
-- 
2.25.1

From 33d2ca63e749da8f1faacb66ece636df66464416 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Tue, 13 Dec 2022 12:07:09 +0100
Subject: [PATCH 4/4] Add entries to ORG-NEWS for changes and
 org-latex-listings-src-omit-language

---
 etc/ORG-NEWS | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5d5e726e0..7fa9122ee 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -432,6 +432,20 @@ following properties: ~:hook~, ~:prepare-finalize~,
 ~:before-finalize~, ~:after-finalize~.  These nullary functions run
 prior to their global counterparts for the selected template.
 
+
+*** New =org-latex-listings-src-omit-language= variable for LaTeX export
+
+The =org-latex-listings-src-omit-la

Re: PATCH: include controlling language= in my previous patch

[Pedro Andres Aranda Gutierrez]

Next try... I'm learning a lot :-)

BR,/PA


On Tue, 13 Dec 2022 at 12:51, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > thanks for the patience. I hope to have implemented all suggestions by
> now.
>
> No. You missed several.
>
> 1. :version is not necessary. See 15.1 Common Item Keywords section of
> Elisp manual:
>
> 2. Please also provide changelog entries. See
> https://orgmode.org/worg/org-contribute.html#commit-messages
>
> More comments below.
>
> > +*** New =org-latex-listings-src-omit-language= variable for LaTeX export
> > +
> > +The =org-latex-listings-src-omit-language= customization variable
> > +allows you to omit the =language= parameter in the exported
> > +=lstlisting= environment. This is necessary when the =listings= backend
> > +forwards the actual listing generation to another package like
> > +=fancyvrb= using the following setup in the document header:
>
> Please use ~code~ for Elisp symbols and double space between sentences.
> You may refer to etc/Documentation_Standards.org file for details.
>
> > +#+BEGIN_example
> > +#+LATEX_HEADER: \\RequirePackage{fancyvrb}
> > +#+LATEX_HEADER:
> \\DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
> > +#+LATEX_HEADER:
> \\DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
> > +#+END_example
>
> Please quote #+LATEX_HEADER in the example block with commas. (Org will
> do it automatically for you if you edit the example block with C-c ')
>
> > +*** The LaTeX export backend only emits =label= and =caption= when they
> are not empty
> > +
> > +When exporting a SRC block and using the listings backend , =label==
> > +and =caption== parameters for the =lstlisting= environment will be
> > +only generated when they are not empty. Things like
> > +
> > +#+BEGIN_src latex
> > +\begin{lstlisting}[label= ,caption= ,captionpos=b]
> > +\end{lstlisting}
> > +#+END_src
> > +
> > +will no more appear.
>
> This is probably not something people need to take note of. Not necessary.
>
> > Subject: [PATCH 2/4] Allow to suppress language= in SRC blocks
> > Subject: [PATCH 3/4] Refine DOCSTRING for
> org-latex-listings-src-omit-language
>
> 2nd and 3rd patches can be merged into one.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From dabdc3026e32ec674e22698de6257d724f60c4af Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Wed, 14 Dec 2022 07:32:31 +0100
Subject: [PATCH 3/3] etc/ORG-NEWS: add org-latex-listings-src-omit-language

* etc/ORG-NEWS: Add information for `org-latex-listings-src-omit-language'
---
 etc/ORG-NEWS | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5d5e726e0..bd78ed9a7 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -432,6 +432,21 @@ following properties: ~:hook~, ~:prepare-finalize~,
 ~:before-finalize~, ~:after-finalize~.  These nullary functions run
 prior to their global counterparts for the selected template.
 
+
+*** New =org-latex-listings-src-omit-language= variable for LaTeX export
+
+The ~org-latex-listings-src-omit-language~ customization variable
+allows you to omit the =language= parameter in the exported
+=lstlisting= environment. This is necessary when the =listings=
+backend delegates listing generation to another package like
+=fancyvrb= using the following setup in the document header:
+
+#+BEGIN_src org
+,#+LATEX_HEADER: \RequirePackage{fancyvrb}
+,#+LATEX_HEADER: \DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
+,#+LATEX_HEADER: \DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
+#+END_src
+
 ** New options
 *** A new option for custom setting ~org-refile-use-outline-path~ to show document title in refile targets
 
@@ -747,7 +762,6 @@ following snippet to allow multiple different ID formats in Org files.
 org-attach-id-uuid-folder-format
 org-attach-id-ts-folder-format))
 #+end_src
-
 * Version 9.5
 
 ** Important announcements and breaking changes
-- 
2.25.1

From 2038bddb662f393d99ceb88c9bf9d2a6898919dc Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Wed, 14 Dec 2022 07:12:55 +0100
Subject: [PATCH 1/3] lisp/ox-latex.el: don't emit empyt label=, capti

RE: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

[Pedro Andres Aranda Gutierrez]

No, please. For two reasons:

1.- In HTML, you have 
2.- This could trickle to other backends where it makes sense

Thanks, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Pedro Andres Aranda Gutierrez]

> From: Ihor Radchenko 
> To: alain.coch...@unistra.fr
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Problems with LaTeX export for $x\text{foo $x$}$-like
> construts?
> Message-ID: <87wn6av84v.fsf@localhost>
> Content-Type: text/plain
>
> alain.coch...@unistra.fr writes:
>
> > Version used: release_9.6-149-g554935
> >
> > With an org file containing only
> >
> >#+begin_export latex
> >$x \text{foo $y$}$
> >
> >\(x \text{foo \(y\)}\)
> >
> >$x \text{foo \(y\)}$
> >
> >\(x \text{foo $y$}\)
> >#+end_export
> >
> > the pdf generated upon latex export gives as expected, i.e., with 'x'
> > and 'y' in mathematical font.
>
> This is to be expected because of how Org parser works.

In my experience, this also applies for some situations while creating
listings.
My question is if there would be space for a `:raw t` in the
`#+begin_export latex` to produce a _verbatim_ copy of the contents of the
environment.

All the best, freedom and just(=justa, gerecht) peace in 2023,

/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: LaTeX tutorial (focused on what Org exports) ??

[Pedro Andres Aranda Gutierrez]

David Masterson writes:
> "Fraga, Eric"  writes:
>> On Sunday,  1 Jan 2023 at 13:43, Ihor Radchenko wrote:
>>> I think that it is not very clear how to use it.
>>> Abstract says that it is self-explaining, but it appears that not every
>>> pdf viewer supports showing the explanations.
>>
>> Yes, that's true.  The PDF viewer has to support popups.  I normally use
>> zathura to view PDF documents but that's one example of a viewer that
>> doesn't work with this document.  In cases like this, I switch to evince
>> (others also work).
>>
>> But I find this document very useful.
>
>> Um, when I viewed it in my Emacs pdfviewer, it appeared to look fine
>> *EXCEPT* that it appeared to be in Latin (good Latin, I think, but I
>> don't read Latin).

LoL... My kleines Latinum, though not completely fit right now, tells me
that
indeed it is very, very good Latin :-)

Now seriously, I'm using org for my academic activities (producing lecture
presentations and notes and laboratory scripts) and I'm extremely happy with
what I achieve. There's always a slight grief in that I can't forward
search to
or reverse search from a PDF...

But anyhow, if you need a proofreader, happy to help..
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Strange thing on emacs master exporting to LaTeX

[Pedro Andres Aranda Gutierrez]

Calling with `emacs -Q` on the following MWE:

```
#+TITLE: Test
#+SUBTITLE: MWE for section* bug
#+LATEX_CLASS: article
# +LATEX_CLASS: scrreprt
#+LATEX_CLASS_OPTIONS: [english,a4paper,fontsize=11pt,oneside,headinclude]
# +OPTIONS: toc:nil H:4
# +LATEX_HEADER: \input{scrbook-extras}

* Introduction
  :PROPERTIES:
  :UNNMBERED: t
  :END:

A stupid introduction

** Prerequisites
```
Results in
```
% Created 2023-01-06 vie 12:41
% Intended LaTeX compiler: pdflatex
\documentclass[english,a4paper,fontsize=11pt,oneside,headinclude]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Pedro Andrés Aranda Gutiérrez}
\date{\today}
\title{Test\\\medskip
\large MWE for section* bug}
\hypersetup{
 pdfauthor={Pedro Andrés Aranda Gutiérrez},
 pdftitle={Test},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 30.0.50 (Org mode 9.6)},
 pdflang={English}}
\begin{document}

\maketitle
\tableofcontents


\section{Introduction}
\label{sec:org3c8c3ba}
A stupid introduction

\subsection{Prerequisites}
\label{sec:org0ecaa5c}
\end{document}
```

I was expecting `\section*{Introduction}` or am I wrong?

Thanks, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Strange thing on emacs master exporting to LaTeX

[Pedro Andres Aranda Gutierrez]

Yep, one isn't getting younger ;-)

Sorry for the noise...
/PA

On Fri, 6 Jan 2023 at 13:43,  wrote:

> Pedro Andres Aranda Gutierrez writes on Fri  6 Jan 2023 13:10:
>  > Calling with `emacs -Q` on the following MWE:
>  >
>  > ```
>  > #+TITLE: Test
>  > #+SUBTITLE: MWE for section* bug
>  > #+LATEX_CLASS: article
>  > # +LATEX_CLASS: scrreprt
>  > #+LATEX_CLASS_OPTIONS:
> [english,a4paper,fontsize=11pt,oneside,headinclude]
>  > # +OPTIONS: toc:nil H:4
>  > # +LATEX_HEADER: \input{scrbook-extras}
>  >
>  > * Introduction
>  >   :PROPERTIES:
>  >   :UNNMBERED: t
>
> Didn't you forget the U in UNNUMBERED?
>
> --
> EOST (École et Observatoire des Sciences de la Terre)
> ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
> 5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44
> F-67084 Strasbourg Cedex, France | [ slot available for rent ]
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Pedro Andres Aranda Gutierrez]

Hi,

> I am happy to help with both ox-latex and ox-beamer with two caveats: my
> time at certain times of the year is very limited (as you know as there
> is still an outstanding item for ox-beamer that I have not been able to
> address since October or longer) and my elisp-fu is sometimes not up to
> scratch.  However, I do have useful LaTeX & beamer expertise which can
> be useful.

I'm certainly time-limited, but use ox-latex and ox-beamer profusely and in
parallel with "pure" LaTEX - whatever you might understand by "pure" ;-)
will be close enough - I could also help when my lectures permit and yes, I
also follow the list

/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: [PATCH] Introduce "export features"

[Pedro Andres Aranda Gutierrez]

Hi,

Ihor wrote:
>> Timothy  writes:
>>
>> “export features” allow for the specification of qualities of the org
buffer
>> being exported that imply certain “features”, and how those features may
be
>> implemented in a particular export.

Looks like a cool "feature" that would bring some structure into
my chaotic configuration...

>>(defun org-export-update-features (backend &rest feature-settings)
>>  "Update FEATURE-SETTINGS for BACKEND.

>From what you explain, maybe "...-update-configs" may be a name that tells
me more

>Also, you will need to add ORG-NEWS entry and document the new feature
>system in "13.17 Advanced Export Configuration" and "A.4 Adding Export
>Back-ends" sections of the manual.

But I'd need ^that^ to judge better

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[no subject]

[Pedro Andres Aranda Gutierrez]

I was playing with your file and changed the last block:

#+begin_src emacs-lisp :var alist=animal_list()
(mapcar #'(lambda (x) (message "mapcar %s" x)) alist)
#+end_src

#+RESULTS:
| mapcar 10 | mapcar 34 | mapcar 103 | mapcar 97 | mapcar 122 | mapcar 101
| mapcar 108 | mapcar 108 | mapcar 101 | mapcar 34 | mapcar 10 | mapcar 10
| mapcar 34 | mapcar 103 | mapcar 105 | mapcar 114 | mapcar 97 | mapcar 102
| mapcar 102 | mapcar 101 | mapcar 34 | mapcar 10 | mapcar 10 | mapcar 34 |
mapcar 108 | mapcar 105 | mapcar 111 | mapcar 110 | mapcar 34 | mapcar 10 |
mapcar 10 | mapcar 34 | mapcar 116 | mapcar 105 | mapcar 103 | mapcar 101 |
mapcar 114 | mapcar 34 | mapcar 10 |

Aparently, you animal_alist is a string and when you pass it to (mapcar)
you get the characters

Hope it helps, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Is there a way of putting the biblatex options in the org file?

[Pedro Andres Aranda Gutierrez]

Hi,
I've been reading through the code and the docs and I don't find any way to
add the biblatex options in my org file.

This does a lot of 'magic'
#+bibliography: python3.bib
#+cite_export: biblatex

But I still depend on some settings coming from .emacs.d/init.el to set the
options for \usepackage{biblatex}

My guess is that including them in the org-file would make it more
"shareable", and that would make using org even more attractive.

Thx,/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: Is there a way of putting the biblatex options in the org file?

[Pedro Andres Aranda Gutierrez]

Hi,

>> This does a lot of 'magic'
>> #+bibliography: python3.bib
>> #+cite_export: biblatex

> just add e.g.:

> #+LATEX_HEADER:
>
\usepackage[isbn=false,url=false,doi=false,eprint=false,related=false]{biblatex}

> Cheers,
> Reza

That's what I'm trying to avoid... and do right now
You have the `pure org` header lines above and then you need
to write LaTeX. I would rather have something like

#+cite_export_options: blah blah

I'll give it a try to see what I come up with when I have a couple of
cycles.

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Re: Is there a way of putting the biblatex options in the org file?

[Pedro Andres Aranda Gutierrez]

To: emacs-orgmode@gnu.org
Re: Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be
universally used as global defaults (was: Patch for \usepackage[ ...
natbib = true ...]{...biblatex} with org-cite)

On Sun, 5 Feb 2023 00:14:59 +0100 (CET) Edgar wrote:
> Dear Ihor,
> On Feb 4, 2023 at 12:31 PM, Ihor Radchenko  wrote:Edgar 
> Lux  writes:
>> For example, ... the proposed idea is
>> a bit awkward:
>>
>> ...
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...]
>> citation-style[...]
>>
>> I assumed that there is one "major" bibliography-style/citation-style.
>> However, it is not really the case in practice. The styles are combined.
> First of all, I quickly glanced at the other citation processors, and they 
> seem to have been implemented with a different design in Org. This *may* have 
> to do with biblatex being more advanced (disclaimer: I'm not saying that it 
> actually is, it's a possibility only).
> If the idea is that all processors are going to get the same syntax, I think 
> that the implementation may not suit one of them. At that point, it may be 
> that the filters will have to be adapted to specific processors in contrived 
> ways. This of course will be much dependent on the choice of processors 
> chosen to be supported by Org. Some other groups may decide to implement, for 
> example, the JabRef #+cite_export (this does not imply that JabRef is a 
> citation processor, it's just a colourful example).
>> For example, adding links to bibliography to citations is applied
>> regardless of the particular citation command being used.
>>
>> So, I am not leaning closer to only allowing options being passed to
>> "processor", but not to styles. This will at least come closer to
>> certain settings being citation package global config applied to
>> everything. If we have options applied to specific citation commands,
>> they will rather fit into citation-style/sub-style.
>>
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style
>> citation-style

> If it were me, I would consider just having the options as =#+cite_export: 
> processor :options "anything"=. If the bibliography-style is important for 
> the user and processor, may be default values can be provided; and let the 
> user read some documentation option which are needed to run her particular 
> processor (provided by them, not necessarily Org). Again, being completely 
> honest, I don't think that you should put a dummy (like me) making these very 
> relevant decisions.

Joining the discussion I seem to have missed before (because I was
using a less org-ish solution).
My scenario: BEAMER and LATEX are my main targets, both with BIBLATEX
and biber as backend. Works nicely, and I can include a bibliography
at the end of my presentations, which is nice for lectures.
I'm more interested in the 'processor' part, because the default
bibliography and citation style fit me. However, I think that
something like:

#+cite_export: processor bibliography-style citation-style :options
opt1=val1,opt2=val2,...

as a generalised form (for the shortened version with default styles):

#+cite_export: processor :options opt1=val1,opt2=val2,...

would be expressive enough.

Best, /PA

On Wed, 22 Feb 2023 at 12:33, Ihor Radchenko  wrote:
>
> Pedro Andres Aranda Gutierrez  writes:
>
> > \usepackage[isbn=false,url=false,doi=false,eprint=false,related=false]{biblatex}
> >
> >> Cheers,
> >> Reza
> >
> > That's what I'm trying to avoid... and do right now
> > You have the `pure org` header lines above and then you need
> > to write LaTeX. I would rather have something like
> >
> > #+cite_export_options: blah blah
>
> Feel free to join the discussion at 
> https://orgmode.org/list/87ilghfyzs.fsf@localhost
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>



-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

Re: Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be universally used as global defaults (was: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite)

[Pedro Andres Aranda Gutierrez]

Soory for the re-post... Just setting up a new email client

On Sun, 5 Feb 2023 00:14:59 +0100 (CET) Edgar wrote:
> Dear Ihor,
> On Feb 4, 2023 at 12:31 PM, Ihor Radchenko  wrote:Edgar 
> Lux  writes:
>> For example, ... the proposed idea is
>> a bit awkward:
>>
>> ...
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...]
>> citation-style[...]
>>
>> I assumed that there is one "major" bibliography-style/citation-style.
>> However, it is not really the case in practice. The styles are combined.
> First of all, I quickly glanced at the other citation processors, and they 
> seem to have been implemented with a different design in Org. This *may* have 
> to do with biblatex being more advanced (disclaimer: I'm not saying that it 
> actually is, it's a possibility only).
> If the idea is that all processors are going to get the same syntax, I think 
> that the implementation may not suit one of them. At that point, it may be 
> that the filters will have to be adapted to specific processors in contrived 
> ways. This of course will be much dependent on the choice of processors 
> chosen to be supported by Org. Some other groups may decide to implement, for 
> example, the JabRef #+cite_export (this does not imply that JabRef is a 
> citation processor, it's just a colourful example).
>> For example, adding links to bibliography to citations is applied
>> regardless of the particular citation command being used.
>>
>> So, I am not leaning closer to only allowing options being passed to
>> "processor", but not to styles. This will at least come closer to
>> certain settings being citation package global config applied to
>> everything. If we have options applied to specific citation commands,
>> they will rather fit into citation-style/sub-style.
>>
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style
>> citation-style

> If it were me, I would consider just having the options as =#+cite_export: 
> processor :options "anything"=. If the bibliography-style is important for 
> the user and processor, may be default values can be provided; and let the 
> user read some documentation option which are needed to run her particular 
> processor (provided by them, not necessarily Org). Again, being completely 
> honest, I don't think that you should put a dummy (like me) making these very 
> relevant decisions.

Joining the discussion I seem to have missed before (because I was
using a less org-ish solution).
My scenario: BEAMER and LATEX are my main targets, both with BIBLATEX
and biber as backend. Works nicely, and I can include a bibliography
at the end of my presentations, which is nice for lectures.
I'm more interested in the 'processor' part, because the default
bibliography and citation style fit me. However, I think that
something like:

#+cite_export: processor bibliography-style citation-style :options
opt1=val1,opt2=val2,...

as a generalised form (for the shortened version with default styles):

#+cite_export: processor :options opt1=val1,opt2=val2,...

would be expressive enough.

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

Re: Re: [POLL] Naming of "export features"

[Pedro Andres Aranda Gutierrez]

No Wayman writes:
> It appears context is king.
> All that aside, I think Ihor's proposal sidesteps the whole issue
> while addressing the complexity of the implementation.

I read
#+cite_export: processor_x options:blablabla
as
"When I want to export citations using 'processor_x' , add options
blablabla to it"

That gives enough context information, IMvHO.
And it hides the implementation specifics ...

/P
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet