Re: Influence the table separator in a code block
fwiw, this may depend on the source language (rather than -- solely? --
on org interpretation of the output block:
#+begin_src R
data.frame(a=c("this", "is", "a", "test"), b=c("tset", "a", "si", "oot,
siht"))
#+end_src
#+RESULTS:
| this | tset |
| is | a |
| a| si|
| test | oot, siht |
block-like markup to export custom html?
I'm using https://github.com/bastibe/org-static-blog to generate http://members.wolfram.com/billw See especially http://members.wolfram.com/billw/2021-07-05-romanovsky-on-bronstein.html I have an org file full of these things to denote side-by-side columns of English and Russian text: @@html:@@ Some English text. @@html:@@ Some Russian text. @@html:@@ ===> My question: is there a notion of a custom block-like structure that, upon export to html (or whatever backend org-static-blog uses), would insert the inlined html code shown above? I'm imagining something like: #+begin_multicol Some English text. #+break: Some Russian text #+end_multicol to produce this upon export: Some English text. Some Russian text. Background: I'm learning Russian and re-learning chess, and one day I realized I could translate articles from old Russian chess magazines. Thanks! bw -- "No, ma'am, we're musicians."
Re: A requires/provides approach to linking source code blocks
one thing about org that i think has been making it complex, in addition to number of features, is non-orthogonality. On 7/13/21, Tim Cross wrote: > > Tom Gillespie writes: > > [snip] > >> >> Once I wrap up the formal grammar for org, one of the next things I >> plan to work on is a clear specification for org babel. This is >> critical because so many of the suggestions that come in deal with >> individuals' specific problems and thus fail to account for how such >> features interact with existing features and how the newly proposed >> feature would block some other features in the future, confuse users, >> etc. Such suggestions also often fail to account for increased >> complexity, nor have they been exposed to a sufficient number of >> examples to reveal fundamental ambiguities in how they could be >> interpreted. The issues with variable behavior between ob langs for >> :pre :post :prologue :epilogue etc. are already enough to keep us busy >> for quite some time. >> > > Yes, that clearly summs up my concerns as well. Often, a 'fix' for some > problem can seem straight-forward, possibly even trivial, when > considered only within one person's use case/workflow. Part of what > makes org so powerful is the level of flexibility it supports. However, > this flexibility makes it extremely difficult to consider, or even know > about, all the existing use cases. > > I suspect that once we have some formal specifications for babel, the > next step will be to develop some good unit tests to verify these > specifications. This would at least highlight/alert developers to > unforeseen impact from changes and alert them to things they may > not have considered. > >> With regard to this thread in particular, it is of some interest, but >> there are fundamental issues, including the fact that certain >> languages (e.g. racket) expect module code to exist somewhere on the >> file system. There are ways around many of these issues, in fact there >> are likely many ways around any individual issue, so org babel needs >> to systematically consider the issues and provide a clear >> specification, or at least a guide for how such cases should be >> handled. >> >> To give an example from one of my continual pain points: I start >> writing python or racket in an org src block and then I want it to be >> a library so that it can be reused by other code both inside and >> outside the org file without having to resort to noweb. >> > > This is an interesting point. I think a number of languages have > challenges here. I run into very similar issues with Clojure. > > To some extent, I think this is a grey area within the literate > programming paradigm. The original literate programming model was > developed at a time when most languages were compiled rather then > interpreted. You generated source code, compiled it and then ran it. > > These days, many 'modern' languages are based around an interpreter and > concepts like 'just in time' compilation. In org mode, things become > even more complex because in addition to generation (tangling) of code, > we also want to have evaluation of code blocks, plus we have added the > concept of 'sessions'. > >> What is the best way to handle this? I don't know. Right now I tangle >> things and resort to awful hacks for the reuse-in-this-org-file case, but >> I'm guessing there is a better generic solution which would allow _any_ >> org block to be exported as a library instead of nowebbed in. >> >> Before jumping for any particular suggestion for how to handle this >> we need to explore the diversity of cases that various ob langs >> present, so that we can find a solution that will work for all of >> them. After all, packaging code to a library for reuse is an >> extremely common pattern that org babel should be able to >> abstract, but it is a major undertaking, not just the addition of a >> keyword here and there. >> > > Agree. I'm not convinced we really understand the requirements here and > more exploration and specification is required. The more we add 'simple' > extensions, options, keywords etc the more likely it is we will make > this a much harder process and will likely result in even larger > 'breakage' once we do define a clearer specification. > >> In short I suggest that we issue a general moratorium on new org babel >> feature suggestions until we can stabilize what we already have and >> provide a clear specification for correct behavior. Until we have that >> spec >> we could encourage users to create extensions that implement those >> features. >> > > Yes. While it might sound harsh or overly limiting, I do think such a > moratorium may be required. We may be able to lift it once we have some > core specifications in place. We would still accept bug fixes (though we > may need to provide some clarity on what is a bug fix and what is a > feature enhancement/change - I regularly see posts flagged as bug fixes > which are actually feature enhancements or extensions).
Re: A requires/provides approach to linking source code blocks
Tom Gillespie writes: [snip] > > Once I wrap up the formal grammar for org, one of the next things I > plan to work on is a clear specification for org babel. This is > critical because so many of the suggestions that come in deal with > individuals' specific problems and thus fail to account for how such > features interact with existing features and how the newly proposed > feature would block some other features in the future, confuse users, > etc. Such suggestions also often fail to account for increased > complexity, nor have they been exposed to a sufficient number of > examples to reveal fundamental ambiguities in how they could be > interpreted. The issues with variable behavior between ob langs for > :pre :post :prologue :epilogue etc. are already enough to keep us busy > for quite some time. > Yes, that clearly summs up my concerns as well. Often, a 'fix' for some problem can seem straight-forward, possibly even trivial, when considered only within one person's use case/workflow. Part of what makes org so powerful is the level of flexibility it supports. However, this flexibility makes it extremely difficult to consider, or even know about, all the existing use cases. I suspect that once we have some formal specifications for babel, the next step will be to develop some good unit tests to verify these specifications. This would at least highlight/alert developers to unforeseen impact from changes and alert them to things they may not have considered. > With regard to this thread in particular, it is of some interest, but > there are fundamental issues, including the fact that certain > languages (e.g. racket) expect module code to exist somewhere on the > file system. There are ways around many of these issues, in fact there > are likely many ways around any individual issue, so org babel needs > to systematically consider the issues and provide a clear > specification, or at least a guide for how such cases should be > handled. > > To give an example from one of my continual pain points: I start > writing python or racket in an org src block and then I want it to be > a library so that it can be reused by other code both inside and > outside the org file without having to resort to noweb. > This is an interesting point. I think a number of languages have challenges here. I run into very similar issues with Clojure. To some extent, I think this is a grey area within the literate programming paradigm. The original literate programming model was developed at a time when most languages were compiled rather then interpreted. You generated source code, compiled it and then ran it. These days, many 'modern' languages are based around an interpreter and concepts like 'just in time' compilation. In org mode, things become even more complex because in addition to generation (tangling) of code, we also want to have evaluation of code blocks, plus we have added the concept of 'sessions'. > What is the best way to handle this? I don't know. Right now I tangle > things and resort to awful hacks for the reuse-in-this-org-file case, but > I'm guessing there is a better generic solution which would allow _any_ > org block to be exported as a library instead of nowebbed in. > > Before jumping for any particular suggestion for how to handle this > we need to explore the diversity of cases that various ob langs > present, so that we can find a solution that will work for all of > them. After all, packaging code to a library for reuse is an > extremely common pattern that org babel should be able to > abstract, but it is a major undertaking, not just the addition of a > keyword here and there. > Agree. I'm not convinced we really understand the requirements here and more exploration and specification is required. The more we add 'simple' extensions, options, keywords etc the more likely it is we will make this a much harder process and will likely result in even larger 'breakage' once we do define a clearer specification. > In short I suggest that we issue a general moratorium on new org babel > feature suggestions until we can stabilize what we already have and > provide a clear specification for correct behavior. Until we have that spec > we could encourage users to create extensions that implement those > features. > Yes. While it might sound harsh or overly limiting, I do think such a moratorium may be required. We may be able to lift it once we have some core specifications in place. We would still accept bug fixes (though we may need to provide some clarity on what is a bug fix and what is a feature enhancement/change - I regularly see posts flagged as bug fixes which are actually feature enhancements or extensions). > > PS The other next thing that I am working on might be another way out > for this particular feature request. Namely, it is simplifying and > extending org keyword syntax so that new keywords (with options) and > associated keywords can be specified using keyword syntax
Re: Citations merged!
*** More reliable sources and less fake news! *** To everyone involved: Thank you for making the world a better place. R+ Nicolas Goaziou writes: Hello, It took years, but citations are now full part of Org syntax. Thanks to everyone involved over the time! Now, it needs to be documented, but that will come a bit later. Regards, -- Nicolas Goaziou -- "Contrariwise," continued Tweedledee, "if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic." -- Lewis Carroll, Through the Looking Glass Rudolf Adamkovič Studenohorská 25 84103 Bratislava Slovakia [he/him]
Re: A requires/provides approach to linking source code blocks
In implementing an extension you might consider doing it as a generalized form of what I did with ob-racket (https://github.com/togakangaroo/ob-racket ). I think it is best to rely on the import/require/include mechanism of the language you're using. Pretty much all of them support adjacent files. The problem with code block execution is that it expands the block and writes it to a temporary directory in a non-predictable location. If you want to reference other blocks, you need them to *also* write into files in the same folder. What I do in ob-racket is support a header :adjacent-file which allows you to pass in the name of another block and then writes it into the same folder as the file to be executed with a predictable name (the name of the block) So something like this #+begin_src racket :adjacent-file stacker-reader-expander.rkt #lang reader "./stacker-reader-expander.rkt" Will make sure the block named `stacker-reader-expander.rkt` is written into that same temporary directory with that same name. There's a few rough edges but for the most part it works well. Would love to see someone take this and generalize it into its own extension. On Tue, Jul 13, 2021 at 2:18 PM Tom Gillespie wrote: > We have been receiving many new feature suggestions and requests > coming in for org babel. I think that Tim's suggestion is the right > one. Nearly all of these need to be implemented as an extension first > and tested independently. Further, even if this is done, it should be > clear that there is zero expectation that such extensions will be > incorporated. > > Once I wrap up the formal grammar for org, one of the next things I > plan to work on is a clear specification for org babel. This is > critical because so many of the suggestions that come in deal with > individuals' specific problems and thus fail to account for how such > features interact with existing features and how the newly proposed > feature would block some other features in the future, confuse users, > etc. Such suggestions also often fail to account for increased > complexity, nor have they been exposed to a sufficient number of > examples to reveal fundamental ambiguities in how they could be > interpreted. The issues with variable behavior between ob langs for > :pre :post :prologue :epilogue etc. are already enough to keep us busy > for quite some time. > > With regard to this thread in particular, it is of some interest, but > there are fundamental issues, including the fact that certain > languages (e.g. racket) expect module code to exist somewhere on the > file system. There are ways around many of these issues, in fact there > are likely many ways around any individual issue, so org babel needs > to systematically consider the issues and provide a clear > specification, or at least a guide for how such cases should be > handled. > > To give an example from one of my continual pain points: I start > writing python or racket in an org src block and then I want it to be > a library so that it can be reused by other code both inside and > outside the org file without having to resort to noweb. > > What is the best way to handle this? I don't know. Right now I tangle > things and resort to awful hacks for the reuse-in-this-org-file case, but > I'm guessing there is a better generic solution which would allow _any_ > org block to be exported as a library instead of nowebbed in. > > Before jumping for any particular suggestion for how to handle this > we need to explore the diversity of cases that various ob langs > present, so that we can find a solution that will work for all of > them. After all, packaging code to a library for reuse is an > extremely common pattern that org babel should be able to > abstract, but it is a major undertaking, not just the addition of a > keyword here and there. > > In short I suggest that we issue a general moratorium on new org babel > feature suggestions until we can stabilize what we already have and > provide a clear specification for correct behavior. Until we have that spec > we could encourage users to create extensions that implement those > features. > > Best, > Tom > > > PS The other next thing that I am working on might be another way out > for this particular feature request. Namely, it is simplifying and > extending org keyword syntax so that new keywords (with options) and > associated keywords can be specified using keyword syntax within a > single org file. This would make it possible to get useful high level > keyword behavior in a single file without burdening the core > implementation with more special cases for associated keywords, and it > would allow users to write small elisp functions that could do some of > what is suggested here, all without need to add anything to the core > org implementation. > >
Re: A requires/provides approach to linking source code blocks
We have been receiving many new feature suggestions and requests coming in for org babel. I think that Tim's suggestion is the right one. Nearly all of these need to be implemented as an extension first and tested independently. Further, even if this is done, it should be clear that there is zero expectation that such extensions will be incorporated. Once I wrap up the formal grammar for org, one of the next things I plan to work on is a clear specification for org babel. This is critical because so many of the suggestions that come in deal with individuals' specific problems and thus fail to account for how such features interact with existing features and how the newly proposed feature would block some other features in the future, confuse users, etc. Such suggestions also often fail to account for increased complexity, nor have they been exposed to a sufficient number of examples to reveal fundamental ambiguities in how they could be interpreted. The issues with variable behavior between ob langs for :pre :post :prologue :epilogue etc. are already enough to keep us busy for quite some time. With regard to this thread in particular, it is of some interest, but there are fundamental issues, including the fact that certain languages (e.g. racket) expect module code to exist somewhere on the file system. There are ways around many of these issues, in fact there are likely many ways around any individual issue, so org babel needs to systematically consider the issues and provide a clear specification, or at least a guide for how such cases should be handled. To give an example from one of my continual pain points: I start writing python or racket in an org src block and then I want it to be a library so that it can be reused by other code both inside and outside the org file without having to resort to noweb. What is the best way to handle this? I don't know. Right now I tangle things and resort to awful hacks for the reuse-in-this-org-file case, but I'm guessing there is a better generic solution which would allow _any_ org block to be exported as a library instead of nowebbed in. Before jumping for any particular suggestion for how to handle this we need to explore the diversity of cases that various ob langs present, so that we can find a solution that will work for all of them. After all, packaging code to a library for reuse is an extremely common pattern that org babel should be able to abstract, but it is a major undertaking, not just the addition of a keyword here and there. In short I suggest that we issue a general moratorium on new org babel feature suggestions until we can stabilize what we already have and provide a clear specification for correct behavior. Until we have that spec we could encourage users to create extensions that implement those features. Best, Tom PS The other next thing that I am working on might be another way out for this particular feature request. Namely, it is simplifying and extending org keyword syntax so that new keywords (with options) and associated keywords can be specified using keyword syntax within a single org file. This would make it possible to get useful high level keyword behavior in a single file without burdening the core implementation with more special cases for associated keywords, and it would allow users to write small elisp functions that could do some of what is suggested here, all without need to add anything to the core org implementation.
Re: [PATCH] Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Tue, 13 Jul 2021 at 21:06, Alan Ristow wrote: > > Also, thanks to Ihor and Bhavin for your work on this. Prior to applying > the patch, I was noticing new bizarre behavior relating to recurring > tasks. I haven't been running the patched org very long yet, but so far, > so good. Thank you for confirming that it is working correctly for you. > Finally, as a newbie here myself, I have a naïve question of my own: > Provided the patch proves successful, how/when is it applied to the > official org repo? Is it up to Ihor (or somebody else) to make a pull > request, for example? >From my very little experience here, the patch will get reviewed by someone, and one of the maintainers (one with committer access) will merge/apply it in a few days. It might take more time as well. https://orgmode.org/worg/org-contribute.html#what-can-I-expect -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [O] What happened to ATTR_ORG?
Sorry, that escaped too soon. I meant to say that #+attr_org: :width 300 wasn't resizing the images in the Org buffer to 300 pixels wide. Turned out it wasn't Imagemagick, it was the variable org-image-actual-width, which was set to ignore any attr_* directives. I changed that and now it's working. Bill On 13 July 2021, William Denton wrote: Following up on this two years later ... I had some images that I wanted to shrink in my Org buffer, but #+attr_org: (setq org-image-actual-width nil) I had the variable set to t: "When non-nil, use the actual width of images when inlining them." There are a few other options, but nil does what I want: "When set to nil, try to get the width from an #+ATTR.* keyword and fall back on the original width if none is found." Bill On 25 May 2019, Cheong Yiu Fung wrote: I'm using the latest Org and it's working. If you'd like to dig the cause you might want to dig in `org-display-inline-images'. It accepts `:width' in any #+ATTR.*-like option, then immediately call `create-image'. I would guess it's an imagemagick problem too. steen writes: I am also having the same issue. I don't have time right now to try to track down causes, but this is not a unique problem. The behavior I am seeing is that #+ATTR_ORG no longer causes the images to be resized, they display at original size. -- Steen On Fri, May 24, 2019 at 8:34 AM John Kitchin wrote: I still use this. Do you see any issues in the Messages? If you try attr_latex does it work? If not you may have an imagemagick problem that can’t rescale the thumbnail. Note you will have to toggle the image display after you add that. On Fri, May 24, 2019 at 11:18 AM William Denton wrote: It used to be possible use ATTR_ORG on images to make them display at a different size, which was very useful when the images were large. It worked like this: #+ATTR_ORG: :width 300 [[file:very-large-image.jpg]] I haven't needed it for a while, but today I went to use it and it's gone! I grepped the source code, ORG-NEWS and the git log, but didn't see any mention of it. What happened? Did it go in version 9? Am I overlooking something? I feel like I've stepped into some parallel universe where everything is the same except this one Org command. Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: http://staplr.org/ -- John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: org-mode export to (latex) PDF
Hi Maxim,
Maxim Nikulin writes:
> I do not know if new engines allows to get list of available fonts and
> to choose a set of fonts with better coverage than lmodern.
LuaTeX and XeTeX use harfbuzz as OpenType rendering engine. On
LuaLaTeX and XeLaTeX you must use the fontspec package
(https://www.ctan.org/pkg/fontspec) to load otf or ttf fonts and add
opentype features. It is very powerful and its interface is very simple
to use. XeTeX has access to system fonts. LuaTeX has access to both
system fonts and any font you want to declare, simply by adding the
path.
For example:
\setmainfont{Palatino Linotype}[Ligatures=NoCommon,Numbers=Lowercase]
With LuaTeX you can also define new opentype features on the fly using
scripts in Lua, via the function fonts.handlers.otf.addfeature
For example, here I define a character substitution:
\directlua{
fonts.handlers.otf.addfeature{
name = "mysub",
type = "substitution",
data = {
periodcentered = "anoteleia",
},
}
}
And here I add that feature to Linux Libertine font:
\setmainfont{Linux Libertine O}[RawFeature=+mysub]
For multilingual management I recommend using Babel instead of
Polyglossia. You can, for example, assign with Babel families from fonts
and language definitions to non-Latin scripts (Cyrillic, Greek,
Devanagari, Arabic, etc.). For example
\babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
\babelfont[russian]{rm}[%
Numbers=Lowercase]{Linux Libertine O}
\babelfont[greek]{rm}[%
Numbers=Lowercase]{Old Standard}
Best regards,
Juan Manuel
Re: [O] What happened to ATTR_ORG?
Following up on this two years later ... I had some images that I wanted to shrink in my Org buffer, but #+attr_org: (setq org-image-actual-width nil) I had the variable set to t: "When non-nil, use the actual width of images when inlining them." There are a few other options, but nil does what I want: "When set to nil, try to get the width from an #+ATTR.* keyword and fall back on the original width if none is found." Bill On 25 May 2019, Cheong Yiu Fung wrote: I'm using the latest Org and it's working. If you'd like to dig the cause you might want to dig in `org-display-inline-images'. It accepts `:width' in any #+ATTR.*-like option, then immediately call `create-image'. I would guess it's an imagemagick problem too. steen writes: I am also having the same issue. I don't have time right now to try to track down causes, but this is not a unique problem. The behavior I am seeing is that #+ATTR_ORG no longer causes the images to be resized, they display at original size. -- Steen On Fri, May 24, 2019 at 8:34 AM John Kitchin wrote: I still use this. Do you see any issues in the Messages? If you try attr_latex does it work? If not you may have an imagemagick problem that can’t rescale the thumbnail. Note you will have to toggle the image display after you add that. On Fri, May 24, 2019 at 11:18 AM William Denton wrote: It used to be possible use ATTR_ORG on images to make them display at a different size, which was very useful when the images were large. It worked like this: #+ATTR_ORG: :width 300 [[file:very-large-image.jpg]] I haven't needed it for a while, but today I went to use it and it's gone! I grepped the source code, ORG-NEWS and the git log, but didn't see any mention of it. What happened? Did it go in version 9? Am I overlooking something? I feel like I've stepped into some parallel universe where everything is the same except this one Org command. Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: http://staplr.org/ -- John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: org-mode export to (latex) PDF
On 10/07/2021 23:44, Stefan Nobis wrote:
Maxim Nikulin writes:
(add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))
so I am unaware whether \usepackage[utf8x]{inputenc} has any drawbacks.
Do not do this. Both, utf8x and ucs, are obsolete and deprecated for
quite some time.
Maybe, I have seen such warnings. However I have tested neither utf8 nor
utf8x on real examples. That is why I am unaware what can be broken in
particular. For small examples with various symbols outside of ASCII,
utf8x may give better support.
Last time I did something serious with LaTeX, bibtex was 8bit internally
(unicode version had not reached stable Linux distributions, pybtex was
buggy), so that time I used 8bit charset.
For proper unicode support, switch from pdflatex to lualatex or
xelatex. With these newer backends (and proper adjustments for the
LaTeX preamble generated by Org) Unicode should work out of the box
(if the font supports the requested Unicode characters).
Maybe my expectation from proper unicode support was too optimistic. I
see the reason why preamble is necessary with 8bit encodings. I
appreciate possibility to easily specify particular ttf or otf font. I
do not like that it is necessary to specify *all* fonts, otherwise some
characters are missed or compilation fails with error. I do not know if
new engines allows to get list of available fonts and to choose a set of
fonts with better coverage than lmodern.
I have tried LuaLaTeX with the following file. From some examples I have
found, I expect, further tuning is required. Apparent problem is missed
unicode characters in math mode. I admit that polyglossia is unavoidable
for any real text but I do not like that \set…font commands are mandatory.
\documentclass{article}
\usepackage{fontspec}
\usepackage{polyglossia}
\setdefaultlanguage{russian}
\setotherlanguage{english}
\setmainfont{CMU Serif} % breaks ∞
\setsansfont{CMU Sans Serif}
\setmonofont{CMU Typewriter Text}
\begin{document}
Test¹ of superscript and ½ fraction.
\textbf{Теорема.} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.
\verb=Катет= и \textsf{гипотенуза}.
Åå. Text Greek α.
\end{document}
(setq org-latex-default-packages-alist
'(("AUTO" "inputenc" t ("pdflatex"))
("T1" "fontenc" t ("pdflatex"))
I just have realized that fontenc behavior should be similar to inputenc
and babel, e.g. something like \usepackage[T1,T2A]{fontenc} should be
used for Russian.
Re: [wip-cite-new] Merging tomorrow?
Is there a timeline for when this will be available in orgmode.org/elpa or
other package repository? I tried it today, but it doesn't seem to be there
yet, at least not in this version:
Org mode version 9.4.6 (9.4.6-10-gee652a-elpaplus @
/Users/jkitchin/Dropbox/emacs/scimax/elpa/org-plus-contrib-20210712/)
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Wed, Jul 7, 2021 at 8:18 PM Nicolas Goaziou
wrote:
> Hello,
>
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.
>
> It is documented, but the documentation is scattered across the various
> "oc" libraries, and some threads in the mailing list. I'll do a summary
> here, from a user point of view.
>
> --8<---cut here---start->8---
> Basically, in order to use it, you need to first set-up a bibliography,
> using one or more "bibliography" keywords. on such a keyword
> visits the related file. Out of the box, Org supports JSON-CSL and
> BibTeX (or biblatex) bibliographies.
>
> Then, citations can be inserted with the following syntax:
>
> [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
>
> Spaces are meaningful except those after the initial colon and before
> the closing bracket.
>
> Every part of the syntax is optional, except the brackets, "cite" and
> the colon. Also the citation must contain at least a key. So its minimal
> form is:
>
> [cite:@key]
>
> The "style" part is detailed below, in the part related to export.
>
> Org can insert or edit citations with (and delete them with
> ), follow them with , fontify them, and export
> them. These four actions (insert, follow, activate, and export) are
> called capabilities. Libraries responsible for these capabilities are
> called citation processors.
>
> You can select one citation processor for each capability, independently
> on the others, through the following variables:
>
> - org-cite-activate-processor
> - org-cite-export-processors
> - org-cite-follow-processor
> - org-cite-insert-processor
>
> Out of the box, Org provides the "basic" (in "oc-basic.el") processor
> for all of these tasks. It also boasts processors dedicated for export:
> "csl", "natbib" and "biblatex".
>
> During export, output for citations is controlled by their style, which
> is an Org label that the export processor may recognize and associate to
> a specific display, or fall-back to a default style (called "nil"). For
> example, most processors support "noauthor" and "text" styles.
>
> Some styles can accept a variant, with the syntax "style/variant".
> Again, it's up to the processor to associate it to a specific display.
> Common variants include "bare", "caps" or "full". They also accept
> short-hands, like "b", "c" and "f". Please refer to the export
> processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.
>
> It is possible to define a default style for a whole document (with
> "cite_export"), or for all documents (with `org-cite-export-processors').
>
> References are displayed with the "print_bibliography" keyword. It is
> possible to add parameters to its value, as some export processors could
> make use of them.
> --8<---cut here---end--->8---
>
> Please let me know if there are any objections to the merge.
>
> Regards,
> --
> Nicolas Goaziou
>
>
Re: [PATCH] Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On 7/13/21 4:55 AM, Carlo Tambuatco wrote: Newbie question: what command do I use to apply the patch…? I can tell you what worked for me. I think you probably need to have cloned org using git for it to work, but I am far from being a git wiz so there could be a workaround I don't know about in the case that you have it installed by a more conventional method. First, I saved the patch file to the same directory where I have org cloned (for me, that is ~/.emacs.d/straight/repos/org). Then I opened a terminal and ran: git apply --check 0001-Fix-duplicate-logbook-entry-for-repeated-tasks.patch to do a dry run and make sure I had saved the patch file in the right place that "git apply" would run correctly. It returned nothing, which is good, so then I ran: git apply --check 0001-Fix-duplicate-logbook-entry-for-repeated-tasks.patch to apply the patch. Since I'm using straight.el as my package manager, I then opened Emacs and ran "M-x straight-rebuild-all". Also, thanks to Ihor and Bhavin for your work on this. Prior to applying the patch, I was noticing new bizarre behavior relating to recurring tasks. I haven't been running the patched org very long yet, but so far, so good. Finally, as a newbie here myself, I have a naïve question of my own: Provided the patch proves successful, how/when is it applied to the official org repo? Is it up to Ihor (or somebody else) to make a pull request, for example? Best regards, Alan
Re: [BUG] org-goto slows down org-set-property
This link ( https://stackoverflow.com/questions/36926513/are-there-elisp-functions-that-list-markers-in-a-given-buffer) suggests there is not a good way to find all the markers associated with a buffer. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Jul 12, 2021 at 11:01 AM Maxim Nikulin wrote: > On 11/07/2021 23:00, Ihor Radchenko wrote: > > Maxim Nikulin writes: > > > >> Ihor, did you get that numbers using emacs -Q? If not, I suspect you may > >> have twice more markers in the buffer than `org-refile-get-targets' > >> usually generates. If my guess is correct it may be necessary to file a > >> bug that org-ql or some other package abuses markers by generation to > >> much of them. > > > > With emacs -Q things are twice better, though still not good enough: > ... > > org-ql might be one of the reasons of slowdown. Without it, the nm-tst > > after clearing the cache is slightly faster (was 13 sec): > > 13.8 - 10.1 = 3.7 that is comparable with "emacs -Q" that is 5.3. So > contribution of org-ql is not major one, but it is still significant. > > > However, markers are also created by agendas for example. The last > > result is also on fresh Emacs. Fresh Emacs tends to be faster in general. > > > > Do you know a good way to find out all the markers associated with a > buffer? > > I was going to ask you, but forgot to do it. Perhaps it is impossible by > design. > > (length org-agenda-markers) > > >
Influence the table separator in a code block
Hello, I'm using #+BEGIN_SRC sh code blocks and org-mode nicely renders the output as a table: #+BEGIN_SRC sh echo FIRST SECOND THIRD echo first second third #+END_SRC #+RESULTS: | FIRST | SECOND | THIRD | | first | second | third | And this is very nice. Unfortunately the autodetection breaks when any item contains a comma (,): #+BEGIN_SRC sh echo FIRST SECOND THIRD echo first second third,d #+END_SRC #+RESULTS: | FIRST SECOND THIRD | | | first second third | d | I tried to force org to use spaces by using "sep". Unfortunately this doesn't work: #+BEGIN_SRC sh :sep " " echo FIRST SECOND THIRD echo first second third,d #+END_SRC #+RESULTS: | FIRST SECOND THIRD | | | first second third | d | Is there a way to force org to split on spaces even when commas are in the output? Thank you in advance for help! Kind regards, Wiktor
