Re: `org-capture' loads all the files in `org-directory'

[Noel Errenil]

Hi Ihor,

> ...
> Note that you are using %^G, while implies (see org-capture-templates 
> docstring):
>
> %^G Prompt for tags, with completion on all tags in all agenda files.
  ^

Thank you so much for the help. You are absolutely right!

> Only the capture template is actually loaded. However, providing tag
> completion for %^G requires Org to scan all the agenda files for
> possible tags. Hence, agenda files must be opened and examined.

This is an oversight and misunderstanding by me. Really appreciate your
explanation.


> The reason why the capture target buffer and the agenda file buffers are
> not closed is efficiency. Opening all the agenda files may take
> considerable amount of time and hence it is generally better to keep
> them open for future use. We might change it in future or provide an
> option to close the opened files if there is enough interest. Feel free
> to write a feature request - we will judge the number of user responses
> to the request.

Currently, I'm happy with this behavior. I'll learn how to submit a
feature request
anyway in case in the future I feel a need to.

After your first reply earlier, I came to realize that the pop-up
buffer in which I am
able to select a template is indeed some kind of agenda view/mode. This can be
confirmed by looking up the source code. So my original problem indeed had sth
to do with agenda, not `org-capture'.

Then I found my setting of `org-agenda-files' was indeed wrong:

Sth like:
(setq org-agenda-files ("~/projects/org/agenda.org"))
 ;; ^^
empty file at the moment
will actually make the whole ~/projects/org directory as the agenda source,
hence all the files under it will be loaded once agenda function is activated.

I did that, again, because I misunderstood the manual. I should use a
list for agenda files
or a plain text file in which I specify agenda files, one per line.

Hope all the information in this thread will help whoever runs into
the same issue as I did.

Best,
Noel


