Re: How to stop results being hidden when using ":results drawer"?

2022-05-13 Thread John Kitchin
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"?

2022-05-12 Thread John Kitchin
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"?

2022-05-11 Thread John Kitchin
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

2022-05-11 Thread John Kitchin
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

2022-05-10 Thread John Kitchin
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))

2022-05-10 Thread John Kitchin
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)

2022-05-09 Thread John Kitchin
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

2022-05-07 Thread John Kitchin
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

2022-05-07 Thread John Kitchin
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

2022-05-05 Thread John Kitchin
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]

2022-04-26 Thread John Kitchin
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

2022-04-22 Thread John Kitchin
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

2022-04-20 Thread John Kitchin
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

2022-04-17 Thread John Kitchin
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

2022-04-17 Thread John Kitchin
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/)]

2022-04-08 Thread John Kitchin
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

2022-04-07 Thread John Kitchin
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

2022-04-05 Thread John Kitchin
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

2022-04-03 Thread John Kitchin
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

2022-04-03 Thread John Kitchin
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

2022-03-30 Thread John Kitchin


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

2022-03-27 Thread John Kitchin


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

2022-03-27 Thread John Kitchin


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

2022-03-27 Thread John Kitchin


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

2022-03-27 Thread John Kitchin
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?

2022-03-25 Thread John Kitchin
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

2022-03-21 Thread John Kitchin


"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

2022-03-21 Thread John Kitchin


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

2022-03-21 Thread John Kitchin


"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

2022-03-21 Thread John Kitchin
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

2022-03-21 Thread John Kitchin
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

2022-03-21 Thread John Kitchin
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

2022-03-20 Thread John Kitchin
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

2022-02-26 Thread John Kitchin
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)

2022-02-24 Thread John Kitchin
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)

2022-02-23 Thread John Kitchin
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

2022-02-18 Thread John Kitchin
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

2022-02-18 Thread John Kitchin
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

2022-02-18 Thread John Kitchin
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

2022-02-17 Thread John Kitchin
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

2022-02-17 Thread John Kitchin
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?

2022-02-13 Thread John Kitchin
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

2022-02-07 Thread John Kitchin
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 '}'

2022-01-24 Thread John Kitchin
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

2022-01-20 Thread John Kitchin
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

2022-01-19 Thread John Kitchin
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

2022-01-13 Thread John Kitchin
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

2022-01-13 Thread John Kitchin
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

2022-01-12 Thread John Kitchin
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

2022-01-07 Thread John Kitchin
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?

2021-12-23 Thread John Kitchin
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

2021-12-15 Thread John Kitchin
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

2021-12-15 Thread John Kitchin
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

2021-12-09 Thread John Kitchin
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

2021-12-08 Thread John Kitchin
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]]

2021-12-06 Thread John Kitchin
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/)]

2021-12-06 Thread John Kitchin
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/)]

2021-12-06 Thread John Kitchin
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/)]

2021-12-06 Thread John Kitchin
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

2021-12-04 Thread John Kitchin
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

2021-12-04 Thread John Kitchin
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

2021-12-03 Thread John Kitchin
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

2021-12-02 Thread John Kitchin
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

2021-12-01 Thread John Kitchin
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

2021-12-01 Thread John Kitchin
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

2021-11-30 Thread John Kitchin
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

2021-11-30 Thread John Kitchin
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

2021-11-24 Thread John Kitchin
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]

2021-11-18 Thread John Kitchin
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]

2021-11-17 Thread John Kitchin
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]

2021-11-17 Thread John Kitchin
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

2021-11-17 Thread John Kitchin
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)

2021-11-17 Thread John Kitchin
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

2021-11-17 Thread John Kitchin
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

2021-11-07 Thread John Kitchin
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

2021-11-07 Thread John Kitchin
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

2021-11-03 Thread John Kitchin
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


Re: org-ref 2 vs org-ref 3

2021-10-20 Thread John Kitchin
All the breaking changes are documented at
https://github.com/jkitchin/org-ref/#breaking-changes-in-version-3.

You can find configuration details at
https://github.com/jkitchin/org-ref/#configuration.

On Wed, Oct 20, 2021 at 2:59 AM Joseph Vidal-Rosset 
wrote:

>
> Dear John,
>
> I upgraded org-ref to get org-ref 3 and I met the following difficulties:
>
> - my shortcut to get the list of my bib file did not work, and I have to
> use the emacs menu,
>

If you mean keyboard shortcuts (like C-c ]), you should define these in
your init files as described in the configuration above. org-ref does not
do this automatically anymore.


>
> - I did not get  via org-ref  a pdf file of any paper,
>

I can't help you on this with so little information. is there some error?


>
> - cite links with the page(s) via "description" show only the page but
> the reference is hidden,
>

I consider the syntax of pre/postnote in the description to be deprecated
(but still supported). I pushed a fix to show the full links with a
description for the version 2 syntax. The preferred way to do pre/post
notes now is like:

