Put #+print_bibliography in an org source code block?
I don't know if this is crazy. But I was wondering if it is possible (or worth exploring as an idea) to turn #+print_bibliography into something that can be evaluated to throw the bibliography as results in the org file itself. This would then allow playing with the bibliography using org, and exporting it to any format. I tried to put #+print_bibliograph in an org source code block, but I guess it would need some way of picking up citations from the document outside the code block. Vikas
Re: Org not exporting blocks?
If you do emacs -Q, can you reproduce the issue? If not, then it is likely something in your init which is causing this. Also, what type of export are you attempting (i.e. PDF, ASCII, HTML etc) Devin Prater writes: > Okay, so I’ve got a strange problem. Whenever I have blocks, like > > #+begin_quote > text > #+end_quote > Or even > > #+begin_center > text > #+end_center > > These blocks aren’t converted through export. It just comes out as > > #+begin quote > text > #+end_quote > > And stuff like that. > > I did recently scrap my init file for Emacs when trying to get Emacspeak > sounds to work on Mac, but that should have /solved/ some problems, not > made more, lol. I also deleted and reinstalled Org from GNU Ella, and > installed the extra Org stuff from non-Gnu Elpa. > > So, are there any settings that control this kind of thing? Report from > org-report-bug below: > > —— > org-babel-after-execute-hook '(org-redisplay-inline-images) > org-html-checkbox-type 'html > org-texinfo-format-headline-function > 'org-texinfo-format-headline-default-function > org-metadown-hook '(org-babel-pop-to-session-maybe) > org-clock-out-hook '(org-clock-remove-empty-clock-drawer) > org-html-format-inlinetask-function > 'org-html-format-inlinetask-default-function > org-enforce-todo-dependencies t > org-odt-format-headline-function 'org-odt-format-headline-default-function > org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default > org-reveal-start-hook '(org-decrypt-entry) > org-export-with-section-numbers nil > org-modules '(ol-bbdb ol-bibtex ol-docview ol-eww ol-gnus ol-info ol-irc > ol-mhe ol-rmail org-tempo ol-w3m org-invoice) > org-blocker-hook '(org-block-todo-from-checkboxes >org-block-todo-from-children-or-siblings-or-parent) > org-export-creator-string "Emacs 27.2 (Org mode 9.4.4)" > org-html-divs '((preamble "aside" "preamble") (content "main" "content") > (postamble "aside" "postamble")) > org-mode-hook '(org-tempo-setup > #[0 > "\305\306 >\203 \307\n\310\311#\210\307\312\313#\210\307\314\315#\210\306 > >\203, \307\n\316\317#\210\307\n\320\321#\210\322 >\203>
Re: org-cite citation commands
This is very helpful already. Keenly looking forward to how this develops. Vikas On Sat, Jul 17, 2021 at 04:52:33PM -0400, John Kitchin wrote: > I made a video of my current org-cite setup at > https://www.youtube.com/watch?v= > 4ta4J20kpmM. You can also find a link to the code to run it in the description > there. > > I don't intend this to be a final video (it is still a little rough!), it is > just to help people see what I am thinking about for the future of org-ref, at > least as far as the citations go. > > 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
Re: [PATCH] ob-core: tangle check library of babel after current buffer
Tom Gillespie writes: > Pinging on this to see if anyone can test it so that it can be merged. > Tom I agree with this patch. Just to make clear the default behavior and the behavior that would exist with this patch. The current behavior 1. You have a code block C1 in a buffer B1. 2. You execute =org-babel-lob-ingest= on B1. This means that C1 now exists in =org-babel-library-of-babel=. 3. You modify C1. 4. You tangle a code block C2 which includes a noweb reference to C1. 5. The version of =org-babel-library-of-babel= would be used instead of the one from the current buffer. The behavior that would be available is (same steps) 5. The version of the current buffer is used instead. -- [[[ If you see a signature in spanish below this message, please omit it. It is automatically inserted in all my messages due to the internal privacy policies of the organization that owns the domain of my email address. ]]] -- La información contenida en este e-mail y sus anexos es confidencial, privilegiada y está dirigida exclusivamente a su destinatario, en consecuencia, solo puede ser utilizada por aquel. Si usted no es el destinatario original, no deberá examinar, usar, copiar o distribuir este mensaje o la información que contiene. Si lo recibe por error, por favor reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o uso total o parcial no autorizada de este mensaje está estrictamente prohibida y sancionada por ley.
Re: org-cite citation commands
I made a video of my current org-cite setup at https://www.youtube.com/watch?v=4ta4J20kpmM. You can also find a link to the code to run it in the description there. I don't intend this to be a final video (it is still a little rough!), it is just to help people see what I am thinking about for the future of org-ref, at least as far as the citations go. 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 Sat, Jul 17, 2021 at 10:44 AM Bruce D'Arcus wrote: > On Sat, Jul 17, 2021 at 10:20 AM Vikas Rawal wrote: > > > Thanks, Bruce and John. Indeed, I used biblatex with natbib=true > > option, which gives me citet and citep in biblatex. But using > > \autocite and \textcite is perfect. > > > > I am noticing a few other issues at this stage. > > > > I have a large biblatex database, and loading it using C-c C-x @ to > > insert citations seems very slow (have not managed to load it thus > > far). Org-ref used to be much faster in this. org-cite works fine with > > a smaller biblatex database. I don't know if others have had the same > > experience. > > Give this a try: > > https://github.com/bdarcus/bibtex-actions#org-cite > > I hope to see similar "insert processors" for ivy-bibtex and helm-bibtex. > > Bottomline, it's trivial to replace that "basic" processor with much > better options. > > See discussion on: > > https://github.com/jkitchin/org-ref/issues/885 > > > I understand that oc-biblatex.el loads biblatex in the background, > > produces the citations and the bibliography, and inserts them in the > > exported output. In that case, what are the possibilities of using > > biblatex commands to configure the output? > > To be precise, you mean what are the options to configure the > oc-biblatex export processor to use different or additional commands? > > ATM, I don't believe there are any, and the alternative is to write > your own export processor, say basing it off the oc-biblatex one. > > What, specifically, do you need, that is not currently supported? > > The current processors are pretty comprehensive; see the note from Andras. > > When designing this sort of thing, you basically have a choice. > > You can just have styles that map directly to the output targets. > > This has an obvious advantage if you only ever use one target. > > But it has a major disadvantage if you want to use others. > > So the approach we took here is to design a common set of styles and > substyles, and then map to output formats from there. > > The result is the citations are more-or-less export format agnostic. > > > I realise that these will > > not work since most of it would be LaTeX specific. Does that mean the > > users will have to work with CSL styles to format the output even if > > they are using oc-biblatex.el? I am still somewhat confused about how > > this is going to work. > > CSL styles are analogous to BST files in bibtex; you use those with oc-csl. > > When using that, citeproc-el handles the output processing, including for > latex. > > Basically, if you want consistent output formatting across latex and > other targets like HTML or OpenDocument, you want to use oc-csl. > > Give it a try. > > Note, though, that citeproc-el does not currently support cite/t or > some others, but that should be coming "soon". > > HTH; let me know if anything is unclear. > > Bruce >
Re: [PATCH] ob-core: tangle check library of babel after current buffer
Tom Gillespie writes: > Pinging on this to see if anyone can test it so that it can be merged. > Tom > > On Wed, Jun 16, 2021 at 4:29 PM Tom Gillespie wrote: >> >> Hi, >>This is a patch that fixes tangling behavior when a block has been >> ingested into the library of babel and then modified. Best! >> Tom > > I have not tested it but I reviewed the code and it looks good to me. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: [PATCH] ob-core: tangle check library of babel after current buffer
Pinging on this to see if anyone can test it so that it can be merged. Tom On Wed, Jun 16, 2021 at 4:29 PM Tom Gillespie wrote: > > Hi, >This is a patch that fixes tangling behavior when a block has been > ingested into the library of babel and then modified. Best! > Tom
Re: org-cite citation commands
Thanks. This is very useful.
Vikas
On Sat, Jul 17, 2021 at 03:55:18PM +0200, András Simonyi wrote:
> Dear Vikas,
>
> the CSL-based processor is in a bit of a flux in this respect, but as
> for the natbib and biblatex processors I've extracted these
> correspondences from the oc source code, which you might find useful.
> (With the exception of the first, "fully nil" styles, one always has
> to use the "/" separator between "cite" and the listed combinations,
> for the default styles this means a double slash, e.g., [cite//b@key]
> leads to \citealp{key} using the natbib processor.
>
> * Natbib
>
> ;; default style.
> --> \citep
> / [bare|b] --> \citealp
> / [caps|c] --> \Citep
> / [full|f] --> \citep*
> / [bare-caps|bc]--> \Citealp
> / [bare-full|bf]--> \citealp*
> / [caps-full|cf]--> \Citep*
> / [bare-caps-full|bcf] --> \Citealp*
>
> ;; author style.
> [author|a] / [caps|c] --> \Citeauthor
> [author|a] / [full|f] --> \citeauthor*
> [author|a] --> \citeauthor
>
> ;; noauthor style
> [noauthor|na] / [bare|b]--> \citeyear
> [noauthor|na] --> \citeyearpar
>
> ;; nocite style.
> [nocite|n] --> \nocite
>
> ;; text style.
> [text|t] / [bare|b] --> \citealt
> [text|t] / [caps|c] --> \Citet
> [text|t] / [full|f] --> \citet*
> [text|t] / [bare-caps|bc] --> \Citealt
> [text|t] / [bare-full|bf] --> \citealt*
> [text|t] / [caps-full|cf] --> \Citet*
> [text|t] / [bare-caps-full|bcf] --> \Citealt*
> [text|t]--> \citet
>
> * biblatex
>
> ;; Default nil style.
> --> autocite
> / [bare|b]--> cite
> / [caps|c]--> Autocite
> / [bare-caps|b] --> Cite
>
> ;; author style.
> [author|a] / [caps|c])--> Citeauthor*
> [author|a] / [full|f])--> citeauthor
> [author|a] / [caps-full|cf] --> Citeauthor
> [author|a]--> citeauthor*
>
> ;; locators style.
> [locators|l] / [bare|b] --> notecite
> [locators|l] / [caps|c] --> Pnotecite
> [locators|l] / [bare-caps|bc] --> Notecite
> [locators|l] --> pnotecite
>
> ;; noauthor style.
> [noauthor|na] --> autocite*
>
> ;; nocite style.
> [nocite|n]--> nocite
>
> ;; text style.
> [text|t] / [caps|c]) --> Textcite
> [text|t] --> textcite
>
> best regards,
> András
>
>
> On Sat, 17 Jul 2021 at 13:41, Vikas Rawal wrote:
> >
> > I have been a long time user of org-ref and am excited to see the
> > development of org-cite. Thanks a lot for this, Nicholas and others
> > who have been working on this. I have been wanting to give it a spin
> > for the last few days and finally got down to doing it.
> >
> > I am aware that the documentation is still in the works and therefore
> > my apologies in advance if asking these questions is premature. I have
> > looked at Nicholas' mails which provide basic documentation and have
> > been trying to follow these.
> >
> > What is the equivalent here of the various citation commands that something
> > like biblatex or bibtex provide? The two most common citation commands I
> > use are citet and citep (or parencite). These are used to produce the
> > following kind of output using org-ref/biblatex:
> >
> >
> > -
> > * citet
> >
> > citet:john is an excellent resource.
> >
> > will be exported as:
> >
> > John (1990) is an excellent resource.
> >
> > * citep
> >
> > This is an excellent resource citep:john.
> >
> > will be exported as
> >
> > This is an excellent resource (John, 1990).
> >
> >
> >
> > How does one achieve this using org-cite?
> >
> > I am a bit lost with the citation styles that are inbuilt in
> > oc-biblatex.el. Is it expected that we will have to write additional
> > citation styles for getting these kinds of output?
> >
> > Apologies if this is a naive or a premature question.
> >
> > Many thanks to everyone.
> >
> > Vikas
> >
>
Re: org-cite citation commands
On Sat, Jul 17, 2021 at 10:20 AM Vikas Rawal wrote: > Thanks, Bruce and John. Indeed, I used biblatex with natbib=true > option, which gives me citet and citep in biblatex. But using > \autocite and \textcite is perfect. > > I am noticing a few other issues at this stage. > > I have a large biblatex database, and loading it using C-c C-x @ to > insert citations seems very slow (have not managed to load it thus > far). Org-ref used to be much faster in this. org-cite works fine with > a smaller biblatex database. I don't know if others have had the same > experience. Give this a try: https://github.com/bdarcus/bibtex-actions#org-cite I hope to see similar "insert processors" for ivy-bibtex and helm-bibtex. Bottomline, it's trivial to replace that "basic" processor with much better options. See discussion on: https://github.com/jkitchin/org-ref/issues/885 > I understand that oc-biblatex.el loads biblatex in the background, > produces the citations and the bibliography, and inserts them in the > exported output. In that case, what are the possibilities of using > biblatex commands to configure the output? To be precise, you mean what are the options to configure the oc-biblatex export processor to use different or additional commands? ATM, I don't believe there are any, and the alternative is to write your own export processor, say basing it off the oc-biblatex one. What, specifically, do you need, that is not currently supported? The current processors are pretty comprehensive; see the note from Andras. When designing this sort of thing, you basically have a choice. You can just have styles that map directly to the output targets. This has an obvious advantage if you only ever use one target. But it has a major disadvantage if you want to use others. So the approach we took here is to design a common set of styles and substyles, and then map to output formats from there. The result is the citations are more-or-less export format agnostic. > I realise that these will > not work since most of it would be LaTeX specific. Does that mean the > users will have to work with CSL styles to format the output even if > they are using oc-biblatex.el? I am still somewhat confused about how > this is going to work. CSL styles are analogous to BST files in bibtex; you use those with oc-csl. When using that, citeproc-el handles the output processing, including for latex. Basically, if you want consistent output formatting across latex and other targets like HTML or OpenDocument, you want to use oc-csl. Give it a try. Note, though, that citeproc-el does not currently support cite/t or some others, but that should be coming "soon". HTH; let me know if anything is unclear. Bruce
Re: org-mode export to (latex) PDF
Hi Maxim,
I think the problem is not the fact that I may be inclined towards book
typesetting but that TeX itself and its workflow is inclined towards
book typesetting. This fact is something that must be taken into account
and that many LaTeX users sometimes forget. The concept of a 'fallback
font' is still something exotic for the TeX working method, despite that
LuaTeX can access TeX primitives using scripting in lua and can achieve
things like that, at the cost of resources. For example, the fontspec
package provides the conditional \IfFontExists{font}{True code}{False
code} which consumes a lot of resources.
Anyway, I would dare to recommend these two possibilities:
a) If you want to define a list of fallback fonts for the LaTeX
process, IMHO should be done org-centric with Elisp (something for
pdfTeX, XeTeX and LuaTeX. I'm afraid this would be a lot of work and too
much cholesterol for Org Mode, though).
b) However, my preference is something that has already been comented in
this thread: add to the documentation (or to Worg web site) a (not too
long) list of recommended fonts for different languages: of course,
fonts that are freely licensed and accessible to everyone. In any
collaborative work in LaTeX I find it's much more simple to share an
easily accessible and free (as in freedom) font than to add a list of
fallback fonts to the documents via code (a true bloat for TeX). The
LaTeX Font Catalogue includes lots of very good quality fonts. For
example, TeX Live includes an excellent font with support for Greek,
Cyrillic and Linguistics: Old Standard, originally designed by prof.
Alexey Kryukov and currently maintained by Robert Alessi:
https://www.ctan.org/pkg/oldstandard (I don't work on Cyrillic and I can
not comment on that aspect: I use this font more for Greek; but it is
often said that Old Standard is one of the best and most documented
options to represent Cyrillic).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> On 17/07/2021 01:34, Juan Manuel Macías wrote:
>> Maxim Nikulin writes:
>>
>>> I think that low level implementation in browser or in some underlying
>>> library is much faster
>>>
>>>
>>>LM Roman 12
>>>abc абв…с
>>>LM Roman 12, CMU Serif
>>>abc абв…с
>>>
>> They are two different scenarios: web publishing and book
>> typesetting
>
> Juan Manuel, it seems you are too inclined to book typesetting. It is
> important case and it should be supported by org. I have repeated two
> times in this thread that there is another case, namely routine quick
> notes. Such documents have another balance concerning time required to
> get acceptable result. TeX takes responsibility for a lot of defaults
> such as what spaces should be added around "=" and what ones around
> right angle bracket. Users do not need to make decisions concerning
> such design details to get accurately typeset equations.
>
> At the age of custom charsets (often 8bit) and encodings the problem
> of multilingual texts was obvious. Unicode and UTF-8 alleviate many
> issues. It happened that Cyrillic is an edge case for Unicode TeX
> engines. Since ~2000 it works out of the box for LaTeX and PdfLaTeX.
> Last years I did not need to adjust config files and regenerate
> formats. Hyphenation, default fonts (OK, "apt install cm-super" to
> avoid rasterized fonts is a bit behind defaults though no manual
> config is required) just work. Each document needs a few universal
> lines to setup Russian. Some users may have specific style files but
> generally source documents are quite portable.
>
> Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
> Every user have to do a decision which fonts should be used even if
> one does not care concerning particular fonts. It increases
> probability to get a file with font configuration that is specific to
> Mac or Windows.
>
> I do not actively use characters from other Unicode planes, however
> sometimes I do it for fun. Getting them completely missing is less
> preferred than displaying them with low quality font. Specifying all
> fonts requires lengthy config, probably different for LuaTeX and
> XeTeX. At first it is necessary to realize which fonts are available
> for particular glyph. Finally it makes *source* document less
> portable.
>
> "font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
> what I consider relatively high-level config for routine documents
> that do not need to be handcrafted. Unavailable glyph or even font is
> not an error, it just causes lookup of candidates in the following
> items. For TeX maybe it is reasonable to consider fallback to complete
> set of fonts at ones (roman + mono + math) if such combination is
> available.
>
>> If I want to use the GFS Porson as italics from
>> another font, a Didot typeface for example, I can do this:
>
> If it is not a book or at the stage of early draft another scenario is
> possible. Text should just appear in the compiled
Re: org-cite citation commands
Thanks, Bruce and John. Indeed, I used biblatex with natbib=true option, which gives me citet and citep in biblatex. But using \autocite and \textcite is perfect. I am noticing a few other issues at this stage. I have a large biblatex database, and loading it using C-c C-x @ to insert citations seems very slow (have not managed to load it thus far). Org-ref used to be much faster in this. org-cite works fine with a smaller biblatex database. I don't know if others have had the same experience. I understand that oc-biblatex.el loads biblatex in the background, produces the citations and the bibliography, and inserts them in the exported output. In that case, what are the possibilities of using biblatex commands to configure the output? I realise that these will not work since most of it would be LaTeX specific. Does that mean the users will have to work with CSL styles to format the output even if they are using oc-biblatex.el? I am still somewhat confused about how this is going to work. I notice that there is an option org-cite-biblatex-options which can be customized to load biblatex with specific options. I have not yet managed to test it. If somebody has already played around with it, it would be useful to know what they could manage to do. In my experience, biblatex and bibtex uniformly process the author names whether they are written in the database file as "John Kitchin" or "Kitchin, John". This does not seem to work with oc-biblatex.el at least out of the box and the two are formatted differently. Thanks again, Vikas
Re: org-cite citation commands
Dear Vikas,
the CSL-based processor is in a bit of a flux in this respect, but as
for the natbib and biblatex processors I've extracted these
correspondences from the oc source code, which you might find useful.
(With the exception of the first, "fully nil" styles, one always has
to use the "/" separator between "cite" and the listed combinations,
for the default styles this means a double slash, e.g., [cite//b@key]
leads to \citealp{key} using the natbib processor.
* Natbib
;; default style.
--> \citep
/ [bare|b] --> \citealp
/ [caps|c] --> \Citep
/ [full|f] --> \citep*
/ [bare-caps|bc]--> \Citealp
/ [bare-full|bf]--> \citealp*
/ [caps-full|cf]--> \Citep*
/ [bare-caps-full|bcf] --> \Citealp*
;; author style.
[author|a] / [caps|c] --> \Citeauthor
[author|a] / [full|f] --> \citeauthor*
[author|a] --> \citeauthor
;; noauthor style
[noauthor|na] / [bare|b]--> \citeyear
[noauthor|na] --> \citeyearpar
;; nocite style.
[nocite|n] --> \nocite
;; text style.
[text|t] / [bare|b] --> \citealt
[text|t] / [caps|c] --> \Citet
[text|t] / [full|f] --> \citet*
[text|t] / [bare-caps|bc] --> \Citealt
[text|t] / [bare-full|bf] --> \citealt*
[text|t] / [caps-full|cf] --> \Citet*
[text|t] / [bare-caps-full|bcf] --> \Citealt*
[text|t]--> \citet
* biblatex
;; Default nil style.
--> autocite
/ [bare|b]--> cite
/ [caps|c]--> Autocite
/ [bare-caps|b] --> Cite
;; author style.
[author|a] / [caps|c])--> Citeauthor*
[author|a] / [full|f])--> citeauthor
[author|a] / [caps-full|cf] --> Citeauthor
[author|a]--> citeauthor*
;; locators style.
[locators|l] / [bare|b] --> notecite
[locators|l] / [caps|c] --> Pnotecite
[locators|l] / [bare-caps|bc] --> Notecite
[locators|l] --> pnotecite
;; noauthor style.
[noauthor|na] --> autocite*
;; nocite style.
[nocite|n]--> nocite
;; text style.
[text|t] / [caps|c]) --> Textcite
[text|t] --> textcite
best regards,
András
On Sat, 17 Jul 2021 at 13:41, Vikas Rawal wrote:
>
> I have been a long time user of org-ref and am excited to see the
> development of org-cite. Thanks a lot for this, Nicholas and others
> who have been working on this. I have been wanting to give it a spin
> for the last few days and finally got down to doing it.
>
> I am aware that the documentation is still in the works and therefore
> my apologies in advance if asking these questions is premature. I have
> looked at Nicholas' mails which provide basic documentation and have
> been trying to follow these.
>
> What is the equivalent here of the various citation commands that something
> like biblatex or bibtex provide? The two most common citation commands I use
> are citet and citep (or parencite). These are used to produce the following
> kind of output using org-ref/biblatex:
>
>
> -
> * citet
>
> citet:john is an excellent resource.
>
> will be exported as:
>
> John (1990) is an excellent resource.
>
> * citep
>
> This is an excellent resource citep:john.
>
> will be exported as
>
> This is an excellent resource (John, 1990).
>
>
>
> How does one achieve this using org-cite?
>
> I am a bit lost with the citation styles that are inbuilt in oc-biblatex.el.
> Is it expected that we will have to write additional citation styles for
> getting these kinds of output?
>
> Apologies if this is a naive or a premature question.
>
> Many thanks to everyone.
>
> Vikas
>
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/)]
Alan Ristow writes: > 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? An email with [PATCH] in header is the pull request for Org :) You can see a list of patches, confirmed bugs, and help requests in https://updates.orgmode.org/ The emails replying to the patch email are the comments to the pull request. The merge is up to Org maintainers. They patches are reviewed and merged as the maintainers get some free time to do it. Best, Ihor
Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Bhavin Gandhi writes: > I was trying to understand your change. So, when we call > `org-agenda-todo', it calls `org-todo' which adds the > post-command-hook. This hook is supposed to run when `org-agenda-todo' > finishes, but instead of that we call it directly. This makes sure that > the change is recorded in `buffer-undo-list'. You are almost correct. To be able to use undo from agenda, we must have all the changes happen inside org-with-remote-undo body. Only then the changes are recorded into agenda's buffer `buffer-undo-list'. post-command-hook, if ran after `org-agenda-todo', will only record changes in the actual org buffer's `buffer-undo-list', but not inside the agenda's `buffer-undo-list'. > Sorry if that's too much to ask, but why don't we need something similar > when org-log-note-how is 'note? Can you please help me understand that? > I tried reading org-add-log-note and org-store-log-note, but I think I'm > missing something basic here. AFAIK, it is quite hard to do with current log note implementation. `org-add-log-note' itself does not record the note text. Instead, it only creates and pre-populates the note buffer and returns the control to the function calling `org-add-log-note'. Regardless where we call `org-add-log-note', the actual note text will only be added to the org buffer when the user presses C-c C-c in the note buffer. And the user input will only be possible after the current command (in our case `org-agenda-todo') finishes. Thus, user note will always be added outside `org-with-remote-undo' and cannot be recorded by agenda. IMHO, the proper way to handle this would be rewriting the log-note code using recursive editing. But that's not a trivial change and should be implemented in a separate patch. > Also, should this line from org.el (org-store-log-note) be removed? > > ;; Don't add undo information when called from `org-agenda-todo'. I think so. It appears to be irrelevant to current state of the code. Someone forgot to remove this comment in one of the past patches. But removing the comment should be a separate patch itself. Best, Ihor
Re: [oc] use-package config question
"Bruce D'Arcus" writes: > Could someone with some expertise in this area recommend how I do the > following? > > Load org-cite and it's associated packages (oc-basic, oc-natbib, > etc.), and set some associated variables, if org-cite is available. It should be default behaviour: (use-package oc ;; The code inside will be executed only and only if the `oc' feature is ;; available. ;; To be 100% sure you can use ;; :ensure nil ... ) See https://github.com/jwiegley/use-package#package-installation for more details. Best, Ihor
Re: org-cite citation commands
We were posting at the same time :-) On Sat, Jul 17, 2021 at 8:39 AM John Kitchin wrote: > There is not currently a way to get \citet and \citep with the biblatex > backend. Yes, but \autocite andt \textcite produce the expected output, and have the advantage they are independent of output format. As in, the current behavior will work in an author-date style or a note-based one. So [cite:@key] and [cite/t:@key] should produce the expected output in both biblatex and natbib. Bruce
Re: org-cite citation commands
On Sat, Jul 17, 2021 at 7:41 AM Vikas Rawal wrote: > What is the equivalent here of the various citation commands that something > like biblatex or bibtex provide? The two most common citation commands I use > are citet and citep (or parencite). These are used to produce the following > kind of output using org-ref/biblatex: > > > - > * citet cite/t > * citep cite (no style; it's default) > I am a bit lost with the citation styles that are inbuilt in oc-biblatex.el. > Is it expected that we will have to write additional citation styles for > getting these kinds of output? No; there is already extensive style support, that works consistently across the different export processors. E.g. cite/t will produce the same output in natbib and biblatex (and very soon, csl). You can see the draft mapping of style here, though I need to update it. https://github.com/bdarcus/bibtex-actions/wiki/Org-cite Bruce
Re: org-cite citation commands
It sounds like you use natbib/bibtex (citet/citep are natbib commands I
think). In that case, my current understanding is that these are the
syntaxes for what you want, with the natbib exporter selected.
[cite:@key] -> \citep{key}
[cite/t:@key] -> \citet{key}
But, if you use the biblatex backend, these map to
[cite:@key] -> \autocite{key}
[cite/t:@key] -> \textcite{key}
There is not currently a way to get \citet and \citep with the biblatex
backend.
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 Sat, Jul 17, 2021 at 7:41 AM Vikas Rawal wrote:
> I have been a long time user of org-ref and am excited to see the
> development of org-cite. Thanks a lot for this, Nicholas and others
> who have been working on this. I have been wanting to give it a spin
> for the last few days and finally got down to doing it.
>
> I am aware that the documentation is still in the works and therefore
> my apologies in advance if asking these questions is premature. I have
> looked at Nicholas' mails which provide basic documentation and have
> been trying to follow these.
>
> What is the equivalent here of the various citation commands that
> something like biblatex or bibtex provide? The two most common citation
> commands I use are citet and citep (or parencite). These are used to
> produce the following kind of output using org-ref/biblatex:
>
>
> -
> * citet
>
> citet:john is an excellent resource.
>
> will be exported as:
>
> John (1990) is an excellent resource.
>
> * citep
>
> This is an excellent resource citep:john.
>
> will be exported as
>
> This is an excellent resource (John, 1990).
>
>
>
> How does one achieve this using org-cite?
>
> I am a bit lost with the citation styles that are inbuilt in
> oc-biblatex.el. Is it expected that we will have to write additional
> citation styles for getting these kinds of output?
>
> Apologies if this is a naive or a premature question.
>
> Many thanks to everyone.
>
> Vikas
>
>
Re: org-mode export to (latex) PDF
On 17/07/2021 01:34, Juan Manuel Macías wrote:
Maxim Nikulin writes:
I think that low level implementation in browser or in some underlying
library is much faster
LM Roman 12
abc абв…с
LM Roman 12, CMU Serif
abc абв…с
They are two different scenarios: web publishing and book typesetting
Juan Manuel, it seems you are too inclined to book typesetting. It is
important case and it should be supported by org. I have repeated two
times in this thread that there is another case, namely routine quick
notes. Such documents have another balance concerning time required to
get acceptable result. TeX takes responsibility for a lot of defaults
such as what spaces should be added around "=" and what ones around
right angle bracket. Users do not need to make decisions concerning such
design details to get accurately typeset equations.
At the age of custom charsets (often 8bit) and encodings the problem of
multilingual texts was obvious. Unicode and UTF-8 alleviate many issues.
It happened that Cyrillic is an edge case for Unicode TeX engines. Since
~2000 it works out of the box for LaTeX and PdfLaTeX. Last years I did
not need to adjust config files and regenerate formats. Hyphenation,
default fonts (OK, "apt install cm-super" to avoid rasterized fonts is a
bit behind defaults though no manual config is required) just work. Each
document needs a few universal lines to setup Russian. Some users may
have specific style files but generally source documents are quite portable.
Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
Every user have to do a decision which fonts should be used even if one
does not care concerning particular fonts. It increases probability to
get a file with font configuration that is specific to Mac or Windows.
I do not actively use characters from other Unicode planes, however
sometimes I do it for fun. Getting them completely missing is less
preferred than displaying them with low quality font. Specifying all
fonts requires lengthy config, probably different for LuaTeX and XeTeX.
At first it is necessary to realize which fonts are available for
particular glyph. Finally it makes *source* document less portable.
"font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
what I consider relatively high-level config for routine documents that
do not need to be handcrafted. Unavailable glyph or even font is not an
error, it just causes lookup of candidates in the following items. For
TeX maybe it is reasonable to consider fallback to complete set of fonts
at ones (roman + mono + math) if such combination is available.
If I want to use the GFS Porson as italics from
another font, a Didot typeface for example, I can do this:
If it is not a book or at the stage of early draft another scenario is
possible. Text should just appear in the compiled document, particular
font does not matter, its choice is postponed since text content has
higher priority. Minimal setup in invaluable.
At least with minimal examples I faced another issue: characters
silently disappears, no warning is generated. Adding babel changes it,
but I still believe that especially for documents with carefully chosen
fonts. It is a serious hidden error to get "invalid char glyph" instead
of all missed characters.
[1] If you want to have fallback fonts, you can also do it in
LuaTeX by adding some Lua code:
https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
Would you recommend such code as default for Org? Let's assume that some
information concerning system fonts are available. I suspect, the
accepted answer is not fool-proof. In addition, XeLaTeX requires
something different.
luaotfload provides fallback feature close to what I expect, however it
is necessary to explicitly specify script that I would prefer to avoid.
Moreover it significantly increases compilation time. Sometimes LuaLaTeX
starts to eat CPU with no progress, emoji does not work for some reason.
I am unsure concerning particular "Noto Sans CJK" since several ones are
available.
\documentclass{article}
\usepackage{fontspec}
\usepackage{unicode-math}
\directlua{luaotfload.add_fallback
("seriffallback",
{
"Noto Serif CJK SC:mode=harf;script=sc;",
"file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
})
}
% TwemojiMozilla is not shown by viewers, visible in pdftotext
%"Noto Color Emoji:mode=harf;"
% or
%"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
% % ! error: (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf)
(ttf): loca
% table not found
% ! ==> Fatal error occurred, no output PDF file produced!
\setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]
\directlua{luaotfload.add_fallback
("sansfallback",
{
"Noto Sans CJK SC:mode=harf;script=sc;",
org-cite citation commands
I have been a long time user of org-ref and am excited to see the development of org-cite. Thanks a lot for this, Nicholas and others who have been working on this. I have been wanting to give it a spin for the last few days and finally got down to doing it. I am aware that the documentation is still in the works and therefore my apologies in advance if asking these questions is premature. I have looked at Nicholas' mails which provide basic documentation and have been trying to follow these. What is the equivalent here of the various citation commands that something like biblatex or bibtex provide? The two most common citation commands I use are citet and citep (or parencite). These are used to produce the following kind of output using org-ref/biblatex: - * citet citet:john is an excellent resource. will be exported as: John (1990) is an excellent resource. * citep This is an excellent resource citep:john. will be exported as This is an excellent resource (John, 1990). How does one achieve this using org-cite? I am a bit lost with the citation styles that are inbuilt in oc-biblatex.el. Is it expected that we will have to write additional citation styles for getting these kinds of output? Apologies if this is a naive or a premature question. Many thanks to everyone. Vikas
Re: Bug: Unable to resolve link when exporting subtree [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/kun/.emacs.d/elpa/org-plus-contrib-20210712/)]
out of curiosity, what did you expect would happen? To me, this seems like correct/expected behaviour as there is no way to resolve that link. (I'm wondering if there is something wrong or missing in the manual which has given a different expectation?) Regards, -- *Tim Cross* /For gor sake stop laughing, this is serious!/
Re: Bug: Unable to resolve link when exporting subtree [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/kun/.emacs.d/elpa/org-plus-contrib-20210712/)]
Kun Liu writes: > I see error > user-error: Unable to resolve link: "*B" This is expected default behaviour. You can customise it using org-export-with-broken-links. Best, Ihor