On Mon, Jul 18, 2022 at 11:24 AM Ihor Radchenko  wrote:
>
> Noel Errenil  writes:
>
> > ...
> > Then, I fire `org-capture', captur a note and `C-c C-c' to save the captured
> > content.
> >
> > Suddenly all the files under ~/projects/org will be loaded into the buffer
> > list, which confuses me so much. Those that have nothing to do with
> > capturing or capture-templates are loaded into Emacs, which makes
> > little sense to me.
> > ...
> > Currently I have `org-directory' set to `~/projects/org'. My
> > `org-capture' config is as follows:
> > ...
> >org-default-notes-file (concat org-directory "/notes.org")))
> > ...
> > ("td" "With Dealines" entry ; todos->deadline
> >(file+headline "tasks.org" "Deadlines")
> >"* TODO %? %^G\nDEADLINE: %T" :kill-buffer t :prepend t)
>
> Note that you are using %^G, while implies (see org-capture-templates 
> docstring):
>
>   %^G Prompt for tags, with completion on all tags in all agenda 
> files.
>   
> ^
>
> > I just expect that only the capture template will be loaded during capturing
> > and the template buffer should be killed (as config-ed) after capturing.
>
> Only the capture template is actually loaded. However, providing tag
> completion for %^G requires Org to scan all the agenda files for
> possible tags. Hence, agenda files must be opened and examined.
>
> The reason why the capture target buffer and the agenda file buffers are
> not closed is efficiency. Opening all the agenda files may take
> considerable amount of time and hence it is generally better to keep
> them open for future use. We might change it in future or provide an
> option to close the opened files if there is enough interest. Feel free
> to write a feature request - we will judge the number of user responses
> to the request.
>
> > What am I doing wrong? Any advice? Thank you so much in advance.
>
> You may either not use global tag completion (use %^g instead %^G in
> your templates) or advice org-capture to close the opened files.
>
> Best,
> Ihor

Re: [External] : Re: missing a character / font in agenda?

[Max Nikulin]

On 17/07/2022 15:58, Ihor Radchenko wrote:

Juan Manuel Macías writes:


I think LEFTWARDS ARROW / #2190 of the 'arrows' Unicode block is much
more common:


Thanks for testing!
I now changed org-agenda to use LEFTWARDS ARROW in b4a72ddf9.

This does not completely solve the reported problem but at least less
users will suffer from it.


At least in Noto Sans Mono (default font in Kubuntu, unsure concerning 
vanilla KDE) \u{2190} "←" arrow is below other dashes like - or —. 
Another symbol \u{21fd} "⇽" LEFTWARDS OPEN-HEADED ARROW from the same 
arrows Unicode block does not has such problem in this font.

Re: org-table with different conventions: decimals

[Juan Manuel Macías]

Uwe Brauer writes:

> Now if I want to switch to the convention used in Germany (that might be
> relevant if I want to export it later to csv, but this is a different
> topic) does work in a strange way, any comments? [...]

Hi, Uwe,

If you only need to export to LaTeX you can load the siunitx package,
which not only fits the decimals perfectly in a table but you can also
define a value for the decimal sign that will be seen in the PDF.

It has a small drawback. Columns with numeric value (S) cannot contain
anything other than numbers. If you want to add an arbitrary text string
in one of those columns you must enclose that string in {}. That is, on
the org side it would be @@latex:{foo}@@

You can try this with your example:

#+LaTeX_Header: \usepackage{siunitx}
#+LaTeX_Header: \sisetup{detect-all}
#+LaTeX_Header: \sisetup{output-decimal-marker = {,}}

#+ATTR_LaTeX: :align SSS
| 3.5 | 4.2 | 7.7 |
#+TBLFM: $3=$1+$2

Best regards,

Juan Manuel 

Re: no syntax highlighting for code blocks with org-publish

[M. Pger]

Thanks for your suggestion. I added the following:

#+begin_src elisp :eval no :exports code
  (setq my-var "org mailing list")
  (message "Hello, %s" my-var)
#+end_src

When exported with ~C-c C-e h o~, syntax highlighting is implemented (with 
colors). When exported with org-publish interestingly I have no color, but 
=setq= is in bold. Would it be possible that ox-publish implements some kind of 
really basic builtin syntax highlighting and ignores htmlize?


--- Original Message ---
On Monday, July 18th, 2022 at 11:50 PM, Tim Cross  wrote:


> "M. Pger" mp...@protonmail.com writes:
>
> > Thank you for your answer. Here it is:
> >
> > 1. Create the following directory structure (3 directories):
> > ~/test/
> > ├── content
> > ├── html
> > └── .packages
> >
> > 2. Create the .el script to build the website (=~/test/build.el=):
> >
> > #+begin_src elisp
> > ;; * Set the package installation directory (in order not to overwrite the 
> > standard ~/emacs.d)
> > (require 'package)
> > (setq package-user-dir (expand-file-name "./.packages"))
> > (setq package-archives '(("melpa" . "https://melpa.org/packages/;)))
> > (add-to-list 'package-archives '("elpa" . "https://elpa.gnu.org/packages/;))
> >
> > ;; * Initialize the package system
> > (package-initialize)
> > (unless package-archive-contents
> > (package-refresh-contents))
> >
> > ;; * Install dependencies
> > ;; ** since org is builtin, by default Emacs does not try to install the 
> > latest version from Elpa (9.5.4)
> > ;; the following solves the issue:
> > (defun mpger-ignore-builtin (pkg)
> > (assq-delete-all pkg package--builtins)
> > (assq-delete-all pkg package--builtin-versions))
> > (mpger-ignore-builtin 'org)
> > ;; ** install packages:
> > (package-install 'org)
> > (package-install 'htmlize)
> >
> > ;; * Load the publishing system:
> > (require 'org)
> > (require 'htmlize)
> > (require 'ox-publish)
> >
> > ;; * Define the project
> > (setq org-publish-project-alist
> > (list
> > (list "pages"
> > :recursive t
> > :htmlized-source t
> > :base-directory "./content/"
> > :base-extension "org"
> > :publishing-directory "./html/"
> > :publishing-function 'org-html-publish-to-html
> > :with-creator t
> > :with-toc t
> > :section-numbers nil
> > :time-stamp-file nil)
> > ))
> >
> > ;; * Generate the site output
> > (org-publish-all t)
> >
> > (message "Done!")
> > #+end_src
> >
> > 3. In =~/test/content/=, create a simple test.org file to be published as 
> > html (=~/test/content/test.org=):
> >
> > #+begin_example
> > * Here's some text
> >
> > Lorem ipsum.
> >
> > * Here's some code
> >
> > #+begin_src R :results output :exports both
> > df <- mtcars ## a comment
> > library(parallel)
> > #+end_src
> >
> > #+end_example
> >
> > 4. Run =~/test/build.el= (e.g. with ~emacs -Q --script ~/test/build.el~) 
> > and compare with
> > the output from ~C-c C-e h o~. The latter has syntax highlighting, the 
> > former has not.
>
>
> Just a shot in the dark. Does syntax highlighting work if the source
> block is something like emacs-lisp rather than R?
>
> I know that syntax highlighting is based on the syntax highlighting from
> the mode used for a specific language. I'm wondering if your not getting
> syntax highlighting because in yhour publish script, R mode is not
> loaded, but when you open the org file and do a 'normal' export, R is
> loaded and so you get syntax highlighting. Therefore, I would try the
> same experiment, but instead of a source block of R code, I would try a
> source block of emacs-lisp code as we know that emacs-lisp mode will be
> loaded.
>
> Could be completely off track though!

Re: [External] : Re: missing a character / font in agenda?

[Daniel Ortmann]

I am not seeing the problem anymore after installing the Symbola fonts.

On 7/16/22 04:15, Ihor Radchenko wrote:

Daniel Ortmann  writes:


More information on that character:

   position: 195 of 690 (28%), column: 26
      character: ⭠ (displayed as ⭠) (codepoint 11104, #o25540,
#x2b60)
    charset: unicode-bmp (Unicode Basic Multilingual Plane
(U+..U+))
code point in charset: 0x2B60
     script: symbol
     syntax: _     which means: symbol
   category: .:Base
   to input: type "C-x 8 RET 2b60" or "C-x 8 RET LEFTWARDS
TRIANGLE-HEADED ARROW"
    buffer code: #xE2 #xAD #xA0
      file code: #xE2 #xAD #xA0 (encoded by coding system utf-8-unix)
    display: no font available

Character code properties: customize what to show
    name: LEFTWARDS TRIANGLE-HEADED ARROW
    general-category: So (Symbol, Other)
    decomposition: (11104) ('⭠')

Would you mind sending a bug report to Emacs devs?
If you run (char-displayable-p ?⭠) on your side but yet not being able
to see the symbol properly, we can hopefully get some good suggestions
(or even a fix) from Emacs guys.

Best,
Ihor

Re: no syntax highlighting for code blocks with org-publish

[Tim Cross]

"M. Pger"  writes:

> Thank you for your answer. Here it is:
>
> 1. Create the following directory structure (3 directories):
> ~/test/
> ├── content
> ├── html
> └── .packages
>
> 2. Create the .el script to build the website (=~/test/build.el=):
>
> #+begin_src elisp
>   ;; * Set the package installation directory (in order not to overwrite the 
> standard ~/emacs.d)
>   (require 'package)
>   (setq package-user-dir (expand-file-name "./.packages"))
>   (setq package-archives '(("melpa" . "https://melpa.org/packages/;)))
>   (add-to-list 'package-archives '("elpa" . "https://elpa.gnu.org/packages/;))
>
>   ;; * Initialize the package system
>   (package-initialize)
>   (unless package-archive-contents
> (package-refresh-contents))
>
>   ;; * Install dependencies
>   ;; ** since org is builtin, by default Emacs does not try to install the 
> latest version from Elpa (9.5.4)
>   ;; the following solves the issue:
>   (defun mpger-ignore-builtin (pkg)
> (assq-delete-all pkg package--builtins)
> (assq-delete-all pkg package--builtin-versions))
>   (mpger-ignore-builtin 'org)
>   ;; ** install packages:
>   (package-install 'org)
>   (package-install 'htmlize)
>
>   ;; * Load the publishing system:
>   (require 'org)
>   (require 'htmlize)
>   (require 'ox-publish)
>
>   ;; * Define the project
>   (setq org-publish-project-alist
>   (list
>(list "pages"
>  :recursive t
>  :htmlized-source t
>  :base-directory "./content/"
>  :base-extension "org"
>  :publishing-directory "./html/"
>  :publishing-function 'org-html-publish-to-html
>  :with-creator t
>  :with-toc t
>  :section-numbers nil
>  :time-stamp-file nil)
>))
>
>   ;; * Generate the site output
>   (org-publish-all t)
>
>   (message "Done!")
> #+end_src
>
>
> 3. In =~/test/content/=, create a simple test.org file to be published as 
> html (=~/test/content/test.org=):
>
> #+begin_example
> * Here's some text
>
> Lorem ipsum.
>
> * Here's some code
>
> #+begin_src R :results output :exports both
>   df <- mtcars ## a comment
>   library(parallel)
> #+end_src
>
> #+end_example
>
> 4. Run =~/test/build.el= (e.g. with ~emacs -Q --script ~/test/build.el~) and 
> compare with
> the output from ~C-c C-e h o~. The latter has syntax highlighting, the former 
> has not.
>

Just a shot in the dark. Does syntax highlighting work if the source
block is something like emacs-lisp rather than R?

I know that syntax highlighting is based on the syntax highlighting from
the mode used for a specific language. I'm wondering if your not getting
syntax highlighting because in yhour publish script, R mode is not
loaded, but when you open the org file and do a 'normal' export, R is
loaded and so you get syntax highlighting. Therefore, I would try the
same experiment, but instead of a source block of R code, I would try a
source block of emacs-lisp code as we know that emacs-lisp mode will be
loaded.

Could be completely off track though!

Re: substitutions in html export?

[Berry, Charles]

Kevin,

> On Jul 17, 2022, at 1:54 PM, kevinbanjo  wrote:
> 
> When I look at the doc string for (org-macro-replace-all) it says:
> 
> Optional argument KEYWORDS, when non-nil is a list of keywords,
> as strings, where macro expansion is allowed.
> 
> I tried passing it '("export-block") but it didn't work, but it seems like 
> something like that should be close.
> 

Does this help?

Adding this to your example:

Here is an inline code src_emacs-lisp[
:results html :exports results :var num=numbers()]{
(format "the result is %d." num )} End.


Produces a paragraph:


Here is an inline code the result is 40. End.



> This whole area of org documentation seems pretty obtuse, with few examples.

Did you browse worg? Especially this:

https://orgmode.org/worg/org-contrib/babel/index.html


Agree that documentation is a WIP and export blocks are mentioned only in 
reference to specific exporters, so there is that.

HTH,
Chuck

Re: [PATCH] Fix bug in org-indent-region when org-adapt-indentation is set to headline-data

[Bastien Guerry]

Hi Ihor,

I'm mostly AFK this week so I won't be able to investigate, I remember
this area was fragile.

Feel free to push the fix if it seems right to you.  We can revert it
back or improve it if needed.

Thanks a lot!

-- 
 Bastien

Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]

[Mamoru Miura]

Dear org community,

I have also faced the problem and have made a patch to fix it. This patch would
not be the best solution since I'm unfamiliar with Emacs Lisp and the detailed
implementation of org-mode. I'd appreciate that if you would review and merge
the patch attached to this mail.

Kind regards,
Mamoru


0001-lisp-org-colview.el-Fix-missing-addition-of-appointm.patch
Description: Binary data

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

> On 18/07/2022 17:32, Juan Manuel Macías wrote:
>> For example, something like this:
>> latex-lang: babel(sorbian) variant(upper)
>> provide(hebrew:import,hyphenrules=+) options(bidi=default),
>> others(french,catalan)
>> returns:
>> \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
>> \babelprovide[import,hyphenrules=+]{hebrew}
>
> I have never tried so complex babel configuration. Should "latex-lang"
> options affect ox-latex in any way besides adding
> \usepackage[...]{babel} and \babelprovide[...]{...}? If not, maybe it
> is better to use

I really think not. It's more of a way to have a more or less complete
configuration of babel (including font options) in a single line and
with a more org-centric syntax. The drawback is that the user would have
to know in this case what he is putting, and know the babel options.

> #+latex_header: \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
> #+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}

That's what I would do as a user. I write all my preambles in pure LaTeX
and don't let Org write anything before the \begin{document} :-)

> directly and add default \usepackage[french]{babel} based on
> "#+language:" only in the case when babel is not loaded through
> "#+latex_header:". Currently such strategy is implemented for inputenc
> or some other package.

humm, what do you think about this idea?:

If I'm not mistaken, the current behavior is as follows. If in the org
document there is this:

#+latex_header: \usepackage[english,french,AUTO]{babel}
#+language: es

it returns:

\usepackage[english,french,spanish]{babel}

But it could be extended to the new babel syntax, so that:

#+latex_header: \usepackage[french,catalan,AUTO,bidi=default]{babel}
#+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}
#+language: es

returns:

\usepackage[french,catalan,spanish,bidi=default]{babel}
\babelprovide[import,hyphenrules=+]{hebrew}

Or, if we want to load the main language via babelprovide (using an ini
file instead of an ldf file):

#+latex_header: \usepackage[french,catalan,spanish]{babel}
#+latex_header: \babelprovide[main,import]{AUTO}
#+language: ru

returns:

\usepackage[french,catalan,spanish]{babel}
\babelprovide[main,import]{russian}

(in this case french, catalan and spanish are the secondary languages)

And this could be extended (in LuaTeX and XeTeX only) to the class
options (which is a new babel feature):

#+latex_class: article
#+latex_class_options: [11pt,draft,AUTO]
#+LaTeX_Header: \usepackage{babel}
#+language: ru

returns:

\documentclass[11pt,draft,russian]{article}
\usepackage{babel}

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Max Nikulin]

On 18/07/2022 17:32, Juan Manuel Macías wrote:


For example, something like this:

latex-lang: babel(sorbian) variant(upper) provide(hebrew:import,hyphenrules=+) 
options(bidi=default), others(french,catalan)

returns:

\usepackage[french,catalan,uppersorbian,bidi=default]{babel}
\babelprovide[import,hyphenrules=+]{hebrew}


I have never tried so complex babel configuration. Should "latex-lang" 
options affect ox-latex in any way besides adding 
\usepackage[...]{babel} and \babelprovide[...]{...}? If not, maybe it is 
better to use


#+latex_header: \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
#+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}

directly and add default \usepackage[french]{babel} based on 
"#+language:" only in the case when babel is not loaded through 
"#+latex_header:". Currently such strategy is implemented for inputenc 
or some other package.

Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]

[Mamoru Miura]

Dear Bastien and org community,

I have also faced the problem and have made a patch to fix it. This 
patch would not be the best solution since I'm unfamiliar with Emacs 
Lisp and the detailed implementation of org-mode. I'd appreciate that if 
you would review and merge the patch attached to this mail.


Kind regards,
MamoruFrom 314877d3e4ec994a025f267a12ebc4d16b5a2aa5 Mon Sep 17 00:00:00 2001
From: Mamoru Miura 
Date: Mon, 18 Jul 2022 18:52:40 +0900
Subject: [PATCH] lisp/org-colview.el: Fix missing addition of appointments to
 effort

* lisp/org-colview.el (org-columns--collect-values): re-compute
appointments' duration because this funtion can not get text property
`'duration'.