version 3 syntax (keys are prefixed by &, and prenote is before the key,
postnote is after the key.

[[cite: 45]]

[[cite:see  45]]

These export to:

\cite[45]{xiao-2006-size-effec}

\cite[see][45]{xiao-2006-size-effec}

version 2 syntax still works, (the two key differences are there is no &
prefixing the citation key, and the pre/post note is in the description.

These citations

[[cite:xiao-2006-size-effec][45]]

[[cite:xiao-2006-size-effec][see::45]]

export to:

version 2 syntax

\cite[45]{xiao-2006-size-effec}

\cite[see][45]{xiao-2006-size-effec}


> at the moment, I downgraded to org-ref 2 and everything works fine.
>
> I imagine that all is in the documentation you wrote to solve these
> problems, but I wanted to point out them, in order to solve them easily
> and to contribute to the improvement of this terrific tool you gave to
> us. I do not imagine now writing without org-ref.
>
> Thanks !
>
> Jo.
>
>


Re: citeproc-style-parse: Symbol’s function definition is void: libxml-parse-xml-region

2021-10-18 Thread John Kitchin
This could mean you have an emacs that was not compiled with libxml.

Type C-h v system-configuration-options

and look for --with-xml2

to see if your emacs was built with it.
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, Oct 18, 2021 at 4:12 AM Timothy  wrote:

> Hi Joseph,
>
> The function libxml-parse-xml-region has been around for a while, what
> version
> of Emacs are you running?
>
> All the best,
> Timothy
>


Re: Expanding how the new cite syntax is used to include cross-references - thoughts?

2021-10-12 Thread John Kitchin
I am not sure it really fits the model of the exporters that are in org,
since it is basically just a pre-processing hook. I don't think there are
any exporters in org that rely on that, e.g. you can't just C-c C-e choose
a backend and export with a pre-processing hook. It doesn't make sense to
make a command that does that either I think, since you might want to use
other pre-processing hooks too, e.g. I have one called natmove (inspired by
the latex package) that moves superscript citations to the right hand side
of punctuation, and in ox-ipynb I use pre-processing functions for removing
solutions, and things like that. So some exports might use all three, and
others only two, some just one, and others none. One solution for that is
file-local variables I guess.

It also is (IMO) a part of org-ref since it uses the links that are defined
in org-ref. I see it as more an extension of org-mode than something that
needs to be in the core. For simple cross-references the built in internal
links are adequate I think.

Anyway, it should be tested for a while to see if it is the right way to do
this. Maybe there are better ideas for it.


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, Oct 12, 2021 at 5:58 PM Bruce D'Arcus  wrote:

> On Tue, Oct 12, 2021 at 5:16 PM John Kitchin 
> wrote:
> >
> > I think the existing link capability of org-mode is completely adequate
> for cross-references. LaTeX exports are almost completely covered in
> org-ref. I made a refproc (
> https://github.com/jkitchin/org-ref/blob/org-ref-3/org-ref-refproc.el)
> that provides similar export behavior for other backends in a
> pre-processing hook. It supports the concepts in autoref and cleveref by
> replacing the org-links with an appropriate org syntax that then exports
> natively. For example, if cref:name references a table, it would get
> replaced by "Table [[name]]" in the buffer and then exported to the desired
> backend.
>
> Nice work John; I'm glad you were able to sort it out.
>
> I haven't had a chance to play with it, but FYI I'm seeing a number of
> compilation warnings (see below), which should be easy enough to fix.
>
> Any reason this, or something like it, shouldn't be added to org?
>
> Bruce
>
> org-ref-refproc.el:15:1: Warning: defcustom for
> ‘org-ref-refproc-clever-prefixes’ fails to specify type
> org-ref-refproc.el:15:1: Warning: defcustom for
> ‘org-ref-refproc-clever-prefixes’ fails to specify type
>
> In org-ref-get-ref-links:
> org-ref-refproc.el:47:54: Warning: reference to free variable
> ‘org-ref-ref-types’
>
> In org-ref-refproc-referenceables:
> org-ref-refproc.el:113:60: Warning: reference to free variable
> ‘org-ref-label-re’
>
> In org-ref-refproc-cref-replacement:
> org-ref-refproc.el:379:41: Warning: assignment to free variable
> ‘prefix-data’
> org-ref-refproc.el:382:27: Warning: reference to free variable
> ‘prefix-data’
>
> In end of data:
> org-ref-refproc.el:244:7: Warning: the function ‘org-ref-ref-jump-to’ is
> not
> known to be defined.
>


Re: Expanding how the new cite syntax is used to include cross-references - thoughts?

2021-10-12 Thread John Kitchin
I think the existing link capability of org-mode is completely adequate for
cross-references. LaTeX exports are almost completely covered in org-ref. I
made a refproc (
https://github.com/jkitchin/org-ref/blob/org-ref-3/org-ref-refproc.el) that
provides similar export behavior for other backends in a pre-processing
hook. It supports the concepts in autoref and cleveref by replacing the
org-links with an appropriate org syntax that then exports natively. For
example, if cref:name references a table, it would get replaced by "Table
[[name]]" in the buffer and then exported to the desired backend.

All of these are references to two tables named b1 and b2

- ref :: ref:b1
- autoref :: autoref:b1
- nameref :: nameref:b1
- pageref :: pageref:b1
- cref :: cref:b1
- cref, two :: cref:b1,b2
- Cref :: Cref:b1
- Cref, two :: Cref:b1,b2

and they are converted to this plain org syntax (which basically mirrors
what would happen in a LaTeX export).

- ref :: [[b1]]
- autoref :: Tab. [[b1]]
- nameref :: [[b1][this is a table b1.]]
- pageref :: [[b1]]
- cref ::  Tab. [[b1]]
- cref, two :: Tabs. [[b1]] and [[b2]]
- Cref :: Tab. [[b1]]
- Cref, two :: Tabs. [[b1]] and [[b2]]

There are some options to control if the clever parts are abbreviated
and/or capitalized.

This should be part of org-ref on Melpa next week.

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, Oct 10, 2021 at 9:30 AM Bruce D'Arcus  wrote:

> Can we go back to this question of whether internal links are adequate
> for cross-references, and if not, what's missing?
>
> On Fri, Aug 13, 2021 at 11:22 AM Eric S Fraga  wrote:
> >
> > Hello John & co.,
> >
> > I need to chime in when it comes to the UI:
> >
> > On Thursday, 12 Aug 2021 at 13:19, John Kitchin wrote:
> > > I would say the UI that I like, have used for many years, and is the
> > > default of org-ref is:
> > >
> > > 1. You type C-c ] to insert a citation
> > > 2. You type C-u C-c ] to insert a cross-reference
> > > 3. you type C-u C-u C-c ] to insert a new label.
> >
> > UI is a very personal thing.  So long as there are 3 different functions
> > that implement these actions, I would be happy...
>
> [snip]
>
> > In terms of the bigger picture, citations and cross-references, to me,
> > are different things (one is external and the other usually internal,
> > respectively) and I see no benefit in conflating them.  I am also still
> > not convinced that org links are not sufficient ...
>
> In reviewing and playing with this functionality a bit, it's clear to
> me that internal links are intended to be cross-references, even if
> they fall short for certain classes of users.
>
> Let's take a simple example of a figure, adapted from the manual:
>
> #+begin_example
> #+CAPTION: This is the caption.
> #+NAME: fig:SED-HR4049
> [[./img/a.jpg]]
>
> Here's a cross-reference to Figure [[fig:SED-HR4049]].
> #+end_example
>
> This internal link seems to produce consistent and correct output
> across latex, html, and odt.
>
> The "fig" prefix is meaningful to ref in latex to enable it to type
> that cross-reference. I'm unsure how typing in the odt context works,
> but it does.
>
> The only downside is one has to manually, per the example, insert the
> prefix (here "Figure ") in text (though this is a small price to pay
> in my view).
>
> If one wants to use cleveref or autoref instead, as is now possible
> with a recent commit, those packages handle that automatically. But of
> course, this only works in latex, so you lose the consistency across
> the backends.
>
> Also, you then need to be able to specify different variants locally
> (for example, cref vs Cref), which is not possible currently.
>
> So I'm unclear: is that added functionality and complexity really
> needed? Is there something else I'm missing?
>
> A separate, possibly more important (?), matter is UI and supporting
> functionality.
>
> I think it would be nice to have better UI support for inserting these
> references.
>
> To John's point, could we add interactive functions to insert labels
> and cross-references (say as customizable functions?), using the
> existing internal link support, and iterate that support over time?
>
> Bruce
>


Re: A minor suggestion about formatting citations

2021-10-11 Thread John Kitchin
you should probably trim each key, and re-add spaces where you want them in
the function that does these kinds of things. Maybe that should even be
controlled by a defcustom that allows 0-1 spaces.

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, Oct 11, 2021 at 9:38 AM Bruce D'Arcus  wrote:

> On Mon, Oct 11, 2021 at 5:40 AM Nicolas Goaziou 
> wrote:
> >
> > Hello,
> >
> > Vikas Rawal  writes:
> >
> > > I find it works better for me if I insert spaces between multiple
> > > citations. For example: [cite: @john56; @john35; @bruce2021] rather
> > > than [cite:@john56;@john35;@bruce2021].
> > >
> > > The of advantage is that if I am citing many references in one place,
> > > and use fill-paragraph/auto-fill, they wrap nicely. As far as I can
> > > see, having spaces in between works just fine.
> > >
> > > If this does not break anything, should this be the recommended
> > > practice for the org-cite-insert-processors?
> >
> > Done, at least for insert processors relying on
> > `org-cite-make-insert-processor'. Thank you.
>
> There is one little issue I see.
>
> Org-ref, and in turn org-ref-cite, have functions, attached via keymap
> on the citation face, that allow one to shift the citation-references
> within a citation.
>
> I've borrowed some of that for oc-bibtex-actions as well.
>
> So if I insert a citation using org-cite-insert, I get this:
>
> [cite:@samers2002; @kohn2005]
>
> If I then shift the right one left, I get this, which seems less than
> ideal:
>
> [cite: @kohn2005;@samers2002;]
>
> WDYT?
>
> Bruce
>
>


Re: [org-cite] How to cite page number(s) in APA Style?

2021-10-05 Thread John Kitchin
Got it, thanks!

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, Oct 5, 2021 at 10:54 AM Bruce D'Arcus  wrote:

> On Tue, Oct 5, 2021 at 10:42 AM John Kitchin 
> wrote:
> >
> > How would this work?
> >
> > Does [cite/locators:@someone-2021].
> >
> > imply a specific field in a bibliography entry, e.g. pages, or location?
> and then CSL is responsible for formatting it to something like "p. 42" or
> "pp. 42-44", etc?
>
> As Rudy noted my example was wrong, because I forgot to include the suffix.
>
> Should be:
>
> [cite/locators:@someone-2021 p. 42]
>
> > And then if you want to refer to another page in someone-2021, then you
> need another bibliography entry with a different key for that, e.g.
> someone-2021-87 that might have page 87 in it?
>
> No. Per above, same key and entry; just a different suffix with locator.
>
> [cite/locators:@someone-2021 p. 87]
>
> Sorry for the confusion.
>
>
> Bruce
>


Re: [org-cite] How to cite page number(s) in APA Style?

2021-10-05 Thread John Kitchin
How would this work?

Does [cite/locators:@someone-2021].

imply a specific field in a bibliography entry, e.g. pages, or location?
and then CSL is responsible for formatting it to something like "p. 42" or
"pp. 42-44", etc?

And then if you want to refer to another page in someone-2021, then you
need another bibliography entry with a different key for that, e.g.
someone-2021-87 that might have page 87 in it?

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, Oct 3, 2021 at 6:59 AM Bruce D'Arcus  wrote:

> On Sun, Oct 3, 2021 at 6:35 AM Rudolf Adamkovič  wrote:
>
> > I use APA (via CSL) to cite and would like to write
> >
> > > According to Someone (2021), foo-bar (p. 42).
> >
> > I can almost do it with
> >
> > > Accordint to [cite/text:@someone-2021], foo-bar
> > > .
> >
> > Any ideas? In APA, this pattern comes up often.
>
> ATM, your only option is to do "(p. 42)."
>
> It would be possible (easy?) to add a "locators" style to
> citeproc-el/oc-csl as in oc-biblatex, in which case you would do:
>
> According to [cite/text:@someone-2021], foo-bar
> [cite/locators:@someone-2021].
>
> Bruce
>
>


Re: Bare oc-csl author variants?

2021-10-05 Thread John Kitchin
These would be equivalent to things like \citeauthor{key} in natbib 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 Tue, Oct 5, 2021 at 9:29 AM Bruce D'Arcus  wrote:

> On Tue, Oct 5, 2021 at 9:19 AM Timothy  wrote:
>
> > > It’s just odd to have a name without any other citation marker. How
> > > would a reader know it’s a citation?
> >
> > For context, I’m basically just using this as a way to insert the
> author’s name
> > without any chance of typos.
>
> Right.
>
> I don't see any downside in adding them myself.
>
> Bruce
>
>


Re: Would it be possible to color horizontal lines in org mode?

2021-09-30 Thread John Kitchin
This looks correct. Some people prefer to use named functions for this,
so it is easier to remove them, but this works fine.

Alper Alimoglu  writes:

> Thank you Professor Kitchin. Would something like follows would work?
> #+BEGIN_SRC emacs-lisp :results silent
> (add-hook 'org-mode-hook (lambda () (font-lock-add-keywords
>  nil
>  '(("^-\\{5,\\}"  0 '(:foreground "red" 
> :weight bold))
> #+END_SRC
>
> -Alper 
>
> On Tue, Sep 28, 2021 at 8:18 PM John Kitchin  wrote:
>
>  you can add a rule like this in an org-mode hook:
>
>  #+BEGIN_SRC emacs-lisp :results silent
>  (font-lock-add-keywords
>   nil
>   '(("^-\\{5,\\}"  0 '(:foreground "red" :weight bold
>  #+END_SRC
>
>  that will make a line starting with at least 5 - be red and bold in color.
>
>  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, Sep 28, 2021 at 4:00 AM Eric S Fraga  wrote:
>
>  You could use hi-lock-mode to define your own colouring for such
>  lines.  But I'm sure those that under font-locking better might be able
>  to add appropriate rules for this horizontal line construct.
>
>  -- 
>  : Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
>  : Latest paper written in org: https://arxiv.org/abs/2106.05096


-- 
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: Would it be possible to color horizontal lines in org mode?

2021-09-28 Thread John Kitchin
you can add a rule like this in an org-mode hook:

#+BEGIN_SRC emacs-lisp :results silent
(font-lock-add-keywords
 nil
 '(("^-\\{5,\\}"  0 '(:foreground "red" :weight bold
#+END_SRC

that will make a line starting with at least 5 - be red and bold in color.

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, Sep 28, 2021 at 4:00 AM Eric S Fraga  wrote:

> You could use hi-lock-mode to define your own colouring for such
> lines.  But I'm sure those that under font-locking better might be able
> to add appropriate rules for this horizontal line construct.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>
>


Re: Capture abort: Symbol’s function definition is void: turn-on-org-provide

2021-09-23 Thread John Kitchin
you should use describe-variable on org-capture-templates. Maybe some other
package has added to it.
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, Sep 23, 2021 at 12:01 PM Joseph Vidal-Rosset <
jos...@vidal-rosset.net> wrote:

>
>
> Le 23/09/2021 à 17:28, Daniel Fleischer a écrit :
> > Joseph Vidal-Rosset  writes:
> >
> >> To capture an email and to link this message for gnus, I get now this
> >> error message:
> >>
> >> Capture abort: Symbol’s function definition is void: turn-on-org-provide
> >
> > What is your capture template?
> >
> > --
> >
> > Daniel Fleischer
>
> In myagenda.el  I have this function:
>
> (setq org-capture-templates
>'(
> ("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org"
> "Tasks")
>   "* TODO [#A] %?\n
> [[~/Dropbox/Orgzly/links.org::%(org-insert-time-stamp (org-read-date nil
> t \"%:date\"))]] \n* %(org-insert-time-stamp (org-read-date nil t
> \"%:date\")) %a "
>  )
> ("n"  ; key
>  "note"   ;name
>  entry;type
>  (file+headline "~/Dropbox/Orgzly/notes.org" "Notes")  ;target
>   "* NOTE du %(org-insert-time-stamp (org-read-date nil t
> \"%:date\")) \n Voir %a " ; template
>  )
> ("H" "HOWTO: C-c C-s : schedule ; C-c C-d : deadline ; C-c C-w :
> org-refile at a point; last: C-c C-t : DONE - F11-a: org-archive"
>   entry (file+headline "" "") ""
>  )
> )
>)
>
> But nowhere in this file have function " turn-on-org-provide" . :(
>
> A suggestion?
>
> Many thanks,
>
> Jo.
>
>
>


Re: [org-cite] citations in property drawers?

2021-09-15 Thread John Kitchin
Not all org files are destined for export. I slightly feel users should be
allowed to put citations in places where it might not make sense in export,
and that they are responsible for knowing what they are doing.

I am sympathetic to the reality that the second half of that statement is a
big ask, and that it can lead to confusion. Nothing stops anyone from
manually typing or pasting a citation into those places though. I would be
inclined to use the activate function to highlight those that are in places
that won't export, rather than limit where people can put them using the
insert mechanism.

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, Sep 15, 2021 at 1:11 PM Tom Gillespie  wrote:

> > That would be a terrible idea. Exporters are not required to handle all
> > data contained in properties drawers, so this may introduce errors,
> > e.g., when trying to number citations.
>
> I agree completely. You can't export something that has no anchor in
> text that would be rendered. Maybe I misunderstood the original
> question, because there is no way that a citation or footnote could be
> exported from there, so I think in your conception text that follows
> the format of the citations or footnotes isn't actually a citation or
> footnote unless it exports as such.
>
> Best,
> Tom
>
>


Re: emacs-jupyter does not send result form babel block

2021-09-08 Thread John Kitchin
I think this is a bug in jupyter-org-client.el in this function:

(defun jupyter-org--add-result (req result)
  (cond
   ((jupyter-org-request-silent-p req)
(unless (equal (jupyter-org-request-silent-p req) "none")
  (message "%s" (org-element-interpret-data result
   ((jupyter-org-request-async-p req)
(jupyter-org--clear-request-id req)
(jupyter-org--do-insert-result req result))
   (t
(push result (jupyter-org-request-results req)

The problem is that when the jupyter block is executed to define the
variable in the python header, it is run with a "silent" results param. The
function above is responsible for adding the results to the
jupyter-org-request struct, and here when it sees the results are silent,
it does not do that, so the results are nil, which is why you see what you
see.

I don't think that behavior is correct. It isn't quite right to just remove
the first block though, at least in this case. The result in this function
is already structured as a fixed-width results element intended to be
interpreted as a results string, and not the numeric value returned. So the
fix is probably upstream from this.

I am not sure what the fix is for this. The code path from C-cC-c to
executing the code, handling the request to the kernel, getting results and
to the output is very hard to follow for me. I would post an issue at
https://github.com/nnicandro/emacs-jupyter/issues.

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, Sep 4, 2021 at 4:22 PM Rafael  wrote:

>
> I am using emacs-jupyter (https://github.com/nnicandro/emacs-jupyter),
> and I have just noticed that results from a block are not sent to
> another block. I think it has to do with this issue
> https://github.com/nnicandro/emacs-jupyter/issues/222. Can somebody
> suggest a workaround? (I actually want to use the output from a kernel
> different from python, but since the problem happens also with the python
> kernel I'm using it as an example).
>
>   #+name: atest
>   #+begin_src jupyter-python :session test
> 1+1
>   #+end_src
>
>   #+RESULTS: graphst
>   : 2
>
>   #+begin_src python :var adjs=atest
> adjs
>   #+end_src
>
>   #+RESULTS
>   : nil
>
>


Re: Bug Re: Greater than, less than bug in emacs-lisp source block

2021-09-07 Thread John Kitchin
My current solution (which already differs from the last one I posted
here...) is here:

https://github.com/jkitchin/scimax/blob/master/scimax-org-src-blocks.el#L61

It is more selective, and only changes the syntax inside these src
blocks:

"jupyter-python" "python" "emacs-lisp"

and does not change the syntax if the character is in a string.

That way it still works with xml and html in strings, or in their own
blocks.

This might be the third iteration of fixing this issue, so I wouldn't
have the hubris to say it is the final solution yet.


Eric S Fraga  writes:

> I believe this has been mentioned in passing in this thread but I'll
> repeat just in case: Unless you are working with xml or HTML in your org
> documents, and even then, having these two lines in your org
> configuration (e.g. org-mode-hook):
>
> (modify-syntax-entry ?< ".")
> (modify-syntax-entry ?> ".")
>
> solves all the problems with languages that use these in an unbalanced
> manner (comparison, assignment).  I've had this configuration for years
> now and it just works (for me).


--
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: Bug Re: Greater than, less than bug in emacs-lisp source block

2021-09-03 Thread John Kitchin
My previous solution seems like it stopped working for some reason. Here is
a new version that "should" only change syntax inside src-blocks, but not
inside strings.

It looks like this does not impact html blocks, or xml blocks.

It is probably possible to make it mode specific if needed.


(defun scimax-org-mode-<>-syntax-fix (start end)
  "Change syntax of characters ?< and ?> to symbol within source code
blocks."
  ;; I think this gets run in a special edit buffer for src-blocks. For now
I
  ;; only run this in the src blocks, so that outside the src-blocks these
still
  ;; act like b=open/close brackets.
  (when (org-src-edit-buffer-p)
(let ((case-fold-search t))
  (goto-char start)
  ;; this "fixes" <>, {} and [] that fixes some issues in src blocks,
but
  ;; makes some new issues, which is now you cannot use them as
brackets.
  ;; this tries to be fancy and not change the syntax in strings.
  (while (re-search-forward "[[<{]\\|[]>}]" end t)
(unless (ppss-string-terminator (syntax-ppss (point)))
 (put-text-property (point) (1- (point))
 'syntax-table (string-to-syntax "_")))


(defun scimax-fix-<>-syntax ()
  "Fix syntax of <> in code blocks.
This function should be added to `org-mode-hook' to make it work."
  (setq syntax-propertize-function 'scimax-org-mode-<>-syntax-fix)
  (syntax-propertize (point-max)))

(add-hook 'org-mode-hook
 #'scimax-fix-<>-syntax)


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, Sep 3, 2021 at 9:47 AM Tim Cross  wrote:

>
> I think what is happening here is that org is bumping up against
> fundamental design limitations of Emacs. In basic terms, much of Emacs'
> underlying design is based on an assumption that a file only has a
> single major mode. Org works hard to get around this limitation, but it
> comes with cost - usually either performance or complexity.
>
> I think this could probably be characterised as a bug without a workable
> solution. While there are things youc an do, they all seem to have
> unwanted side effects. To what extent those side effect impact you
> depends on your use case (as John points out, if you have blocks of HTML
> or XML or JSX etc, changing the syntax table to make < and > 'normal'
> characters would fix the elisp issue, but break things in those source
> blocks.
>
> So really, what we have is an issue without a clean solution. Best
> anyone can do is select one of the proposed work-arounds which has
> minimal impact on the user. Personally, I never edit source blocks
> except in the special edit mode, so don't really notice the problem with
> mismatched parens.
>
> John Kitchin  writes:
>
> > That is probably a matter of opinion.
> >
> > If you use angle brackets as delimiters, e.g. in html, xml in
> src-blocks, then the current syntax definition makes sense because
> > you can use them to find open and closing brackets, navigate them, etc..
> If you don't use those, it makes less sense, and maybe
> > isn't even something 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, Sep 3, 2021 at 7:42 AM Charles Millar 
> wrote:
> >
> >  Thank you, John.
> >
> >  I will give it a try.
> >
> >  However, is this a bug that should be fixed within org source code?
> >
> >  Charlie Millar
> >
> >  On 9/2/21 2:24 PM, John Kitchin wrote:
> >  > I think this issue is described in
> >  >
> https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch
> .
> >  > There are also some solutions 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
> >  >
> >  >
> >  >
> >  > On Thu, Sep 2, 2021 at 2:10 PM Charles Millar 
> wrote:
> >  >
> >  >> Set up:
> >  >> GNU E

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

2021-09-03 Thread John Kitchin
That is probably a matter of opinion.

If you use angle brackets as delimiters, e.g. in html, xml in src-blocks,
then the current syntax definition makes sense because you can use them
to find open and closing brackets, navigate them, etc.. If you don't use
those, it makes less sense, and maybe isn't even something 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, Sep 3, 2021 at 7:42 AM Charles Millar  wrote:

> Thank you, John.
>
> I will give it a try.
>
> However, is this a bug that should be fixed within org source code?
>
> Charlie Millar
>
>
> On 9/2/21 2:24 PM, John Kitchin wrote:
> > I think this issue is described in
> >
> https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch
> .
> > There are also some solutions 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
> >
> >
> >
> > On Thu, Sep 2, 2021 at 2:10 PM Charles Millar 
> wrote:
> >
> >> Set up:
> >> GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
> >> cairo version 1.16.0) of 2020-12-31
> >> Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @
> >> /usr/local/share/org-mode/lisp/)
> >>
> >> The following code will evaluate
> >>
> >> #+begin_src emacs-lisp
> >> (defun Foo ()
> >> (if (= 2 4) bar))
> >> #+end_src
> >>
> >> #+RESULTS:
> >> : Foo
> >> and the opening and closing parentheses match.
> >>
> >> If a greater than is inserted instead of equals, thus
> >>
> >> #+begin_src emacs-lisp
> >> (defun Foo ()
> >> (if (> 2 4) bar))
> >> #+end_src
> >>
> >> it apparently evaluates, however, the closing parenthesis immediately
> >> following the "4" is paired with the opening paren before "if" and not
> >> the opening paren immediately before the ">"
> >>
> >> A "less than" results with stranger parenthesis matching - the closing
> >> paren after the "4" matches no others; the closing paren immediately
> >> after "bar" matches the opening paren before "if"
> >>
> >> Charlie Millar
> >>
> >>
> >>
> >>
> >
>
>
>


Re: Greater than, less than bug in emacs-lisp source block

2021-09-02 Thread John Kitchin
I think this issue is described in
https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch.
There are also some solutions 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



On Thu, Sep 2, 2021 at 2:10 PM Charles Millar  wrote:

> Set up:
> GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
> cairo version 1.16.0) of 2020-12-31
> Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @
> /usr/local/share/org-mode/lisp/)
>
> The following code will evaluate
>
> #+begin_src emacs-lisp
> (defun Foo ()
> (if (= 2 4) bar))
> #+end_src
>
> #+RESULTS:
> : Foo
> and the opening and closing parentheses match.
>
> If a greater than is inserted instead of equals, thus
>
> #+begin_src emacs-lisp
> (defun Foo ()
> (if (> 2 4) bar))
> #+end_src
>
> it apparently evaluates, however, the closing parenthesis immediately
> following the "4" is paired with the opening paren before "if" and not
> the opening paren immediately before the ">"
>
> A "less than" results with stranger parenthesis matching - the closing
> paren after the "4" matches no others; the closing paren immediately
> after "bar" matches the opening paren before "if"
>
> Charlie Millar
>
>
>
>


