Re: interaction of fontified calendar entries and org-read-date
Awesome work! Thanks for tracking that down! On Wed, Feb 21, 2024 at 6:17 AM Ihor Radchenko wrote: > John Kitchin writes: > > > However, if I edebug `calendar-make-temp-face' and step through each > line, > > then it works the same as using a face. And, after that it seems to work > > most of the time. > > It turned out that the problem is caused by interaction between Org > mode's overlay and calendar.el's overlay. They have the same priority, > so the order they are applied depends on subtle details of the code and > on when redisplay occurs. > That's why edebug yielded different results. > > See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69271 > > I fixed this subtle issue on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67d937248 > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: interaction of fontified calendar entries and org-read-date
Thanks for the tip on `calendar-make-temp-face'. It gets even weirder now. If I use a face, that function does not even seem to get called, so it seems to work. If I use the anonymous face though, it does get called, and I see the inconsistent behavior. However, if I edebug `calendar-make-temp-face' and step through each line, then it works the same as using a face. And, after that it seems to work most of the time. "Do not call this directly from Lisp code; use ‘defface’ instead." seems like a weird message. Where else would one use this? Anyway, thanks again, I have stumbled on a solution, which is to modify `calendar-mark-visible-date' so it does not use `calendar-make-temp-face' . It is a small change of: (t ; attr list (overlay-put (make-overlay (1- (point)) (1+ (point))) 'face (calendar-make-temp-face mark))) to (t ; attr list (overlay-put (make-overlay (1- (point)) (1+ (point))) 'face mark)) That seems to work. A simpler way though is to just put the overlays on manually in the hook, e.g. (let* ((mark-calendar (lambda () ;; Goto today (save-excursion (calendar-cursor-to-visible-date (read (format-time-string "(%m %d %Y)"))) (overlay-put (make-overlay (1- (point)) (1+ (point))) 'face (list :foreground "blue" :weight 'bold) (calendar-today-visible-hook)) (add-hook 'calendar-today-visible-hook mark-calendar) (org-read-date)) I can live with that solution. Thanks for the assist! On Wed, Feb 14, 2024 at 3:14 PM Ihor Radchenko wrote: > John Kitchin writes: > > > why does it work with a face though? > > It really does. That's confusing. And proves that Emacs is smart enough > to invert cursor color in some situations. > > My only guess is that `calendar-make-temp-face' is using `make-face' > incorrectly. I guess that > > Do not call this directly from Lisp code; use `defface' instead. > > in `make-face' docstring is there for a reason. > Maybe report this as Emacs bug in calendar.el? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: interaction of fontified calendar entries and org-read-date
why does it work with a face though? On Wed, Feb 14, 2024 at 10:00 AM Ihor Radchenko wrote: > John Kitchin writes: > > > This slightly different code (differs only in assigning an anonymous face > > instead of an actual face doesn't do that exactly. Today is still marked > > red, but it is no longer selected with the inverse square. Neighboring > days > > do get the red square, but not "today". > > > > (let* ((mark-calendar (lambda () > > (calendar-mark-visible-date > > (read (format-time-string "(%m %d %Y)")) > > (list :foreground "red" :weight 'bold > >(calendar-today-visible-hook)) > > (add-hook 'calendar-today-visible-hook > >mark-calendar) > > (org-read-date)) > > That's because cursor background becomes the same as text foreground and > Emacs prevents the clash. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
interaction of fontified calendar entries and org-read-date
I am trying to debug something in org-read-date. If I run this code: (let* ((mark-calendar (lambda () (calendar-mark-visible-date (read (format-time-string "(%m %d %Y)")) 'font-lock-warning-face))) (calendar-today-visible-hook)) (add-hook 'calendar-today-visible-hook mark-calendar) (org-read-date)) I get a little calendar that pops up, today is marked red, and there is a red square on it. I can use shift arrows to move the red box around so i can see what day is selected. This slightly different code (differs only in assigning an anonymous face instead of an actual face doesn't do that exactly. Today is still marked red, but it is no longer selected with the inverse square. Neighboring days do get the red square, but not "today". (let* ((mark-calendar (lambda () (calendar-mark-visible-date (read (format-time-string "(%m %d %Y)")) (list :foreground "red" :weight 'bold (calendar-today-visible-hook)) (add-hook 'calendar-today-visible-hook mark-calendar) (org-read-date)) This is somewhat of an xy kind of question. I am writing code that sets the color of a day based on the number of tasks due that day, so I can't exactly define faces for all of those, and I was using the anonymous face for that. However, in doing that I lost the inverse video selection cursor so it is hard to tell where the cursor actually is. I assume that somewhere the cursor is getting an inverse-video attribute from the face that isn't present in the anonymous face, but I haven't been able to figure out where that comes in. Any suggestions for either how to fix this, or another approach to coloring the days in the calendar? -- John ------- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: What do you recommend for acronyms in org-mode?
It is hard to say what the issue is without some working example that shows performance issues. Usually getting better performance means compromising some functionality, e.g. not validating citation keys (this requires some lookup which could take time for large documents/bibtex files), etc. There are several org-ref-activate-*-links that turn font-lock on and off for different links. org-ref does use some caches, and if these are invalidated frequently, e.g. by frequently adding new bibtex entries, they have to be rebuilt, which can also take some time. Some of this is controlled by bibtex-completion though. On Sat, Aug 26, 2023 at 9:01 PM Maske wrote: > Hi John! > > I was using org-ref some time ago, but it seemed to get emacs slower, in > my low resources PC. > > Would you give me some tips to make org-ref lighter? > > Best regards > > 27 ago 2023 2:33:05 John Kitchin : > > You can see how these work in org-ref in this video: > https://www.youtube.com/watch?v=sebs2vSIEk4=PL0sMmOaE_gs3E0OjExoI7vlCAVygj6S4I=13. > > > On Sat, Aug 26, 2023 at 1:21 PM Maske wrote: > >> I would like to know what do you use for acronyms, glossaries, etc for >> using inside org-mode? Not for exportation, just to use them inside Emacs. >> >> Maybe radio links, or the package org-glossary? org-ref? >> >> Best regards >> > > > -- > John > > --- > Professor John Kitchin (he/his) > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > https://kitchingroup.cheme.cmu.edu > https://pointbreezepubs.gumroad.com/ pycse bookstore > > -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
adding rules for flyspell
I use flyspell, and it looks like org-mode sets flyspell-generic-check-word-predicate to be org-mode-flyspell-verify. I have a few places I would like to augment this to avoid flyspell overlays in different places. In the past I have done this with around advice, which was ok for one rule, but less desirable for many rules. does anyone do anything clever here? I am currently making a list of predicate functions, and a generic function that runs each one, but I wondered if there was another approach. thanks. -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: org-ref-helm-insert-ref-link and latex src blocks
I think you can't use an org-link in a latex src block. You should probably
use \eqref{eq:test:2} (probably typed manually). org-ref is not currently
clever enough to do that automatically when you inserting in a latex src
block.
On Tue, May 30, 2023 at 5:29 AM Uwe Brauer wrote:
> Hi
>
> Please look at the following lines
> eqref:eq:test:1 has been inserted with org-ref-helm-insert-ref-link
> it is correctly exported to latex.
>
>
> \begin{equation}
> \label{eq:test:1}
> \int
> \end{equation}
> eqref:eq:test:1
>
>
> However the same reference in a latex src block is not correctly supported
>
>
> #+begin_src latex :results latex replace :exports results :eval t
> \begin{equation}
> \label{eq:test:2}
>
> \end{equation}
> eqref:eq:test:2
> #+end_src
>
>
> There is some logic to it, however when I use org-edit-special
> to deal with the reference reftex-reference does do work, but gives the
> error
>
> ,
> | Debugger entered--Lisp error: (error "RefTeX works only in buffers
> visiting a file")
> | signal(error ("RefTeX works only in buffers visiting a file"))
> | error("RefTeX works only in buffers visiting a file")
> | reftex-access-scan-info(nil)
> | reftex-reference()
> | funcall-interactively(reftex-reference)
> | call-interactively(reftex-reference nil nil)
> | command-execute(reftex-reference)
> |
> `
>
> Any idea what to do?
>
> Thanks and regards
>
> Uwe Brauer
>
>
>
>
>
>
> --
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military.
> I support the NATO membership of the Ukraine.
> I support the EU membership of the Ukraine.
>
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>
>
>
--
John
---
Professor John Kitchin (he/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: org-latex-pdf-process as a lisp function?
Thanks for this and the other one too! On Sun, Apr 30, 2023 at 12:41 PM Ihor Radchenko wrote: > John Kitchin writes: > > > The documentation for org-latex-pdf-process says that it can be a list of > > strings, or a lisp function. > > ... > > In org-compile-file-commands, I think this line > > > > ((pred functionp) process) > > > > should instead be > > > > ((pred functionp) (list process)) > > Yes, indeed. > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=310a66891 > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
org-latex-pdf-process as a lisp function?
The documentation for org-latex-pdf-process says that it can be a list of strings, or a lisp function. I have used a function for a long time, but recently it seems to have broken. Now I get an error in org-compile-file. The issue comes in the first line where (commands (org-compile-file-commands source process ext spec err-msg) binds my function to commands, and later that is expected to be a list, but it is a function now. I think this probably occurred in https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/lisp/org-macs.el?id=b29f77241681abd6fb12de3b7e26c009cb28c63d In org-compile-file-commands, I think this line ((pred functionp) process) should instead be ((pred functionp) (list process)) that seems to make it work for me. Org mode version 9.7-pre (release_9.6.4-337-geaf274 -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Troubleshooting empty *Org PDF LaTeX Output*
For a while the *Org PDF LaTeX Output* buffer has been empty for me when I export to PDF. I am currently using: Org mode version 9.7-pre (release_9.6.4-337-geaf274 It looks like this happens because of this code: https://git.sr.ht/~bzg/org-mode/tree/main/item/lisp/ox-latex.el#L4313 It seems to have been added in commit f0dfbf0c3999e44ef7b6704e6584aa2a5d43f2d8 Author: TEC Date: Sun Dec 25 00:59:21 2022 +0800 ox-latex: Erase compile buffer at the start * lisp/ox-latex.el (org-latex-compile): Before running the compile command, erase the log buffer to ensure that stale/old logging is cleared. It seems like it is in the wrong place though, and it erases the buffer after the compile happens. It looks like the code should be modified to look like something like this: (defun org-latex-compile (texfile snippet) "Compile a TeX file. TEXFILE is the name of the file being compiled. Processing is done through the command specified in `org-latex-pdf-process', which see. Output is redirected to \"*Org PDF LaTeX Output*\" buffer. When optional argument SNIPPET is non-nil, TEXFILE is a temporary file used to preview a LaTeX snippet. In this case, do not create a log buffer and do not remove log files. Return PDF file name or raise an error if it couldn't be produced." (unless snippet (message "Processing LaTeX file %s..." texfile)) (let* ((compiler (or (with-temp-buffer (save-excursion (insert-file-contents texfile)) (and (search-forward-regexp (regexp-opt org-latex-compilers) (line-end-position 2) t) (progn (beginning-of-line) (looking-at-p "%")) (match-string 0))) ;; Cannot find the compiler inserted by ;; `org-latex-template' -> `org-latex--insert-compiler'. ;; Use a fallback. org-latex-compiler)) (process (if (functionp org-latex-pdf-process) org-latex-pdf-process ;; Replace "%latex" with "%L" and "%bib" and ;; "%bibtex" with "%B" to adhere to `format-spec' ;; specifications. (mapcar (lambda (command) (replace-regexp-in-string "%\\(?:\\(?:bib\\|la\\)tex\\|bib\\)\\>" (lambda (m) (upcase (substring m 0 2))) command)) org-latex-pdf-process))) (spec `((?B . ,(shell-quote-argument org-latex-bib-compiler)) (?L . ,(shell-quote-argument compiler (log-buf-name "*Org PDF LaTeX Output*") (log-buf (and (not snippet) (get-buffer-create log-buf-name))) (outfile)) (with-current-buffer log-buf (erase-buffer)) (setq outfile (org-compile-file texfile process "pdf" (format "See %S for details" log-buf-name) log-buf spec)) (org-latex-compile--postprocess outfile log-buf snippet) ;; Return output file name. outfile)) WDYT? -- John --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: org-ref-formatted-citation-formats for books: ISBN
there isn't enough information to tell what you are trying to do or if it
is the right thing to do. I don't think that is how org-ref exports to HTML
anymore, now it uses CSL. There is something like that syntax for
bibtex-completion-display-formats.
You should file an issue at https://github.com/jkitchin/org-ref/issues with
a small example org-file, bibtex example, and configuration that reproduces
your problem.
On Thu, Mar 30, 2023 at 8:11 AM Ihor Radchenko wrote:
> Uwe Brauer writes:
>
> > The following setting in my custom file
> > ...
> > ("book" . "${author}, /${title}/ (${year}), ${ISBN}, (pp.
> ${pages}) ${address}: ${publisher}.")
> >
> > However when I want to export a book reference to HTML, the ISBN field
> > is not inserted.
> >
> > Any idea what is wrong?
>
> Maybe it is case-sensitive.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
--
John
---
Professor John Kitchin (he/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: How to produce an org-ref citation from ivy-bibtex
The best place to report org-ref issues is https://github.com/jkitchin/org-ref/issues. On Wed, Mar 1, 2023 at 7:25 AM Sven Bretfeld wrote: > Hi John > > Thank you very much again. Elegant solution, and it works. > > I just wonder why I seem to be the only one on the list who had that > problem. Am I so out of fashion to use org-ref and ivy/helm-bibtex > together? I have been doing that for surely 10 years but had to stick > with an old version of org-ref until recently (because of a completely > different problem that I will post in another thread). > > Have a nice day, > > Sven > > > Am Tue, Feb 28, 2023 at 12:07:35PM -0500 schrieb John Kitchin: > > You can try something like this > > > > #+BEGIN_SRC emacs-lisp > > (setq bibtex-completion-format-citation-functions > > '((org-mode . (lambda (keys) (org-ref-insert-cite-keys keys) > "")) > > (latex-mode. bibtex-completion-format-citation-cite) > > (markdown-mode . > bibtex-completion-format-citation-pandoc-citeproc) > > (default . bibtex-completion-format-citation-default))) > > #+END_SRC > > > > it seems like ivy-bibtex at least expects some kind of string to be > returned, > > but org-ref-insert-cite-keys does the insertion for you. > > > > On Sun, Feb 26, 2023 at 11:19 AM Sven Bretfeld <[1]sven.bretf...@ntnu.no > > > > wrote: > > > > Hi everybody > > > > Is it at all possible to produce a correct org-ref citation format > > from ivy-bibtex (or helm-bibtex, I tried both)? What I mean by > > "correct" is the format: [[cite:]]. > > > > The problem seems to come down to the question what has to be > inserted > > in the 2nd line here: > > > > (setq bibtex-completion-format-citation-functions > > '((org-mode . ??) > > (latex-mode. bibtex-completion-format-citation-cite) > > (markdown-mode . > bibtex-completion-format-citation-pandoc-citeproc) > > (default . bibtex-completion-format-citation-default))) > > > > (A) Not setting the variable at all, defaults to producing an ebib > > link which is of no use to me at all. > > > > (B) Putting org-ref-helm-bibtex-insert-citation here (as found on > > reddit) does not work, since the function does not seem to exist > > anymore. > > > > (C) Putting org-ref-insert-cite-link here is obviously wrong. > Choosing > > that from the list of ivy-bibtex-actions, just calls the function > > interactively, you have to search for the bib-entry again and the > > resulting link looks like: [[cite:]]^&. The terminating '^&' > > obviously makes subsequent LaTeX-exports fall. > > > > (D) Putting "bibtex-completion-format-citation-org-cite" here, > > produces standard org-links: [cite:@citekey]. These are not > correctly > > exported to a tex file when the org-ref package is loaded. > > > > The only working solution I have found is to use org-ref's own cite > > function org-ref-insert-cite-link. I know that ivy-bibtex can be set > > as backend (require 'org-ref-ivy). But in this way ivy-bibtex's other > > actions (like opening an associated PDF or note file) are lost. > > > > It would be nice to be able to use a SINGLE key-binding to select a > > bib-entry and then decide what to do with it (insert org reference, > > insert tex reference, open pdf, etc.). This was possible earlier (I > > did that for years with older versions of org-ref-helm) but is > > apparently no longer possible now. > > > > Many thanks for help and suggestions, > > > > Sven > > > > > > > > References: > > > > [1] mailto:sven.bretf...@ntnu.no > > -- ohn --- Professor John Kitchin (he/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: How to produce an org-ref citation from ivy-bibtex
You can try something like this #+BEGIN_SRC emacs-lisp (setq bibtex-completion-format-citation-functions '((org-mode . (lambda (keys) (org-ref-insert-cite-keys keys) "")) (latex-mode. bibtex-completion-format-citation-cite) (markdown-mode . bibtex-completion-format-citation-pandoc-citeproc) (default . bibtex-completion-format-citation-default))) #+END_SRC it seems like ivy-bibtex at least expects some kind of string to be returned, but org-ref-insert-cite-keys does the insertion for you. On Sun, Feb 26, 2023 at 11:19 AM Sven Bretfeld wrote: > Hi everybody > > Is it at all possible to produce a correct org-ref citation format > from ivy-bibtex (or helm-bibtex, I tried both)? What I mean by > "correct" is the format: [[cite:]]. > > The problem seems to come down to the question what has to be inserted > in the 2nd line here: > > (setq bibtex-completion-format-citation-functions > '((org-mode . ??) > (latex-mode. bibtex-completion-format-citation-cite) > (markdown-mode . bibtex-completion-format-citation-pandoc-citeproc) > (default . bibtex-completion-format-citation-default))) > > (A) Not setting the variable at all, defaults to producing an ebib > link which is of no use to me at all. > > (B) Putting org-ref-helm-bibtex-insert-citation here (as found on > reddit) does not work, since the function does not seem to exist > anymore. > > (C) Putting org-ref-insert-cite-link here is obviously wrong. Choosing > that from the list of ivy-bibtex-actions, just calls the function > interactively, you have to search for the bib-entry again and the > resulting link looks like: [[cite:]]^&. The terminating '^&' > obviously makes subsequent LaTeX-exports fall. > > (D) Putting "bibtex-completion-format-citation-org-cite" here, > produces standard org-links: [cite:@citekey]. These are not correctly > exported to a tex file when the org-ref package is loaded. > > The only working solution I have found is to use org-ref's own cite > function org-ref-insert-cite-link. I know that ivy-bibtex can be set > as backend (require 'org-ref-ivy). But in this way ivy-bibtex's other > actions (like opening an associated PDF or note file) are lost. > > It would be nice to be able to use a SINGLE key-binding to select a > bib-entry and then decide what to do with it (insert org reference, > insert tex reference, open pdf, etc.). This was possible earlier (I > did that for years with older versions of org-ref-helm) but is > apparently no longer possible now. > > Many thanks for help and suggestions, > > Sven > >
Re: Links to external targets with (or despite) org-ref
You are welcome.
I also discovered just now that you can do C-u C-u C-c C-l to skip storing
functions that are not part of org-core.
If anyone knows how to use store functions that do not clobber the build in
ones, I would be happy to update org-ref so you can use all the link store
options.
On Wed, Feb 22, 2023 at 5:20 AM Sven Bretfeld wrote:
> Hi John
>
> That's working well. Thank you very much. And thousand thanks for
> org-ref in general.
>
> Sven
>
> Am Mon, Feb 20, 2023 at 01:07:49PM -0500 schrieb John Kitchin:
> > The quickest thing might be to remove the store properties on the ref
> links.
> > This should do it.
> >
> > #+BEGIN_SRC emacs-lisp
> > (cl-loop for reflink in '("ref" "pageref" "nameref" "eqref" "autoref"
> "cref"
> > "Cref" "crefrange" "Crefrange")
> > do
> > (setf (cdr (assoc reflink org-link-parameters))
> > (org-plist-delete (cdr (assoc reflink org-link-parameters))
> :store)))
> > #+END_SRC
> >
> > I guess I don't have that setup quite right in org-ref, it seems like it
> should
> > not clobber other ways to store links.
> >
> > On Sun, Feb 19, 2023 at 10:39 AM Sven Bretfeld <[1]sven.bretf...@ntnu.no
> >
> > wrote:
> >
> > Hi everybody
> >
> > I'm looking to create labels/links to specific text positions in org
> > files (not line number, not header).
> >
> > I know that [[file:~/path_to_file::target]] can be used to jump to
> > <>. That would be fine and works for me -- IF I write the
> link
> > manually.
> >
> > However, org-ref which I use for citations seems to overwrite the
> > default behaviour of org-store-link and org-insert-link. So when the
> > point is on <> and org-store-link is called (C-c l), I get a
> > prompt "Store link with (default org-ref-store-ref)". No alternatives
> > are offered when TAB is hit. Hiting RET saves the link as
> > "Crefrange:target". A corresponding org-insert-link (C-c C-l)
> produces
> > a link of the form [[Crefrange:target]] which, when in another file,
> > of course leads nowhere ("search failed"). How to get the file name
> > into these links without manually rewriting the link?
> >
> > I couldn't find anything on this issue in the org-ref manual or on
> the
> > internet.
> >
> > Thanks for help,
> >
> > Sven
> >
> >
> >
> > References:
> >
> > [1] mailto:sven.bretf...@ntnu.no
>
Re: Links to external targets with (or despite) org-ref
The quickest thing might be to remove the store properties on the ref
links. This should do it.
#+BEGIN_SRC emacs-lisp
(cl-loop for reflink in '("ref" "pageref" "nameref" "eqref" "autoref"
"cref" "Cref" "crefrange" "Crefrange")
do
(setf (cdr (assoc reflink org-link-parameters))
(org-plist-delete (cdr (assoc reflink org-link-parameters)) :store)))
#+END_SRC
I guess I don't have that setup quite right in org-ref, it seems like it
should not clobber other ways to store links.
On Sun, Feb 19, 2023 at 10:39 AM Sven Bretfeld
wrote:
> Hi everybody
>
> I'm looking to create labels/links to specific text positions in org
> files (not line number, not header).
>
> I know that [[file:~/path_to_file::target]] can be used to jump to
> <>. That would be fine and works for me -- IF I write the link
> manually.
>
> However, org-ref which I use for citations seems to overwrite the
> default behaviour of org-store-link and org-insert-link. So when the
> point is on <> and org-store-link is called (C-c l), I get a
> prompt "Store link with (default org-ref-store-ref)". No alternatives
> are offered when TAB is hit. Hiting RET saves the link as
> "Crefrange:target". A corresponding org-insert-link (C-c C-l) produces
> a link of the form [[Crefrange:target]] which, when in another file,
> of course leads nowhere ("search failed"). How to get the file name
> into these links without manually rewriting the link?
>
> I couldn't find anything on this issue in the org-ref manual or on the
> internet.
>
> Thanks for help,
>
> Sven
>
>
Re: org-ref 3 setup
indeed, you should only use that before parsing hook for non-latex exports.
See the documentation for org-export-before-parsing-hook. You need to
write a function that takes one argument and does nothing for latex, and
calls the csl processor otherwise.
perhaps something like this:
(defun org-ref-preprocessing (backend)
(unless (eq backend 'latex)
(org-ref-csl-preprocess-buffer backend)))
(setq org-export-before-parsing-hook '(org-ref-preprocessing))
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore
On Wed, Jul 20, 2022 at 10:48 AM Joseph Vidal-Rosset <
jos...@vidal-rosset.net> wrote:
>
> Le 20/07/2022 à 16:20, Joseph Vidal-Rosset a écrit :
> >
> >
> > Le 20/07/2022 à 15:38, John Kitchin a écrit :
> >
> >> (let ((org-export-with-broken-links t)
> >>(org-latex-pdf-process
> >> '("pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o %f"
> >> "bibtex %b"
> >> "makeindex %b"
> >> "pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o %f"
> >> "pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o
> >> %f")))
> >> (org-open-file (org-latex-export-to-pdf)))
> >>
> >>
> >> this doesn't do anything in your init file to change anything. it only
> >> temporarily (let) defines some variables, and then tries to export the
> >> current buffer (an elisp file) to pdf and open it. that is a mistake
> >> to try.
> >
> > You are certainly right. I believe that these lines block a
> > configuration file that is responsible for the fact that the export via
> > pdflatex does not work correctly. This file is therefore loaded after
> > myorgexport.el, like mysnippets.el that is not loaded, for example. It
> > is also possible that myorgexport.el itself is somewhere incorrect.
> >
> > I will go to make tests, I'll keep you informed.
>
> The BIG advantage of launching Emacs Prelude with emacs --daemon is that
> it is possible to identify (with your help in this case, John) the
> reason of a problem in such or such setup, every personal setup being
> located in possible several small files ~/.emacs.d/personal/myfile1.el,
> ~/.emacs.d/personal/myfile2.el, etc.
> (I am really thankful to Bozhidar Batsov - hence this cc. to his email
> address - and to all the contributors of Prelude Emacs, and I recommend
> this nice starter kit for Emacs.)
>
> John, you kindly gave me a solution to get the bibliography in an html
> email exported via gnus and orgmode, and in my
> .emacs.d/personal/myorgmime.el I had this line of code:
>
> > (setq org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))
> ;; to get the bibliography in email (thanks to John Kitchin)
>
> Deactivated, the export in pdflatex works correctly for the
> bibliography... I now have to find a coherent way to get both exports of
> bibliography...
>
> Many thanks John for your so kind, so constant, and so patient help !
>
> All the best,
>
> Jo.
>
>
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
Maybe it is still needed so the tooltip looks nice. On Tue, Jul 12, 2022 at 7:15 AM András Simonyi wrote: > Dear All, > > On Sun, 10 Jul 2022 at 09:17, Ihor Radchenko wrote: > > > AFAIU, oc-natbib/oc-bibtex also do not support @string because they also > > rely upon the built-in Emacs parser for bib files. > > > I have submitted a bug report to Emacs devs [1]. Hopefully it can be > > fixed on Emacs side without a need to switch the bibtex parser. > > Thanks Ihor for submitting the bug report, I think it will be useful > for Emacs to contain a built-in bibtex parser with proper @string > support. > OTOH, a small correction: as far as I can see, oc-natbib and > oc-bibtex (and oc-biblatex) do not parse bib(la)tex files at all, > since they simply transform Org citation and bibliography commands to > their LaTeX equivalent. > > best wishes, > András > > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: [PATCH] oc-csl: Add support for nocite citations
It is a special command. See
https://texfaq.org/FAQ-nocitestar
It is used to put all entries in a bibtex file in the bibliography.
Here is a minimal example Tex file that should list all the entries in
mybibliography.bib
\documentstyle{article}
\begin{document}
\nocite{*}
\bibliographystyle{unsrt}
\bibliography{mybibliography}
\end{document}
On Sun, Jul 3, 2022 at 8:35 AM Ihor Radchenko wrote:
> "Bruce D'Arcus" writes:
>
> > Ihor - on *, he is bringing oc-csl in line with the oc-natbib and
> > oc-biblatex processors.
>
> I am sorry, but I still do not understand. AFAIK, \nocite{*} is not a
> valid LaTeX command.
>
> Best,
> Ihor
>
> --
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: We have asynchronous sessions, why have anything else?
The Jupyter project is one approach to this. It currently has dozens of kernels for different languages, and new kernels can certainly be made. The emacs-jupyter package provides one implementation of an interface. It is complex, and relies on a compiled module for the zeromq message passing library. I am not advocating for this as the solution for org-babel, but it is an interesting case study. You can even connect to remote kernels. I use it a lot. On Mon, Jun 27, 2022 at 8:56 PM Tim Cross wrote: > > Tom Gillespie writes: > > >> I am not even sure if all the babel backends support try-except. > >> Think about ob-gnuplot or, say, ob-latex. > > > > Indeed many do not. Defining some standard "features" > > for org babel language implementations is something that > > is definitely of interest so that we can provide clear interfaces > > for things like stdio, error handling, return values, async, > > file output, remote execution, sessions, return value caching, > > module discovery/tangling, execution from file vs stdin, execution > > without a file system path, runtime environment specification, > > and much more. However, at the moment there is only a preliminary > > survey of a subset of these that was put together by Ian Martins. > > > > https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html > > > >> the two could be unified if we expand the functionality of the async > filter > > > > While this might be possible, I would definitely hold off on this because > > the changes in semantics absolutely will break many users' blocks. We > > barely knew what the impact of changing the default return value for > shell > > blocks would be. > > > > I absolutely look forward to the day when this can be done safely and > > with confidence, but I think we need a much stronger handle on babel > > interfaces in general before such a change could even be considered. > > > > At the moment each ob lang impl pretty much has to be considered > > to be completely unique, even if the text looks like bash for e.g. > > shell, comint, and screen. Users are known to rely on undocumented > > quirks of the ob lang impls that can differ wildly in their semantics. > > > > Well said Tom. > > As you point out, there are numerous deficiencies with the current > implementation, despite the fact it all sort of works. To get the sort > of improvements and consistency users want, I suspect this needs more > than just small tweaks around the edges. > > To some extent, I see the current babel implementation as similar to a > prototype. It has worked well and we have learnt a lot about what people > want to use it for and the type of functionality they are wanting and > what some of the core challenges are. Now comes the next step, which is > definitely non-trivial. We need to take all that knowledge and > consolidate it into a single model from which we can define the > interfaces and associated APIs. A big job which will take considerable > time. > > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: org-ref3 export html with references of pages
Hi Joseph, It looks like what I suggested (e.g. use a csl file that supports what you want) This org file: #+csl-style: american-medical-association-brackets.csl #+csl-locale: en-US See [[cite: 55-56]] bibliography:~/Dropbox/emacs/bibliography/references.bib leads to this output for me. You have to export it with C-c C-e rh to use the org-ref exporter. [image: image.png] John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore On Sat, Jun 25, 2022 at 6:00 AM Joseph Vidal-Rosset wrote: > > Hello everyone, > > With org-ref (version 3) I meet the following (minor) problem with the > html export of references when I want to give the pages of a book in > numerical csl format. > > With LaTeX export, no difficulty: I get > > [1, pp. 55-56] > > to refer to the book 1 and pages 55-56. > > With html export, I get only: > > [1] > > and no mean to give the pages in this format. > > John Kitchin tried to help me (with downgrade to org-ref version 2), but > it is not so easy to downgrade and with regular org and prelude > upgrades, it is not easy always to keep the same version of org-mode. > > Help is welcome, if someone knows the solution. > > All the best, > > Jo. > > >
Re: Abbreviations support
Org-ref supports this for glossaries and acronyms. See https://youtu.be/sebs2vSIEk4 For an overview. On Sat, Jun 4, 2022 at 6:13 AM Timothy wrote: > Hi Denis, > > > Is there support for abbreviations in org-mode? Something like what the > acro > > package provides for latex, i.e., assemble a list of all used > abbreviations, use > > a full form when an abbreviation is used for the first time, the > abbreviated > > form afterwards. If that does not exist: What would be a good way to > approach > > that? > > Not directly, but I think you could do something like this as a > halfway-house: > > ┌ > │ Blah blah text ABBR > │ > │ * Abbreviations > │ > │ - <<>> :: Some abbreviation > │ ... > └ > > I’d think there’s scope for a package say “org-abbreviations” which > provides > acro-like support. Perhaps even support for a central abbreviations file. > Hmm, I > may think of trying a small MVP for that this weekend. > > All the best, > Timothy > -- 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: Trouble producing nicely aligned org tables from emacs-jupyter code blocks using latest org version
I would guess it could. I don't do anything asynchronous, and I am not sure when org-babel-after-execute-hook runs, if it is immediately there is no table to clean up I suppose. It is not necessary to run on a subtree, but on a very large document you probably don't want to do org-element-parse often. 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, May 18, 2022 at 4:57 PM Richard Stanton wrote: > Thanks for the suggestion, John. I’ve tried playing around with this, and > am I right that it seems to have trouble when execution is asynchronous? > > On May 18, 2022, at 1:16 PM, John Kitchin wrote: > > I use a function in an after execute hook for this: > https://github.com/jkitchin/scimax/blob/master/scimax-org.el#L205 > > This works on a subtree, which has been fine for me. You could adapt it to > only work in the results section. > > 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, May 18, 2022 at 4:07 PM Richard Stanton > wrote: > >> I’m running Emacs 28.1 under macOS 12.4 and want to create tables from >> Python code blocks that can be exported to either LaTeX or HTML. The >> simplest way to do this seems to be to generate the output as an org table, >> and using the built-in version of org (9.4.6 >> (9.4.6-798-g738759.dirty-elpaplus @ >> /Users/stanton/.emacs.d/elpa/org-plus-contrib-20210929/)), this works fine >> using either a python or emacs-jupyter code block: >> >> #+begin_src jupyter-python >> [ >> ["Wide a", "b", "c"], >> None, >> [1, 2, 3], >> [4, 5, 6], >> None, >> [7, 8, 9] >> ] >> #+end_src >> >> #+RESULTS: >> | Wide a | b | c | >> |+---+---| >> | 1 | 2 | 3 | >> | 4 | 5 | 6 | >> |+---+---| >> | 7 | 8 | 9 | >> >> #+begin_src python >> return [ >> ["Wide a", "b", "c"], >> None, >> [1, 2, 3], >> [4, 5, 6], >> None, >> [7, 8, 9] >> ] >> #+end_src >> >> #+RESULTS: >> | Wide a | b | c | >> |+---+---| >> | 1 | 2 | 3 | >> | 4 | 5 | 6 | >> |+---+---| >> | 7 | 8 | 9 | >> >> >> To use the latest version of org, I change just two lines in my init.el >> from >> >> (straight-use-package '(org :type built-in)) >> (straight-use-package '(org-contrib :type built-in)) >> >> to >> >> (straight-use-package '(org :type git :repo " >> https://code.orgmode.org/bzg/org-mode.git;)) >> (straight-use-package '(org-contrib :type git :repo " >> https://git.sr.ht/~bzg/org-contrib”)) >> >> Having done this, the python block still works fine, but the horizontal >> lines in the jupyter-python block are no longer properly aligned with the >> text: >> >> #+begin_src jupyter-python >> [ >> ["Wide a", "b", "c"], >> None, >> [1, 2, 3], >> [4, 5, 6], >> None, >> [7, 8, 9] >> ] >> #+end_src >> >> #+RESULTS: >> | Wide a | b | c | >> |---+---+---| >> | 1 | 2 | 3 | >> | 4 | 5 | 6 | >> |---+---+---| >> | 7 | 8 | 9 | >> >> #+begin_src python >> return [ >> ["Wide a", "b", "c"], >> None, >> [1, 2, 3], >> [4, 5, 6], >> None, >> [7, 8, 9] >> ] >> #+end_src >> >> #+RESULTS: >> | Wide a | b | c | >> |+---+---| >> | 1 | 2 | 3 | >> | 4 | 5 | 6 | >> |+---+---| >> | 7 | 8 | 9 | >> >> By the way, the org version loaded this time is 9.5.3 (9.5.3-g277897 @ >> /Users/stanton/.emacs.d/straight/build/org/). >> >> The table exports OK, but isn’t much fun to look at in the org file >> itself. >> >> Since I like to use emacs-jupyter, any suggestions would be appreciated. >> I know this worked fine just a few weeks ago. >> >> Thanks! >> >> Richard Stanton >> >> >> >> >> >> >
Re: Trouble producing nicely aligned org tables from emacs-jupyter code blocks using latest org version
I use a function in an after execute hook for this: https://github.com/jkitchin/scimax/blob/master/scimax-org.el#L205 This works on a subtree, which has been fine for me. You could adapt it to only work in the results section. 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, May 18, 2022 at 4:07 PM Richard Stanton wrote: > I’m running Emacs 28.1 under macOS 12.4 and want to create tables from > Python code blocks that can be exported to either LaTeX or HTML. The > simplest way to do this seems to be to generate the output as an org table, > and using the built-in version of org (9.4.6 > (9.4.6-798-g738759.dirty-elpaplus @ > /Users/stanton/.emacs.d/elpa/org-plus-contrib-20210929/)), this works fine > using either a python or emacs-jupyter code block: > > #+begin_src jupyter-python > [ > ["Wide a", "b", "c"], > None, > [1, 2, 3], > [4, 5, 6], > None, > [7, 8, 9] > ] > #+end_src > > #+RESULTS: > | Wide a | b | c | > |+---+---| > | 1 | 2 | 3 | > | 4 | 5 | 6 | > |+---+---| > | 7 | 8 | 9 | > > #+begin_src python > return [ > ["Wide a", "b", "c"], > None, > [1, 2, 3], > [4, 5, 6], > None, > [7, 8, 9] > ] > #+end_src > > #+RESULTS: > | Wide a | b | c | > |+---+---| > | 1 | 2 | 3 | > | 4 | 5 | 6 | > |+---+---| > | 7 | 8 | 9 | > > > To use the latest version of org, I change just two lines in my init.el > from > > (straight-use-package '(org :type built-in)) > (straight-use-package '(org-contrib :type built-in)) > > to > > (straight-use-package '(org :type git :repo " > https://code.orgmode.org/bzg/org-mode.git;)) > (straight-use-package '(org-contrib :type git :repo " > https://git.sr.ht/~bzg/org-contrib”)) > > Having done this, the python block still works fine, but the horizontal > lines in the jupyter-python block are no longer properly aligned with the > text: > > #+begin_src jupyter-python > [ > ["Wide a", "b", "c"], > None, > [1, 2, 3], > [4, 5, 6], > None, > [7, 8, 9] > ] > #+end_src > > #+RESULTS: > | Wide a | b | c | > |---+---+---| > | 1 | 2 | 3 | > | 4 | 5 | 6 | > |---+---+---| > | 7 | 8 | 9 | > > #+begin_src python > return [ > ["Wide a", "b", "c"], > None, > [1, 2, 3], > [4, 5, 6], > None, > [7, 8, 9] > ] > #+end_src > > #+RESULTS: > | Wide a | b | c | > |+---+---| > | 1 | 2 | 3 | > | 4 | 5 | 6 | > |+---+---| > | 7 | 8 | 9 | > > By the way, the org version loaded this time is 9.5.3 (9.5.3-g277897 @ > /Users/stanton/.emacs.d/straight/build/org/). > > The table exports OK, but isn’t much fun to look at in the org file itself. > > Since I like to use emacs-jupyter, any suggestions would be appreciated. I > know this worked fine just a few weeks ago. > > Thanks! > > Richard Stanton > > > > > >
Re: How to stop results being hidden when using ":results drawer"?
If you add this and click on it: [[elisp:(org-show-entry)]] The drawer will collapse. This issue is specific to using a scimax function `scimax-ob-execute-and-next-block` that executes the current block then moves to the next or creates a new block if needed. This is a UI feature from jupyter notebooks that I like to use. That function uses `(org-babel-next-src-block)`, which uses org-next-block, which calls org-show-context, which uses org-show-set-visibility, which calls org-show-entry, which hides the drawers. It isn't an org-core issue perhaps, other than it is not obvious why org-show-entry has a hard-coded line to hide drawers in it. Ihor Radchenko writes: > John Kitchin writes: > >> This does not change anything for me. >> >> The function that causes folding for me is `org-entry-show'. Presumably >> because of this line: (org-cycle-hide-drawers 'children) >> >> My solution was an override advice that makes this function not run when >> point is in a src-block >> (https://github.com/jkitchin/scimax/blob/master/scimax-jupyter.el#L281). > > Could you elaborate? I am not sure how `org-entry-show' has anything to > do with hiding results. > > I tried the following Org file with latest Org main (after (require > 'ob-python)): > > * test heading > > #+begin_src python :results drawer output > print(1+2) > #+end_src > > #+RESULTS: > :results: > 3 > :end: > > The drawer does not get hidden. > > Best, > Ihor -- 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 Pronouns: he/him/his
Re: How to stop results being hidden when using ":results drawer"?
This does not change anything for me. The function that causes folding for me is `org-entry-show'. Presumably because of this line: (org-cycle-hide-drawers 'children) My solution was an override advice that makes this function not run when point is in a src-block (https://github.com/jkitchin/scimax/blob/master/scimax-jupyter.el#L281). Ihor Radchenko writes: > Richard Stanton writes: > >> I’m creating documents where I run Python code blocks that create LaTeX >> mathematical output that I want to be able to export to either LaTeX/PDF or >> HTML. >> >> Using :wrap in the header works fine, except that LaTeX complains about the >> unknown environment “results” (it still compiles the file to PDF fine). >> >> Using :wrap export latex works fine for LaTeX export, but I can’t get HTML >> that way. >> >> The recommended method seems to be to use :results drawer. This works fine >> from an export perspective to both LaTeX/PDF and to HTML. However, it has one >> significant drawback when I’m actually creating the document: the results >> drawer starts out hidden and to see what’s there I have to click on it. This >> makes debugging the code in the first place a lot less convenient. >> >> Is there a way to use :results drawer and have the results NOT hidden by >> default? > > I think that you are experiencing the same issue with > https://list.orgmode.org/80k0ar1lml@felesatra.moe/T/#u > > Does it help when you run > M-: (setq org-fold-core-first-unfold-functionsp nil) > before running the code block? > > Best, > Ihor -- 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 Pronouns: he/him/his
Re: How to stop results being hidden when using ":results drawer"?
hm. what is xenops doing? That isn't a package I use, but my results drawers are also closed when opening a file. 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, May 11, 2022 at 4:16 PM Richard Stanton wrote: > It works fine when I use emacs -Q, so I did some hunting around and > discovered that it’s a bad interaction with the xenops package. A shame, as > this package does a great job of almost-real-time previewing of LaTeX > equations, figure and tables. > > > > On May 11, 2022, at 10:51 AM, Richard Stanton > wrote: > > > > I see that the same question was asked by John Kitchin in 2016. The > accepted answer back then was either to put > > > > #+STARTUP: showeverything > > > > at the top of the org file or to use (setq org-startup-folded > "showeverything”). > > > > I don’t know if something has changed in org since then, but neither of > these seems to work for me at the moment. All of my :results: drawers start > out and remain hidden until I click on them and press TAB. > > > > > >> On May 11, 2022, at 9:52 AM, Richard Stanton > wrote: > >> > >> I’m creating documents where I run Python code blocks that create LaTeX > mathematical output that I want to be able to export to either LaTeX/PDF or > HTML. > >> > >> Using :wrap in the header works fine, except that LaTeX complains about > the unknown environment “results” (it still compiles the file to PDF fine). > >> > >> Using :wrap export latex works fine for LaTeX export, but I can’t get > HTML that way. > >> > >> The recommended method seems to be to use :results drawer. This works > fine from an export perspective to both LaTeX/PDF and to HTML. However, it > has one significant drawback when I’m actually creating the document: the > results drawer starts out hidden and to see what’s there I have to click on > it. This makes debugging the code in the first place a lot less convenient. > >> > >> Is there a way to use :results drawer and have the results NOT hidden > by default? > >> > >> Thanks for any suggestions! > >> > >> Richard Stanton > >> > >> > > > > >
Re: Org-ref not working when exporting to LaTeX
The regular export is preferred for LaTeX (C-c C-e l o) is preferred for LaTeX export as it generates the LaTeX cite commands. The version in C-c C-e r p uses CSL for the formatting, not LaTeX, and it allows you to get nicely formatted results without using bibtex/biblatex as the citation processor. 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, May 11, 2022 at 2:15 PM Daniel Fleischer wrote: > Alessandro Bertulli [2022-05-11 Wed 19:41] wrote: > > > I'm going to post my setup in a minute. The > > point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF file > > gets produced, but it doesn't process the citation keys. For example, in > > my file (see below), I got the key "acm:code" literally printed on the > > PDF file, in a bold font. > > Hi, org-ref uses its own export engine which you call via (C-c C-e r p). > Please try that and report back if there are still issues. > > -- > > Daniel Fleischer > >
Re: Citations using org-ref export to LaTeX incorrectly
Can you post this as an issue at
https://github.com/jkitchin/org-ref/issues?
Thanks.
On Tue, May 10, 2022 at 8:36 PM Daniel Fleming wrote:
> Hello,
>
> I initially posted this to the Emacs StackExchange, but it was suggested
> I might get more traction on the mailing list.
>
> I am writing my dissertation in org-mode with org-ref to handle
> citations. I can not get a multi-source multi-note citation to export
> correctly.
>
> Following the documentation for org-ref provided here:
>
> https://github.com/jkitchin/org-ref/blob/master/org-ref.org#2021-version-2-vs-version-3
> I am using the new `&' syntax with semi-colon separated sources. However
> the pre and post notes do not come through to LaTeX as you can see in
> the second code block below.
>
> Here is the org-mode code:
>
> ```
> [[cite:On Van Tillian apologetics see _apolog; and
> _cornel_van_til; One example in systematic theology is
> :-system-theol; Finally on christian worship see
> _contem_worsh_music; and _worsh_spirit_truth]]
> ```
>
> Which exports to:
>
> ```
> \cite[On Van Tillian apologetics
> see][]{frame15_apolog,frame95_cornel_van_til,frame13:-system-theol,frame97_contem_worsh_music,frame96_worsh_spirit_truth}}
> ```
>
> Notice that only the first note is exported and then it is just the
> sources.
>
> I do have the fallback of using multiple [[cite:source][text::text]]
> blocks, but I'd rather use the new syntax if it works.
>
> Thank you much!
>
> --
> Daniel Fleming
>
> --
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: [how to joint column/rows of tables that are in different files (id?)] (was: how to best correct exams (code matlab) using org mode (and tables))
Can you make a temporary org-buffer that copies all those tables into one place, and then join them? Uwe Brauer writes: > I think I almost have a working workflow. > > What I need is a functionality to join either columns or rows of tables > that are in different files. > > Here is what I have in mind for tables that are in the same file > > > ** Columns > > #+NAME: T1 > | col1 | col2 | > > |1 | 2| > > #+NAME: T2 > | col3 | > > | 3| > > #+BEGIN_SRC emacs-lisp :var t1=T1 t2=T2 > (cl-mapcar #'append t1 t2) > #+END_SRC > > > #+RESULTS: > | col1 | col2 | col3 | > |1 |2 |3 | > > ** Rows > > #+BEGIN_SRC emacs-lisp :var t1=T1 t2=T2 > (append t1 t2) > #+END_SRC > > > #+RESULTS: > | col1 | col2 | > |1 |2 | > | col3 | | > |3 | | > > > > Now the 3rd package orgtbl-aggregate allows me to aggerate column of > tables that are in different files, via an ID generated via > org-id-get-create > and saved via org-id-update-id-locations > as in > > #+BEGIN: aggregate :table "uwe" :cols "Level" > #+END: > > Where the table uwe is located in a different file. However it seems > only to work for one table at the time, so if you have 20 tables in 20 > files that a bit complicated > > Any idea how to append column or rows from different table in different > files in one go? > > Thanks > > Uwe -- 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 Pronouns: he/him/his
Re: how to best correct exams (code matlab) using org mode (and tables)
I guess the best thing to do would be some combination of `htmlize-buffer' and adding tooltips to the markups. I don't see a super clear path to that at the moment. The htmlize-buffer is straightforward, and it would show where your remarks are. Getting from marginalia.org to tooltips in the right place though is not as straightforward. htmlize-buffer is only necessary if you want to see the syntax in the buffer. Here is some rough code that wraps the file in and makes the text you added remarks on have tooltips associated with your remarks. You could then return the feedback.html file. #+BEGIN_SRC emacs-lisp (let* ((hls (sort (org-remark-highlights-get) (lambda (a b) (> (caadr a) (caadr b) (notes (cl-loop for (key (start . end) type) in hls collect (progn (with-current-buffer (org-remark-notes-buffer-get-or-create) (goto-char (org-find-property org-remark-prop-id key)) (save-restriction (org-narrow-to-subtree) (org-end-of-meta-data t) (buffer-substring (point) (point-max (with-temp-file "feedback.html" (insert-file-contents "some-file") (cl-loop for (key (start . end) type) in hls for note in notes do (cl--set-buffer-substring start end (format "%s" note (buffer-substring start end (goto-char (point-min)) (insert "") (goto-char (point-max)) (insert "")) (browse-url "feedback.html")) #+END_SRC Uwe Brauer writes: > Hi > > I came around > https://kitchingroup.cheme.cmu.edu/blog/2013/10/23/Writing-exams-in-org-mode/ > > Which is a bit outdated. > > My use case are to correct of matlab files, so usually I have a single org > file with a table and insert the results. > > However what I missing is that my comments, and observations are difficult to > track. > > I am now experimenting with org-remark putting the remarks and marks in the > property sections of headers and use than > > columnview > like > > #+begin_src > #+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :indent nil :hlines 2 > :format "%5TODO(Status) %5Ap(Name) %5com(Comment) %5Ej1(Ej1/20) %5Ej2(Ej2/25) > %5Ej3(Ej3/55) %5Res(Result)" > #+END: > #+end_src > > What do others use? > > Regards > > Uwe Brauer -- 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 Pronouns: he/him/his
Re: Concatenate properties
Where did you add that? 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 Fri, May 6, 2022 at 11:40 AM Tyler Grinn wrote: > John Kitchin writes: > > > I believe this is hard coded in org-entry-get-with-inheritance. The > > fastest option would be an override advice with your own function that > > replaces (and value " ") with (and value ""), and maybe the two other > > " " with "". > > > > 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 > > > > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If > this is something the community would want I will clean it up and send > in a patch. >
Re: Concatenate properties
I like the variable idea. I would make it a concatenation string for joining. That way “” would concatenate the way Tyler wants, “ “ would preserve current behavior, and “,” could lead to a comma separated list for example. Other things like “\n” might lead to a column, etc. On Sat, May 7, 2022 at 1:32 AM Ihor Radchenko wrote: > Tyler Grinn writes: > > > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: > > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If > > this is something the community would want I will clean it up and send > > in a patch. > > Hmm. I am not sure if it going to be a straightforward patch. You may > need to update org-element parser accordingly. > > Also, I do not like the idea of extending org syntax with :PROPERTY^:. > It may be easier to introduce a variable similar to > org-use-property-inheritance where the user can customise how to > accumulate parent properties. > > Best, > Ihor > -- 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: Concatenate properties
I believe this is hard coded in org-entry-get-with-inheritance. The fastest option would be an override advice with your own function that replaces (and value " ") with (and value ""), and maybe the two other " " with "". 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 Thu, May 5, 2022 at 6:38 PM Tyler Grinn wrote: > > I'm exporting sub-trees as pdf files for some classes I'm taking: > > # -*- org-use-property-inheritance: t; -*- > > * Class A > :PROPERTIES: > :EXPORT_FILE_NAME: support/Class A > :END: > ** Assignment 1 >:PROPERTIES: >:EXPORT_FILE_NAME+: /assignment-1 >:END: >Some assignment for Class A > ** Assignment 2 >:PROPERTIES: >:EXPORT_FILE_NAME+: /assignment-2 >:END: >Some other assignment for Class A > * Class B > :PROPERTIES > :EXPORT_FILE_NAME: support/Class B > :END: > ** Assignment 1 >:PROPERTIES: >:EXPORT_FILE_NAME+: /assignment-1 >:END: >Some assignment for Class B > ** Assignment 2 >:PROPERTIES: >:EXPORT_FILE_NAME+: /assignment-2 >:END: >Some other assignment for Class B > > And this works great, except there's always a space between > 'support/Class A' and '/assignment-1.pdf'. Is there any way to > concatenate the two properties rather than join them with spaces? > > Best, > > Tyler > >
Re: [the culprit]
This seems like something that could (should?) go in a personal config, as a custom function, or advice. You could, for example do something like this (lightly tested) #+BEGIN_SRC emacs-lisp (defun my-put (property value here) (interactive (list nil nil current-prefix-arg)) (if (null here) (org-set-property property value) (let* ((property (or property (org-read-property-name))) (value (or value (org-read-property-value property (save-excursion (beginning-of-line) (search-forward ":") (backward-char) (insert (format ":%s: %s\n" property value)) #+END_SRC if you call it as M-x my-put, it just uses org-set-property. If you call it as C-u M-x my-put, it inserts the property before the point. It does not check you are in a property drawer, which could be a good idea. 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 Tue, Apr 26, 2022 at 2:43 AM Uwe Brauer wrote: > >>> "IR" == Ihor Radchenko writes: > > > Uwe Brauer writes: > >>> But it does not help, org-set-property sets always a new property at > the > >>> end of the property list. > >> > >>> Any idea what to do (besides touching the function itself) > >> > >> > >> It seems that the culprit is the function > >> org-entry-put > >> which always puts a new entry at the end of the property section. > > > You are right, org-set-property adds the property to the end of property > > drawer. I do not think that its docstring suggests anything different. > > > Do you want to propose a new feature request? I guess patches are > welcome. > > The question is what would be the best solution? > > 1. Change the behavior for org-entry-put > > 2. Or just for org-set-property. > > If it is the first option, then maybe a variable should be added > org-set-property-at-line say, what could be t or nil. > > Recently I use drawers that have a lot of properties, that I want a bit > organised, but if new properties are added always at the end, that > complicates things. What do others think (I don't have the feeling that > large drawers are very common). >
Re: org-cite styles don't allow * in them
I agree. 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 Fri, Apr 22, 2022 at 8:57 AM Bruce D'Arcus wrote: > On Thu, Apr 21, 2022 at 4:06 AM Nicolas Goaziou > wrote: > > > If there's no objection, I'll add asterisk character to the list of > > allowed characters in citation style. > > > > More generally, what other characters should be allowed ? > > This request is to accommodate latex command names, and the only > non-letter characters those use are asterisks. > > I think it's fine to stop there. > > Bruce > >
Re: [PATCH] oc-basic: Detect malformed bibtex bibliographies
I would see if you can cache the result and not do it more than needed; it
can add a performance issue on large files.
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, Apr 20, 2022 at 8:39 AM Bruce D'Arcus wrote:
> On Wed, Apr 20, 2022 at 8:28 AM Ihor Radchenko wrote:
> >
> > There is an edge case triggering infinite loop in oc-basic.
> >
> > It is caused by bibtex-map-entries (used in
> > org-cite-basic--parse-bibtex) when ran on a malformed bibtex buffer [1].
> >
> > The proposed patch validates the bibtex buffer before processing and
> > throws an error if issues are found. `bibtex-validate` also
> > conveniently displays a list of errors with clickable links to
> > problematic lines.
> >
> > I believe that it is useful for the users to see such issues instead of,
> > say, failing silently on malformed bibliographies.
> >
> > WDYT?
>
> I haven't tested it, but this is an excellent idea!
>
> Bruce
>
> > Best,
> > Ihor
> >
> > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55036
> >
> > * lisp/oc-basic.el (org-cite-basic--parse-bibtex): Validate the
> > bibliography before parsing. Display list of issues if any (via
> > `bibtex-validate`).
> > (org-cite-basic--parse-bibliography): Set buffer file name needed by
> > `bibtex-validate`. Empty the cache in case of error.
> > ---
> > lisp/oc-basic.el | 38 --
> > 1 file changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
> > index 873986d07..79f7a4844 100644
> > --- a/lisp/oc-basic.el
> > +++ b/lisp/oc-basic.el
> > @@ -214,6 +214,10 @@ (defun org-cite-basic--parse-bibtex (dialect)
> >(let ((entries (make-hash-table :test #'equal))
> > (bibtex-sort-ignore-string-entries t))
> > (bibtex-set-dialect dialect t)
> > +;; Throw an error if bibliography is malformed.
> > +(unless (bibtex-validate)
> > + (user-error "Malformed bibliography at %S"
> > + (or (buffer-file-name) (current-buffer
> > (bibtex-map-entries
> > (lambda (key _)
> > ;; Normalize entries: field names are turned into symbols
> > @@ -258,21 +262,27 @@ (defun org-cite-basic--parse-bibliography
> ( info)
> > (when (or (org-file-has-changed-p file)
> >(not (gethash file
> org-cite-basic--file-id-cache)))
> >(insert-file-contents file)
> > + (setf (buffer-file-name) file)
> >(puthash file (org-buffer-hash)
> org-cite-basic--file-id-cache))
> > - (let* ((file-id (cons file (gethash file
> org-cite-basic--file-id-cache)))
> > - (entries
> > -(or (cdr (assoc file-id
> org-cite-basic--bibliography-cache))
> > -(let ((table
> > - (pcase (file-name-extension file)
> > - ("json" (org-cite-basic--parse-json))
> > - ("bib" (org-cite-basic--parse-bibtex
> 'biblatex))
> > - ("bibtex"
> (org-cite-basic--parse-bibtex 'BibTeX))
> > - (ext
> > - (user-error "Unknown bibliography
> extension: %S"
> > - ext)
> > - (push (cons file-id table)
> org-cite-basic--bibliography-cache)
> > - table
> > - (push (cons file entries) results)
> > +(unwind-protect
> > +(condition-case nil
> > +(unwind-protect
> > + (let* ((file-id (cons file (gethash file
> org-cite-basic--file-id-cache)))
> > + (entries
> > +(or (cdr (assoc file-id
> org-cite-basic--bibliography-cache))
> > +(let ((table
> > + (pcase (file-name-extension
> file)
> > + ("json"
> (org-cite-basic--parse-json))
> > + ("bib"
> (org-cite-basic--parse-bibtex 'biblatex))
> > +
Re: org-cite styles don't allow * in them
On Sun, Apr 17, 2022 at 9:18 AM Ihor Radchenko wrote: > John Kitchin writes: > > > I am also not a fan of using Unicode here and prefer a simple ascii > > asterisk. That works fine for me so far, but I am not a heavy user of > bold > > markup and citations. > > What about something like [cite/citet*/:@key]? > "*/" is not recognised as bold ending. That is a great solution when you want to have bold, and it would be optional if you don’t use bold there. You still would need to add * to the cite pattern. > > > > As I mentioned there is the same problem for links, and in the last 10 > > years I can’t recall an issue being reported with bold. > > This is because links containing "\\*[ -.,;:!?'")}\\[]" match are > extremely rare. > > In contrast, [cite/citet*:@key] is likely to be used fairly frequently > and has much higher chance to break things. We have had a citet*:key link (and all the other * variants) for a long time in org-ref, with no reported issues I can recall. > > Best, > Ihor > > -- 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: org-cite styles don't allow * in them
I am also not a fan of using Unicode here and prefer a simple ascii asterisk. That works fine for me so far, but I am not a heavy user of bold markup and citations. As I mentioned there is the same problem for links, and in the last 10 years I can’t recall an issue being reported with bold. On Sun, Apr 17, 2022 at 4:41 AM Ihor Radchenko wrote: > "Bruce D'Arcus" writes: > > >> A less awkward solution (IMO) would be to use an entity like ⋆. It is > >> straightforward to add that to the org-element-citation-prefix-re. Then > I > >> see something like this. > > > > So Ihor, is there any problem with John's proposed change here? > > I am not a big fan of using unicode characters, but otherwise I have no > objections and no better ideas (except a general desire to solve similar > parser issues more generally). > > However, I am not org-cite's maintainer. So, I would prefer to hear from > Nicolas before implementing anything myself. > > Best, > Ihor > -- 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: [BUG] org-cite does not support techreport, mastersthesis, phdthesis, and conference entries [9.5.2 (release_9.5.2-426-gf6813d @ /usr/share/emacs/site-lisp/org/)]
I guess this could be related to the dialect of the bibtex file. If it is BibTeX, then org-cite-basic--parse-bibtex finds conference and masterthesis for me, and probably anything defined in bibtex-entry-alist. Things that are not in that list would probably be ignored. This is outsourced to bibtex.el. #+BEGIN_SRC emacs-lisp (mapcar 'car bibtex-entry-alist) #+END_SRC #+RESULTS: | Article | InProceedings | Conference | InCollection | InBook | Proceedings | Book | Booklet | PhdThesis | MastersThesis | TechReport | Manual | Unpublished | Misc | if the file has a biblatex dialect then these are the entries that can be parsed. #+BEGIN_SRC emacs-lisp (mapcar 'car bibtex-biblatex-entry-alist) #+END_SRC #+RESULTS: | Article | Book | MVBook | InBook | BookInBook | SuppBook | Booklet | Collection | MVCollection | InCollection | SuppCollection | Dataset | Manual | Misc | Online | Patent | Periodical | SuppPeriodical | Proceedings | MVProceedings | InProceedings | Reference | MVReference | InReference | Report | Software | Thesis | Unpublished | If you open your bibtex file and type C-h v bibtex-dialect, or check that in the Entry-Types menu you can see what the dialect is. 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 Fri, Apr 8, 2022 at 7:10 AM Eric S Fraga wrote: > On Friday, 8 Apr 2022 at 00:44, Olaf Trygve Berglihn wrote: > > When using the @techreport, @mastersthesis, @phdthesis, and @conference > org-cite > > fails to find the entry. Export to some formats fails due to this. > > I have tried this and it is true that org cite fails but only for > mastersthesis and conference, in my case, with org up to date as of a > few minutes ago. > > According to https://www.bibtex.com/e/entry-types/, conference as a type > was only included for compatibility with Scribe (as either proceedings > or inproceedings do the job) but the others are definitely in the list > and should be supported, I guess. > > -- > : Eric S Fraga, with org release_9.5.2-426-gf6813d in Emacs 29.0.50 > >
Re: org-cite styles don't allow * in them
On Thu, Apr 7, 2022 at 12:17 AM Ihor Radchenko wrote: > "Bruce D'Arcus" writes: > > > On Sun, Apr 3, 2022 at 5:07 PM John Kitchin > wrote: > >> > >> I was looking into using latex commands as styles in org-cite, e.g. > >> > >> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is > not allowed. Could that be allowed? > > > > I have no insight into the restriction, but I hope it can be removed. > > I do like the proposal in general, but I can see a potential issue for > users. Constructs like "word*:" can be recognised as a valid bold > emphasis ending. For example: > > >>> Some *bold emphasis with reference [cite/citet*:@key] will end > >>> at "citet*", but not here*. > That is a fair point, and also an issue with links that have * in them (which is also already allowed). I can't say it has ever been reported as an issue though. > > Note that inserting zero-width space will not only be awkward here, but > also breaks parser: e.g. [cite/citet:@key] is not currently > recognised as a citation. A less awkward solution (IMO) would be to use an entity like ⋆. It is straightforward to add that to the org-element-citation-prefix-re. Then I see something like this. [image: image.png] I don't know how difficult it would be to improve the emphasis handling, it seems like the start/end markers should not cross some element boundaries. > > Best, > Ihor >
Re: org-cite styles don't allow * in them
Would you find it suitable to use [cite/command:pre @key post] in general? For portability, I suppose there could be a defcustom mapping if one wanted to leverage the oc-csl library with pretty minimal effort. I think two things need to be addressed to fix that. First is allowing a * in the style/variant section; there are probably 17 or so of these commands in natbib/biblatex. Second is fixing org-activate-link so that link activation functions don't get called on something like [cite/citet:@key]. This is necessary for org-ref and org-cite to co-exist, but also other packages or users might also define links like cite:. 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 Tue, Apr 5, 2022 at 11:56 AM Bruce D'Arcus wrote: > On Sun, Apr 3, 2022 at 5:07 PM John Kitchin > wrote: > > > > I was looking into using latex commands as styles in org-cite, e.g. > > > > [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is > not allowed. Could that be allowed? > > I have no insight into the restriction, but I hope it can be removed. > > It occurs to me in that scenario it should be easy to write a function > that allows users to toggle between the two sets of styles: the direct > latex ones, and the more general default org-cite ones. > > Bruce >
overlap between cite syntax and link activation
I think there is some overlap between the org-cite syntax and org-link activation. Consider this org-cite: [cite/noauthor/bare:@key] Now define this link: #+BEGIN_SRC emacs-lisp (org-link-set-parameters "bare" :help-echo "BARE LINK" :activate-func (lambda (start end path _bracketp) (message-box "%S activating bare" (list start end path)) (put-text-property start end 'face '(:foreground "OrangeRed1" #+END_SRC When I put my cursor on the org-cite line and press spc, I see a message box pop up, and the @key has a tooltip of "BARE LINK". I guess this means the activate-func is being used too aggressively. It looks like it is called after (re-search-forward org-link-any-re limit t). This does seem to match the cite syntax above. Does anyone else see this? 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
org-cite styles don't allow * in them
I was looking into using latex commands as styles in org-cite, e.g. [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not allowed. Could that be allowed? 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: citations: org-cite vs org-ref 3.0
Max Nikulin writes: > On 28/03/2022 20:16, Bruce D'Arcus wrote: >> On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote: >>> >>> John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) >>> https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly >>> stated a technical limitation that is a real reason why org-cite is not >>> an option for you and for some other users: performance has not been >>> optimized for large BibTeX databases. It is deserved to be mentioned. >> >> FWIW, Ihor posted a patch related to this a week or so ago. > > I am optimistic concerning that patch since a couple of users confirmed > improvement, but it is up to John to decide if it is acceptable in > comparison to org-ref. I am unsure concerning startup time. I think this will be a problem that is processor specific. It is important that org have a reasonable performance here, but I don't think it was a goal to have the fastest bibtex/json/etc. parser available, just a reasonable default that works out of the box. That is, it doesn't take too long to read the database for insertion, and fontification is not a performance breaker, on say a moderate sized database and org-file. Getting high performance from large databases and large files with lots of citations (say a dissertation or big review article) takes some work. -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
Max Nikulin writes: > On 21/03/2022 18:51, John Kitchin wrote: >> citenum and bibentry are the only two I am not sure have a CSL analog. > > I read your messages once more and I should say that I feel some disagreement > of > this one (I removed most of it) and the earlier and longer one from Sun, 20 > Mar > 2022 20:31:29 -0400 https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu > > I admit that org-ref is carefully tuned to your workflow. I hope, it is > possible > to left aside decomposition of org-cite into modules for some time. > > Let's assume org-cite with natbib backend for citations and org-ref for > cross-references. It seems, a couple of missed styles currently is not a > problem > due to the defcustom for the mapping. > > Are there still any technical limitations that prevent getting in the exported > LaTeX file the same citation commands as for org-ref? If all one wants is LaTeX export, there are not technical limitations. That is not all people want in general though, they also want other exports, and that they are reasonably similar, or even possible. It is easy to get \citenum and \bibentry for LaTeX. I promise though, someone wants this or some other thing for HTML. Rather than rehash a lot of experiences, I really encourage you to try writing a processor that can support this. Or even, try modifying org-ref-cite to support it. Not as some thought experiment about what should be possible, but an actual experiment that is worked out. > In particular I am worrying concerning https://github.com/jkitchin/org-ref > README (and the same phrase from the earlier message): > >> org-cite does not meet my citation and technical document publishing needs, >> and it was not possible to integrate it into org-ref without compromising >> those. I have taken this out of the readme. I still agree with the sentiment, but my needs are not the same as others (for example, I include in my needs include ease of support and development, which is not a user need), and it is possible to meet some basic needs fully. > Does it refer to exported result or to convenience of working with citations? > Would it help if it were possible to choose style by its natbib command? > > I see that you do not like org-cite styles, but I can not figure out what are > the real blockers that prevent producing documents having the same > quality. If you spend enough time teaching people how to use these things, you might feel differently about this. It is so easy to just switch away to Endnote, Papers, Paperpile, Mendeley, Zotero, Overleaf, etc. I guess I am not on the prevailing side here though. -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
Nicolas Goaziou writes:
> Hello,
>
> John Kitchin writes:
>
>> I do not think it is productive for the community to say or consider it
>> is a sad situation. Many good things have emerged from these
>> discussions, even if it is not yet consensus on a solution. It is a
>> complex problem, with many years of effort by many people on each side.
>> That is an indication of how ambitious this project is and that there
>> may be more than one solution that is needed.
>
> [...]
>
>> There are more than 8 years of legacy org-ref documents. I have written
>> 40+ scientific papers with it, and countless technical documents with
>> more than 8000 cite links among them. org-ref has exceeded 190K
>> downloads from MELPA, so I feel obligated to maintain org-ref for
>> myself, and those users. org-ref may be heavyweight in bundling a lot of
>> capability together that could be separated into individual packages,
>> but it is also convenient for people who need it, and a GitHUB issue or
>> pull request away from new features. I remain committed to supporting
>> this, and I do it in a way I can manage, hence the monolithic package
>> design.
>
> I think there's a misunderstanding here. Org Cite was never meant as
> a replacement for Org Ref. It was designed from the beginning as
> a framework other libraries could rely on and extend in their own way.
> Org Ref could have been one of them.
>
> It looks like a social problem to me. I remember well asking for
> feedback when implementing the various prototypes, i.e., ways to make
> Org Cite more useful to other libraries. I don't think I got much of it,
> barring the cross-references topic, which is not solved. Maybe I was not
> explicit enough about what I was expecting. For example, this is—please
> correct me if I'm wrong—the first time I read about the "BibLaTeX is not
> fully implemented in Org Cite" and "Org Cite is adding an extra
> abstraction layer on top of BibLaTeX commands" issues, which are both
> trivial to solve, either on the Org Cite or the Org Ref side. But then
> again, it is perfectly fine if Org Cite doesn't provide that, as some
> libraries can extend it if needed.
I don't think it is the first time I have mentioned biblatex is not
fully implemented, but I am not sure. I have mentioned things like
\citenum somewhere, but it is not the main point.
I know it is not that difficult to add support for LaTeX export in
org-cite, e.g. [cite/num:]. I don't think it is all that easy to add
additional backend support though, for something like [cite/num:] in
HTML or other backends. No doubt, it is not impossible, if someone would
just do it, and that might include extending citeproc too, or developing
some pre-processing function to get a citation number, or something
else. Whether cite/num or any other command exists is not the main
point. What is the point is what mechanisms exist to support the
addition, and the exports to various backends.
Regarding that org-cite adds an abstraction layer, how else could one
interpret this (from
https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax)
other than abstraction:
[cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}?
Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even,
\citenum?
I get it, you can define [cite/noauthor/year:] or even [cite/year:] or
[cite/y:] and even [cite/citeyear:] to get the command in there, and
something for each of those other ones. Maybe even the documented
convention will change to some other potentially mnemonic form.
I also get they are not all that common perhaps, except for a few people
who use them, and maybe should be responsible for supporting it
themselves, either by defcustom or their own library.
This is just trading a proliferation of links for a proliferation of
styles IMO, and it feels a lot like the XKCD standards issue
https://xkcd.com/927/.
As others have argued, it is just a bit of knowledge, maybe a UI can
compensate to help you insert what you want, then know what it means
later. It is my opinion that this will be a technical debt though. I am
content to agree to disagree on this point.
It might be a social problem, and I do not think it is trivial to solve.
It is not just about having a syntax that works. I wrote and shared a
whole set of processors for org-cite that did or tried to do all those
things above. It was fine to use, but it was very difficult code to
write for me. I don't personally want to support it in part because it
was so difficult to write. I don't even want to support it for my own
use at this time. This should not stop anyone who wants to do that
themselves though. Maybe there is a cleaner approach I missed, or others
may be better programmers, and/or have more time to figure this out. At
this time, I do
Re: citations: org-cite vs org-ref 3.0
Nicolas Goaziou writes: > Hello, > > Max Nikulin writes: > >> Nicolas, concerning a new thread, I have an impression that you are >> busy with over activities since you are participating in discussions >> not so frequently. So I am unsure at which moment it is appropriate to >> raise such question that otherwise may just be buried in the list >> archive. > > I don't see how my presence (or not) on the list relates to this. If > there's an idea worth a discussion, it should not be buried within > a thread. > >> Outside of Org, citations are links. > > But we're on an Org mailing list so… > >> I consider fixed set of properties as a problem. > > I don't think it is a problem for citations. > >> At first I tried to draw attention to additional link attributes. > > I think link attributes were discussed a couple of times on this ML > already. Nothing was implemented tho. I don't think any further implementation outside the existing link framework is required to do this. The only limitations of the current framework are (I think) it is limited to a single line (i.e. not multiline), and it would be difficult to have nested links. Otherwise, you can put most things in the path, and then parse it as you see fit. I think it would be interesting to couple this with a recursive descent parser one day, and some DSL perhaps. There is a prototype of this idea at https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ I wouldn't claim it is the best way to do that, or the right thing to do. scimax-editmarks is a step further (https://github.com/jkitchin/scimax/blob/master/scimax-editmarks.org) that doesn't use org-links or any org-syntax for something more like an inline object. It mostly addresses the multiline issue, but it also doesn't support nested objects, mostly because of my limited knowledge of recursive parsing. I would not advocate for putting this in org either though. If you are interested in this kind of thing, you might find https://www.emacswiki.org/emacs/linkd.el interesting too. It leverages an S-expression approach, which makes the parsing and nesting more straightforward. I know this is a little off-track of the original thread, but I agree with Nicolas that it does not seem necessary at this point to add this into org. > > I'm not convinced Org should generalize this to any inline object, > either, mainly because it sounds messy. Of course, if you have an > idea on the subject, please share it. > > In any case, this is another topic, neither related to citations nor to > cross-references. > >> For citations some values may be passed to specific citation backend >> overriding default value derived from style. > > In that situation, you can define a new style specific to the citation > back-end. > > Regards, -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
I have updated the readme in org-ref to indicate you can use both packages. Max Nikulin writes: > On 21/03/2022 18:51, John Kitchin wrote: >> Vikas Rawal writes: >>> >>> From the perspective of a user, this was only meant to express a >>> sentiment that one finds oneself in a situation of having to choose >>> between two good things, and that we have not been able to find a way >>> to make both compatible with each other. It was in not meant as a >>> disrespect in any way. >> I don't think you have to choose. You can use org-cite for >> citations, and org-ref for cross-references. The citation syntax is >> orthogonal, you just should not mix them. You can even wire org-ref to >> use org-cite-insert like this: >> (setq org-ref-insert-cite-function (lambda () (org-cite-insert nil))) > > I am glad to read this. John, could you, please, update the README file for > https://github.com/jkitchin/org-ref to clarify that both packages may be used > within the same document while org-ref is used solely for cross-references (I > may create a github issue if your prefer)? From my point of view the following > phrase may be considered as prohibitive in respect to combining the packages > for > any purpose: > >> You can use both org-cite and org-ref (although you should not do that in the >> same document as they are independent citation tools). > I feel some ambiguity in the starting message in this thread: > > Vikas Rawal, Sun, 20 Mar 2022 17:38:30 +0530. > https://list.orgmode.org/caltzab2bhuldoxaamuzfqh2h453ekb6k7bkohbu-dhpn98a...@mail.gmail.com > >> This obviously creates many problems including that two people using >> different citation systems cannot share org files. > Accordingly to the org-ref README installed org-ref package does not break > org-cite, so people are free to share documents. They just should have both > packages configured and should adhere to a chosen package in each document > (for > *citations*). -- 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 Pronouns: he/him/his
Re: [oc] provide style/citation preview?
I think this kind of preview is well-suited for external packages. There is a subtle point I ran into with this preview approach though, and that is what is the backend export you want to see? People expect one source (org) to export to different backends, and even use one source to make a PDF and HTML (and maybe others). Now it also possible to use different citation styles for different backends, and the backends may use different citation processors (e.g. bib(la)tex or CSL). I felt this was too complex to try to get right in one package. External packages could provide any subset of these they want, e.g. the way https://github.com/andras-simonyi/org-cite-csl-activate does. My opinion of course. I think the basic CSL styled citation tooltip that is independent of the final state is a good compromise. The point is to give enough context about the key to tell you what it is without visiting the source, and if you need more, you go visit the source (bibtex file, org file, etc.). "Bruce D'Arcus" writes: > On Thu, Mar 24, 2022 at 12:33 PM Vikas Rawal wrote: > >>> So I'm just wondering how best to dynamically generate those previews, >>> perhaps even just using a pre-selected reference*, and if maybe oc >>> could make that easier? >>> >> >> Some kind of overlay that shows citations as they would (at least as close >> as possible) look in the export? > > Something like this? > > https://github.com/andras-simonyi/org-cite-csl-activate > > I think he was hoping to incorporate that into the oc-csl processor at > some point, and that would indeed be another approach to in-buffer > previewing. > > The issue I have is more just generating the preview content for > incorporation into the completion annotations. > > Bruce -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
"Bruce D'Arcus" writes: > On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin wrote: > > ... > >> A bit of routine work will alleviate some user issues: >> - add missed styles > > The initial list of style-command mappings was pretty comprehensive, > but we left out some of the more obscure biblatex commands because > unsure if they were needed, or how best to add them (conceptually > there's a mix of different kinds of commands in biblatex, which are > hard to fit into a more general style system, for example). > > Since then: > > - people have occasionally asked to add new mappings, and Nicolas has added > them > - he's also added the styles defcustoms for biblatex, so users can do > this themselves > > In short, I think we're good on this actually. > >> - improve documentation, e.g. to make backend choice more conscious. > > This is the bigger user-facing issue that could use attention. > >> Another point is more serious. Besides citations there are internal >> cross-references. Org supports them but only in a rudimentary form. > > Indeed, the question of how to better support cross-references in org > is an important one. > > I don't really use them much, and so am still unsure if this could be > addressed with incremental improvements in existing org link support, > or if it would require more significant enhancements. No incremental improvement is required IMO, regular links are sufficient. org-ref has handled these with regular links from the beginning. It even has an org-ref-refproc now for non-LaTeX exports that has some support for things like sorting, grouping and cleveref. You can find an example org file at https://github.com/jkitchin/org-ref/blob/master/examples/refproc.org, and see it in action at https://www.youtube.com/watch?v=rRR-5NSpKyE the video has some rough spots, but you can get the idea. You can support all kinds of things in these links (for example, I now support pre/post note text in the cite link paths), really anything you want to parse out of the path. > > Perhaps we need the community to itemize what the gaps and limitations > are there? > > > Bruce > >> Actually cross-references are similar to citations in the sense that >> they can have style, prefixes and suffixes, and their appearance depends >> on target properties. Another feature is grouping. However >> cross-references should not be handled by citation backends, they >> require different handlers. Unfortunately there is no way to define >> custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". >> >> I can not judge if uniform UI issues are really severe and if it would >> be convenient if depending on prefix argument either org-cite or org-ref >> command would be called for a citation or for a reference. >> >> Actually "[cite:...]" construct is a kind of link with additional >> flexibility missed for regular links. Anything besides target and >> description requires some workarounds. Usual approach is proliferation >> of link types. E.g. inline source blocks allows almost arbitrary extra >> parameters. Citation syntax is rather domain specific, it allows more >> than regular links, but for convenience the set of properties is fixed: >> style, prefixes, locators, suffixes. It is impossible to add extra one. >> >> To assign additional properties, info "(org) Links in HTML export" >> https://orgmode.org/manual/Links-in-HTML-export.html recommends usage of >> "#+ATTR_HTML", but such technique has several issues: >> - attributes becomes specific to the export backend >> - the same attributes are added to the enclosing paragraph >>https://linevi.ch/en/org-link-extra-attrs.html >> - a paragraph may have more than one link. >> It is possible to use link target similar to form values encoded into >> URI, but it hardly can be considered as convenient for editing. >> >> Custom citation types may alleviate the issue with cross-references. It >> would be great to have more flexible links with arbitrary properties >> (and it would allow to consider citations and cross-references as >> special cases of links), but it does not fit into the Org syntax. >> >> P.S. John has a valid complain but it hardly relates to the "cite vs. >> cross-reference" topic. When some package is not loaded and link type is >> undefined then the link becomes a fuzzy one leading to user confusion. >> >> -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
chris writes: > On Sunday, 20 March 2022 20:44:50 CET Bruce D'Arcus wrote: >> On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko wrote: >> > For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. >> >> Not really; or rather minimally. > > I use `org-cite` with a very minimal configuration, and it works very well. I > don't use `ivy` at all. I don't use `helm` at all. Those are very large > framework and should not be forced to people. (I don't use `org-ref`.) These days org-ref does not require helm or ivy, and it does not install them. You can use the core library with any completion backend you want. It uses vanilla completing-read. org-ref does rely exclusively on bibtex-completion at this time. I have not abstracted that out to allow pluggable alternatives like citar. > > I only use `citar` with minimal configuration. I use `vertico` for the > completion. `citar` is simple enough for me to be able to read and understand > a large part of it. > > IMO the more layers of code there are, the more difficult it is to have > things > work right. And similarly with the size of the code. > > Chris > >> >> Ivy-bibtex supports, for example, inserting of org-cite citations, but >> not via org-cite-insert. > > And I have `org-cite-insert` working straight out of the box. > >> >> So there are currently no org-cite processors for ivy-bibtex etc. >> >> Bruce -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
"Bruce D'Arcus" writes: > On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko wrote: > >> For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. > > Not really; or rather minimally. > > Ivy-bibtex supports, for example, inserting of org-cite citations, but > not via org-cite-insert. > > So there are currently no org-cite processors for ivy-bibtex etc. I think this one in https://github.com/jkitchin/org-ref-cite/blob/main/org-ref-cite-insert.el provides an insert processor based on bibtex-completion, and that provides ivy-bibtex actions. The commentary in this file also discusses some challenges in relying exclusively on completing-read. My opinion of course. I don't think you need a special processor for ivy-bibtex. It could be wired to insert org-cites on its own. > > Bruce -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
Bruce and I looked into this UI approach in https://github.com/jkitchin/org-ref-cite/issues/9. Bruce and I discussed and worked on this for almost two weeks. There are 70 comments in this issue. There are opportunities now to annotate completion targets, which you can see in the link above. The annotations are not selectable though during completion, and this implementation was not too fast as I recall. You probably should also augment the tooltips like this because you have to be able to tell what a citation format is in the future too, not just at insert time, e.g. suppose you are reading work of a collaborator. It was hard to write, and ambiguous in ways, e.g. what is the export backend you want? The annotations should differ for LaTeX (where you want to see the latex command) vs HTML (where you probably want to see the formatted CSL cite)... We did not surmount these challenges at the time. Maybe others will succeed in this another day. 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, Mar 21, 2022 at 8:42 AM Bruce D'Arcus wrote: > On Mon, Mar 21, 2022 at 8:23 AM John Kitchin > wrote: > > >> A package could be created, say `org-cite-literal-biblatex' which is > just a copy > >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' > and > >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in > >> `org-cite-biblatex'). As far as I can tell this would provide exactly > the > >> functionality you say org-cite can’t provide but org-ref does. > > > > > > I wrote this package you suggest in org-ref-cite. In discussions during > that development, it was clear the preference was on the more abstracted, > and uniform syntax across backends cite commands in org-cite, and not this > kind of variant. Of course one can do this. It is not that org-cite can't > provide it, it is that it doesn't at this time. > > Just for some broader context on this particular issue. > > The advantage of the org-cite style/variant design reflected in the > included export processors (natbib, biblatex, csl) is that the same > styles will mostly generate the same final output. > > But that portability will only work with those styles and variants. > > With the new org-cite-biblatex-styles defcustom, however, one can > augment or completely replace all those. But if you care about that > portability, you'd want to be aware of this, and think about it. > > So per Timothy's point, you actually don't even need a new processor > for biblatex if you want to include all the extensive list of biblatex > commands. > > Natbib AFAIK is already fully covered. > > There's another POV on this though: > > If one doesn't like to see the org-cite styles, because of familiarity > with LaTeX commands etc., I would argue that can be addressed in the > style part of an insert processor and/or in an activate processor. > E.g. I would argue this is a UI issue; not fundamentally about the > styles names. > > Bruce >
Re: citations: org-cite vs org-ref 3.0
e if a user chooses to use > org-cite. Do the capabilities of cross-referencing have to be wedded > to the citation system? They don't have to be integrated. Someone could separate out that functionality. I don't have unlimited time to spend on these things, and org-ref is designed with the constraints I have so that I am able to develop and support it. That is all you should read into this. I don't have the time or energy develop and maintain separate packages that I use together. I do not want to separate org-ref into separate core packages for cross-references, indexes, glossary/acronyms, bibtex utilities, and packages that integrate helm, ivy, etc. > > Can this not be resolved? > > I am content to agree to disagree on these points and move forward with > both packages because they solve different problems, are suitable for > different communities, and they continue to benefit each other. > > Friendly co-existence should be our goal. But can that be a situation > in which one is able to choose between the best of both and, as far as > possible, switch from one to the other. As far as I can tell, you can already do this. > > Thanks again for your time and effort, > > Vikas -- 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 Pronouns: he/him/his
Re: citations: org-cite vs org-ref 3.0
On Sun, Mar 20, 2022 at 9:57 PM Timothy wrote:
> Hi John,
>
> Thanks for your considered response.
>
> When you contrast org-cite and org-ref, you say:
>
> > With org-ref, bib(la)tex export is almost fully supported, and is easy,
>
> I find this odd as org-cite supports bib(la)tex export, and rather easily.
>
> ┌
> │ #+bibliography: references.bib
> │ #+cite_export: biblatex authortitle/authortitle-ibid
> │
> │ [cite:@key] etc.
> │
> │ #+print_bibliography:
> └
>
> The limitation which I think is on your mind is that not all bib(la)tex
> commands
> are supported, and not in the “usual” form. For instance, to get
> `pnotecite' one
> would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, you
> can just
> customise `org-cite-biblatex-styles'. For instance, `parencite' is not
> currently
> available, but if I just add `("parencite" nil "parencite" nil nil)' I can
> then do
> `[cite/parencite:]' or if I replace the first `"parencite"' with
> `"paren"', just
> `[cite/paren:]'.
>
Yes, of course I mean the citation commands.
>
> A package could be created, say `org-cite-literal-biblatex' which is just
> a copy
> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and
> `org-cite-biblatex-style-shortcuts' (or just sets those variables in
> `org-cite-biblatex'). As far as I can tell this would provide exactly the
> functionality you say org-cite can’t provide but org-ref does.
>
I wrote this package you suggest in org-ref-cite. In discussions during
that development, it was clear the preference was on the more abstracted,
and uniform syntax across backends cite commands in org-cite, and not this
kind of variant. Of course one can do this. It is not that org-cite can't
provide it, it is that it doesn't at this time. Even so, it is only a
partial solution to deprecating org-ref.
>
> You can already use `.bib' files, and so frankly I cannot myself see the
> point in
> org-ref’s existence beyond bifurcating the community on this. At this
> point the
> only remaining motivation I see is old documents and current users, and
> for this
> a migration tool seems more appropriate.
> I don’t mean to be overly critical, however this is my current honest
> assessment
> of the situation.
>
> –
> All the best,
> Timothy
>
> John Kitchin writes:
>
> > I do not think it is productive for the community to say or consider it
> > is a sad situation. Many good things have emerged from these
> > discussions, even if it is not yet consensus on a solution. It is a
> > complex problem, with many years of effort by many people on each side.
> > That is an indication of how ambitious this project is and that there
> > may be more than one solution that is needed. It pains me quite a bit
> > there is a sentiment of fractionation, and that I may be contributing to
> > it.
> >
> > My regular job workload the past few years has been crushing, and I have
> > not had the time to participate in this that I wish I had. I am not sure
> > I can add much here without sounding or feeling defensive about org-ref,
> > and my decision to continue supporting and developing it. I have thought
> > about this for most of the day, and in the (very long, apologies in
> > advance) response that follows I will do my best to provide a balanced
> > perspective (from my point of view) on the situation.
> >
> > Some specific context that is important to me is that I wrote org-ref
> > long ago to solve a specific problem for me in the preparation of
> > scientific publications that are destined for LaTeX export. I intended
> > it to provide nearly equivalent bib(la)tex citation export, and as
> > reasonable an export as possible for everything else. I use org-ref
> > professionally, and it is a complete solution for me. I simply cannot
> > compromise on the capability org-ref provides me, or wait for an
> > alternative complete solution in org-mode. I have work I have to do now,
> > and org-ref lets me do it. This alone is reason enough for me to
> > continue using, developing and supporting org-ref. I understand org is
> > not intended to be a substitute for writing LaTeX, but it is a fact of
> > my job that I have to do that.
> >
> > There are more than 8 years of legacy org-ref documents. I have written
> > 40+ scientific papers with it, and countless technical documents with
> > more than 8000 cite links among them. org-ref has exceeded 190K
> > downloads from MELPA, so I feel obligated to maintain org-ref for
> > myself, and those users. org-ref may be heavyweight in bundling a lot of
>
Re: citations: org-cite vs org-ref 3.0
rned a lot studying the org-cite code, but I will be honest that I find it difficult to make contributions to. That gave me pause in continuing to develop it. It is fair to say that org-cite showed me some ways to address limitations of org-ref that I did not see before, org-ref is better for it, and the writing community that uses pre/post notes and biblatex is much better served as a result. Where does this leave me, org-ref and org-cite? I still have differences of opinion on design choices between them, and those differences are likely irreconcilable. These differences arise from my experiences in writing, teaching, using, developing and supporting org-ref. For those who need high fidelity LaTeX export like I do, I think org-ref is still a superior solution. For everyone else, and especially if you do not need sophisticated cross-references and don't want the dependencies of org-ref, org-cite is likely the better solution. I am content to agree to disagree on these points and move forward with both packages because they solve different problems, are suitable for different communities, and they continue to benefit each other. I can see not everyone sees this as a positive situation though, and that has weighed heavily upon me lately. These times are heavy enough. Anyway, this turned out much longer than I expected, so thanks everyone who has contributed to making org better, I hope I got things mostly correct, you found it a fair assessment, we might still be friends, and thanks for reading to the end. j Nicolas Goaziou writes: > Hello, > > Vikas Rawal writes: > >> This obviously creates many problems including that two people using >> different citation systems cannot share org files. > > Indeed. >> >> What is the general view of the community about this? > > I don't know about the general view of the community, but, as a data > point, I find it very sad. > > That's not helpful, tho. > > Regards, -- 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 Pronouns: he/him/his
Re: org-cite and org-ref-cite
I would not recommend org-ref-cite (https://github.com/jkitchin/org-ref-cite). It was an early approach to trying to integrate org-ref with oc-cite. As far as I know, it worked fine for that, and was pretty complete for citations, but I have abandoned this approach and archived the repo. If anyone would like to take over this repo I would be happy to transfer it. If you are looking for something above and beyond the default oc-cite capabilities, https://github.com/bdarcus/citar is probably a better choice than org-ref-cite as it is actively developed. 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, Feb 26, 2022 at 8:42 AM Henrik Frisk wrote: > > > Den fre 25 feb. 2022 kl 13:56 skrev Eric S Fraga : > >> On Friday, 25 Feb 2022 at 08:50, Henrik Frisk wrote: >> > The only thing I can't seem to sort out is to change the style of the >> > citation. Regardless where I do it I get the error "Wrong type >> > argument: org-cite-processor," >> >> It would help if you could post a minimal example. >> >> Of course, I should have done it right away. This is related to > org-ref-cite: > > If I click on a reference, say [cite/t:@Smith2022] I get a hydra menu in > which I can choose 's: Change style'. Choosing that generates a 'Wrong > type argument: org-cite-processor,' message. Same if I do C-u C-c \ to > insert a new refernce and choose style. > > > >> > Another question: if I would like to export to LaTeX but with citation >> > commands rather than formated citations, would that be possible? I am >> > sorry if I'm missing something obviuos. >> >> Yes, definitely possible. I have the following: >> >> #+cite_export: bibtex plain >> >> Excellent, that was what I was looking for. Thanks! >> > > /Henrik > >
Re: Footnote tooltips (an attempt)
that is a nice solution. I probably should have read the docstring on org-footnote-get-definition a little more closely, it has the definition you need in it! John --- John Kitchin (he/his) Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore On Wed, Feb 23, 2022 at 9:04 PM Juan Manuel Macías wrote: > Hi John, > > John Kitchin writes: > > > I think this might be a simpler approach. what you want (I think) is > > to leverage font-lock on tooltips to set a help-echo function instead > > of a string. You can override org-activate-footnote-links with an > > advice (which makes it easy to undo of you need). The tooltip function > > then looks up the tooltip when you ask for it. The 3 pieces are below. > > the first function looks up and returns a tooltip. the second is a > > lightly modified version of org-activate-footnote-links which just > > replaces the footnote reference string with the first function. the > > last piece is the override advice. you could use a minor mode to > > toggle the advice on and off. > > Thank you very much for your comment and code, which has helped me to > clarify my ideas. Your approach is in a certain way similar to the last > version of my attempt, which I attached in the previous message: through > a first function I get the definition of each note, which is returned as > a text string. And I also override via `advice-add' > 'org-activate-footnonte-links' with a new function, which is also > slightly modified, including a variable that gets the tooltip from the > first function. The problem is that with my approach the tooltip does > not appear on the fly, but when the next note is added. I think what my > first function (the one that gets the footnote definition) was missing > was the three arguments of your first function: `_win _obj position' and > the (goto-char position), and pass it as a symbol (not as a variable) to > the second function that overrides org-activate-footnote-links, as you > do in your code. Modifying my function from your code, it would look > something like this: > > (defun my-org-fn-get-def (_win _obj position) > (save-excursion > (goto-char position) > (let* ((el (org-element-context)) >(label (org-element-property :label el)) >(def (nth 3 (org-footnote-get-definition label > (when def (concat "Footnonte: " def) > > And it seems that now the tooltips appear instantly, and are updated in > real time. > > Best regards, > > Juan Manuel >
Re: Footnote tooltips (an attempt)
I think this might be a simpler approach. what you want (I think) is to leverage font-lock on tooltips to set a help-echo function instead of a string. You can override org-activate-footnote-links with an advice (which makes it easy to undo of you need). The tooltip function then looks up the tooltip when you ask for it. The 3 pieces are below. the first function looks up and returns a tooltip. the second is a lightly modified version of org-activate-footnote-links which just replaces the footnote reference string with the first function. the last piece is the override advice. you could use a minor mode to toggle the advice on and off. #+BEGIN_SRC emacs-lisp (defun footnote-reference-tooltip (_win _obj position) "Get footnote contents" (save-excursion (goto-char position) (let* ((fnf (org-element-context)) (label (org-element-property :label fnf)) (p (nth 1 (org-footnote-get-definition label (when p (goto-char p))) (let ((fnd (org-element-context))) (string-trim (buffer-substring (org-element-property :contents-begin fnd) (org-element-property :contents-end fnd)) (defun footnote-tooltip (limit) "Add text properties for footnotes." (let ((fn (org-footnote-next-reference-or-definition limit))) (when fn (let* ((beg (nth 1 fn)) (end (nth 2 fn)) (label (car fn)) (referencep (/= (line-beginning-position) beg))) (when (and referencep (nth 3 fn)) (save-excursion (goto-char beg) (search-forward (or label "fn:")) (org-remove-flyspell-overlays-in beg (match-end 0 (add-text-properties beg end (list 'mouse-face 'highlight 'keymap org-mouse-map 'help-echo (if referencep #'footnote-reference-tooltip "Footnote definition") 'font-lock-fontified t 'font-lock-multiline t 'face 'org-footnote)) (advice-add 'org-activate-footnote-links :override 'footnote-tooltip) #+END_SRC John ------- John Kitchin (he/his) Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore On Wed, Feb 23, 2022 at 2:52 PM Juan Manuel Macías wrote: > Hi Samuel, > > Samuel Wales writes: > > > what a great idea. i am interested in your comments. emacs has lots > > of tooltip-related features. eldoc, help-at-pt, mouse-avoidance, etc. > > you don't want tooltips when your mouse happens to end up over. or > > for your mouse to go haywire just because you ended up over. i ran > > into a lot of confusion with various mechanisms. > > > > [e.g. i like having tooltips in echo area, and don't like eldoc for > > function sigs, and do want cursor/mouse consistency.] > > > > i found that some tooltip features actually break others. just > > wondering if you noticed this and what you think of it. > > I don't have much experience with Emacs tooltips and I haven't studied > them much, because I hardly use the mouse in Emacs :-) But I noticed > that you can also display the content of a tooltip in the echo area, > with `' (`display-local-help'), or even set to non-nil > `help-at-pt-display-when-idle' and evaluate `help-at-pt-set-timer', so > that a tootltip is displayed at point; and in this scenario, they can be > useful to me to quickly have some type of information. > > You can also set this variable to force tooltips always in the echo > area: > > (setq tooltip-use-echo-area t) > > Anyway, I haven't given up on the idea of footnote tooltips yet. Here's > a new version of the code I attached in my first post in this thread, > and I think it's simpler now and works better, though I don't know if it > might have any side effects... Footnote tooltips are activated with the > minor mode `my-org-fn-tooltip-mode'. > > A new demo video: > > https://cloud.disroot.org/s/sBGJjCzbYgYbn5k > > Best regards, > > Juan Manuel > >
Re: processing of babel blocks and select_tags
I guess that is just expanding the src blocks, not actually running them. I couldn't find where that happens though, it is early in the export process I think. Maybe you can just use a preprocessing hook to export to org, which should only include the selected sections, then export that to what you want. 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 Fri, Feb 18, 2022 at 7:07 AM Eric S Fraga wrote: > Hello all, > > TL;DR: can I have org completely ignore src blocks in non-selected > sections during export without using COMMENT? > > Longer version: I am in the process of writing a book. I prefer to have > all the content in one file and use SELECT_TAGS to limit the export (for > formatting) to the current section I am working on. > > I have noticed that all org babel src blocks are processed in some way > even if (a) they are not in a selected section and (b) have, for > instance, ":eval no-export" set. For some of these blocks, the > processing time appears to be quite significant, e.g. if they have a > ":var x=somebigtable", but I could be wrong about this, of course. > > I do not understand why these src blocks are processed at all. Is there > some way to stop them being processed? I know I could "comment" out all > other sections but that's a lot more work and messy than simply tagging > the current section to be selected. > > Attached is a minimal example. When I export, I see these messages: > > org-babel-exp process julia at position 162... > org-babel-exp process julia at position 384... > > Thank you, > eric > > -- > : Eric S Fraga, with org release_9.5.2-385-g37d8bc in Emacs 29.0.50 >
Re: ob-powershell fixes, looking for original author
I guess the author is here: https://list.orgmode.org/186354732.20201118123...@essential-it.be/ 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 Fri, Feb 18, 2022 at 7:28 AM Monstara wrote: > I already made a pull request. The repo has not been touched for about > five years, though. > > On Fri, Feb 18, 2022 at 1:56 PM John Kitchin > wrote: > >> Try posting an issue on the original repo? >> >> On Fri, Feb 18, 2022 at 2:02 AM Monstara wrote: >> >>> Hello, I found an incomplete implementation >>> <https://github.com/rkiggen/ob-powershell> of ob-powershell and fixed it >>> <https://github.com/MoisMoshev/ob-powershell>. >>> However, the original did not have a license, so it is not possible to >>> proceed further, e.g. put it up on melpa. >>> Is the original author here on the list? I think they do not have a >>> contact address on github. Also posted on reddit to no avail. >>> >>> Regards, >>> Mois >>> >> -- >> 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: ob-powershell fixes, looking for original author
Try posting an issue on the original repo? On Fri, Feb 18, 2022 at 2:02 AM Monstara wrote: > Hello, I found an incomplete implementation > <https://github.com/rkiggen/ob-powershell> of ob-powershell and fixed it > <https://github.com/MoisMoshev/ob-powershell>. > However, the original did not have a license, so it is not possible to > proceed further, e.g. put it up on melpa. > Is the original author here on the list? I think they do not have a > contact address on github. Also posted on reddit to no avail. > > Regards, > Mois > -- 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: org-ref-helm-insert-cite-link (using bibtex) when exporting to html
I guess you are using the older org-ref version 2 here. If so, there isn't a real way to customize that, it comes from org-ref-get-html-bibliography which hard codes an unordered list. In version 3, you can use csl for this. 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 Thu, Feb 17, 2022 at 3:19 PM Uwe Brauer wrote: > "JK" == John Kitchin writes: >>>> >>> There aren't enough details here to figure out what you mean. The >> bibliography formatting should be determined by the CSL style. >> > I am not sure whether I should send here all my settings, but I convert > the org file either with the standard org exporter or as in this example > using org-mime-htmlize the result is an unnumbered list. > > MR2980528 <#m_-6043399637367556315_MR2980528> > > MR2779087 <#m_-6043399637367556315_MR2779087> > > MR2608125 <#m_-6043399637367556315_MR2608125> > > Bibliography > >- [MR2980528] Coutand & Shkoller, Well-posedness in smooth function >spaces for the moving-boundary three-dimensional compressible Euler >equations in physical vacuum, *Arch. Ration. Mech. Anal.*, *206(2)*, >515-616 (2012). link <https://doi.org/10.1007/s00205-012-0536-1>. doi ><http://dx.doi.org/10.1007/s00205-012-0536-1>. >- [MR2779087] Coutand & Shkoller, Well-posedness in smooth function >spaces for moving-boundary 1-D compressible Euler equations in physical >vacuum, *Comm. Pure Appl. Math.*, *64(3)*, 328-366 (2011). link ><https://doi.org/10.1002/cpa.20344>. doi ><http://dx.doi.org/10.1002/cpa.20344>. >- [MR2608125] Coutand, Lindblad, Shkoller & Steve, A priori estimates >for the free-boundary 3D compressible Euler equations in physical vacuum, > *Comm. >Math. Phys.*, *296(2)*, 559-587 (2010). link ><https://doi.org/10.1007/s00220-010-1028-5>. doi ><http://dx.doi.org/10.1007/s00220-010-1028-5>. > >
Re: org-ref-helm-insert-cite-link (using bibtex) when exporting to html
There aren't enough details here to figure out what you mean. The bibliography formatting should be determined by the CSL style. 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 Thu, Feb 17, 2022 at 10:57 AM Uwe Brauer wrote: > > Hi > > I have a small org file with some bibtex references I insert using > org-ref-helm-insert-cite-link. > > When I export the file to html, the list of reference gets a bullet > list. > > Any change to get a numerated list (I am not sure I asked that in the > past...)? > > Regards > > Uwe Brauer > > >
Re: Possible to robustly embed elisp links in source block table results?
This is not a complete answer to why this happens, but a practical one that I think is what you want. In the code below I just added | in your jq call to construct the table. I also have to use :results raw to get it to work. The :colnames did not work for me here, so I added the echo line to get column names. It is not beautiful, but it works. #+BEGIN_SRC sh :results raw echo "| column a | column b | column c|\n|-" jq --null-input -r 'range(1; 4) | tostring | [ "| A" + ., "| B" + ., " | [[elisp:(ignore \"" + . + "\")][Do it]] |"] | @tsv' #+END_SRC #+RESULTS: | column a | column b | column c | |--+--+--| | A1 | B1 | [[elisp:(ignore "1")][Do it]]| | A2 | B2 | [[elisp:(ignore "2")][Do it]]| | A3 | B3 | [[elisp:(ignore "3")][Do it]]| Tim Landscheidt writes: > Hi, > > I want org-mode to display a tab-separated values table ge- > nerated by jq that includes elisp links that do something > (differently) for each row, especially containing data that > is not displayed in other columns. > > The source block: > > | #+BEGIN_SRC sh :colnames '(Column\ A Column\ B Column\ C) > | jq --null-input -r 'range(1; 4) | tostring | [ "A" + ., "B" + ., > "[[elisp:(ignore)][Do it]]"] | @tsv' > | #+END_SRC > > evaluates to: > > | #+RESULTS: > | | Column A | Column B | Column C | > | |--+--+--| > | | A1 | B1 | [[elisp:(ignore)][Do it]]| > | | A2 | B2 | [[elisp:(ignore)][Do it]]| > | | A3 | B3 | [[elisp:(ignore)][Do it]]| > > which org-mode displays as: > > | #+RESULTS: > | | Column A | Column B | Column C | > | |--+--+--| > | | A1 | B1 | Do it| > | | A2 | B2 | Do it| > | | A3 | B3 | Do it| > > with each "Do it" being a button that, when pressed and con- > firmed, executes ignore. Great! > > Executing Emacs Lisp: > > | (org-insert-link nil "elisp:(ignore \"1\")" "Do it") > > results in the org-mode source code: > > | [[elisp:(ignore "1")][Do it]] > > so let's try jq generating that with: > > | #+BEGIN_SRC sh :colnames '(Column\ A Column\ B Column\ C) > | jq --null-input -r 'range(1; 4) | tostring | [ "A" + ., "B" + ., > "[[elisp:(ignore \"" + . + "\")][Do it]]"] | @tsv' > | #+END_SRC > > This jq call, executed in a shell, evaluates to the output > (tab-separated): > > | A1 B1 [[elisp:(ignore "1")][Do it]] > | A2 B2 [[elisp:(ignore "2")][Do it]] > | A3 B3 [[elisp:(ignore "3")][Do it]] > > When org-mode evaluates the source block, it strips it down > to: > > | #+RESULTS: > | | Column A | Column B | Column C | > | |--+--+--| > | | A1 | B1 |1 | > | | A2 | B2 |2 | > | | A3 | B3 |3 | > > where "1", "2" and "3" are not buttons or anything else but > plain text, and any other input has been permanently dis- > carded (i. e., is not just not displayed). > > If however I set ":results raw" in the source block: > > | #+BEGIN_SRC sh :colnames '(Column\ A Column\ B Column\ C) :results raw > | jq --null-input -r 'range(1; 4) | tostring | [ "A" + ., "B" + ., > "[[elisp:(ignore \"" + . + "\")][Do it]]"] | @tsv' > | #+END_SRC > > org-mode evaluates that to: > > | #+RESULTS: > | A1 B1 Do it > | A2 B2 Do it > | A3 B3 Do it > > with each "Do it" being a button that, when pressed and con- > firmed, will execute (ignore "1"), (ignore "2") and (ignore > "3"), respectively. > > So in the first and third source block, org-mode teases me > that I can embed elisp links in that very nice table format > (first source block) with "complex" Lisp code (third source > block), but when I try to combine the two (second source > block), it slaps me in the face. > > Surely I must be missing some obvious solution? Is there > another syntax I need to use? Do I need to have jq output > the raw columns A, B, D and E and then define a :post source > block that converts that to A, B and C = f(D, E)? > > My alternative and thus benchmark for such "dashboards" that > show "stuff" and offer things to do with it are derivatives > of tabulated-list-mode, but their programming requires de- > finitions of functions & Co. that need to be updated syn- > chronously; an org-mode source block on the other hand just > does what it says on the tin. > > TIA, > Tim -- 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 Pronouns: he/him/his
Re: Conversion to Jupyter notebooks
I use ox-ipynb pretty regularly to make lecture notebooks. It isn't quite like most exporters, e.g. it doesn't support all kinds of links to sections, There is support for making different versions of the notebooks though, e.g. with/without solutions, or without sections that are just for you. That should all be described in the commentary in the library. 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, Feb 7, 2022 at 5:14 AM Joost Kremers wrote: > On Mon, 7 Feb 2022, at 10:14, Ihor Radchenko wrote: > > ox-ipynb is being maintained at > > https://github.com/jkitchin/ox-ipynb > > Ah, great! I had somehow missed that... > > > -- > Joost Kremers > Life has its moments > >
Re: Missing the second '}'
depending on the file, you may be able to use M-x check-parens. I say
depending on the file because it matters how the open/close marker syntax
is defined in the file.
Or go to the beginning, and run M-x forward-sexp repeatedly until you get
an error?
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, Jan 24, 2022 at 11:02 AM Sharon Kimble
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi folks.
>
> In a document that I'm compiling I seem to have failed to close the '{'
> and '}', and the second one isn't in the document. If I write '\label{}'
> then it succeeds, but at a couple of places in the document this show
> '\label{'.
>
> How can I find where I've failed to close the brackets please, so that I
> can then achieve normality please?
>
> Thanks
> Sharon.
> - --
> A taste of linux = http://www.sharons.org.uk
> TGmeds = http://www.tgmeds.org.uk
> DrugFacts = https://www.drugfacts.org.uk
> Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.2
> -BEGIN PGP SIGNATURE-
>
> iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmHuzPAdHGJvdWRpY2Nh
> c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1vLKA//Y298U9Rb+t+VYvhy
> PepzASzFj+HDFbUUhnCouODx0fQbIxEZvi0EzRM6HgxUTTkgxOqy8puGI+XUJPdm
> ncbWyVqqA7M5xjl/w9HMX08dwd/0pIRIUmODP2IDBO2HdwyOA8QNW2Nab6/+UlMU
> leJh0263TCfpv54Dsjg1RDhNulHubKr5TNadHJDqy50dT87wSRJC2RdKFJ71ljQZ
> 4zlUzEwulvgRB+6KbxGdoEQJW61c3qM7NKz2OQSa8p3EKT/t0LZGF7ToJevZzarJ
> cunE7dbnuDPGsmNVberc572xBrqgFH7iVW3zcYwTLc2JRDL4/2BFdH1UoGaAsjyk
> 9fpgYuqLP5dgJMwBmRCYtCsvKN4VFuyk8k4zYqJx19bJIxobKuYniZtVr5joFUfV
> +jgr0ss+ZqLoQPanrrCOPycn0aVxteDVUdN+V37b1iVdDPQuanF/fkL7x59LV3pp
> C1r5N9bX3X+5bBGaO4XF5p5UnUyg19luULdIONpC94MbsxWNmUF1XWZJvR2Oh/tj
> YI5Ctw7POFITHo92TEny6kdpjtLag2+5INQajl6oQ19Lm+fmhu7/Vm4PSSm/Rybh
> KatZgvdgBHd0veollwOqwGSvopNMYPPJ6s5uT5Sop8+gM6bc1guddqdApezVB0WD
> i/fweF+vFfk7Ot14Kw8S3efgYm8=
> =XMFk
> -END PGP SIGNATURE-
>
>
Re: handling as special special block in derived export
It depends on what the src things look like. You might be able to just call
ffap or some variant of it. Here is an example of the follow part that
works for a file and url for me.
#+BEGIN_SRC emacs-lisp
(org-link-set-parameters
"rstack"
:follow (lambda (path)
(ffap (or (ffap-url-at-point)
(ffap-file-at-point)
#+END_SRC
#+RESULTS:
| :follow | (lambda (path) (ffap (or (ffap-url-at-point)
(ffap-file-at-point |
[[rstack:(("./screenshots/date-20-01-2022-time-10-36-54.png" . fade-out)
(src2 . fade-in) ("https://google.com; . fade-out))]]
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 Thu, Jan 20, 2022 at 10:21 AM Matt Price wrote:
>
>
> On Wed, Jan 19, 2022 at 12:18 PM John Kitchin
> wrote:
>
>> I am not sure this is quite what you are looking for. You could use a
>> macro like this.
>>
>>
>>
>> {{{r-stack(((src1 . fade-out) (src2 . fade-in) (src3 . fade-out)))}}}
>>
>> * code :noexport:
>>
>> #+macro: r-stack (eval (r-stack $1))
>>
>> #+BEGIN_SRC emacs-lisp
>> (defun r-stack (src-alist)
>> "SRC-alist will be a string containing a list of (src . data-fragment)
>> src is a url or filename
>> data-fragment
>>
>> Returns a string for export."
>> (let ((src (read src-alist)))
>> (format "#+BEGIN_EXPORT html
>>
>> %s
>>
>> ,#+END_EXPORT"
>>(string-join
>> (cl-loop for (src . data-fragment) in src
>> collect
>> (format " "
>> data-fragment src))
>> "\n"
>>
>>
>> (r-stack "((src1 . fade-out) (src2 . fade-in) (src3 . fade-out))")
>> #+END_SRC
>>
>> #+RESULTS:
>> : #+BEGIN_EXPORT html
>> :
>> :
>> :
>> :
>> :
>> : #+END_EXPORT
>>
>> You could also make a link do that.
>>
>
> Huh. This wasn't at all what I was thinking but it may be a much better
> way than I'd htought of.
>
> A link seems like it would be a great solution, especially if I could
> figure out how to get the :follow function to open an individual ~src~
> path. Would you use "looking-at" to get the right candidate, or can you
> think of a way to get completion candidates for a function that opens the
> file? I'm looking at your eamples in
> https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9
> but can't quite follow the code.
>
> Thank so mjch for this really interesting solution.
>
>>
>> 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, Jan 19, 2022 at 9:42 AM Matt Price wrote:
>>
>>> I am trying ot figure out if I can create a simplified syntax for a
>>> particular special block in a derived HTML exporter.
>>>
>>> I'm trying to produce HTML like this:
>>>
>>> >> data-fragment="fade-in" src="..."/>
>>>
>>> The derived backend (org-re-reveal) already has an
>>>
>>> #+ATTR_REVEAL that an make the data-fragment attributes, so it's not hard
>>> to produce
>>> the desired outpu:
>>>
>>> #+begin_r-stack
>>> #+ATTR_REVEAL: :frag appear[[imglink1]]
>>> #+ATTR_REVEAL: :frag appear[[imglink2]]#+end_r-stack
>>>
>>> However, I'd really like to add a less verbose syntax, like this:
>>>
>>> #+begin_r-stack :frag (appear appear)[[imglink1]][[imglink2]]#+end_r-stack
>>>
>>> My question is: will the exporter preserve information from these
>>> header-like arguments, and is
>>> there a mechanism I can use in a custom ~special-block-function~ to make
>>> use of htem?
>>>
>>> Thanks for your help as always!
>>>
>>> Matt
>>>
>>>
Re: handling as special special block in derived export
I am not sure this is quite what you are looking for. You could use a macro
like this.
{{{r-stack(((src1 . fade-out) (src2 . fade-in) (src3 . fade-out)))}}}
* code :noexport:
#+macro: r-stack (eval (r-stack $1))
#+BEGIN_SRC emacs-lisp
(defun r-stack (src-alist)
"SRC-alist will be a string containing a list of (src . data-fragment)
src is a url or filename
data-fragment
Returns a string for export."
(let ((src (read src-alist)))
(format "#+BEGIN_EXPORT html
%s
,#+END_EXPORT"
(string-join
(cl-loop for (src . data-fragment) in src
collect
(format " "
data-fragment src))
"\n"
(r-stack "((src1 . fade-out) (src2 . fade-in) (src3 . fade-out))")
#+END_SRC
#+RESULTS:
: #+BEGIN_EXPORT html
:
:
:
:
:
: #+END_EXPORT
You could also make a link do that.
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, Jan 19, 2022 at 9:42 AM Matt Price wrote:
> I am trying ot figure out if I can create a simplified syntax for a
> particular special block in a derived HTML exporter.
>
> I'm trying to produce HTML like this:
>
>data-fragment="fade-in" src="..."/>
>
> The derived backend (org-re-reveal) already has an
>
> #+ATTR_REVEAL that an make the data-fragment attributes, so it's not hard to
> produce
> the desired outpu:
>
> #+begin_r-stack
> #+ATTR_REVEAL: :frag appear[[imglink1]]
> #+ATTR_REVEAL: :frag appear[[imglink2]]#+end_r-stack
>
> However, I'd really like to add a less verbose syntax, like this:
>
> #+begin_r-stack :frag (appear appear)[[imglink1]][[imglink2]]#+end_r-stack
>
> My question is: will the exporter preserve information from these header-like
> arguments, and is
> there a mechanism I can use in a custom ~special-block-function~ to make use
> of htem?
>
> Thanks for your help as always!
>
> Matt
>
>
Re: Playing down the text in org-mode
You might check out my scimax-editmarks package. You can create bracket
syntax like that which can be fontified, e.g. made smaller, lighter, etc.
to de-emphasize. It is not org-syntax, and uses a pre-processing step on
export, but if all you want is visual syntax in org-mode, something like
this might be what you are looking for. The details are in this video
description, and you can see what it looks like and does here
https://www.youtube.com/watch?v=qBmvBkpzixs
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 Thu, Jan 13, 2022 at 2:16 PM fatiparty--- via General discussions about
Org-mode. wrote:
>
> Jan 14, 2022, 06:50 by maciasch...@posteo.net:
>
> > Hi,
> >
> > fatiparty--- via "General discussions about Org-mode." writes:
> >
> >> Is there anything to perform the opposite, playing down the text?
> >>
> >
> > Are you referring to nested emphasis, something like in LaTeX
> >
> > \emph{foo \emph{bar} baz}
> >
> > = foo...baz in italic; bar in normal font?
> >
> > Best regards,
> > Juan Manuel
> >
>
> I am referring to an org file. Suppose I have a file doc.org
>
> cat doc.org
>
> a celebration that started in the 4th Century [IV] in the Southern Levant
> [ _a geographical region that corresponds to present-day Israel and
> Palestine_ ].
>
> org-mode in emacs will emphasize by underlining geographical detail. I
> would like
> to have a way to play down the text rather than emphasizing the text. It
> would be
> beneficial to have other bracketing characters for doing the opposite of
> emphasizing.
>
>
>
>
>
>
>
>
>
Re: Playing down the text in org-mode
It depends on what you mean. I can't think of a standard markup for de-emphasis. You could imply it with color perhaps, e.g. some shade of grey, or size by making it smaller. At least for LaTex/HTML, both of those can be done. You would either need to use something like a macro, or a link for something like that I think. I made a link for colorized text once ( https://kitchingroup.cheme.cmu.edu/blog/2016/11/08/New-color-link-in-org-9-0-using-font-lock-to-color-the-text/) that you might be able to adapt. 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 Thu, Jan 13, 2022 at 1:28 PM fatiparty--- via General discussions about Org-mode. wrote: > In org-mode one can use the emphasizing tags > > *word* /word/ _word_ > > Is there anything to perform the opposite, playing down the text? > >
Re: Bibliographies on export with ox-context and ox-epub
These two packages can co-exist. This message means do not mix citations from both in a single org file; use one or the other. 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, Jan 12, 2022 at 11:42 AM juh wrote: > On 12.01.22 15:53, Nicolas Goaziou wrote: > > Note that Org Cite and Org Ref are, unfortunately, incompatible > > projects. Org Cite defines citations as a new kind of object, whereas > > Org Ref extends links to create citations. In short, you cannot mix > > both. > > Do I have to erase every trace of Org Ref in my setup? > > juh > >
Re: Cannot set invisible text property
Maybe try this instead (you added the symbol as a list, not just a symbol): 123 #+BEGIN_SRC emacs-lisp (add-text-properties 1 3 '(invisible hide-this-stuff)) (add-to-invisibility-spec 'hide-this-stuff) #+END_SRC #+RESULTS: : (hide-this-stuff (org-hide-block . t) (org-link) (outline . t) t) #+BEGIN_SRC emacs-lisp (remove-from-invisibility-spec 'hide-this-stuff) #+END_SRC #+RESULTS: : ((org-hide-block . t) (org-link) (outline . t) t) 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 Thu, Jan 6, 2022 at 5:48 PM Enrico Flor wrote: > In a minor mode I wrote for myself, I use add-text-properties to make > certain things invisible. This does not work in org-mode, and I don't > understand why. For instance, the following has no effect in when the > buffer is in org-mode (and only when it's in org mode): > > (add-text-properties 1 3 '(invisible t)) > > Any other text property I try to add does not give me any problem. > I have also tried to achieve the same by adding things to > buffer-invisibility-spec, but again, the following has no effect > whatsoever, if in org-mode: > > (add-text-properties 1 3 '(invisible hide-this-stuff)) > (add-to-invisibility-spec '(hide-this-stuff)) > > Can anyone give me a hint as to what is going on? > > Thank you. >
Re: text after sub headings?
You can also use drawers (as an alternative to inline tasks) for collapsible content. Another potential is to use blocks. You can define your own kind of blocks, or even just use an org block and it is collapsible. 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 Thu, Dec 23, 2021 at 4:22 PM Robert Nikander wrote: > Max Nikulin wrote: > > Have you seen the following and links therein? > > https://orgmode.org/worg/org-faq.html#closing-outline-sections > > No, I hadn't found that. Thanks. Those links answer my question. > > Juan Manuel Macías wrote: > > It is an interesting question; however, I would say that this is not a > > useful or realistic structure. Regardless of the Org trees/subtrees and > > their folding ability (indicating that each thing is at a certain > > level), I think that a content will be more useful and intelligible if > > […] > > I see your point. > > Maybe it depends on how you use org-mode and how you imagine the meaning > of the "*" items. I see some disagreement about this in the old threads > that Max linked to. No need to rehash it deeply here again; I was just > curious. > > The way I'm using org-mode so far, I'm not exporting to other formats, and > I can see a use for collapsible sections in the middle of a larger chunk of > text. I can already kind of do it with a "-" list item, like this. (Or > other things like code blocks, etc) > > * Heading > Top Text > Top Text > - Sub > This can be hidden if I hit 'tab' key on "Sub". > More Top Text > More Top Text > > If you view a "*" item as "book section", it's confusing. But if you view > a "*" item as "collapsible thing", then it makes more sense. > > > >
Re: org-cite and export to ODT
you are still not getting the directions. You don't export with C-c Ce oo here. You run that src block by putting your cursor in it and typing C-c C-c to run it. For org-ref, you have to use a preprocessing hook to replace the cite links with the csl derived links before the export is done. That is what the src block does. It temporarily defines org-export-before-parsing-hook to run those three hook functions before making an odt file. Alternatively you can do C-c C-e ro which will use the org-ref exporter that at least runs the org-ref csl preprocessor. 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, Dec 15, 2021 at 6:58 PM Xianwen Chen (陈贤文) wrote: > Thank you John. I'm not sure why it does not work. Below is the minimal > example I created, using your example. I ran C-e o o to export to ODT. The > resulted ODT file didn't have the reference. > > #+title: A basic example of org-ref for csl export > #+options: toc:nil > #+csl-style: apa-5th-edition.csl > #+csl-locale: en-US > > * Bibliography > > bibliography:~/data/library/bibliography/biblatex/biblatex.bib > > cite:bayulken-et-al-2020-nbs-climate_change-pandemics > > * build :noexport: > > #+BEGIN_SRC emacs-lisp :results silent > (let ((org-export-before-parsing-hook '(org-ref-cite-natmove ;; do this > first > org-ref-csl-preprocess-buffer > org-ref-refproc))) > (org-open-file (org-odt-export-to-odt) 'system)) > #+END_SRC > > > On Wed, Dec 15, 2021 at 10:16 PM John Kitchin > wrote: > >> That code does not belong in your .emacs file. It should be in an >> emacs-lisp block in your org-file like it is in the example. You should run >> it from the org file. >> >> >> >> >> 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, Dec 15, 2021 at 5:12 PM Xianwen Chen (陈贤文) < >> xianwen.c...@gmail.com> wrote: >> >>> Thank you all for the responses. I have to upgrade from orgmode 9.4.4 to >>> 9.5 first, to try out org-cite. >>> >>> I tried >>> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument. >>> I added the following codes to my .emacs: >>> >>> (let ((org-export-before-parsing-hook '(org-ref-cite-natmove ;; do this >>> first >>> org-ref-csl-preprocess-buffer >>> org-ref-refproc))) >>> (org-open-file (org-odt-export-to-odt) 'system)) >>> >>> I tried to eval-region, after selecting these codes. I got the complain >>> that org-ref-cite-natmove's function definition is void. >>> >>> Do I need to install or require something other than cite-ref? >>> >>> Xianwen >>> >>> On Thu, Dec 9, 2021 at 2:57 PM John Kitchin >>> wrote: >>> >>>> If you are trying to use org-ref for this see >>>> https://www.youtube.com/watch?v=rRR-5NSpKyE and this example: >>>> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument. >>>> You need to use a preprocessing hook (org-ref-csl-preprocess-buffer) with >>>> org-ref to get the citations and bibliography . >>>> 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 Thu, Dec 9, 2021 at 4:54 AM Xianwen Chen (陈贤文) < >>>> xianwen.c...@gmail.com> wrote: >>>> >>>>> I have been using org-ref and biblatex. They export well to PDF, >>>>> through LaTeX. I am able to export to ODT as well. However, I'm not able >>>>> to >>>>> have the bibliography or the references in the produced ODT. >>>>> >>>>> I searched online and found this tutorial: >>>>> https://kjambunathan.github.io/org-mode-ox-odt/Bibliography-and-Citations-in-ODT-export.html. >>>>> However, when following through the tutorial, I wasn't able to find >>>>> ox-jabref. >>>>> >>>>> Thinking about the new org-cite, which is orgmode's native citation >>>>> solution, I'm wondering if it would be easier to use org-cite within >>>>> orgmode and export to ODT? A small example with configuration suggestion >>>>> will be highly appreciated! >>>>> >>>>> Xianwen >>>>> >>>>
Re: org-cite and export to ODT
That code does not belong in your .emacs file. It should be in an emacs-lisp block in your org-file like it is in the example. You should run it from the org file. 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, Dec 15, 2021 at 5:12 PM Xianwen Chen (陈贤文) wrote: > Thank you all for the responses. I have to upgrade from orgmode 9.4.4 to > 9.5 first, to try out org-cite. > > I tried > https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument. > I added the following codes to my .emacs: > > (let ((org-export-before-parsing-hook '(org-ref-cite-natmove ;; do this > first > org-ref-csl-preprocess-buffer > org-ref-refproc))) > (org-open-file (org-odt-export-to-odt) 'system)) > > I tried to eval-region, after selecting these codes. I got the complain > that org-ref-cite-natmove's function definition is void. > > Do I need to install or require something other than cite-ref? > > Xianwen > > On Thu, Dec 9, 2021 at 2:57 PM John Kitchin > wrote: > >> If you are trying to use org-ref for this see >> https://www.youtube.com/watch?v=rRR-5NSpKyE and this example: >> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument. >> You need to use a preprocessing hook (org-ref-csl-preprocess-buffer) with >> org-ref to get the citations and bibliography . >> 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 Thu, Dec 9, 2021 at 4:54 AM Xianwen Chen (陈贤文) >> wrote: >> >>> I have been using org-ref and biblatex. They export well to PDF, through >>> LaTeX. I am able to export to ODT as well. However, I'm not able to have >>> the bibliography or the references in the produced ODT. >>> >>> I searched online and found this tutorial: >>> https://kjambunathan.github.io/org-mode-ox-odt/Bibliography-and-Citations-in-ODT-export.html. >>> However, when following through the tutorial, I wasn't able to find >>> ox-jabref. >>> >>> Thinking about the new org-cite, which is orgmode's native citation >>> solution, I'm wondering if it would be easier to use org-cite within >>> orgmode and export to ODT? A small example with configuration suggestion >>> will be highly appreciated! >>> >>> Xianwen >>> >>
Re: org-cite and export to ODT
If you are trying to use org-ref for this see https://www.youtube.com/watch?v=rRR-5NSpKyE and this example: https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument. You need to use a preprocessing hook (org-ref-csl-preprocess-buffer) with org-ref to get the citations and bibliography . 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 Thu, Dec 9, 2021 at 4:54 AM Xianwen Chen (陈贤文) wrote: > I have been using org-ref and biblatex. They export well to PDF, through > LaTeX. I am able to export to ODT as well. However, I'm not able to have > the bibliography or the references in the produced ODT. > > I searched online and found this tutorial: > https://kjambunathan.github.io/org-mode-ox-odt/Bibliography-and-Citations-in-ODT-export.html. > However, when following through the tutorial, I wasn't able to find > ox-jabref. > > Thinking about the new org-cite, which is orgmode's native citation > solution, I'm wondering if it would be easier to use org-cite within > orgmode and export to ODT? A small example with configuration suggestion > will be highly appreciated! > > Xianwen >
Re: Raw Org AST snippets for "impossible" markup
Have you seen
https://github.com/tj64/org-dp? It seems to do a lot with creating and
manipulating org elements. It might either be handy or lead to some
inspiration.
On Wed, Dec 8, 2021 at 6:20 PM Juan Manuel Macías
wrote:
> Max Nikulin writes:
>
> > As you have guessed, It is not my choice, it is interface of ox.el and
> > org-element.el.
>
> Indeed. Sorry for my haste: it's the consequences of not read the code
> carefully :-)
>
> Of course, your orgia-link-procedure could be extended to more org
> elements.
> I can't think of what kind of scenario that might fit in, but as a proof
> of concept I find it really stimulating. E.g:
>
> #+begin_src elisp
> (org-export-string-as " \"Lorem\\nipsum\\ndolor\")>" 'html t)
> #+end_src
>
> #+RESULTS:
> :
> :
> : Lorem
> : ipsum
> : dolor
> :
>
> #+begin_src elisp
> (org-export-string-as " (\":environment foreigndisplayquote :options {greek}\"))
> \"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
> Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" 'latex t)
> #+end_src
>
> #+RESULTS:
> : \begin{foreigndisplayquote}{greek}
> : Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲνἈρταξέρξης,
> νεώτερος δὲ Κῦρος·
> : \end{foreigndisplayquote}
>
>
> > However if you strongly want to use proper terminology in markup, you
> > may try to trade it for +your soul+ compatibility and portability
> > issues. The following almost works:
>
> Interesting, thank you.
>
> Yes, it is strange the new line added in `evilatex-emph' ... I have no
> idea why that happens.
>
> Best regards,
>
> Juan Manuel
>
--
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: Looking for extensions of [[file:~/xx.org::My Target]]
You might find the scimax-notebook project ( https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org) interesting for this. It builds on projectile and defines a link ( https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org#notebookproject-links) similar to what you describe. You can learn more about it here: https://www.youtube.com/watch?v=H4sK5ld6Bw0 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, Dec 6, 2021 at 8:44 PM Eduardo Ochs wrote: > Hi people, > > this node of the Org manual > > (info "(org)Search Options") > > http://www.gnu.org/software/emacs/manual/html_node/org/Search-Options.html > > explains that we can use links like this one > > [[file:~/xx.org::My Target]] > > to point to a string like "<>" in the file ~/xx.org. > > Where can I find extensions of that syntax that allow using several > "projects"? I am thinking of something like this: after telling the > extension that in the local filesystem > > the project "dn6" is at ~/LATEX/dednat6/, and > the project "edrxrepl" is at ~/edrxrepl/ > > then the links > > [[file:dn6/stacks.lua:Stack-tests]] and > [[file:edrxrepl/edrxpcall.lua:Class]] > > would point to: > > the string "<>" in ~/LATEX/dednat6/stacks.lua and > the string "<>" in ~/edrxrepl/edrxpcall.lua, > > and I imagine that every such extension would also allow telling the > HTML exporter where these "projects" are in the web... > > Thanks in advance! > Eduardo Ochs > http://angg.twu.net/#eev > > > > P.S.: I still know far less Org than I should, but I am trying to > remedy this... > > P.P.S.: eev uses this trick to point to anchors in "projects": > http://angg.twu.net/eev-intros/find-eev-quick-intro.html#8.5 > http://angg.twu.net/eev-intros/find-eev-quick-intro.html#9.2 > I need to add to its docs references to how other packages do > similar things. > >
Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]
It is a "feature" of other completion tools that differentiate between the selected candidate (usually the highlighted one) and the current input (which may be incomplete, and usually not what you want to select, but sometimes is (e.g. when you want an empty string, or to choose something that is not a candidate but similar to one e.g. with fuzzy matching)). That happens with helm and ivy, probably selectrum, and other backends that try to improve on the vanilla completing-read interface. 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, Dec 6, 2021 at 1:42 PM Daniel Nemenyi wrote: > > Nicolas Goaziou wrote (on Mon 06 Dec 2021 17:58): > > > The prompt displays : "" to exit, which means you have to select the > > empty value to exit. How you do select that value depends on the > > completion UI. > > > > I admit it is not particularly clear. Maybe we should spell out the > > "empty value" part of the prompt. > > I sort of got that -- though I must admit I did try entering two double > quotes just in case! -- but the issue is that it's not clear how one > inserts an empty value. > > Couldn't the top value one could select simply be ""? Or is this just a > problem with helm? > >
Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]
You could consider something like this:
The insert processors provided by org-cite use depend only on Emacs and use
completing-read to select one or more citation keys for insertion.
Completing-read is intended for selecting a single item, and org-cite
compensates for this by letting you select multiple keys, and exiting
when the selected candidate is an empty string. With a vanilla Emacs
installation, you can press Tab to see a list of possible candidates, and
use Tab for completion. Each time you press return with a completed
candidate in the minibuffer that key is added to a list to be inserted.
Press return with an empty minibuffer to finish and insert the selected
keys.
If you use an alternate completion-backend like helm, ivy, selectrum, etc.
you will see different behavior because they have a different concept of
the selected candidate vs the current input to select the current input
(which must be empty).
With helm, you cannot mark candidates, and there are no alternate actions.
You press return on each entry you want to select, and when you are done
selecting them you press C-return or M-return (bound to
helm-cr-empty-string) to insert all the entries at once.
With ivy, you press return on each entry you want to select, and when you
are done selecting them you press C-M-j (exits with current input instead
of the current candidate) to insert them.
With Selectrum, ... (don't know what the keybinding here is)
(not sure if there are other ones that should also be included)
Other insert processors may use these backends natively, so this
information may not apply to them.
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, Dec 6, 2021 at 9:43 AM Bruce D'Arcus wrote:
> On Mon, Dec 6, 2021 at 9:33 AM Daniel Nemenyi wrote:
> > Apologies, I did ('Thanks org-ref I'm done...'), slip of the tongue.
>
> Oh, I missed that; sorry John.
>
> > Could have a go though if someone could give me a pointer? But if this
> is left to the user, perhaps we should include a line in the documentation
> telling them?
>
> The completion UIs have different keybindings for this. What should
> the documentation say?
>
> Bruce
>
>
Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]
org-ref should not get any credit for this. That is a feature of the built in org-cite library, which uses completing-read for that behavior. completing-read is only for reading one thing at a time, and org-cite works around that in a way that leads to the behavior you see. It looks like helm (if you use helm-mode), but it is actually the helm version of completing read, and not a helm selection command. Other completion backends use different bindings, e.g. ivy uses C-M-j I think. 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, Dec 6, 2021 at 7:57 AM Daniel Nemenyi wrote: > > Hello, > > I'm finding myself stuck in the `HELM Org Cite Insert` buffer that lists > possible citations after calling org-cite-insert using Helm. After > selecting a reference I am prompted to select more, and there isn't an > obvious way to say, 'Thanks org-ref I'm done, kill this minibuffer and > insert the refs I have chosen.' > > I was eventually told on Stack Overflow that M-RET does the job, but I > would have expected either the first option in the HELM buffer to do this, > or else there to be an option in the HELM Select Action list? > > Thanks! > Daniel > > Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version > 3.24.24, cairo version 1.16.0) > Package: Org mode version 9.5.1 (9.5.1-g36086a @ > /home/dan/.emacs.d/elpa/org-9.5.1/). Helm (20211205.) > >
Re: [fyi] extensible syntax, syntax features, parsing risk
Is it related to https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html I implemented that idea for fun once: https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ 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, Dec 4, 2021 at 5:10 PM Samuel Wales wrote: > the quoted post below, which had message id > 20524da70901041233g105f372fv175a47dc9884f...@mail.gmail.com , starts a > thread relevant to the current discussion of syntax, at least > historically, maybe practically. could not find it online. > > there were succeeding threads with examples and other stuff for id > markers and graph-theoretic things and other examples, where you as > user could always use a cl-like syntax [i.e. something like > "$[functionality-name arg :keyword arg]"]. my main concern was the > proliferation of syntax, and the risks of that [e.g. parsing] and > wanting the ability of factoring of syntax features. > > display, parsing and so on would be shared [factored] among all the > different such features; org would always handle that the same. thus > as a user even, you could add some new feature in lisp, and write it > in org using this syntax. it would already work. > > i have more in notes. idk if it is still relevant, but i have > included the thread starter for the earliest thread [carsten/myself]. > > On 1/4/09, Samuel Wales wrote: > > A general idea, which might or might not be useful. > > > > There are occasionally questions about syntax, like this: > > > > Also, I'm afraid definition matching regexp won't play > > nicely with text indentation, ... -- Paul > > > > Or this: > > > > What would be safer? -- Carsten > > > > I like the footnote implementation, so this is for future > > features, not necessarily footnotes. > > > > One issue when implementing new syntax (or changing existing > > syntax or cleaning up code) is parsing risk, which I will > > define as the risk that the syntax and the regexp or > > matching code: > > > > 1) conflicts with user text > > 2) conflicts with existing features > > 3) will be hard to maintain > > 4) constrains future features by making them conflict > > syntactically > > 5) makes you run out of syntax to use in the future > > 6) will require complicated regexps > > 7) doesn't readily handle stuff you might want in the > > future, like being combined with another feature > > 8) will be hard to quote, escape, comment, *boldify*, etc. > > 9) doesn't handle nestability, print-readability, > > pretty-printability, syntax coloring, etc. > > 10) will be inefficient when called in a loop > > 11) isn't factored out > > 12) etc. > > > > For example, one of the many reasons for using org-IDs (:)) > > in the conversation manager (as proposed) is that there are > > already functions to parse org-IDs, so a new syntax is not > > necessary and therefore parsing risk is minimized. > > > > In case parsing risk is a concern when adding a new feature > > to org, here is one idea: have a generic syntax that is > > extensible with keywords. > > > > The idea is to have a bracketing syntax with a reserved > > keyword as the first element that says what you are doing. > > > > To use footnotes as an example (this is not a suggestion to > > change footnote syntax, just an example that can be used for > > future syntax): > > > > You might use something like "here is some text to be > > footnoted $[fn apple]" to specify the footnote link, and > > "$[fn-target apples are delicious]" to specify the target. > > > > The general point I want to make is that once such a syntax > > is decided on, many future features are possible without > > introducing parsing risk. > > > > For example, you can implement a new feature as > > "$[my-new-feature ...]". Then there is no parsing risk, > > even though you have just added a new feature. > > > > For modifications of features, you can use keywords: > > "$[my-new-feature ... :myparameter ...]". These are easily > > parsed by standard functions for parsing lists. > > > > You can develop ways to boldify, quote, nest, prettily > > print, etc. this syntax, and those ways will work well with > > all future features that use it. > > &g
Re: Org-syntax: Intra-word markup
Along these lines (and combining the s-exp suggestion from Max) , you can
achieve something like this with links.
This is lightly tested, and I am not thrilled with the eval for exporting,
but I couldn't get a macro to work on the export function to avoid it, and
this is just a proof of concept idea. This might only be suitable for
individual solutions, since you have to define this markup yourself.
#+BEGIN_SRC emacs-lisp :results silent
(defun italic (s)
(pcase backend ;; lexical
('latex (format "{\\textit{%s}}" s))
('html (format "%s" s))
(_ s)))
(defun @@-export (path desc backend)
(eval `(concat ,@(read path
(org-link-set-parameters
"@@"
:export #'@@-export)
#+END_SRC
In org, it would look like Here is a [[@@:((italic "part") "ial")]] markup.
And in exports this is what this implementation does.
#+BEGIN_SRC emacs-lisp
(org-export-string-as "Here is a [[@@:((italic \"part\") \"ial\")]]
markup." 'latex t)
#+END_SRC
#+RESULTS:
: Here is a {\textit{part}}ial markup.
#+BEGIN_SRC emacs-lisp
(org-export-string-as "Here is a [[@@:((italic \"part\") \"ial\")]]
markup." 'html t)
#+END_SRC
#+RESULTS:
:
: Here is a partial markup.
#+BEGIN_SRC emacs-lisp
(org-export-string-as "Here is a [[@@:((italic \"part\") \"ial\")]]
markup." 'ascii t)
#+END_SRC
#+RESULTS:
: Here is a partial markup.
Of course, you are free to do what you want with the path, including parse
it yourself to generate the output, and since it is a link, you could do
all kinds of things to make it look the way you want with faces, overlays,
etc.
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, Dec 4, 2021 at 12:54 PM Tom Gillespie wrote:
> Hi all,
> After a bunch of rambling (see below if interested), I think I have
> a solution that should work for everyone. The key realization is that
> what we really want is the ability to have a "parse me separately"
> type of syntax. This meets the intra-word syntax needs and might
> meet some other needs as well.
>
> The solution is to make @@org:...@@ "parse me separately"
> block! It nearly works that way already too! To minimize typing
> we could have @@:...@@ the empty type default to org.
>
> This seems like a winner to me. The syntax for it already exists
> and won't conflict. It requires relatively minimal additional typing
> the implication is clear, and there are other places where such
> behavior could be useful.
>
> This syntax seems like a winner to me
> @@org:/hello/@@world
> @@:/hello/@@world
>
> You can also do things like
> #+begin_src org
> I want a number in this number@@org:src_elisp{(+ 1 2)}@@word!
> #+end_src
>
> Which would render to
> #+begin_src org
> I want a number in this number3word!
> #+end_src
>
> Thoughts?
>
> Best!
> Tom
>
> --- rambling below -
>
>
> > This idea reminds me a bit of Scribble/Racket where every document is
> > just inverted code, which makes it possible to insert arbitrary Racket
> > code in your prose...
>
> I will say, despite some of my comments elsewhere, that I think
> exploring certain features of Scribble syntax for use in Org mode
> would simplify certain parts of the syntax immensely.
>
> For example
> various inline blocks are an absolute pain to parse because they
> allow nested delimiters /if they are matched/. The implementation
> of the /if they are matched/ clause is currently a nasty hack which
> generates a regular expression that can only actually handle nesting
> to depth 3. Actually implementing the recursive grammar add a lot
> of complexity to the syntax and is hard to get right.
>
> It would be vastly simpler to use Scribble's |<{hello }} world}>|
> style syntax and always terminate at the first matching delimiter.
> I'm sure that this would break some Org files, but it would make
> dealing with latex fragments and inline source blocks and inline
> footnotes SO much simpler. Matching an arbitrary number of
> angle brackets does add some complexity, but it is tiny compared
> to the complexity of enforcing matched parens and their failure cases
> especially because many of the places where nesting is required
> probably only see use of the nesting feature in a tiny fraction of
> all cases.
>
> One other reason why this is attractive is that all the instances
> where nested delimiters can appear on a line are preceded by
> some non-whitespace character. This means that using the
> pipe syntax d
Re: citeproc-org and org-ref 3
I have seen this happen at times, and I think it is style and maybe browser dependent. Could you send me a small example (including the csl file you use) that I could look at? Joseph Vidal-Rosset writes: > Hi John, > > A detail about exporting with org-ref 3 in html when the csl style is > for numeric references. With org-ref 2 + citeproc-org, I got this: > > [1] R. Descartes, Meditations on First Philosophy: with Selections from > the Objections and Replies. Oxford: OUP Oxford, 2008. > > (see the references here : > https://www.vidal-rosset.net/descartess_first_proof_of_gods_existence_in_first-order_logic.html > ) > > With org-ref 3, with apparently any numeric style, I get this: > > [1] > R. Descartes, Meditations on First Philosophy: with Selections from the > Objections and Replies. Oxford: OUP Oxford, 2008. > > I mean that each bibliographical reference is below its number link, and > it is not very nice. I wonder about the reason of this difference of > output, and a possible solution. > > Best wishes, > > Jo. > > Le 02/12/2021 à 18:35, John Kitchin a écrit : >> Glad to hear it is working again for you! Best wishes, >> >> Joseph Vidal-Rosset writes: >> >>> Dear all, >>> >>> >>> I just succeeded in solving my problem. >>> >>> l-210-235 of myblogexporter.el, I changed the code for: >>> >>> (defun org-export-head-export-headers (directory-name backend) >>> "Exports each heading to directory-name using backend" >>> (if (equal backend "html") >>> (org-export-head--run-on-each-heading >>> #'(lambda () >>> (org-set-property >>> "EXPORT_FILE_NAME" >>> (concat directory-name (org-export-head--escaped-headline))) >>> (deactivate-mark) >>> (let ((org-export-before-parsing-hook >>> '(org-ref-csl-preprocess-buffer))) >>> (cl-letf (((symbol-function 'org-export-get-reference) >>> (symbol-function 'org-export-get-reference-custom))) >>> (if org-export-head-click-toc-h2 >>> (cl-letf (( >>>;(symbol-function 'org-html-toc) >>>(symbol-function >>> 'org-export-head--custom-toc))) >>> (org-html-export-to-html nil t) >>> (set-buffer-modified-p t)) "-noexport-noreexport")) >>> (if (equal backend "pdf") >>> (org-export-head--run-on-each-heading >>> #'(lambda () >>> (org-set-property >>> "EXPORT_FILE_NAME" >>> (concat directory-name (org-export-head--escaped-headline))) >>> (deactivate-mark) >>> (org-latex-export-to-pdf nil t) >>> (set-buffer-modified-p t)) "-noexport-noreexport"))) >>> >>> and it works with org-ref 3. >>> >>> Best wishes, I attach myblogexporter.el >>> >>> Jo. >>> >>> Le 02/12/2021 à 14:17, Joseph Vidal-Rosset a écrit : >>>> Dear John (cc. Ivan), >>>> >>>> First, thanks for your help and for your patience, that's very kind of you. >>>> >>>> The good news is that indeed, org-ref 3 exports nicely the html >>>> bibliography with my CSL file, it works well with your org file and your >>>> bibliography. My error was simple: I did not use the specific org-ref >>>> keys but the ordinary h-o keys.. A stupid mistake. >>>> >>>> The bad news is that this new function for exporting with org-ref 3 is >>>> not included in org-export-head, a nice org mode to blog exporter, made >>>> by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a >>>> different file, I find this exporter very convenient. I had no problem >>>> with this org-ref 2 to use this blog-exporter, but it org-ref 3 is >>>> unfortunately not still adapted to its use. Nevertheless, I believe that >>>> it should be possible to find the lines to include this function >>>> (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))) >>>>(org-open-file (org-html-export-to-html))) >>>> in org-export-head. I tried, but without success, because I am simply >>>> not expert enough. I see the best, that is to export both with org-ref 3 >>>> (i.e. "
Re: citeproc-org and org-ref 3
Glad to hear it is working again for you! Best wishes, Joseph Vidal-Rosset writes: > Dear all, > > > I just succeeded in solving my problem. > > l-210-235 of myblogexporter.el, I changed the code for: > > (defun org-export-head-export-headers (directory-name backend) >"Exports each heading to directory-name using backend" >(if (equal backend "html") >(org-export-head--run-on-each-heading > #'(lambda () > (org-set-property > "EXPORT_FILE_NAME" > (concat directory-name (org-export-head--escaped-headline))) > (deactivate-mark) > (let ((org-export-before-parsing-hook > '(org-ref-csl-preprocess-buffer))) > (cl-letf (((symbol-function 'org-export-get-reference) > (symbol-function 'org-export-get-reference-custom))) >(if org-export-head-click-toc-h2 >(cl-letf (( > ;(symbol-function 'org-html-toc) > (symbol-function > 'org-export-head--custom-toc))) > (org-html-export-to-html nil t) > (set-buffer-modified-p t)) "-noexport-noreexport")) >(if (equal backend "pdf") >(org-export-head--run-on-each-heading > #'(lambda () > (org-set-property > "EXPORT_FILE_NAME" > (concat directory-name (org-export-head--escaped-headline))) > (deactivate-mark) > (org-latex-export-to-pdf nil t) > (set-buffer-modified-p t)) "-noexport-noreexport"))) > > and it works with org-ref 3. > > Best wishes, I attach myblogexporter.el > > Jo. > > Le 02/12/2021 à 14:17, Joseph Vidal-Rosset a écrit : >> Dear John (cc. Ivan), >> >> First, thanks for your help and for your patience, that's very kind of you. >> >> The good news is that indeed, org-ref 3 exports nicely the html >> bibliography with my CSL file, it works well with your org file and your >> bibliography. My error was simple: I did not use the specific org-ref >> keys but the ordinary h-o keys.. A stupid mistake. >> >> The bad news is that this new function for exporting with org-ref 3 is >> not included in org-export-head, a nice org mode to blog exporter, made >> by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a >> different file, I find this exporter very convenient. I had no problem >> with this org-ref 2 to use this blog-exporter, but it org-ref 3 is >> unfortunately not still adapted to its use. Nevertheless, I believe that >> it should be possible to find the lines to include this function >> (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))) >> (org-open-file (org-html-export-to-html))) >> in org-export-head. I tried, but without success, because I am simply >> not expert enough. I see the best, that is to export both with org-ref 3 >> (i.e. "r h") and org-export-head, but I am unable to code it. >> >> No doubt that it should be for you and Ivan a piece of cake, but please >> do it only if you think that it is interesting and if you find the time >> to do it. >> >> Best wishes, >> >> Jo. >> >> PS in attachment, myblogexporter.el in my ~/.emacs.d/personal (usual >> path with Prelude Emacs). >> >> Le 01/12/2021 à 23:16, John Kitchin a écrit : >>> >>> Joseph Vidal-Rosset writes: >>> >>>> Dear Andras, >>>> >>>> You are very probably right. I will have a look on this entry in my >>>> default bibliography file. >>>> >>>> The code >>>> >>>> (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))) >>>> (org-open-file (org-html-export-to-html))) >>>> >>>> put in .emacs.d/personal/preload/myorgexport.el >>>> >>> This code should not go in your init file. It is executed each time, and >>> not what you want. I usually put it a src block at the end in a section >>> tagged noexport and run it from there. >>> >>> Alternatively, if this is the only preprocessing you do, I think you can >>> do C-c C-e rh to export to html (this runs the org-ref html exporter. >>> >>> Finally, if you really want something in your init file it should be >>> like this: >>> >>> (defun my-html () >>> (interactive) >>> (let ((org-export-before-parsing-hook >>> '(org-ref-csl-preproc
Re: citeproc-org and org-ref 3
before-parsing-hook
>> '(org-ref-csl-preprocess-buffer))) (org-open-file
>> (org-html-export-to-html)))
>>eval-buffer(# nil
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t) ;
>> Reading at buffer position 3196
>>
>> load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
>>load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
>>mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
>>(progn (message "[Prelude] Loading personal configuration files in
>> ..." prelude-personal-preload-dir) (mapc 'load (directory-files
>> prelude-personal-preload-dir 't "^[^#.].*el$")))
>>(if (file-exists-p prelude-personal-preload-dir) (progn (message
>> "[Prelude] Loading personal configuration files in ..."
>> prelude-personal-preload-dir) (mapc 'load (directory-files
>> prelude-personal-preload-dir 't "^[^#.].*el$"
>>eval-buffer(# nil "/home/joseph/.emacs.d/init.el" nil
>> t) ; Reading at buffer position 4489
>>load-with-code-conversion("/home/joseph/.emacs.d/init.el"
>> "/home/joseph/.emacs.d/init.el" t t)
>>load("/home/joseph/.emacs.d/init" noerror nomessage)
>>startup--load-user-init-file(#f(compiled-function () #> 0xec639179d6199fa>) #f(compiled-function () #> -0x1f3c686ddc0dc635>) t)
>>command-line()
>> normal-top-level()
>>
>> It's too complicated for me.
>> org-ref version 2 with citeproc-org by Andras worked well, but now I am
>> afraid that to downgrade to org-ref 2 is not necessarily the best
>> solution. I am lost.
>>
>> Best wishes, and thanks for your help.
>>
>> Jo.
>>
>>
>> Le 30/11/2021 à 18:31, John Kitchin a écrit :
>> > See https://www.youtube.com/watch?v=rRR-5NSpKyE
>> > <https://www.youtube.com/watch?v=rRR-5NSpKyE> for an overview of what to
>> > do. basically you need a csl file that provides the style you want, and
>> > you specify it like this in the org file or in default settings. You may
>> > also need a locale file if you are not blogging in english.
>> >
>> > #+csl-style: apa-5th-edition.csl
>> >
>> > #+csl-locale: en-US
>> >
>> >
>> > You can find a basic example org file for html export with CSL at
>> > https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
>> > <https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org>
>> >
>> > Here is a minimal way to export your blog file I suppose.
>> >
>> > (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>> >(org-open-file (org-html-export-to-html)))
>> >
>> >
>> > 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 <http://kitchingroup.cheme.cmu.edu>
>> >
>> >
>> >
>> > On Tue, Nov 30, 2021 at 12:16 PM András Simonyi
>> > mailto:andras.simo...@gmail.com>> wrote:
>> >
>> > Dear Joseph,
>> >
>> > unfortunately, my note on the `citeproc-org` page has become kind of
>> > misleading and has to be updated because org-ref didn't switch to the
>> > new org-cite citation syntax after all, although this was the plan for
>> > a while. I think if you wish to use org-ref 3 then you should simply
>> > remove citeproc-org entirely -- if I understand correctly the latest
>> > version of org-ref supports the old syntax as well and is capable of
>> > CSL-based export (among others) on its own.
>> >
>> > best regards,
>> > András
>> >
>> > On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
>> > mailto:jos...@vidal-rosset.net>> wrote:
>> > >
>> > >
>> > > Dear John, and dear Andras,
>> > >
>> > > Having updated my org-ref to the last version, I see that the html
>> > > export of bibliography does not work any longer for my blog.
>> > >
>> > > Reading Andras's note here
>> > > https://github.com/andras-simonyi/citeproc-org
>> > <https://github.com/andras-simonyi/citeproc-org>
>> > > I confess that I am lost.
>> > >
>> > > What have I to do to not waste too much time with this problem?
>> > >
>> > > Best wishes,
>> > >
>> > > Jo.
>> > >
>> >
>>
--
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
Pronouns: he/him/his
Re: citeproc-org and org-ref 3
uot;curley-nil-on-bennet-spinoz" (("Url" .
>>> "http://dx.doi.org/10.1163/9789004246638_005;) ("Doi" .
>>> "10.1163/9789004246638_005") ("Date_added" . "Mon May 16 19:09:37 2016")
>>> ("Booktitle" . "Spinoza: Issues and Directions") ("Series" . "Spinoza:
>>> Issues and Directions") ("Year" . "nil") ("Publisher" . "Brill Academic
>>> Publishers") ("Pages" . "39-52") ("Author" . "Edwin Curley") ("Title" .
>>> "ON BENNETTS SPINOZA: THE ISSUE OF TELEOLOGY") ("=type=" . "InBook")
>>> ("=key=" . "curley-nil-on-bennet-spinoz")))
>>> maphash(#f(compiled-function (key entry) #>> -0x7fcb46b5c8e80b3>) #)
>>> citeproc-hash-itemgetter-from-any(("~/Dropbox/Orgzly/reforg.bib"))
>>> org-ref-process-buffer(html)
>>> org-ref-csl-preprocess-buffer(html)
>>> run-hook-with-args(org-ref-csl-preprocess-buffer html)
>>> org-export-as(html nil nil nil (:output-file "~/test.html"))
>>> org-export-to-file(html "~/test.html" nil nil nil nil nil)
>>> org-html-export-to-html()
>>> (org-open-file (org-html-export-to-html))
>>> (let ((org-export-before-parsing-hook
>>> '(org-ref-csl-preprocess-buffer))) (org-open-file
>>> (org-html-export-to-html)))
>>> eval-buffer(# nil
>>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil t) ;
>>> Reading at buffer position 3196
>>>
>>> load-with-code-conversion("/home/joseph/.emacs.d/personal/preload/myorgexport..."
>>> "/home/joseph/.emacs.d/personal/preload/myorgexport..." nil nil)
>>> load("/home/joseph/.emacs.d/personal/preload/myorgexport...")
>>> mapc(load ("/home/joseph/.emacs.d/personal/preload/myorgexport..."))
>>> (progn (message "[Prelude] Loading personal configuration files in
>>> ..." prelude-personal-preload-dir) (mapc 'load (directory-files
>>> prelude-personal-preload-dir 't "^[^#.].*el$")))
>>> (if (file-exists-p prelude-personal-preload-dir) (progn (message
>>> "[Prelude] Loading personal configuration files in ..."
>>> prelude-personal-preload-dir) (mapc 'load (directory-files
>>> prelude-personal-preload-dir 't "^[^#.].*el$"
>>> eval-buffer(# nil "/home/joseph/.emacs.d/init.el" nil
>>> t) ; Reading at buffer position 4489
>>> load-with-code-conversion("/home/joseph/.emacs.d/init.el"
>>> "/home/joseph/.emacs.d/init.el" t t)
>>> load("/home/joseph/.emacs.d/init" noerror nomessage)
>>> startup--load-user-init-file(#f(compiled-function () #>> 0xec639179d6199fa>) #f(compiled-function () #>> -0x1f3c686ddc0dc635>) t)
>>> command-line()
>>> normal-top-level()
>>>
>>> It's too complicated for me.
>>> org-ref version 2 with citeproc-org by Andras worked well, but now I am
>>> afraid that to downgrade to org-ref 2 is not necessarily the best
>>> solution. I am lost.
>>>
>>> Best wishes, and thanks for your help.
>>>
>>> Jo.
>>>
>>>
>>> Le 30/11/2021 à 18:31, John Kitchin a écrit :
>>>> See https://www.youtube.com/watch?v=rRR-5NSpKyE
>>>> <https://www.youtube.com/watch?v=rRR-5NSpKyE> for an overview of what to
>>>> do. basically you need a csl file that provides the style you want, and
>>>> you specify it like this in the org file or in default settings. You may
>>>> also need a locale file if you are not blogging in english.
>>>>
>>>> #+csl-style: apa-5th-edition.csl
>>>>
>>>> #+csl-locale: en-US
>>>>
>>>>
>>>> You can find a basic example org file for html export with CSL at
>>>> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
>>>> <https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org>
>>>>
>>>> Here is a minimal way to export your blog file I suppose.
>>>>
>>>> (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>>> (org-open-file (org-html-export-to-html)))
>>>>
>>>>
>>>> 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 <http://kitchingroup.cheme.cmu.edu>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 30, 2021 at 12:16 PM András Simonyi
>>>> mailto:andras.simo...@gmail.com>> wrote:
>>>>
>>>> Dear Joseph,
>>>>
>>>> unfortunately, my note on the `citeproc-org` page has become kind of
>>>> misleading and has to be updated because org-ref didn't switch to the
>>>> new org-cite citation syntax after all, although this was the plan for
>>>> a while. I think if you wish to use org-ref 3 then you should simply
>>>> remove citeproc-org entirely -- if I understand correctly the latest
>>>> version of org-ref supports the old syntax as well and is capable of
>>>> CSL-based export (among others) on its own.
>>>>
>>>> best regards,
>>>> András
>>>>
>>>> On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
>>>> mailto:jos...@vidal-rosset.net>> wrote:
>>>> >
>>>> >
>>>> > Dear John, and dear Andras,
>>>> >
>>>> > Having updated my org-ref to the last version, I see that the html
>>>> > export of bibliography does not work any longer for my blog.
>>>> >
>>>> > Reading Andras's note here
>>>> > https://github.com/andras-simonyi/citeproc-org
>>>> <https://github.com/andras-simonyi/citeproc-org>
>>>> > I confess that I am lost.
>>>> >
>>>> > What have I to do to not waste too much time with this problem?
>>>> >
>>>> > Best wishes,
>>>> >
>>>> > Jo.
>>>> >
>>>>
>>>
--
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
Pronouns: he/him/his
Re: citeproc-org and org-ref 3
See https://www.youtube.com/watch?v=rRR-5NSpKyE for an overview of what to do. basically you need a csl file that provides the style you want, and you specify it like this in the org file or in default settings. You may also need a locale file if you are not blogging in english. #+csl-style: apa-5th-edition.csl #+csl-locale: en-US You can find a basic example org file for html export with CSL at https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org Here is a minimal way to export your blog file I suppose. (let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))) (org-open-file (org-html-export-to-html))) 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 Tue, Nov 30, 2021 at 12:16 PM András Simonyi wrote: > Dear Joseph, > > unfortunately, my note on the `citeproc-org` page has become kind of > misleading and has to be updated because org-ref didn't switch to the > new org-cite citation syntax after all, although this was the plan for > a while. I think if you wish to use org-ref 3 then you should simply > remove citeproc-org entirely -- if I understand correctly the latest > version of org-ref supports the old syntax as well and is capable of > CSL-based export (among others) on its own. > > best regards, > András > > On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset > wrote: > > > > > > Dear John, and dear Andras, > > > > Having updated my org-ref to the last version, I see that the html > > export of bibliography does not work any longer for my blog. > > > > Reading Andras's note here > > https://github.com/andras-simonyi/citeproc-org > > I confess that I am lost. > > > > What have I to do to not waste too much time with this problem? > > > > Best wishes, > > > > Jo. > > >
Re: how to export red colored TeX to latex
maybe @@latex:\textcolor{red}{$\delta \phi = \frac{2 m}{R}$}@@ will do.
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 Tue, Nov 30, 2021 at 11:29 AM Uwe Brauer wrote:
>
>
> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?
>
> Thanks
>
> Uwe Brauer
>
>
>
Re: Bibliographies on export with ox-context and ox-epub
If you are happy with org-ref, here is a minimal example that shows how to
get a bibliography via csl, and a pre-processing hook.
* test
A sentence with ref [[cite:]].
* Bibliography
bibliography:~/Dropbox/emacs/bibliography/references.bib
* build
:noexport:
#+csl-style: apa-5th-edition.csl
#+csl-locale: en-US
#+BEGIN_SRC emacs-lisp
(require 'ox-epub)
(let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
(org-open-file (org-epub-export-to-epub)))
#+END_SRC
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, Nov 24, 2021 at 3:00 AM juh wrote:
> Hi all,
>
> I am kind of lost with references and ox-context and ox-epub.
>
> Is there a tutorial how to integrate a bibliography in ConTeXt and
> epub-Export?
>
>
> What I want to achieve is to use a bibtex bibliographies with org-roam and
> export them to epub and ConTeXt to generate bibliographies in the output.
>
> The first wish kind of works as I can insert entries from the bibtex file
> with C-].
>
> They look like this:
>
> Nam a sapien.[[cite:@horkheimer_dialektik_1984]]
>
> This is the org-ref entry in settings.org.
>
> (straight-use-package 'org-ref)
> (with-eval-after-load "org-ref"
> (setq reftex-default-bibliography '("~/org/bibliography.bib")))
>
> (setq bibtex-completion-bibliography '("~/org/bibliography.bib")
> bibtex-completion-library-path '("~/org/bibtex-pdfs/")
> bibtex-completion-notes-path "~/org/notes/"
> bibtex-completion-pdf-open-function
> (lambda (fpath)
> (call-process "open" nil 0 nil fpath)))
>
> (define-key org-mode-map (kbd "C-c ]") 'org-ref-insert-link)
>
>
> What puzzles me is that I could not find a hint to create a bibliography
> for epub export and context export. Maybe there isn't. But as some
> things with references does not work in my setup I fear that my
> configuration is not working. I take snippets from the documentations of
> the packages.
>
> I miss an overall example or tutorial for note taking via org-roam and
> exporting to epub and ConTeXt.
>
> So for now my current publishing workflow is split into two.
>
> 1. Zettelkasten via org-roam
>
> 2. PDF and epub creation via pandoc and cite-proc.
>
> As you can see there is a break of tools, so I would like to avoid this.
>
> TIA
> juh
>
> --
> Autoren-Homepage: . http://literatur.hasecke.com
> Satiren & Essays: . http://www.sudelbuch.de
> Privater Blog: http://www.hasecke.eu
> Netzliteratur-Projekt: http://www.generationenprojekt.de
>
>
>
>
Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create]
if you don't get a helm buffer popping up, it could mean you have not turned helm-mode on (e.g. M-x helm-mode). That redefines completing-read in a helm style, and should act and feel like helm when you insert a ref link. If you don't have that on, then you will see the older completing read behavior where you have to press tab to see the candidates etc. The old v2 definition of org-ref-helm-insert-cite-link can be found at https://github.com/jkitchin/org-ref/blob/org-ref-2/org-ref-helm-bibtex.el#L406, but for refs, it probably just calls this function: https://github.com/jkitchin/org-ref/blob/org-ref-2/org-ref-helm.el#L62. in v3, you can customize the insert functions any way you want, so if you want to use the old v2 functions and have them around, there should be no issue with that. I think if you set `org-ref-insert-ref-function` to the function you want, it should just work the way you want. 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 Thu, Nov 18, 2021 at 2:46 AM Uwe Brauer wrote: > >>> "JK" == John Kitchin writes: > > > Probably M-x org-ref-insert-ref-link will do what you want. A lot of > things > > got "simplified" in version 3 to leverage completing-read more natively. > > helm-mode should work with org-ref-insert-ref-link. > > I see. I think I got it to work, but the navigation is not entirely > clear to me, if I fire up that function a buffer pops up with possible > labels but how do I do something like scroll-up and scroll-down? > > > See https://github.com/jkitchin/org-ref#configuration for some details > on > > how to configure v3 with helm. > > Honestly I miss a bit the old behaviour, when calling a ref function.[1] > > So I checked out the org-ref-2 branch from the github repository. > > But still there the function org-ref-helm-insert-cite-link is gone and > other related org-ref-helm functions. Is this correct? > > > Footnotes: > [1] I mean the helm menu that popped up > >
Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create]
Probably M-x org-ref-insert-ref-link will do what you want. A lot of things got "simplified" in version 3 to leverage completing-read more natively. helm-mode should work with org-ref-insert-ref-link. See https://github.com/jkitchin/org-ref#configuration for some details on how to configure v3 with helm. 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, Nov 17, 2021 at 4:41 PM Uwe Brauer wrote: > >>> "JK" == John Kitchin writes: > > > it usually takes up to 4 hours to propagate to MELPA. I can't reproduce > > the error you report. At least, with a fresh emacs and install from > MELPA > > everything seems to load and work fine, even with emacs 29. There seem > to > > be many issues with native-compiling on the most modern emacs, are you > > using that? > > I think, I succeeded cloning and installing directly from your github > repository, but now the function I was using for a long time > > org-ref-helm-insert-cite-link > > Seems to be gone, what happened? >
Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create]
it usually takes up to 4 hours to propagate to MELPA. I can't reproduce
the error you report. At least, with a fresh emacs and install from MELPA
everything seems to load and work fine, even with emacs 29. There seem to
be many issues with native-compiling on the most modern emacs, are you
using that?
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, Nov 17, 2021 at 1:58 PM Uwe Brauer wrote:
>
> > in the most current version (3) of org-ref, the labels that are found are
> > defined in org-ref-ref-label-regexps. At the moment there isn't a pattern
> > for ID. No particular reason, I haven't used ID like that for many
> years. I
> > added and pushed that to the current repo just now.
>
> Thanks, that is in MELPA already?
>
> BTW, I downloaded the latest MELPA org-ref pkg and obtained the
> following error (running emacs 29, master a couple of days ago)
> ,
> |
> | Debugger entered--Lisp error: (wrong-type-argument listp "gls")
> | cl-first("gls")
> | (org-link-set-parameters (cl-first command) :follow
> | #'or-follow-glossary :face 'org-ref-glossary-face-fn :help-echo
> | 'or-glossary-tooltip :export #'(lambda (path _ format) (cond ((memq
> format '(latex beamer)) (format "\\%s{%s}" (cl-first command) path)) (t
> (format "%s" path)
> | (let ((command (car --dolist-tail--))) (org-link-set-parameters
> (cl-first command) :follow #'or-follow-glossary :face
> 'org-ref-glossary-face-fn :help-echo 'or-glossary-tooltip :export #'(lambda
> (path _ format) (cond ((memq format '...) (format "\\%s{%s}" (cl-first
> command) path)) (t (format "%s" path) (setq --dolist-tail-- (cdr
> --dolist-tail--)))
> | (while --dolist-tail-- (let ((command (car --dolist-tail--)))
> (org-link-set-parameters (cl-first command) :follow #'or-follow-glossary
> :face 'org-ref-glossary-face-fn :help-echo 'or-glossary-tooltip :export
> #'(lambda (path _ format) (cond ((memq format ...) (format "\\%s{%s}" ...
> path)) (t (format "%s" path) (setq --dolist-tail-- (cdr
> --dolist-tail--
> | (let ((--dolist-tail-- org-ref-glossary-gls-commands)) (while
> --dolist-tail-- (let ((command (car --dolist-tail--)))
> (org-link-set-parameters (cl-first command) :follow #'or-follow-glossary
> :face 'org-ref-glossary-face-fn :help-echo 'or-glossary-tooltip :export
> #'(lambda (path _ format) (cond (... ...) (t ... (setq --dolist-tail--
> (cdr --dolist-tail--)
> | eval-buffer(# nil
> "/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." nil t) ; Reading
> at buffer position 10359
> |
>
> load-with-code-conversion("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..."
> "/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." nil t)
> | load("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." nil t)
> | #f(compiled-function (c) # -0x142f0bcbab31255a>)(("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..."
> . 1136))
> | mapc(#f(compiled-function (c) #)
> (("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 911)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 912)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 913)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/doi-..." . 1130)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 1135)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 1136)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 1139)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 1292)
> ("/home/oub/.emacs.d/elpa/org-ref-2020.1229/org-..." . 1341)))
> | package--reload-previously-loaded(#s(package-desc :name org-ref
> :version (20211110 1229) :summary "citations, cross-references and
> bibliographies in ..." :reqs ((dash (0)) (s (0)) (f (0)) (htmlize (0))
> (hydra (0)) (avy (0)) (parsebib (0)) (bibtex-completion (0)) (citeproc
> (0))) :kind nil :archive nil :dir
> "/home/oub/.emacs.d/elpa/org-ref-2020.1229" :extras ((:url . "
> https://github.com/jkitchin/org-ref;) (:keywords "org-mode" "cite" "ref"
> "label") (:maintainer "John Kitchin" . "jkitc...@andrew.cmu.edu")
> (:authors ("John Kitchin" . "jkitc...@andrew.cmu.edu")) (:commit .
> "c87b4155cd2f60ca3a9bed2e6e366c1fa47aec33")) :signed nil))
> | package-activate-1(
Re: [org-cite] CSL processor, APA Style, and no-date citations
in org-ref there is a natbib-bbl preprocessor for this. It works with bibtex (not biblatex) though. You can see how it works here: https://www.youtube.com/watch?v=lq3LspE-rAs=PL0sMmOaE_gs3E0OjExoI7vlCAVygj6S4I=8 You would have to use another preprocessor to convert org-cites to org-ref links, or adapt the code in https://github.com/jkitchin/org-ref/blob/master/org-ref-natbib-bbl-citeproc.el to work off of the org-cites. 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, Nov 17, 2021 at 12:53 PM Bruce D'Arcus wrote: > On Wed, Nov 17, 2021 at 12:47 PM Rudolf Adamkovič wrote: > > > In the meantime, can I use the BibLaTeX backend (or something else) for > *HTML* export? > > I don't believe so, unless there's some good latex -> html solution > I'm not aware of. > > Bruce > >
Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create] (was: insert automatically a reference to a section header and a link)
in the most current version (3) of org-ref, the labels that are found are defined in org-ref-ref-label-regexps. At the moment there isn't a pattern for ID. No particular reason, I haven't used ID like that for many years. I added and pushed that to the current repo just now. 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, Nov 17, 2021 at 11:55 AM Uwe Brauer wrote: > > Please look at this example > > * new >:PROPERTIES: >:ID: 43b3de77-4074-47f2-9a4a-9cddebb33951 >:END: > > ** Inverse problem >:PROPERTIES: >:CUSTOM_ID: sec:one >:END: > > > ** new title >:PROPERTIES: >:ID: f3c76e50-5be9-47f2-bad4-257166670481 >:END: > > Two ids were generated by org-id-get-create. I thought that could be > another solution to my problem. > > However, strangely enough org-ref-helm-insert-ref-link > does not find these two IDs it only finds CUSTOM_ID. > > @John: you are the author of that package, why doesn't the function find > the ID? > > Regards > > Uwe > > > > > > >
Re: insert automatically a reference to a section header and a link
there is nothing like that that I know of. You can write your own, in org
(following Eric's use of radio targets) it might look like this.
(defun my-heading ()
(interactive)
(let* ((title (string-trim (read-string "title: ")))
(tokens (split-string title " " t))
(label (format "<>"
(string-join
(seq-take tokens (min 3 (length tokens)))
"-"
(insert (format "%s %s" label title
you could also insert the leading * if you prefer.
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, Nov 17, 2021 at 8:59 AM Uwe Brauer wrote:
>
> >>> "ESF" == Eric S Fraga writes:
>
> > On Wednesday, 17 Nov 2021 at 08:36, Uwe Brauer wrote:
> >> In auctex+reftex it is possible that when I insert a new section header
> >> a reference label is inserted automatically:
>
> > I do the following usually:
>
> > * <> Introduction
>
> Right, but how do you do this automatically?
>
> Maybe I did not explain this clearly enough: in auctex+reftex, when I
> fire up the command LaTeX-section, I am
>
> 1. Asked for the title
>
> 2. And then the title *and* a label is inserted automatically. (I
>can configure what is inserted to a certain extend). Usually I
>obtain \section{Alternativa de Fredholm}
>\label{sec:altern-de-fredh}
>
>
> I am looking for a similar functionality in org mode
>
> > In section [[introduction]], I show something.
>
> > I prefer visible labels instead of custom IDs although the latter works
> > as well but you need to say [[id:introduction]].
>
> > HTH,
> > eric
>
>
>
Re: issue using org-export-before-parsing-hook in a src-block
I should also add I see the same error if I just run
#+BEGIN_SRC emacs-lisp
(org-org-export-as-org)
#+END_SRC
and I see the same behavior with an emacs -q session.
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 Sun, Nov 7, 2021 at 9:04 AM John Kitchin wrote:
> If I run this block in an org file:
>
> #+BEGIN_SRC emacs-lisp
> (let ((org-export-before-parsing-hook '((lambda (_backend) nil
> (org-org-export-as-org))
> #+END_SRC
>
> I get a traceback that starts with
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
> goto-char(nil)
> (if existing-result (goto-char existing-result) (goto-char
> (org-element-property :end inline)) (skip-chars-backward " \11"))
>
> that seems to originate in
>
> org-babel-insert-result(# ("value" "replace")
> ("emacs-lisp" "(let ((org-export-before-parsing-hook '((lambda (_..."
> ((:colname-names) (:rowname-names) (:result-params "value" "replace")
> (:result-type . value) (:results . "value replace") (:exports . "both")
> (:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no")
> (:tangle . "no") (:eval . "never-export")) "" nil 1 "(ref:%s)") nil
> "emacs-lisp")
>
> If I put :results silent that doesn't happen. Is this a bug?
>
> The org-file is empty in this case except for that block, but that doesn't
> seem to matter.
>
> 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
>
>
issue using org-export-before-parsing-hook in a src-block
If I run this block in an org file:
#+BEGIN_SRC emacs-lisp
(let ((org-export-before-parsing-hook '((lambda (_backend) nil
(org-org-export-as-org))
#+END_SRC
I get a traceback that starts with
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
goto-char(nil)
(if existing-result (goto-char existing-result) (goto-char
(org-element-property :end inline)) (skip-chars-backward " \11"))
that seems to originate in
org-babel-insert-result(# ("value" "replace")
("emacs-lisp" "(let ((org-export-before-parsing-hook '((lambda (_..."
((:colname-names) (:rowname-names) (:result-params "value" "replace")
(:result-type . value) (:results . "value replace") (:exports . "both")
(:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no")
(:tangle . "no") (:eval . "never-export")) "" nil 1 "(ref:%s)") nil
"emacs-lisp")
If I put :results silent that doesn't happen. Is this a bug?
The org-file is empty in this case except for that block, but that doesn't
seem to matter.
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
org-store-link question
In a basically vanilla emacs, if I have a target like <> with my point on it, and I run org-store-link (via C-c l), and then somewhere else do org-isnert-link (via C-c C-l) I get a link like [[file:~/s/f.org::test]] If I define a link now like this: #+BEGIN_SRC emacs-lisp (org-link-set-parameters "jump" :store (lambda () (org-link-store-props :type "jump" :link (format "jump:%s::%s" (buffer-file-name) (line-number-at-pos) #+END_SRC and do that again, all I can insert with C-c C-l is something like: [[jump:~/s/f.org::9]] and the file link is not an option anymore. Should the file link still be there? 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