TINYCHANGE
---
 lisp/org-colview.el | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 13643101b..35acc9deb 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -288,10 +288,9 @@ possible to override it with optional argument 
COMPILED-FMT."
 ;; to use appointment duration.
 org-agenda-columns-add-appointments-to-effort-sum
 (string= p (upcase org-effort-property))
-(get-text-property (point) 'duration)
-(propertize (org-duration-from-minutes
- (get-text-property (point) 'duration))
-'face 'org-warning))
+(when-let* ((formatted-item 
(org-agenda-format-item nil (org-get-entry) nil nil nil t))
+(duration-string (get-text-property 0 
'duration formatted-item)))
+  (propertize (org-duration-from-minutes 
duration-string 'face 'org-warning)))
"")))
;; A non-nil COMPILED-FMT means we're calling from Org
;; Agenda mode, where we do not want leading stars for
-- 
2.37.0

Re: [feature] Consistent fixed indentation of headline data

[Ihor Radchenko]

Valentin Lab  writes:

>> Also, I am not sure if we really need a new custom variable. We already
>> have many. What about simply allowing an integer value of
>> org-adapt-indentation?
>> 
>
> Well, my guess was that the "adapt" word in `org-adapt-indentation' was 
> referring to adaptive (in other words: "changing") indentation depending 
> on the depth of the outline. It seemed at first un-natural to force a 
> fixed behavior here. This is why I went with a sub-behavior of when 
> `org-adapt-indentation' was set to nil, a way to tell that we didn't 
> want adaptive indentation. It also had the advantage to separate the 
> implementation and help writing code that would not break the existing 
> behaviors.
>
> Of course, I'm completely okay to go with your suggestion. Although, I'm 
> at a lack of inspiration about what would be the best option here: 
> wouldn't a simple integer as you suggest hide the fact that this will 
> target only the headline data ? Could we think of more structured value, 
> perhaps like a cons =(`headline-data . 2)= ? I'm afraid these additions 
> could be seen as bringing some unwanted complexity.
>
> Although I'm expressing some doubts, I'm ready to implement it using an 
> integer on `org-adapt-indentation' as you suggest. Just wanted to make 
> sure it seem sound to everyone before committing to a change that is not 
> that trivial (well, compared to actual changes).

Your doubts make sense. In fact, I somehow missed that you only offered
to indent the headline data to fixed indentation.

Now, after more thinking and thoughtfully reading the relevant code, I
find a new variable more reasonable. However, I do not think that the
new variable should be `org-headline-data-fixed-indent-level'. Instead,
we can offer something like `org-indent-level' with default value 'auto
referring to (1+ (org-current-level)) and possible value of integer -
what you propose. Then, org-adapt-indentation will control the
indentation as usual, but the actual indentation will be calculated
depending on the `org-indent-level' value.

As an added bonus, users will also be able to set fixed indentation
using the combination of org-adapt-indentation=t and
org-indent-level=some-number. Not that I find it useful, but it will be
consistent. Moreover, the implementation will be nothing but changing
the calculation of headline contents indentation from
(1+ (org-current-level)) to a slightly more complex branching.

>> Note that your patch is _not_ a tiny change (not <15 LOC).
>> See https://orgmode.org/worg/org-contribute.html#first-patch and
>> https://orgmode.org/worg/org-contribute.html#copyright
>> Would you consider signing the copyright assignment papers with FSF?
>
> Ok, I was not sure about that (counting the actual functional code 
> change was still under 15LOC, but I guess test counts also). I'm in the 
> process of signing the copyright assignment papers.

Note that FSF should reply within 5 working days. If they don't, let us know.

>>> @@ -18371,6 +18386,9 @@ ELEMENT."
>>> ;; a footnote definition.
>>> (org--get-expected-indentation
>>>  (org-element-property :parent previous) t))
>>> +  ((and (not (eq org-headline-data-fixed-indent-level nil))
>>> + (memq type '(drawer property-drawer planning node-property 
>>> clock)))
>>> + org-headline-data-fixed-indent-level)
>>> ;; Otherwise, move to the first non-blank line above.
>> 
>> Why clock? It does not belong to property drawers.
>>
>
> I probably lack some important knowledge here to understand your point. 
> Here's what I understand: `clock' type targets the 'CLOCK:' keyword (and 
> not direct timestamps, I added a test to make sure). AFAIK, these 
> 'CLOCK:' lines are made with 'C-c C-x C-i/o' and usually appears in 
> between a ':LOGBOOK:' drawer. However older implementation of org-mode 
> did not include these 'CLOCK: ...' lines in logbook drawers. My 
> intention here, was to make sure that even these orphaned 'CLOCK: ...' 
> lines, when appearing before any content, would be considered as 
> headline data, and as such, be indented by the fixed amount.
>
> I definitively consider the logbook (and clock out of logbooks), 
> property drawer, and planning info ("SCHEDULED", "DEADLINE") as headline 
> data and are all targeted for indentation. In my code, if I remove 
> `clock' in the list of types, the intended test about 'CLOCK:' fails...

AFAIU, the correct test is the one used inside org-indent-line:

(and (eq org-adapt-indentation 'headline-data)
   (not (or (org-at-clock-log-p)
(org-at-planning-p)))
   (save-excursion
 (beginning-of-line 1)
 (skip-chars-backward "\n")
 (or (org-at-heading-p)
 (looking-back ":END:.*" (point-at-bol)

(inverse of)

Best,
Ihor

[PATCH] Fix bug in org-indent-region when org-adapt-indentation is set to headline-data (was: [feature] Consistent fixed indentation of headline data)

[Ihor Radchenko]

Valentin Lab  writes:

>>> @@ -1216,6 +1259,13 @@
>>>   (org-test-with-temp-text "* H\n:PROPERTIES:\n:key:\n:END:"
>>> (org-indent-region (point-min) (point-max))
>>> (buffer-string)
>>> +  ;; ;; Indent property drawers according to `org-adapt-indentation'.
>>> +  ;; (let ((org-adapt-indentation 'headline-data))
>>> +  ;;   (should
>>> +  ;;(equal "* H\n  :PROPERTIES:\n  :key:\n  :END:\n\ncontent2"
>>> +  ;;   (org-test-with-temp-text "* 
>>> H\n:PROPERTIES:\n:key:\n:END:\n\ncontent"
>>> +  ;; (org-indent-region (point-min) (point-max))
>>> +  ;; (buffer-string)
>> 
>> This test is commented. Is it intentional?
>
> My bad ! and an interesting talking point. I'm removing these commented 
> line in the upcoming patch. They were here (and inadvertently committed) 
> because while trying to test that my addition would not indent beyond 
> the headline data, I noticed that actually `org-adapt-indentation' set 
> to `headline-data' was actually indenting beyond headline data ! As I 
> don't want to break anything, I was left quite puzzled with what to do:
> - I can fix this, but fixing this is for me subject to another 
> submission, and will touch behaviors that might be wanted,
> - Not fixing this make me submitting a feature that carries what I see 
> like a "bug".
>
> But, is that a bug ? Here is the case:
>
> --8<---cut here---start->8---
> * H
> :PROPERTIES:
> :key:
> :END:
>
> content
> --8<---cut here---start->8---
>
> Using `org-indent-region' on all the content, with 
> `org-adapt-indentation' set to `headline-data', will result to:
>
> --8<---cut here---start->8---
> * H
>:PROPERTIES:
>:key:
>:END:
>
>content
> --8<---cut here---start->8---
>
> My issue is with the treatment of the 'content' line that is not 
> headline-data for me, and should not have been indented. Am I right in 
> my expectation ?

Yes are right and we got a bug here.

I am attaching the tentative fix.

Bastien, I feel that the current implementation of
`org--get-expected-indentation' is wrong since we introduced
`org-adapt-indentation' 'headline-data value. AFAIU, it was done by you
in e3b79ad2b. See the commit message in the patch below for the
explanation why I think that something is going wrong.

Am I missing something?

Best,
Ihor

>From 9917d69543226c68ca9e749e4f53e5f3e8ec8e79 Mon Sep 17 00:00:00 2001
Message-Id: <9917d69543226c68ca9e749e4f53e5f3e8ec8e79.1658149652.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Mon, 18 Jul 2022 21:00:13 +0800
Subject: [PATCH] org-indent-region: Fix when `org-adapt-indentation' is
 'headline-data

* lisp/org.el (org--get-expected-indentation): Remove the extra
condition added in e3b79ad2b in the cond branch for first line in an
element.  Checking `org-adapt-indentation' t value here trigger the
last default cond branch that assumes that we are _not_ at the first
line.

The new logic explicitly avoids inheriting indentation from previous
sibling when `org-adapt-indentation' is set to 'headline-data and the
previous sibling is satisfying "headline data" condition as in
`org-indent-line'.  The case when `org-adapt-indentation' is set to t
is already handled correctly when calculating the CONTENTSP
indentation for parent headline.

Fixes https://orgmode.org/list/c13cab60-bbc9-e69e-6d0d-7fe75c590...@kalysto.org
---
 lisp/org.el | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 99e5d0dc7..64b148d9c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18455,9 +18455,9 @@ (defun org--get-expected-indentation (element contentsp)
 	(org-element-property :parent element) t))
   ;; At first line: indent according to previous sibling, if any,
   ;; ignoring footnote definitions and inline tasks, or parent's
-  ;; contents.
-  ((and ( = (line-beginning-position) start)
-	(eq org-adapt-indentation t))
+  ;; contents.  If `org-adapt-indentation' is `headline-data', ignore
+  ;; previous headline data siblings.
+  ((= (line-beginning-position) start)
(catch 'exit
 	 (while t
 	   (if (= (point-min) start) (throw 'exit 0)
@@ -18474,6 +18474,21 @@ (defun org--get-expected-indentation (element contentsp)
 		((memq (org-element-type previous)
 		   '(footnote-definition inlinetask))
 		 (setq start (org-element-property :begin previous)))
+;; Do not indent like previous when the previous
+;; element is headline data and `org-adapt-indentation'
+;; is set to `headline-data'.
+((save-excursion
+   (goto-char start)
+   (and
+(eq org-adapt-indentation 'headline-data)
+(not (or (org-at-clock-log-p)
+   

discovering export (and other) keywords?

[kevinbanjo]

this page:

https://orgmode.org/manual/Macro-Replacement.html#index-macro-replacement_002c-during-export

says:

Org also recognizes macro references in keywords, such as ‘CAPTION’, ‘TITLE’,
‘AUTHOR’, ‘DATE’, *and for some back-end specific export options.*

How do I discover what those back end specific options are?

Also, for various elements (e.g. begin_src emacs-lisp, begin_export html,
etc...) how do I discover what the acceptable keywords are, preferably
without only having to go thru the manual pages?

TIA,
-Kevin

An org backend to Haddock

[Yuchen Pei]

Hello,

I decided to write an Org backend to Haddock[1], so that haskell library
documentation can be generated in org mode markup.  Compared to the
existing backends (html, latex and hoogle), the org format allows
utilising features like the infinite levels of heading hierarchy,
flexible folding / unfolding, cross-package linking, jumping to any
declaration with org-goto and the endless potentials of emacs
customisation.

It seems to me most information and haskell language features one can
find on displayed on hackage are supported by the org backend and
included in the output org files, though there are still some rough
edges and unsupported language features (like infix declarations and
linear types) which I aim to fix.  Some example output can be found at
[2] (I will need to rename the "assets" part of the url as it is not
accurate), including base[4], ghc-prim[5] and ghc-lib-parser[6] (I use
it for reference of the GHC API as it is easier to build than GHC).  For
more information, check out the README file[3].

Given this is not the official version of haddock and my changes are in
haddock-api, I'm calling it haddorg-api, for lack of a better name /
approach.  I'll be happy to contribute my changes upstream if a
different license covering my contribution (AGPLv3+) is accepted.

Let me know what you think.

[1] https://g.ypei.me/haddock.git/tree/haddock-api
[2] https://ypei.org/assets/haddorg-output/
[3] https://g.ypei.me/haddock.git/tree/haddock-api/README.org
[4] https://ypei.org/assets/haddorg-output/base-4.16.1.0.org.gz
[5] https://ypei.org/assets/haddorg-output/ghc-prim-0.8.0.org.gz
[6] https://ypei.org/assets/haddorg-output/ghc-lib-parser-9.2.2.20220307.org.gz

Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  

Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]

[Gustavo Barros]

Hi Ihor,

On Mon, 18 Jul 2022 at 14:28, Ihor Radchenko  wrote:


I feel that you are overcomplicating things a bit.


Well, the most important objective of the analysis was to try to figure 
out if the `todayp' condition was too strict or not.  Since your 
suggested fix implies removing it as well, I take I have you convinced? 
;)


What if we simply change all the agenda lines if and only if their 
date
in agenda is earlier or equal to the next scheduled time (after 
repeater

is triggered)?


I think this is a good condition, better than the one I had devised 
(considering the span of the agenda and the repetition frequency).  As 
far as I can tell, it will also require parsing the planning info of the 
entry and consider the relevant cases, but perhaps you are seeing more 
than I can.  And I presume you refer only to repeating tasks, so that 
the rest of the current conditional (except `todayp') would remain in 
place.  The only case I can think of which might trip a little this 
condition is a date range, but "date range with repeater" seems corner 
enough for us not to sweat much over it.


One thing to consider is the timing of things and how it affects the 
conditional.  You said "earlier or equal to the next scheduled time 
(after repeater is triggered)".  We are looking at things in 
`org-agenda-todo' after `org-todo' has done its job, in other words, 
after the repeater has "stepped". 
`org-agenda-headline-snapshot-before-repeat' is stored in `org-todo' 
because there would be no longer any way to retrieve it at this point, 
but we don't store anything else, as far as I can tell.  So, at this 
point, the current scheduled (dedlined, etc.) time would be "the 
next/first instance which is *not* done", and hence wouldn't it be 
"earlier, but not equal, to the next scheduled time"?


Another thing for which you might have something in mind, but I don't 
see how to handle it is that `org-agenda-change-all-lines' can receive 
the `just-this' argument and that decides whether just the current line 
gets changed or if all entries with the same marker are looped over.  So 
it's either "this" or "all". Perhaps the version of the conditional you 
suggested will require change in `org-agenda-change-all-lines' so that 
it can change "some, according to a given predicate".


In sum, all in all, the conditional you suggested sounds very good to 
me, and a clear improvement relative to the current state of things. 
And regardless of anything else, it seems we agree that `todayp' is too 
strict and removing it would be the low hanging fruit in all this.


Best,
Gustavo.

Publishing a project and selecting files (possibly with tags)

[Benoit Bidoggia]

Dear list,

This is my problem: I have a large set of org files (created with
org-roam), which contains all my thoughts on different topics (for
example "work1", "work2", "personal1"...)

I would like to create different projects (for example "work1",
"work2", "personal1") to be able to publish these files under
different folders (for example "./pub_work1", "./pub_work2",
"./pub_personal1") for which I could define some filters to decide
what goes where.

The rules should be something likes this:
- nothing is exported, except that
- files with tag "WORK1" are exported in "./pub_work1"
- files with tag "WORK2" are exported in "./pub_work2"
- files with tag "PERSONAL1" are exported in "./pub_personal1"

I cannot use the file name to filter the files, which seems to exclude
the possibility of using the options ":exclude" and ":include" of
org-publish-project-alist.

Ideally I would like to use tags (or some descriptors I can include
directly in the org file), but I did not have much success using the
options ":with-tags" or ":select-tags".

Can this be done? If so, how?

Thank you very much, best regards.
Benoît

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Juan Manuel Macías writes:

> latex-lang: babel(sorbian) variant(upper) 
> provide(hebrew:import,hyphenrules=+) options(bidi=default), 
> others(french,catalan) 
>
> returns:
>
> \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
> \babelprovide[import,hyphenrules=+]{hebrew}

PS: In fact, I think that this new implementation would no longer depend
on a list of languages neither for babel nor for polyglossia, since it
is not connected to the #+language keyword. The old list would be kept
for backwards compatibility.

Best regards,

Juan Manuel 

Re: [PATCH v6] ol.el: add description format parameter to org-link-parameters

[Max Nikulin]

Hugo,

I am sorry if I am wrong, but I do not see you among known Org 
contributors. You patch is likely greater than it is allowed for 
TINYCHANGE, so before you patch can be committed, copyright assignment 
should be signed, see 
https://orgmode.org/worg/org-contribute.html#copyright for details.


On 18/07/2022 03:59, Hugo Heagren wrote:

 From fbe030ad3a2aafd09d491aefb9c56242b7ec669b Mon Sep 17 00:00:00 2001
From: Hugo Heagren
Date: Sat, 16 Jul 2022 19:50:15 +0100
Subject: [PATCH] test-ol: tests for insert-description param when inserting
  links


Emacs-26.3:
make test-dirty BTEST_RE=test-ol/insert-link-insert-description

selected tests: test-ol/insert-link-insert-description
Running 1 tests (2022-07-18 12:21:46+0200)
Test test-ol/insert-link-insert-description backtrace:
  signal(wrong-type-argument (listp :insert-description))
  apply(signal (wrong-type-argument (listp :insert-description)))
  (setq value-7565 (apply fn-7563 args-7564))
  (unwind-protect (setq value-7565 (apply fn-7563 args-7564)) (setq fo
  (if (unwind-protect (setq value-7565 (apply fn-7563 args-7564)) (set
  (let (form-description-7567) (if (unwind-protect (setq value-7565 (a
  (let ((value-7565 (quote ert-form-evaluation-aborted-7566))) (let (f
  (let* ((fn-7563 (function signal)) (args-7564 (condition-case err (l
  (closure (t) nil (let* ((fn-7563 (function signal)) (args-7564 (cond
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name test-ol/insert-link-insert-descriptio
  ert-run-or-rerun-test(#s(ert--stats :selector "test-ol/insert-link-i
  ert-run-tests("test-ol/insert-link-insert-description" #f(compiled-f
  ert-run-tests-batch("test-ol/insert-link-insert-description")
  ert-run-tests-batch-and-exit("test-ol/insert-link-insert-description
  (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
  org-test-run-batch-tests("test-ol/insert-link-insert-description")
  eval((org-test-run-batch-tests org-test-select-re))
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
  command-line()
  normal-top-level()
Test test-ol/insert-link-insert-description condition:
(wrong-type-argument listp :insert-description)
   FAILED  1/1  test-ol/insert-link-insert-description


+(ert-deftest test-ol/insert-link-insert-description ()
+  "Test `:insert-description' parameter handling."
+  ;; String case.


The cases might be improved by using different values, so when 
particular `should' form fail it is easier to find it in the code



+  (should
+   (string=
+"foobar"
+(test-ol-with-link-parameters-as
+"id" (:insert-description "foobar")


E.g. "foobar-string"


+  (test-ol-insert-link-get-desc "id:foo-bar"
+  ;; Lambda case.
+  (should
+   (string=
+"foobar"
+(test-ol-with-link-parameters-as
+"id" (:insert-description (lambda (_link-test _desc) "foobar"))
+  (test-ol-insert-link-get-desc "id:foo-bar"


"foobar-lambda"

Further "foobar-desc-arg", etc.


+`:insert-description'
+
+  String or function used as a default when prompting users for a
+  link's description.  A string is used as-is, a function is
+  called with two arguments: the full link text, and the


"link text" might be a bit ambiguous here. I would consider "link 
location", "string containing link type and target", or something else.



+  description generated by `org-insert-link'.  It should return
+  the description to use (this reflects the behaviour of
+  `org-link-make-description-function').  If it returns nil, no
+  default description is used, but no error is thrown (from the
+  user's perspective, this is equivalent to a default description
+  of \"\").

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Ihor Radchenko writes:

> Do you refer to the paragraph below when saying that Org implementation
> makes it hard to add new features? The rest of the above paragraph
> implies that the difficulty is on LaTeX side, not on Org side.

Sorry for not explaining clearly. Actually I think the problem is not
with Org or Babel (LaTeX), but rather with the "translation" from Babel
(latex) to Org. Currently the babel interface is more complex, although
it is more consistent and robust within LaTeX. The challenge is how to
style all of that for an Org user who wants to just get a correct PDF
out-of-the-box using a simple and basic syntax (of course, you don't
need to translate the whole babel: to use babel with all its power it's
better to write the LaTeX code directly). 

For that reason I think that, for now, it is more practical to keep the
old babel syntax on the Org side (as I do in my patch):

\usepackage[langs]{babel}

which is perfectly valid for pdflatex, lualatex and xelatex (except in
the languages that are loaded in babel through ini files).

> In any case, your existing patch is an already an improvement. I do not
> deem it as requirement to apply the patch.

Well, between today and tomorrow I can prepare a new version of the
patch with all your suggestions from the previous email incorporated.
And for the future I can work on a fresh re-implementation of all this,
using the :options-alist export property, as you suggest.

For example, something like this:

latex-lang: babel(sorbian) variant(upper) provide(hebrew:import,hyphenrules=+) 
options(bidi=default), others(french,catalan) 

returns:

\usepackage[french,catalan,uppersorbian,bidi=default]{babel}
\babelprovide[import,hyphenrules=+]{hebrew}

or this (in this case Hebrew is the main language):

latex-lang: babel provide(hebrew:main,import,hyphenrules=+) 
options(bidi=default), others(french,catalan) 

returns:

\usepackage[french,catalan,bidi=default]{babel}
\babelprovide[main,import,hyphenrules=+]{hebrew}

And the above is equivalent to:

latex-lang: babel(hebrew) options(bidi=default,provide=*), 
others(french,catalan) 

returns:

\usepackage[french,catalan,hebrew,bidi=default,provide=*]{babel}

Note that for monolingual documents, now in babel it would be enough to
indicate the language in the document class options (only for LuaTeX and
XeTeX), so it would be enough to do something like this:

#+latex_class: article
#+latex_class_options: [french,10pt,draft]
#+LaTeX_Header: \usepackage{babel}


Best regards,

Juan Manuel 

Re: no syntax highlighting for code blocks with org-publish

[M. Pger]

Thank you for your answer. Here it is:

1. Create the following directory structure (3 directories):
~/test/
├── content
├── html
└── .packages

2. Create the .el script to build the website (=~/test/build.el=):

#+begin_src elisp
  ;; * Set the package installation directory (in order not to overwrite the 
standard ~/emacs.d)
  (require 'package)
  (setq package-user-dir (expand-file-name "./.packages"))
  (setq package-archives '(("melpa" . "https://melpa.org/packages/;)))
  (add-to-list 'package-archives '("elpa" . "https://elpa.gnu.org/packages/;))

  ;; * Initialize the package system
  (package-initialize)
  (unless package-archive-contents
(package-refresh-contents))

  ;; * Install dependencies
  ;; ** since org is builtin, by default Emacs does not try to install the 
latest version from Elpa (9.5.4)
  ;; the following solves the issue:
  (defun mpger-ignore-builtin (pkg)
(assq-delete-all pkg package--builtins)
(assq-delete-all pkg package--builtin-versions))
  (mpger-ignore-builtin 'org)
  ;; ** install packages:
  (package-install 'org)
  (package-install 'htmlize)

  ;; * Load the publishing system:
  (require 'org)
  (require 'htmlize)
  (require 'ox-publish)

  ;; * Define the project
  (setq org-publish-project-alist
(list
 (list "pages"
   :recursive t
   :htmlized-source t
   :base-directory "./content/"
   :base-extension "org"
   :publishing-directory "./html/"
   :publishing-function 'org-html-publish-to-html
   :with-creator t
   :with-toc t
   :section-numbers nil
   :time-stamp-file nil)
 ))

  ;; * Generate the site output
  (org-publish-all t)

  (message "Done!")
#+end_src

3. In =~/test/content/=, create a simple test.org file to be published as html 
(=~/test/content/test.org=):

#+begin_example
* Here's some text

Lorem ipsum.

* Here's some code

#+begin_src R :results output :exports both
  df <- mtcars ## a comment
  library(parallel)
#+end_src
#+end_example

4. Run =~/test/build.el= (e.g. with ~emacs -Q --script ~/test/build.el~) and 
compare with the output from ~C-c C-e h o~. The latter has syntax highlighting, 
the former has not.

Best,

M





--- Original Message ---
On Monday, July 18th, 2022 at 1:42 AM, Ihor Radchenko  
wrote:


> "M. Pger" mp...@protonmail.com writes:
>
> > While syntax highlighting for code blocks is correctly implemented when I 
> > export a Org document with M-x org-html-export-to-html, it does not work 
> > when the same document is exported as part of an org-publish project 
> > defined using org-publish-project-alist.
> >
> > Org-version: 9.5.4 (also tried with 9.5.2)
> > Htmlize-version: 1.57
> >
> > Note that including :htmlized-source t does not solve the problem.
> >
> > Any idea of what's happening?
>
>
> May you provide an example reproducer?
>
> Best,
> Ihor

Re: org-cature-ref

[Henrik Frisk]

Den mån 18 juli 2022 kl 01:56 skrev Ihor Radchenko :

> Henrik Frisk  writes:
>
> >> Could you please provide a bit more details on what you did, what you
> >> expected to get, and what you got?
> >>
> >> Yes, of course!
> >
> > I saw in another thread recently that you had the bibtex captured as a
> code
> > block (begin_src bibtex) which I wasn't able to get. In the documentation
> > at https://github.com/yantar92/org-capture-ref#org819faa2 it says:
> >
> > "Alternatively it is possible to use org-capture-ref-get-bibtex-field to
> > get metadata directly (:bibtex-string field will contain formatted BiBTeX
> > entry).
> >
> > This, I thought, was the way to achieve this. What I get is:
> >
> > :BOOKMARK:misc:
> > :PROPERTIES:
> > :TITLE:Something
> > :BTYPE:misc
> > :ID:   Something_org_captur_ref_extrac_9c0
> > :AUTHOR:   someone
> > :CREATED:  [2022-07-12 tis 17:26]
> > :HOWPUBLISHED: Github
> > :NOTE: Online; accessed 12 juli 2022
> > :RSS:  https://something.org
> > :URL:   https://something.org
> > :END:
>
> Did you try to customize org-capture-ref-capture-template?
>
> Its default template is
>
> "%{fetch-bibtex}* TODO %?%{space}%{org-entry}"
> "%{extra}"
>
> %{org-entry} part is responsible for generating property drawer via
> org-capture-ref-headline-format-function.
>
> If you prefer adding bibtex directly, you may want something like
>
> "%{fetch-bibtex}* TODO %?%(org-capture-ref-get-bibtex-field :title)"
> "#+begin_src bibtex"
> "%(org-capture-ref-get-bibtex-field :bibtex)"
> "#+end_src bibtex"
>
> That's what I was trying to do, but now it works! This is really
brilliant, thank you!
Note: it should be:

"%(org-capture-ref-get-bibtex-field :bibtex-string)"

in the above example.

A couple of questions more:

1. In the examples at the beginning of the project's  github you have
examples that have a combination of prperties and bibtex source, with
preperties such as ID and CREATED. These could be helpful but I can't
figure out how to add them with my limited knowledge.
2. When you write that there is support for Google Scholar "BiBTeX page",
what do you mean? In a Google scholar search, if I click "Cite" and then
choose BiBTeX, I don't get the expected result, but maybe you are referring
to something else?

Again, thank you. This will make my life easier!

/henrik

Re: Could an "org-anniversary" be a PROPERTY?

[Ihor Radchenko]

Ypo  writes:

> It works! Thanks, Ihor.
>
> How could I've known? Should I've known?

The manual on diary integration (11.3.1 Weekly/daily agenda) says:

   If you are using the diary only for expression entries and holidays,
it is faster to not use the above setting, but instead to copy or even
move the entries into an Org file.  Org mode evaluates diary-style
expression entries, and does it faster because there is no overhead for
first creating the diary display.  Note that the expression entries must
   ^
start at the left margin, no whitespace is allowed before them, as seen
^^
in the following segment of an Org file:(2)

 * Holidays
   :PROPERTIES:
   :CATEGORY: Holiday
   :END:
 %%(org-calendar-holiday)   ; special function for holiday names

 * Birthdays
   :PROPERTIES:
   :CATEGORY: Ann
   :END:
 %%(org-anniversary 1956  5 14) Arthur Dent is %d years old
 %%(org-anniversary 1869 10  2) Mahatma Gandhi would be %d years old

I proposed something that is not a diary item, but that also allow
diary-sexp syntax: Diary-style expression entries (8.1 Timestamps):

Diary-style expression entries
 For more complex date specifications, Org mode supports using the
 special expression diary entries implemented in the Emacs Calendar
 package(2).  For example, with optional time:

  * 22:00-23:00 The nerd meeting on every 2nd Thursday of the month
<%%(diary-float t 4 2)>

Best,
Ihor

org-table with different conventions: decimals

[Uwe Brauer]

Hi

In my current setting, the following works

| 3.5 | 4.2 | 7.7 |
#+TBLFM: $3=$1+$2

Now if I want to switch to the convention used in Germany (that might be
relevant if I want to export it later to csv, but this is a different
topic) does work in a strange way, any comments? I would expect

| 3,5 | 4,2 | (7, 7) |
#+TBLFM: $3=$1+$2


| 3,5 | 4,2 | 7,7|
#+TBLFM: $3=$1+$2


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

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> For Max's comment, using plist/alist would make things more clear
>> code-wise for future developers. I always find it annoying when I need
>> to go back and forth checking which element should be second or third or
>> forth in the list. Especially if the variable is used all around the
>> codebase. Though this particular case is not such -
>> `org-latex-language-alist' is used just in few places.
>
> I agree with Maxim and with you that an anonymous list is hardly usable
> for future features. For this new list I followed the style of the
> previous ones and I admit that I was quite conservative. The problem,
> imho, is that with the current org implementation I find it difficult to
> add new features. For example, Babel now has two ways of loading
> languages: the old one, through ldf files, which is the one that Org
> implements and that produces the traditional babel syntax; and the new
> system through ini files, which also incorporates a new syntax with many
> options and variants. New languages have been defined by ini files, but
> cannot be loaded by the old syntax. That is the cause of the asterisks
> in my list: when a language has an asterisk it means that it is only
> served in babel through an ini file and, therefore, the traditional
> syntax cannot be used, so it is not implemented for use in babel. And
> furthermore, the new babel syntax and ini files can only be used with
> the Unicode TeX engines: XeTeX and LuaTeX. This all looks like a puzzle
> (I'm getting dizzy just rereading it :-)), and I don't see a clean and
> sensible way to translate it to Org settings.

Do you refer to the paragraph below when saying that Org implementation
makes it hard to add new features? The rest of the above paragraph
implies that the difficulty is on LaTeX side, not on Org side.

In any case, your existing patch is an already an improvement. I do not
deem it as requirement to apply the patch.

> I also think that the current Org settings for loading languages with
> Polyglossia or Babel is unhelpful and unclear. Also, it depends on
> putting explicit LaTeX code in the document. A code that, in the case of
> Polyglossia, is a fake LaTeX code, because something like this:
>
> \usepackage[french,AUTO]{polyglossia}
>
> is not really the Polyglossia syntax. And it can lead to confusion.

I hope that Timothy's work on more flexible and configurable template
generation can improve things.

> I think this should be reimplemented in the future using a more
> org-centric syntax, using keywords (somehow keeping the
> above for backwards compatibility). I don't know, maybe something like
> this, with a specific keyword for language LaTeX settings:
>
> #+latex_language: es variant:mx babel-ini:t other:en,de,el etc.
>
> In this case, I think it would make more sense to define a more robust
> list, an alist or a plist (as Maxim suggested), leaving the door open to
> a fresh reimplementation of langs in latex export. I can get to work as
> soon as I have some time and finish with other commitments, that will
> keep me busy practically all summer.
>
> WDYT?

This sounds reasonable. Implementing via :options-alist export property
will conform more to the overall design (see the docstring of
org-export-options-alist - it enables a lot of flexibility in terms of
customization, including the option syntax similar to what you proposed).

Best,
Ihor

Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]

[Ihor Radchenko]

Gustavo Barros  writes:

> ... (lots of detailed analysis with various cases)
> WDYT?

I feel that you are overcomplicating things a bit.
What if we simply change all the agenda lines if and only if their date
in agenda is earlier or equal to the next scheduled time (after repeater
is triggered)?

Best,
Ihor

Re: Could an "org-anniversary" be a PROPERTY?

[Ypo]

It works! Thanks, Ihor.

How could I've known? Should I've known?



El 18/07/2022 a las 1:49, Ihor Radchenko escribió:

Ypo  writes:


I am starting to use org-contacts and wanted to unify my existing
"Birthdays" list, with the new formatted contacts I am creating.

Do the anniversaries have to be out of PROPERTIES?

Example: This is not "parsed into agenda":

:PROPERTIES:
:BDAY: %%(org-anniversary 1980 02 19)
:END:

Try

:BDAY: <%%(org-anniversary 1980 02 19)>

(diary sexp-style timestamp)

Best,
Ihor