org-table with different conventions: decimals
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
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/)]
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?
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
Re: substitutions in html export?
kevinbanjo writes: >> You need to construct the export block programmatically. Maybe something >> like >> >> #+begin_src emacs-lisp :results html :exports results :var num=numbers() >>(format "the result is %d" num ) >> #+end_src >> >> > The problem with that is when I export I get both above and below > the result (even though I added :results output raw) and I need it inline > plus it's changing my angle brackets to > and < (I'm trying to generate > php code). > > Any idea how to fix that? Use inline src block or an inline call to the src block. Best, Ihor
Re: `org-capture' loads all the files in `org-directory'
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: [PATCH] Delete some Emacs 24 compat code
great! one of the things i like about org is the close attention to user-oriented nature of maintenance. everything on mailing list, maint branch, compilation warnings few, etc. this is more of the same user-oriented goodness. i have noticed an impressive amount of bug fixing, code improvement, documentation improvement type of activity recently and it is greatly appreciated. it's a kind of user-openness attitude that i think improves the software. by analogy, kind of like including science-oriented research subjects to get knowledge and noticing and priorities instead of imposing an arbitrary wall. On 7/17/22, Bastien Guerry wrote: > Hi Ihor and Samuel, > > Ihor Radchenko writes: > >> In addition, we might also announce the oldest supported Emacs version >> in https://orgmode.org/Changes.html. > > The current release of Org is meant to be compatible with the last > three major releases of Emacs. That is, as of now, 28, 27, 26. > > See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility > > If the current release is de facto compatible with older Emacsen and > a new release will change this, yes, let's announce it in the release > notes. > > We can also send an email to the list using the "X-Woof-Change" to > announce this upcoming change for the upcoming release. > > For example, the current release of Org (9.5.4) is compatible with > Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some > reason Org 9.6 only supports Emacs >=26, let's announce it on the list > and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. > > I think doing this manually is fine. > > Bug fixes from the maint branch should never change the compatibility > status of Org. > > Evolutions on the master branch can change the compatibility, but not > break the global promise of being compatible with the last three major > releases of Emacs. > > -- > Bastien > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: substitutions in html export?
On Sun, Jul 17, 2022 at 11:54 AM Berry, Charles wrote: > Kevin, > > > On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote: > > > > > > > > On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko > wrote: > > See inline calls in > https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks > > > > The export block provides text that is to be used "as is" by the html > backend. So, "call_numbers()" is treated as html. > > You need to construct the export block programmatically. Maybe something > like > > #+begin_src emacs-lisp :results html :exports results :var num=numbers() >(format "the result is %d" num ) > #+end_src > > The problem with that is when I export I get both above and below the result (even though I added :results output raw) and I need it inline plus it's changing my angle brackets to > and < (I'm trying to generate php code). Any idea how to fix that? -Kevin
Re: Fwd: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
Ihor Radchenko writes: >> valign-mode causes the problem. Try these steps to reproduce the problem : >> add-hook for valign and open a large org file, then try moving the mouse a >> few times，quickly TAB and SHIFT-TAB a few times. > > Thanks! I have opened an issue in valign repo: > https://github.com/casouri/valign/issues/30 > > This problem needs to be fixed on valign side. After further investigation and discussions with Emacs devs, the issue has been fixed on Org side. Fixed. Best, Ihor
Re: org-cature-ref
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"
Best,
Ihor
Re: Could an "org-anniversary" be a PROPERTY?
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
Re: no syntax highlighting for code blocks with org-publish
"M. Pger" 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: substitutions in html export?
kevinbanjo writes:
> 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.
KEYWORDS argument is listing the "keyword" syntactic elements. Your
export block is an "export block" element where macro expansion cannot
work by design.
> This whole area of org documentation seems pretty obtuse, with few
> examples.
Could you please point out which particular part of org documentation is
lacking?
Best,
Ihor
Re: substitutions in html export?
kevinbanjo writes: > Thanks for that Chuck. It would seem a lot cleaner if there was a hook or > something one could run that would just expand macros in export blocks > before exporting them. Check out export filters in 13.17 Advanced Export Configuration By default, we cannot allow Org syntax inside export blocks because it can interfere with the exported format syntax. Best, Ihor
Re: substitutions in html export?
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.
This whole area of org documentation seems pretty obtuse, with few examples.
Re: org-cature-ref
Den lör 16 juli 2022 kl 11:16 skrev Ihor Radchenko : > Henrik Frisk writes: > > >>> Is so, you probably need > >>> > >>> org-protocol://capture?template... > >>> instead of > >>> org-protocol://capture-html?template... > >>> > >>> Thanks, that was the issue and it works fine now. However, I can't seem > >> to get the org-capture-ref-get-bibtex-field to work by simply replacing > org-capture-ref-headline-format > >> with it. Not sure where the ":bibtex-string" should go in the template > >> which is probably why it doesn't work. > > 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: /Henrik
Re: substitutions in html export?
On Sun, Jul 17, 2022 at 11:54 AM Berry, Charles wrote: > Kevin, > > > On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote: > > > > > > > > On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko > wrote: > > See inline calls in > https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks > > > > I did this and it didn't work (but the one outside the export block did): > > > > #+title:test > > > > #+name: numbers > > #+begin_src emacs-lisp :exports none > > 40 > > #+end_src > > > > #+begin_export html > > > > the result is call_numbers() > > > > #+end_export > > > The export block provides text that is to be used "as is" by the html > backend. So, "call_numbers()" is treated as html. > > You need to construct the export block programmatically. Maybe something > like > > #+begin_src emacs-lisp :results html :exports results :var num=numbers() >(format "the result is %d" num ) > #+end_src > > > HTH, > > Chuck > > > Thanks for that Chuck. It would seem a lot cleaner if there was a hook or something one could run that would just expand macros in export blocks before exporting them. -Kevin
Re: substitutions in html export?
Kevin, > On Jul 17, 2022, at 10:18 AM, kevinbanjo wrote: > > > > On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko wrote: > See inline calls in > https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks > > I did this and it didn't work (but the one outside the export block did): > > #+title:test > > #+name: numbers > #+begin_src emacs-lisp :exports none > 40 > #+end_src > > #+begin_export html > > the result is call_numbers() > > #+end_export The export block provides text that is to be used "as is" by the html backend. So, "call_numbers()" is treated as html. You need to construct the export block programmatically. Maybe something like #+begin_src emacs-lisp :results html :exports results :var num=numbers() (format "the result is %d" num ) #+end_src HTH, Chuck
Could an "org-anniversary" be a PROPERTY?
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: BTW: Thanks for your advices with org-capture. I found too a very useful introductory video from Protesilaos (I wasn't able to understand the documentation till I watched this video): https://youtu.be/qCdScs4YO8k
Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)
Hi, Ihor Radchenko writes: > Hmm. You are right. I missed "optionally". > > Still, I find this idea as the best solution for people who want to > process the source block text during noweb expansion. > > Alternative ideas are welcome though. I'd prefer to avoid breaking > change if we can find an equally simple syntax alternative to assign > source block code to a variable. The uses are maybe too niche to warrant the breaking change. A syntax extension like : var=block-id[] seems possible, even though brackets are already overloaded. One alternative is to only allow the syntax inside noweb brackets instead of generic variable arguments. I assume there'd be much less breakage. It would also makes sense to allow noweb references instead of block ids. We'd add support for : <> and <> would also insert the contents as a by-product. Do you have any example of use in mind, beyond my original one ? Regards, -- Sébastien Miquel
no syntax highlighting for code blocks with org-publish
Dear All, 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? Best, MP
Re: substitutions in html export?
On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko wrote: > See inline calls in > https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks > I did this and it didn't work (but the one outside the export block did): #+title:test #+name: numbers #+begin_src emacs-lisp :exports none 40 #+end_src #+begin_export html the result is call_numbers() #+end_export the result outside an export block is call_numbers()
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Ihor Radchenko 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.
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 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?
Best regards,
Juan Manuel
Re: toggle a checkbox in a property
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >> But how can I obtain >> >> * Test >> :PROPERTIES: >> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a >> :Received: [-] >> :END: >> >> org-toggle-checkbox does not work for these sort of checkboxes. > The [ ] <> [X] is hardcoded. > But you can always set Received_ALL property to provide a manual list of > allowed property values. From https://orgmode.org/guide/Properties.html I tried * CD collection :PROPERTIES: :Box_ALL: [-] [X] :Publisher_ALL: "Deutsche Grammophon" Philips EMI :END: *** Goldberg Variations :PROPERTIES: :Title: Goldberg Variations :Composer: J.S. Bach :Publisher: Deutsche Grammophon :Box: :END: But it did not work, the value is not accpeted if I chose Or * CD collection :PROPERTIES: :Box_ALL: - X :Publisher_ALL: "Deutsche Grammophon" Philips EMI :END: *** Goldberg Variations :PROPERTIES: :Title: Goldberg Variations :Composer: J.S. Bach :Publisher: Deutsche Grammophon :Box: :END: Then I don't get a box. smime.p7s Description: S/MIME cryptographic signature
[SOLVED] (was: toggle a checkbox in a property)
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >> But how can I obtain >> >> * Test >> :PROPERTIES: >> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a >> :Received: [-] >> :END: >> >> org-toggle-checkbox does not work for these sort of checkboxes. > The [ ] <> [X] is hardcoded. > But you can always set Received_ALL property to provide a manual list of > allowed property values. *** Goldberg Variations :PROPERTIES: :Box_ALL: "[-]" "[X]" "[ ]" :Title:Goldberg Variations :Composer: J.S. Bach :Publisher: Deutsche Grammophon :Box: [-] :END Solves the issue thanks smime.p7s Description: S/MIME cryptographic signature
Re: toggle a checkbox in a property
https://orgmode.org/manual/Property-Syntax.html#Property-Syntax On Sun, Jul 17, 2022 at 10:31 PM Uwe Brauer wrote: > >>> "IR" == Ihor Radchenko writes: > > > Uwe Brauer writes: > >> But how can I obtain > >> > >> * Test > >> :PROPERTIES: > >> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a > >> :Received: [-] > >> :END: > >> > >> org-toggle-checkbox does not work for these sort of checkboxes. > > > The [ ] <> [X] is hardcoded. > > But you can always set Received_ALL property to provide a manual list of > > allowed property values. > > Thanks but could you provide some link or information, I am unable to > find any example >
Re: toggle a checkbox in a property
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >> But how can I obtain >> >> * Test >> :PROPERTIES: >> :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a >> :Received: [-] >> :END: >> >> org-toggle-checkbox does not work for these sort of checkboxes. > The [ ] <> [X] is hardcoded. > But you can always set Received_ALL property to provide a manual list of > allowed property values. Thanks but could you provide some link or information, I am unable to find any example smime.p7s Description: S/MIME cryptographic signature
Re: substitutions in html export?
See inline calls in https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
substitutions in html export?
Hi everyone:
Is there any way to make something like this actually work?
#+title:test
#+macro: num 50
#+name: numbers
#+begin_src emacs-lisp no-export
40
#+end_src
#+begin_export html
the result is {{{num}}}
another result is <>
#+end_export
Re: toggle a checkbox in a property
Uwe Brauer writes: > But how can I obtain > > * Test > :PROPERTIES: > :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a > :Received: [-] > :END: > > org-toggle-checkbox does not work for these sort of checkboxes. The [ ] <> [X] is hardcoded. But you can always set Received_ALL property to provide a manual list of allowed property values. Best, Ihor
Re: [bug] org-list-struct-apply-struct: insert an item in the end of a list
Phil Estival writes: > Hi there > > - A nasty bug when inserting an item in a list > in last position (org 9.5.3-g69c588): > - here is a list > with a sub list > > - like here ; > > and then text > x I am unable to reproduce on the latest main. Best, Ihor
toggle a checkbox in a property
Hi Look at this example * Test :PROPERTIES: :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a :Received: [X] :END: Using `org-shiftright' I can obtain * Test :PROPERTIES: :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a :Received: [ ] :END: But how can I obtain * Test :PROPERTIES: :ID: 46b9eb11-e258-4dc9-bf56-3c2112cf6b0a :Received: [-] :END: org-toggle-checkbox does not work for these sort of checkboxes. regards Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: image size in ox-pandoc
juh writes: > This does not work: > > #+CAPTION: Foobar > #+NAME: fig:imagew > #+ATTR_CONTEXT: :width 5cm > [[file:/image.png]] Have you tried #+attr_latex? Best, ihor
Re: [BUG] C-c C-o on headline evaluates source code blocks with links inside [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > This will skip links inside property drawers, for example. > Attaching an alternative patch. Applied onto main via 057df6cce. Best, Ihor
Re: [PATCH] Re: [BUG] org-agenda-remove-restriction-lock does not remove file lock [9.5.2 (release_9.5.2-17-gea6b74 @ /nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0/share/emacs/29.0.
Ihor Radchenko writes: > Visuwesh writes: > >> C-u C-c C-x < followed by C-c C-x > does not remove the file restriction >> lock. >> >> `org-agenda-remove-restriction-lock' checks for non-nil value of >> `org-agenda-restriction' but `org-agenda-set-restriction-lock' explicitly >> sets it to nil when TYPE is 'file. Setting `org-agenda-restriction' to >> a dummy value like 'dummy gets the job done. > > Confirmed. > > The fix is attached. > Setting org-agenda-restriction to non-nil appears to be risky since > org-agenda-set-restriction-lock explicitly sets it to nil. So, I use > different approach. Fixed. Applied onto main via df0e96ba4. Best, Ihor
Re: [PATCH v5] ol.el: add description format parameter to org-link-parameters
Max Nikulin writes: > Ihor, Hugo raised a question how to interpret nil returned by > :insert-description functions. Do you have any opinion? I do not like > the idea to consider it as an error since string is expected. I would > prefer to call `org-link-make-description-function' as a fallback. > > On 17/07/2022 04:20, Hugo Heagren wrote: >>> Can you also update the documentation for >>> org-link-make-description-function? >> >> I'm not sure what sort of documentation you have in mind? What should >> I add? > > I have no idea what Ihor means. From my point of view, mention of > :insert-description and `org-link-parameters' may give a hint to users. Let me clarify. The new :insert-description parameter is a more fine-grained equivalent to already existing org-link-make-description-function. The latter can, de facto, return string or nil - it is passed to `read-string' as INITIAL-INPUT argument. So, I suggested interpreting nil return value in :insert-description just as it is already interpreted in org-link-make-description-function. Further, I asked to document that nil value is allowed - both in :insert-description docstring section and in org-link-make-description-function docstring. Best, Ihor
Re: [PATCH v5] ol.el: add description format parameter to org-link-parameters
Hugo Heagren writes: >> Can you also update the documentation for >> org-link-make-description-function? > > I'm not sure what sort of documentation you have in mind? What should > I add? I referred to my earlier statement: > tl;dr The question is: what is the Good Behaviour when > :default-description is set to something, which is meant to return a > string and returns 'nil instead? Should it be treated like an empty > string, or as an error? Currently, the internal implementation will treat nil return value as if there was no :default-description and org-link-make-description-function were set to nil. We may probably document this. It sounds like a useful behaviour. If the :default-description function returns non-string and not nil, the behaviour is simply undefined. It was also the case for org-link-make-description-function. Though we might add a cl-assert somewhere near the end of org-insert-link to deliberately throw an error. The return value of org-link-make-description-function can also be nil in addition to string. I suggest documenting this, just as you did for :insert-description parameter. Best, Ihor
Re: org-capture and fast selection of tags
Christian Heinrich writes: > thanks for your feedback. I attached a patch, but I'm not sure why you said > "all but the last line". > That last line for me was (org-set-tags tags), which proved important as > otherwise the tags were not > set in the buffer. By "all but last line" I implied that the part that reads the tags should be factored out. That part should not modify the tags in file, just read the tags using the preferred interface and return the selected tag list. This return value can be used in org-set-tags-command to be passed to org-set-tags. For org-capture the return value can be used to insert the tags in place of %^g (rather than putting the tags under headline unconditionally). Now, after examining the code of org-set-tags-command more closely, I found out that org-fast-tag-selection is actually tricky to use as I described above. org-fast-tag-selection itself is changing the headline tags even before the user finishes the selection process. So, an appropriate patch would also need to alter org-fast-tag-selection in such a way that it could be called without side effects (changing buffer text) - it can be done by providing a new optional argument to org-fast-tag-selection. Best, Ihor
Re: Org for developing LaTeX packages
Juan Manuel Macías writes: > Out of curiosity, I wonder if Marcin or someone else finally got around > to implementing something concrete for this. I think some kind of > extension to org-babel-tangle that would generate the typical docstrip > .dtx and .ins files might be nice. Perhaps this would open up the use of > Org to LaTeX package developers, though admittedly docstrip is deeply > rooted in planet LaTeX and hardly anything else is used. I do not think that we need any extensions to org-babel-tangle for this. AFAIU, appropriate export backend should be more suitable to generate output that involves both code blocks and other org file elements. Best, Ihor
Re: [BUG] org-capture-kill: doesn't remove the right text region
Caleb Chase writes: > I discovered a bug with org-capture and org-capture kill when > canceling an item or plain type template on a heading that has only an > empty line for content. Minimal reproduction is as follows: Thanks for reporting! Confirmed. Best, Ihor
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Juan Manuel Macías writes: > I attach the new version of the patch with both variables declared > obsolete. Thanks! We usually declare obsolete variables in org-compat.el. > If everything is ok, I can add what is necessary to NEWS and to the Org > Manual. I have some minor comments. You can address them and then go ahead with NEWS and manual. 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. > +(make-obsolete-variable 'org-latex-babel-language-alist > +"set `org-latex-language-alist' instead." "9.6") > + > +(make-obsolete-variable 'org-latex-polyglossia-language-alist > +"set `org-latex-language-alist' instead." "9.6") > + As I mentioned earlier, please move the obsoletion statements to org-compat. > - "Alist between language code and corresponding Polyglossia option.") > + "Alist between language code and corresponding Babel/Polyglossia option. > + > +For the names of the languages, the Babel nomenclature is > +preferred to that of Polyglossia, in those cases where both > +coincide. > + > +The alist supports three types of members: > + > +- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION. > + > +- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION > +ASTERISK (the presence of the asterisk indicates that this > +language is not loaded in Babel using the old method of ldf > +files but using ini files. If Babel is loaded in an Org > +document with these languages, the \"AUTO \" argument is just > +removed, to avoid compilation errors). Two spaces between sentences please, as in https://orgmode.org/worg/org-contribute.html > ;; If LANGUAGE is already loaded, return header without AUTO. > ;; Otherwise, replace AUTO with language or append language if > ;; AUTO is not present. > (replace-match >(mapconcat (lambda (option) (if (equal "AUTO" option) language option)) > (cond ((member language options) (delete "AUTO" options)) > + ((let ((l (assoc language-code > org-latex-language-alist))) > + (and (consp l) (= (length l) 3))) (delete "AUTO" > options)) A comment explaining why "3" would be useful. > - (if (and (consp l) (= (length l) 3)) > - (format "[variant=%s]" (nth 2 l)) > + (if (and (consp l) (= (length l) 4)) > + (format "[variant=%s]" (nth 3 l)) > "") > - (nth 1 l > + (if (and (consp l) (= (length l) 4)) > + (nth 2 l) > + (nth 1 l) Again, comment explaining all these 2,3,4 would help. Best, Ihor
Re: PATCH: [PATCH] Allow bulk agenda actions to take log notes
Max Mikhanosha writes: > Currently org-agenda-bulk-action is completely broken if anything tries to > take a log note during the action, this patch fixes it by storing log note > setup variables in a list, and then taking one log note, and duplicating it > over all affected items. Thanks for the patch! I tried to test the patch and ran into an issue using the following recipe: 1. Create /tmp/bug.org with the following contents: #+TODO: TODO(t) | DONE(d@) * TODO this is test * TODO this is test * TODO this is test * TODO this is test * TODO this is test * TODO this is test * TODO this is test * TODO this is test 2. Open Emacs from Org git repo folder containing the patch applied onto the latest main branch: make clean; make autoloads; emacs-29-vcs -Q -L ./lisp /tmp/bug.org 3. Open agenda via M-x org-agenda < t 4. Move point to one of the TODO entries and change the toto state to DONE: t DONE 5. The log window will pop. Enter "something" C-c C-c 6. Mark several TODO entries in the agenda 7. Try to bulk-mark them DONE: B t DONE 8. Observe no window popup, empty notes, and some entries not being marked as done in the agenda buffer. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
Hi Ihor and Samuel, Ihor Radchenko writes: > In addition, we might also announce the oldest supported Emacs version > in https://orgmode.org/Changes.html. The current release of Org is meant to be compatible with the last three major releases of Emacs. That is, as of now, 28, 27, 26. See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility If the current release is de facto compatible with older Emacsen and a new release will change this, yes, let's announce it in the release notes. We can also send an email to the list using the "X-Woof-Change" to announce this upcoming change for the upcoming release. For example, the current release of Org (9.5.4) is compatible with Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some reason Org 9.6 only supports Emacs >=26, let's announce it on the list and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. I think doing this manually is fine. Bug fixes from the maint branch should never change the compatibility status of Org. Evolutions on the master branch can change the compatibility, but not break the global promise of being compatible with the last three major releases of Emacs. -- Bastien
Re: [PATCH] Re: org-agenda-clock-report-header
Ihor Radchenko writes: > From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00 2001 > Message-Id: > <9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com> > From: Ihor Radchenko > Date: Mon, 9 May 2022 20:34:38 +0800 > Subject: [PATCH] org-agenda-clock-report-header: Update docstring Applied onto main via 702b0a81e after adding reference to relevant manual page. Best, Ihor
Re: [External] : Re: missing a character / font in agenda?
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. Best, Ihor
Re: @string abbreviation in bib file not honored in (basic) org-cite
Ihor Radchenko writes on Sun 17 Jul 2022 16:26: > Fixed on main via c550a4290. > > After discussion with Emacs devs, it turned out that there is a way to > make bibtex.el parse and substitute @string abbreviations. I don't know what "Fixed on main via c550a4290" means, but I just made a 'git pull' (release_9.5.4-630-gbf930b) and now @string is expanded as expected. Thanks. -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: [Bug] incorrect indent of next heading after org-paste-subtree
Ihor Radchenko writes: > The fix is attached. Let me know if it also works on your side. Fixed. Applied onto main via 064afa0c0. Best, Ihor
Re: [BUG] Documentation errata [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Ihor Radchenko writes: > Hmm. Note that SINGLE-QUOTE is not actually typed, so your version is > also kind of confusing. > > I propose an alternative as the attached. Applied onto main via 79f0969cc. Best, Ihor
Re: [PATCH v4] org-encode-time compatibility and convenience helper
Ihor Radchenko writes: > All the tests are passing now on my side. > > I'll postpone merging to next week to make sure that there are no more > comments. Applied onto main via e08ce5b27, ae1db7df3, 8908a1bda, f3802b017, a4105d094, a18969768, and 132a9d304 after resolving a trivial merge conflict. Best, Ihor
Re: [PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo.
Stefan Kangas writes: > The attached patch fixes a small typo I found in the > `org-refile-targets' docstring. Thanks! Applied onto main via bf930b6fe. Best, Ihor
Re: @string abbreviation in bib file not honored in (basic) org-cite
alain.coch...@unistra.fr writes:
> My .bib file is
>
>@string{jgr="J. Geophys. Res."}
>@ARTICLE{chouet88,
>journal=jgr,
>author={Chouet, B.}, title={Resonance of a fluid-driven crack: [...]},
>year={1988}, volume={93}, number={B5}, pages={4375-4400}
Fixed on main via c550a4290.
After discussion with Emacs devs, it turned out that there is a way to
make bibtex.el parse and substitute @string abbreviations.
Best,
Ihor
Re: `org-capture' loads all the files in `org-directory'
Noel Errenil writes:
> Hello, org community
>
> I ran into the titled issue and haven't found any solution or explanation:
>
> First, I start Emacs and there are just a few buffers such as *scratch* and
> *Messages*.
>
> 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.
>
FWIW, in my case, org seems to open org files that are necessary to
identify the capture target, like when refiling somewhere else. Using
`C-c C-c', org does not open other files though, just the targetted one.
Cleaning up your org agenda files, if possible, might reduce the number
of files org needs to load.
(customize-option 'org-agenda-files)
Bruno
> I'm running Emacs 28.1 on (Gentoo) Linux. I can reproduce this on my
> macOS too.
>
> Currently I have `org-directory' set to `~/projects/org'. My
> `org-capture' config is as follows:
>
> ;; vars
> (with-eval-after-load 'org
> (setq-default fill-column 80)
> (setq
>org-deadline-warning-days 0
>org-startup-folded 'content
>org-hide-leading-stars t
>org-agenda-include-diary t
>org-src-fontify-natively t
>org-src-preserve-indentation t
>org-edit-source-content-indentation 0
>org-indent-indentation-per-level 1
>org-directory "~/projects/org"
>org-agenda-files (concat org-directory "/agenda.org")
>org-default-notes-file (concat org-directory "/notes.org")))
>
> ;; org-capture templates
> (setq org-capture-templates
> '(("t" "Tasks")
> ("td" "With Dealines" entry ; todos->deadline
>(file+headline "tasks.org" "Deadlines")
>"* TODO %? %^G\nDEADLINE: %T" :kill-buffer t :prepend t)
> ("ts" "Scheduled" entry ; todos->scheduled
>(file+headline "tasks.org" "TODOS")
>"* TODO %? %^G\nSCHEDULED: %T" :kill-buffer t :prepend t)
> ;; memos
> ("m" "Memo" entry
> (file+headline "memo.org" "MEMO")
> "* %? %^G\n%U" :kill-buffer t :prepend t)
> ;; notes
> ("n" "Daily Notes" entry
> (file+headline "notes.org" "NOTES")
> "* %? %^G\n%U" :kill-buffer t :prepend t)
> ;; readings
> ("r" "Readings")
> ("ra" "Article" entry
> (file+headline "readings.org" "ARTICLE")
> "* TODO %^{Short title for heading} %^G \nTTL: %^{Long title}
> \nSRC: %^{Link} \n%u \nSUM: %^{Quick note?}"
> :kill-buffer t)
> ("rb" "Book" entry
> (file+headline "readings.org" "BOOK")
> "* TODO %^{Short title for heading} %^G \nTTL: %^{Long title}
> \nSRC: %^{Link} \n%u \nSUM: %^{Quick note?}"
> :kill-buffer t)))
>
> 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.
>
> What am I doing wrong? Any advice? Thank you so much in advance.
`org-capture' loads all the files in `org-directory'
Hello, org community
I ran into the titled issue and haven't found any solution or explanation:
First, I start Emacs and there are just a few buffers such as *scratch* and
*Messages*.
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.
I'm running Emacs 28.1 on (Gentoo) Linux. I can reproduce this on my
macOS too.
Currently I have `org-directory' set to `~/projects/org'. My
`org-capture' config is as follows:
;; vars
(with-eval-after-load 'org
(setq-default fill-column 80)
(setq
org-deadline-warning-days 0
org-startup-folded 'content
org-hide-leading-stars t
org-agenda-include-diary t
org-src-fontify-natively t
org-src-preserve-indentation t
org-edit-source-content-indentation 0
org-indent-indentation-per-level 1
org-directory "~/projects/org"
org-agenda-files (concat org-directory "/agenda.org")
org-default-notes-file (concat org-directory "/notes.org")))
;; org-capture templates
(setq org-capture-templates
'(("t" "Tasks")
("td" "With Dealines" entry ; todos->deadline
(file+headline "tasks.org" "Deadlines")
"* TODO %? %^G\nDEADLINE: %T" :kill-buffer t :prepend t)
("ts" "Scheduled" entry ; todos->scheduled
(file+headline "tasks.org" "TODOS")
"* TODO %? %^G\nSCHEDULED: %T" :kill-buffer t :prepend t)
;; memos
("m" "Memo" entry
(file+headline "memo.org" "MEMO")
"* %? %^G\n%U" :kill-buffer t :prepend t)
;; notes
("n" "Daily Notes" entry
(file+headline "notes.org" "NOTES")
"* %? %^G\n%U" :kill-buffer t :prepend t)
;; readings
("r" "Readings")
("ra" "Article" entry
(file+headline "readings.org" "ARTICLE")
"* TODO %^{Short title for heading} %^G \nTTL: %^{Long title}
\nSRC: %^{Link} \n%u \nSUM: %^{Quick note?}"
:kill-buffer t)
("rb" "Book" entry
(file+headline "readings.org" "BOOK")
"* TODO %^{Short title for heading} %^G \nTTL: %^{Long title}
\nSRC: %^{Link} \n%u \nSUM: %^{Quick note?}"
:kill-buffer t)))
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.
What am I doing wrong? Any advice? Thank you so much in advance.