Re: how to get multi-line author in ODT export?

2021-08-26 Thread John Kitchin
That is really nice, thanks for sharing it!
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, Aug 26, 2021 at 12:55 PM Juan Manuel Macías 
wrote:

> Hi again,
>
> Another simpler approach, with a filter:
>
> #+TITLE: The kessel run in 12 parsecs
> #+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
>
> #+BIND: org-export-filter-plain-text-functions (author-lb-filter)
> #+begin_src emacs-lisp :exports results :results none
>   (defun author-lb-filter (text backend info)
> (cond ((org-export-derived-backend-p backend 'odt)
>(replace-regexp-in-string "!!!" "\n" text))
>   ((org-export-derived-backend-p backend 'latex)
>(replace-regexp-in-string "!!!" "" text
> #+end_src
>
> Content...
>
> Best regards,
>
> Juan Manuel
>
> Juan Manuel Macías writes:
>
> > Hi Eric,
> >
> > I think the problem is in this two lines of `org-odt-template', that
> > creates the meta.xml file inside the odt file:
> >
> > (format "%s\n" author)
> > (format "%s\n" author)
> >
> > Perhaps, modifying them like this:
> >
> > (format "\n"
> (replace-regexp-in-string "" "\n" author))
> > (format "\n"
> (replace-regexp-in-string "" "\n" author))
> >
> > We could do this in our documents:
> >
> > #+AUTHOR: Han Solo \\ Chewbacca
> >
> > (little tested)
> >
> > Best regards,
> >
> > Juan Manuel
> >
> > Eric S Fraga writes:
> >
> >> So, as usual, I answer my own question, sort of.
> >>
> >> The problem is that org exports the author text enclosed within a
> >> special directives, specifically:
> >>
> >>  (format "%s" author))
> >>
> >> New line directives are not allowed within this declaration, it
> >> seems.  Removing (manually) the initial-creator directive then works.
> >>
> >> So, my question would be: is this text:initial-creator tagging
> >> necessary?  If not, can we remove it?  The OpenDocument schema is vague
> >> about whether this is necessary.  If we cannot remove it, i.e if
> >> initial-creator is required in the document, could it be put in
> >> separately (as a meta:initial-creator tag) so that the author field can
> >> be more general?
> >>
> >> I am *not* an ODT expert of any sort.  But it is my route to Word
> >> documents when the need arises (which is luckily seldom).
> >>
> >> Anyway, no panic: I can simply manually edit the odt file just before
> >> the final processing...
> >>
> >> Thank you,
> >> eric
> >
> >
>
>


Re: how to get multi-line author in ODT export?

2021-08-26 Thread John Kitchin
Does something like this work for you:

#+options: author:nil
#+author: Test author - not shown in export

@@odt:First author
lineSecond
line@@

Testing with content

This exports to ODT like this for me:
[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
http://kitchingroup.cheme.cmu.edu



On Thu, Aug 26, 2021 at 10:24 AM Eric S Fraga  wrote:

> So, as usual, I answer my own question, sort of.
>
> The problem is that org exports the author text enclosed within a
> special directives, specifically:
>
>  (format "%s" author))
>
> New line directives are not allowed within this declaration, it
> seems.  Removing (manually) the initial-creator directive then works.
>
> So, my question would be: is this text:initial-creator tagging
> necessary?  If not, can we remove it?  The OpenDocument schema is vague
> about whether this is necessary.  If we cannot remove it, i.e if
> initial-creator is required in the document, could it be put in
> separately (as a meta:initial-creator tag) so that the author field can
> be more general?
>
> I am *not* an ODT expert of any sort.  But it is my route to Word
> documents when the need arises (which is luckily seldom).
>
> Anyway, no panic: I can simply manually edit the odt file just before
> the final processing...
>
> Thank you,
> eric
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-628-g366444
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>
>


Re: [wip-cite-new] Merging tomorrow?

2021-08-20 Thread John Kitchin
I think bibtex-completion is agnostic of ivy or helm, and doesn't require
either of them to work. You can use it for candidates to selectrum if you
want, and the other many features it offers for notes, pdf, etc...


On Fri, Aug 20, 2021 at 11:07 AM Bruce D'Arcus  wrote:

> I think so.
>
> I actually just started the process of removing the bibtex-completion
> dependency.
>
> Give it a try in any case. It should work well with org-cite, and you
> can even use pieces of org-ref-cite if you prefer that to my
> (currently) more minimal embark-based approach.
>
> On Fri, Aug 20, 2021 at 10:53 AM Eric S Fraga  wrote:
> >
> > Bruce,
> >
> > off-list, I notice that bibtex-actions has been updated.  I have been
> > using bibtex-completions but as I now longer use either ivy or helm,
> > having switched to selectrum, I should probably switch to your
> > package.  Would this be a correct view/conclusion?
> >
> > Thank you,
> > eric
> >
> > --
> > : Professor Eric S Fraga
> > : Fresa black box optimization: doi:10.5281/zenodo.5045812
> > : PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
> >
> > Latest publications: doi:10.3303/CET2186011 & arxiv:2106.05096
>
>


too aggressive org-cite fontification?

2021-08-19 Thread John Kitchin
If I have a link like cite:@key, it is fontified as an org-ref link, but if
it is [[cite:@key]] it is fontified as an org-cite. That seems like a bug,
only [cite:@key] should be fontified as an org-cite.

Does anyone else see this behavior?


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: Function for retrieving the link of an Org Mode buffer

2021-08-14 Thread John Kitchin
I would probably do it like this:

(org-element-map (org-element-parse-buffer) 'link
  (lambda (lnk)
(let ((lnkplist '()))
  (setq lnkplist (plist-put lnkplist :link (org-element-property
:raw-link lnk)))
  (when (org-element-property :contents-begin lnk)
(setq lnkplist (plist-put lnkplist :desc (buffer-substring-no-properties
 (org-element-property :contents-begin lnk)
 (org-element-property :contents-end lnk)
  lnkplist)))



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, Aug 13, 2021 at 9:16 PM Rodrigo Morales <
moralesrodrigo1...@gmail.com> wrote:

>
> I've written the following function for retrieving the links from a
> given Org Mode buffer.
>
> #+BEGIN_SRC elisp
> (defun my/org-collect-links-in-buffer (buffer)
>   "Collect all the links in the current buffer. If the link has a
> description, then it is also collected.
>
> Returns a list of PLISTS of the form:
>
> ((:link LINK)
>  (:link LINK :desc DESC)
>  (:link LINK))"
>   (with-current-buffer buffer
> (save-excursion
>   (beginning-of-buffer)
>   (let (links)
> (while (re-search-forward org-any-link-re nil t)
>   (catch 'done
> (let* ((element (org-element-context))
>(type (org-element-type element)))
>   (unless (eq type 'link)
> (throw 'done t))
>   (let (obj
> (link (org-element-property :raw-link element))
> desc)
> (push link obj)
> (push :link obj)
> (when (and (org-element-property :contents-begin element)
>(org-element-property :contents-end element))
>   (setq desc (buffer-substring-no-properties
>   (org-element-property :contents-begin
> element)
>   (org-element-property :contents-end
> element)))
>   (push desc obj)
>   (push :desc obj))
> (push obj links)
> links
> #+END_SRC
>
> I would really appreciate any feedback.
>
>


Re: Custom function for killing the thing at point

2021-08-14 Thread John Kitchin
alternatively, fall back to org-mark-element. I am not sure what
differences in what you are trying to achieve and this are, but this should
cover all org elements:

(defun org-kill-element ()
  (interactive)
  (org-mark-element)
  (call-interactively #'kill-region))

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, Aug 13, 2021 at 9:45 PM Ihor Radchenko  wrote:

> Rodrigo Morales  writes:
>
> >   (t
> >(error "The element at point couldn't be copied.")))
>
> I would fall back to region between :begin and :end of the element.
>
> Also, it might be helpful to print a short message about what element
> have just been copied.
>
> Best,
> Ihor
>
>


  1   2   3   4   5   6   7   8   9   10   >