Re: Basic citations: should default citation style have a name and style code?
On Sun, Jan 14 2024, William Denton wrote: > On Sunday, January 14th, 2024 at 00:08, William Denton > wrote: > >> While we're talking about citations, I'm stuck on something else. If I run >> "C-c C-x @" to insert a citation into a file, I'm shown a list of >> bibliography >> entries and I can go up and down and hit RET on any I chose. That works well. >> But---the prompt says, "Key (empty input exits)." What makes empty input? I >> can't figure it out. I've never seen that phrase before. I can't make it exit >> properly---I either keep adding citations or C-g or DEL cancels it---so I >> can't make the function work. If anyone knows, I can try making a patch to >> make it clearer. > > As so often happens, a few minutes after sending an email I think I found the > answer: it's seems to be a problem with the completion mechanism Ivy. > > https://stackoverflow.com/q/77489325/854346 > > I ran "emacs -Q" and I see how it works there, with RET closing things off, > which makes sense. > > Last year I looked at Vertico and thought about trying it out, but since > everything was working fine, I didn't. Now I've found a reason, I guess. Ah, > Emacs! You'll run into the same issue with Vertico, I suspect. Completion mechanisms such as Ivy and Vertico tend to default to the first visible candidate when you just hit RET, not to the current input. This is so that you don't need to complete the top candidate, you can just hit a few characters and if the candidate you want is at the top, you can just hit RET. A consequence of this is that you cannot use RET to select the empty input. Both Ivy and vertico provide a command for that, though. I don't know which command Ivy uses and to which it is bound, but the docs should be able to tell you. -- Joost Kremers Life has its moments
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Sat, Nov 05 2022, Ihor Radchenko wrote: > Mmm.. By manually checking magit log. It can provide extra highlight for > things that have been changed and also moved around (which is more > accurate than raw LOC count from git). > > And I missed one of the aikrahguzar's commits. With f41befa, his > contribution exceeds 15LOC. I can see if he/she is willing to sign a copyright assignment form. There's another contributor not reflected in the commit log, however. The code that removes TeX markup was originally part of Ebib and contributed by Hugo Heagren. I moved it to parsebib without thinking about proper attribution. I'll ask him as well. -- Joost Kremers Life has its moments
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Thu, Nov 03 2022, Ihor Radchenko wrote: > The rules are in > https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant > > Shuguang Sun contributed TINYCHANGE (no need for copyright assignment; >though he contributed ~15LOC and it is on the edge) > Martin R. Albrecht also contributed TINYCHANGE > Alex Branham -- TINYCHANGE > aikrahguzar -- TINYCHANGE > András Simonyi has copyright assignment (see > https://orgmode.org/worg/contributors.html) > And you have the copyright assignment How did you determine this, if I may ask? aikrahguzar's contribution at first sight seems more involved, though I admit part of those changes is stuff being moved around. > I see no obstacles to go for ELPA, unless you have strong reasons to > avoid asking copyright assignment for future contributors. No, I don't have reasons to avoid that. -- Joost Kremers Life has its moments
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Sun, Oct 30 2022, Ihor Radchenko wrote: > May I know if there is any update on the copyright assignment situation? > If you need any help, we can provide it. I have signed the form and sent it in, and I have received the counter-signed form back from the FSF. Parsebib's Github page mentions 6 contributors, however, and I have no idea if they all have copyright assignments, or if their contributions are small enough not to require one. I could dive into that and see if we need more copyright assignments, or I could ask for parsebib to be included in non-GNU Elpa, which would probably be faster. Don't know if you have a preference. -- Joost Kremers Life has its moments
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Tue, Jul 19 2022, Bruce D'Arcus wrote: >> So does this mean there is no longer any reason to add parsebib to (Non-)GNU >> ELPA? > > No, since parsebib is an important dependency for citeproc-el, and > Ihor was suggesting Andras try to get that in ELPA. Ok, thanks. Sending my copyright assignment now... -- Joost Kremers Life has its moments
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Sun, Jul 17 2022, Ihor Radchenko wrote:
> alain.coch...@unistra.fr writes:
>
>> My .bib file is
>>
>>@string{jgr="J. Geophys. Res."}
>>@ARTICLE{chouet88,
>>journal=jgr,
>>author={Chouet, B.}, title={Resonance of a fluid-driven crack: [...]},
>>year={1988}, volume={93}, number={B5}, pages={4375-4400}
>
> Fixed on main via c550a4290.
>
> After discussion with Emacs devs, it turned out that there is a way to
> make bibtex.el parse and substitute @string abbreviations.
So does this mean there is no longer any reason to add parsebib to (Non-)GNU
ELPA?
--
Joost Kremers
Life has its moments
Re: Can citeproc be installed without using MELPA? (was: @string abbreviation in bib file not honored in (basic) org-cite)
On Sun, Jul 10 2022, Ihor Radchenko wrote: > András Simonyi writes: > >>> The problem with parsebib is that it does not even have license >>> (I do not see any in https://github.com/joostkremers/parsebib). If >>> parsebib were a part of Emacs core or at least a part of ELPA, we would >>> also be able to use it in Org core. >> >> looking into the source code (parsebib.el), the library seems to be >> under a BSD-type license. Yes, it is. It's a single file and the license is at the top. I can add a separate license file if that's necessary. > Then, I am wondering if parsebib can be added to ELPA or at least > non-GNU ELPA. The same can be said for all other dependencies of > citeproc.el and for citeproc itself. I'd have no problem if it were added to non-GNU ELPA. GNU ELPA is a little difficult because I don't have a copyright assignment on file. (It's proven a little difficult to get someone in the company to sign the corporate waiver...) -- Joost Kremers Life has its moments
Re: Conversion to Jupyter notebooks
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
Conversion to Jupyter notebooks
Hi list, I was wondering if anyone here has experience converting Org files to Jupyter notebooks, keeping the python source blocks as code blocks and correctly identifying the =#+RESULTS:=. Just dropping the results would be fine as well. I realise there are several ways to interact with Jupyter notebooks in Emacs, but that's not really what I'm looking for. I'd like a plain old Org file with source blocks that I can execute within Emacs and I would like to convert that into an .ipynb file that I can share with people that don't use Emacs. All I could find on the internet was a script by John Kitchin[1] that's from 2017 and it's apparently not entirely compatible with current Emacs and/or Org mode, as it throws errors when I try to use it. I'm sure I could fix the errors, but before I invest the time to do that, I wanted to ask here. TIA Joost Footnotes: [1] https://kitchingroup.cheme.cmu.edu/blog/2017/01/21/Exporting-org-mode-to-Jupyter-notebooks/ -- Joost Kremers Life has its moments
Re: "Orgdown", the new name for the syntax of Org-mode
On Sun, Nov 28 2021, Tom Gillespie wrote: > PS Another brainstormed name: Orgsyn? Why not just use the term "Org markup"? It's descriptive and should be understandable to people familiar with the concept of markup languages. -- Joost Kremers Life has its moments
Re: [org-cite] CSL processor, APA Style, and no-date citations
On Wed, Nov 17 2021, Bruce D'Arcus wrote: > I don't believe so, unless there's some good latex -> html solution > I'm not aware of. There's (at least) tex4ht and lwarp, but to what extent they support biblatex, I don't know. -- Joost Kremers Life has its moments
Re: Evaluate or execute?
On Sun, Oct 24 2021, Thomas S. Dye wrote: > The org manual and various documents on Worg appear to use the subject terms > as > synonyms for running a bit of source code and gathering its result. Is there > a > useful distinction that this non-software engineer is missing? Or, are the > terms simply synonymous? To me, the term "evaluate" suggests that the piece of code returns a value that one is interested in, while "execute" suggest that the code has some side effect and doesn't return a value (or one that is ignored). Though I doubt this is a very firm distinction that is strictly adhered to. For practical purposes, you can probably consider them synonymous. -- Joost Kremers Life has its moments
[OT] Ebib file field [was: New user experience ct'd: exporting citations into LaTeX (9.5)]
On Wed, Oct 13 2021, Leszek Wroński wrote: > thank you very much for your responses to my previous query. (I will > study the ebib package more closely; as of now it does not seem to > work with the file fields in my Mendeley-created .bib file. This can probably be remedied with a little Elisp. There's a user option `ebib-file-name-mod-function`, which is called to convert the contents of the `file` field into a file name that can be passed to a pdf viewer (and vice versa). An example is in this Github issue: https://github.com/joostkremers/ebib/issues/126 If your Elisp fu isn't too strong, I should be able to help. -- Joost Kremers Life has its moments
Re: Useful package? Compat.el
On Mon, Oct 11 2021, Timothy wrote: > I think the way to do this would be as a “soft” dependency, i.e. not needed > for > anyone running a recent version of Emacs, but needed if you want to use Org > with > an old version of Emacs. Not sure how this would best be done, but if this > were > to be useful, this is how I’d imagine it working. IIUC you can simply specify a dependency on `compat` and the package itself will make sure only the necessary compatibility functions are loaded given the Emacs version it's running in. So if you're running Emacs 28, nothing is loaded; if you're running Emacs 27, `compat-28.1` is loaded to ensure packages written for Emacs 28 can still be used; if you're running Emacs 26, both `compat-27.1` and `compat-28.1` are loaded, etc. -- Joost Kremers Life has its moments
Re: Request to Unsubscribe
On Fri, Oct 01 2021, Jain, Rishabh wrote: > Hi: > > Hope you are doing well. I'd appreciate if you can help unsubscribe me from > the orgmode mailing list. > > Please let me know if you have any questions or concerns. > > Kind Regards, > Rishabh It's not immediately obvious, but the mailing list page tells you how to unsubscribe: https://lists.gnu.org/mailman/listinfo/emacs-orgmode Just scroll down to the bottom. -- Joost Kremers Life has its moments
Re: Org-cite follow function for ebib
Hi Thomas & others, On Sat, Aug 07 2021, Thomas S. Dye wrote: > Aloha Joost, > > Following some pointers from Eric and Bruce I have this in my > configuration and it seems to work fine, though I haven't had a chance > to use it very much. Thanks for figuring that out. :-) Once I get to implementing support, I'll use it as a starting point. There should also be a way to open the correct file automatically, without the user having to select it. -- Joost Kremers Life has its moments
Re: Org-cite follow function for ebib
On Fri, Aug 06 2021, Thomas S. Dye wrote: > Yes, I have set the basic follow processor and org-open-at-point takes > me to the .bib file at the entry for the key at point. Unfortunately, I haven't had the time yet to update Ebib for the new functionality. Ebib needs to implement a follow processor so that `org-open-at-point` takes you to the entry in Ebib. > Surprisingly (to me), M-x ebib sometimes displays the entry for the key > at point, too. That's because when you start Ebib with `M-x ebib` (or a key bound to that function, of course), it checks to see if point is at something that looks like a key and tries to find a corresponding entry in the current database. That functionality is not customisable and not very well implemented, so it doesn't always work. (Also, if point is at the `cite` prefix, it doesn't work.) -- Joost Kremers Life has its moments
Re: [wip-cite-new] Merging tomorrow?
On Thu, Jul 08 2021, Bruce D'Arcus wrote: > On Wed, Jul 7, 2021 at 11:48 PM Timothy wrote: > >> wip-cite-new deals with citing from bibliographies, but I don't think it >> deals with within-document referencing --- should it? > > It doesn't now. > > I guess to break down the second question further: > > 1. Should it? One thing to keep in mind here: these are two different sets of functionality and a tool designed to handle one isn't necessarily right for handling the other. Org-cite provides four capabilities: insert, follow, activate and export. And while they may be very similar conceptually for a user, a provider would need to handle each of these very differently for citations and in-document references. And that's the point: while it makes sense for Ebib to provide insert and follow capabilities for citations, there is really no point in Ebib providing those for in-document references as well. It doesn't have the infrastructure for it, nor is Ebib the first (or even second or third) option that comes to mind when you think about inserting and following in-document references. I do think it makes sense if such a hypothetical org-new-ref has a very similar conceptual design to org-cite and a very similar user interface (e.g., the same keybindings), and perhaps a part of the code can be shared, it should be possible to register different provides for them. -- Joost Kremers Life has its moments
Re: [org-cite] citekey restrictions?
On Sun, May 16 2021, Nicolas Goaziou wrote:
> However, allowing anything means some keys will not be compatible with
> some bibliography formats. For example, I doubt BibTeX would appreciate
> a percent character in a key.
Careful, trying to find out the details of BibTeX's file format is a quest that
I think no-one has ever returned from. :D I have a comment in =parsebib.el=
saying that BibTeX allows $ ^ and & in entry keys, despite the fact that those
characters are special in TeX...
The regexp =parsebib.el= uses for entry keys is this:
"[^\"@\\#%',={} \t\n\f]+"
Mind you, I have no idea if BibTeX really rejects all these characters (well,
I'm pretty sure about the white space... :D ), but even if they are acceptable,
they probably don't occur much in the wild. At least I'm not aware of any user
complaints since the time I added support for $^&, which was four years ago,
> So... let's get liberal and say a key must match:
>
> (rx "@" (one-or-more (any word "-.:?!`'/*@+|()<>&_^$#%&~")))
>
> Nothing bad could happen, right?
On a scale of 1 to 10, 1 being getting an error message and having to go online
to find out what it means, and 10 being the total and utter destruction of our
solar system, I doubt it'll exceed 1.
--
Joost Kremers
Life has its moments
Re: CSL-JSON support for =parsebib=
On Sat, May 08 2021, András Simonyi wrote: > this is just to +1 this on my part as well. Although unadvertised, > citeproc-org basically already supports CSL-JSON bibliographies, and > it would be fantastic if other components of the Emacs > citation/bibliography infrastructure also did. BTW, would CSL-JSON > support in =parsebib= mean that there is hope for having CSL-support > in Ebib too? Yes, that is the plan. No promises on an ETA, but it's high on my to-do list. -- Joost Kremers Life has its moments
Re: CSL-JSON support for =parsebib=
On Fri, May 07 2021, Titus von der Malsburg wrote:
>> Apparently, =json-parse-{buffer|string}= then gives you a symbol with a space
>> in it...
>
> I now see that symbol names “can contain any characters whatever” [1]. But
> many
> characters need to be escaped (like spaces) which isn’t pretty.
Agreed. But if you pass such a symbol to =symbol-name= or to =(format "%s")=,
the escape character is removed, so when it comes to displaying those symbols to
users, it shouldn't matter much.
Note, though, that the keys in CSL-JSON don't seem to contain any spaces or
other weird characters. There are just lower case a-z and dash, that's all.
>> This works for the Elisp library =json.el=, but Emacs 27 can be compiled with
>> native JSON support, which, however, doesn't provide this option,
>> unfortunately.
>
> I see. In this case it might make sense to propose string keys as a feature
> for
> json.c. The key is a string anyway at some point during parsing, so avoiding
> the
> conversion to symbol may actually be the best way to speed things up.
True. I'll ask on emacs-devel. Personally, I'd prefer strings, too, but I'm a
bit hesitant about doing the conversion myself, esp. given that in Ebib, all the
keys would need to be converted back before I can save a file.
>> That would be easy to support, but IMHO is better handled in
>> bibtex-completion:
>> just parse the buffer and then call =gethash= on the resulting hash table. Or
>> what use-case do you have in mind?
>
> One use case: bibtex-completion drops fields that aren’t needed early on to
> save
> memory and CPU cycles. (Some people work with truly enormous bibliographies,
> like crypto.bib with ~60K entries.) But this means that we sometimes have to
> read an individual entry again if we need more fields that were dropped
> earlier.
> In this case I’d like to be able to read just one entry without having to
> reparse the complete bibliography.
Makes sense. For .bib sources, this should be fairly easy to do. For .json, I
can't really say how easy it would be. It's not difficult to find the entry key
in the buffer, but from there you'd have to be able to find the start of the
entry in order to parse it. Currently, I don't know how to do that.
>>> - Functions for resolving strings and cross-references.
[...]
>> parsebib has a lower-level API and a higher-level API, and the latter does
>> essentially what you suggest here. I thought bibtex-completion was already
>> using it...
>
> Nope. I think the high-level API didn’t exist when I wrote my code in 2014.
No, it didn't. I seem to remember, though, that you gave me the idea for the
higher-level API, which is probably why I assumed you were using it.
So that part of =parsebib= hasn't been tested much... (Ebib doesn't use it,
either). If you do decide to start using it, please test it and report any
issues you find. And let me know if I can help with testing.
--
Joost Kremers
Life has its moments
Re: CSL-JSON support for =parsebib=
Hi Titus,
On Fri, May 07 2021, Titus von der Malsburg wrote:
> I’m the maintainer of bibtex-completion, helm-bibtex, and ivy-bibtex. My name
> is
> actually Titus, not Theo ;)
:$ (I do apologise!)
> Regarding the symbols vs. string issue: I don’t have a strong opinion, but
> personally tend to favor a conservative solution that avoids braking changes.
> First, it’s difficult to predict how switching to symbols is going to affect
> other software including custom code written by users. Second, JSON key names
> can contain spaces and other weird stuff.
Apparently, =json-parse-{buffer|string}= then gives you a symbol with a space
in it...
> So strings are perhaps a more natural
> choice anyway. (It appears that you can actually configure the JSON parser to
> use strings instead of symbols. See variable `json-key-type`.)
This works for the Elisp library =json.el=, but Emacs 27 can be compiled with
native JSON support, which, however, doesn't provide this option, unfortunately.
> Finally,
> it’s not necessarily clear that avoiding the conversion to strings saves
> sufficiently many CPU cycles to justify the effort.
I can simply try it out. Shouldn't be difficult to code up.
> Regarding support for CSL-JSON: bibtex-completion is currently very
> BibTeX-oriented and uses fairly low-level parsing functions from parsebib. We
> could add similar support for CSL-JSON
I'm afraid that won't be possible, because the CLS-JSON support in parsebib
isn't low-level. ;-) There's basically just a single function that gives you all
the entries in the buffer and that's it.
> Some rough ideas for such an API (just for illustration):
> - A function that returns all entries in a .bib or CSL-JSON file.
Those already exist... ;-) For JSON, that's basically the only option, because
the actual parsing isn't handled by parsebib. For BibTeX, such a function has
existed for some time now.
> - A function that returns an entry with a specific key (or multiple entries).
That would be easy to support, but IMHO is better handled in bibtex-completion:
just parse the buffer and then call =gethash= on the resulting hash table. Or
what use-case do you have in mind?
> - Functions for resolving strings and cross-references.
This, too, is something that parsebib already does.
parsebib has a lower-level API and a higher-level API, and the latter does
essentially what you suggest here. I thought bibtex-completion was already
using it...
--
Joost Kremers
Life has its moments
CSL-JSON support for =parsebib=
Hi, [Cc-ing Theo von der Malsburg] Now that Org is getting support for Citeproc, it could be useful to add support for the CSL-JSON format for bibliographic data to Emacs. Therefore, after a friendly request from Denis Maier, I have added support for this format to the =parsebib= library. Since =parsebib= is used by =bibtex-completions=, which in turn is used by =bibtex-actions=, =helm-bibtex=, =ivy-bibtex=, =org-ref= and =org-roam-bibtex=, this is a first step in making bibliographic data in =.json= format directly available to Org users, without the need of any BibTeX conversion. [Boy, look at me doing the marketing speak! :D ] Anyway, this really is the first step. =bibtex-completion= will need to be modified in order to make use of the new functionality, and the same may be true of the packages based on it. At this point, the new code isn't merged into =master= yet. It is available in the =wip/csl= branch of =parsebib='s Github repo: https://github.com/joostkremers/parsebib/tree/wip/csl The README has most of the details. I appreciate any and all comments, suggestions and tips. For those maintaining packages based on =parsebib=, I have at least one question: currently, =parsebib= returns a BibTeX entry in the form of an alist of =( . )= pairs, where both == and == are strings. A CSL-JSON entry is returned as an alist, but the == names are symbols, not strings. It would be extremely impractical to return the JSON data with strings as field names, because the JSON parsing libraries in Emacs return symbols, so converting them would take time. Plus, those libraries also expect symbols when serialising Elisp data to JSON. (Which I intend to make use of in Ebib later on.) It would be easier to modify the BibTeX output to return field names as symbols. I originally chose strings, because that's what =bibtex.el= uses, making it a little easier to integrate with it. So the question: would it be helpful to make this change to the BibTeX data, so that the data from both sources uses the same format? Or would it be better to keep it as it is, even if that means that BibTeX data and JSON data isn't compatible? TIA Joost -- Joost Kremers Life has its moments
Re: Question about citation processors [wip-cite branch]
On Tue, May 04 2021, Denis Maier wrote: > Well, IIRC, in author-year styles \autocite is equivalent to \parencite. I > think, what the manual talks about is not that \autocite wouldn't be > appropriate > for author-year styles, but rather that relying /solely/ on \autocite doesn't > give authors the flexibility they might want in these styles, Yes, I did a quick test and you're right. > So, I think \autocite is the better choice. Yes. -- Joost Kremers Life has its moments
Re: Question about citation processors [wip-cite branch]
Hi Nicolas, On Tue, May 04 2021, Nicolas Goaziou wrote: > If you think my assumption is incorrect, please let me know what kind of > hook would be required. No, I don't think there's anything Org should provide. I just wanted to be sure I hadn't missed anything. >> - =:active= just means "font-lock", right? > > Yes, with the emphasis that more than faces could be provided (e.g., > help-echo, specific keymap, …). Ah, that's good to know. I hadn't realised that. >> - What kind of data structure do the =:follow= and =:activate= functions >> take? >> Should I just look at =oc-basic.el= or is this written down >> somewhere? > > Processors must be registered using `org-cite-register-processor' > function from "oc.el". See its docstring for details. All arguments are > detailed. The docstring talks about a "citation object", and the "citation or citation reference object at point". Do I assume correctly that these are structures as returned by =org-element-parse-buffer=? > At some point, we will need to write some documentation in the manual, > too... For the moment, I can follow the lead in =oc-basic.el= and do what it does. > "oc.el" provides a number of hopefully useful tools. Among them, > `org-cite-list-bibliography-files' function returns what you're asking > for. Global variable and keywords are cumulative. Great, thanks! > HTH! Yes, this was certainly very helpful. Thank you for your answer and thank you for all the hard work you've put in. The same goes for everyone else who put time and effort into making org-cite happen, of course. :-) -- Joost Kremers Life has its moments
Re: Question about citation processors [wip-cite branch]
On Tue, May 04 2021, Bruce D'Arcus wrote: > On Tue, May 4, 2021 at 10:47 AM Joost Kremers > wrote: > >> I can add some comments regarding biblatex: >> >> - default: \parencite[1] > > WDYT of \autocite for default? > > It's conceptually the same as the CSL default. If that is the case then it's probably the better choice. The biblatex manual states that \autocite requires that the citation style defines a command for it and that it is not appropriate for author-year style citations. I assume that's something for the user to be aware of when using such citations? -- Joost Kremers Life has its moments
Re: Question about citation processors [wip-cite branch]
On Tue, May 04 2021, Bruce D'Arcus wrote:
> One other little thing:
>
> On Tue, May 4, 2021 at 10:47 AM Joost Kremers
> wrote:
>
>> - locators: \notecite[3]
>
> Are you sure about this?
Well, no, I hadn't tried it... I did mention there were variants, though. ;-)
> Here's the use case:
>
> https://github.com/jgm/pandoc/issues/7205
In order to get:
```
According to Jones (1998) , “students often had difficulty using APA
style, especially when it was their first time” (p. 199).
```
i.e., with parentheses around the locator, you need to use \pnotecite:
```
According to \textcite[]{Jones1998} , ``students often had difficulty using APA
style, especially when it was their first time'' \pnotecite[][199]{Jones1998}.
```
\notecite gives the locator without parentheses.
--
Joost Kremers
Life has its moments
Re: Question about citation processors [wip-cite branch]
On Tue, May 04 2021, Bruce D'Arcus wrote: > On Tue, May 4, 2021 at 9:27 AM Joost Kremers wrote: > >> - A user should be able to insert citations into an Org document. IIUC >> nothing >> in org-cite provides any functionality for this, right? Is there a default >> list of styles a user would expect to be supported, or does this depend >> solely >> on the bibliography style one uses? > > I'll just comment on this Joost. Thanks. :-) > Correct on your first question. ACK > As for your second, that's what the activity today is about. TBD, but > it seems there's some good ideas on that. > > I tried to put this together into this wiki page, because doing it on > an email list is hard. > > https://github.com/bdarcus/bibtex-actions/wiki/Org-cite I can add some comments regarding biblatex: - default: \parencite[1] - text: \textcite - author: \citeauthor[2] - title: \citetitle[2] - year: \citeyear[2] - locators: \notecite[3] - nocite: \nocite Biblatex of course has a wealth of citation commands, most with variants of different kinds. Not sure if that's relevant right now. HTH Joost Footnotes: [1] Note that biblatex also has \cite, which produces a citation without parentheses. But the natbib column has \citep here, so \parencite seems appropriate. [2] The biblatex manual states that this does not do "citation tracking", though what this implies is not clear to me. [3] There are variants \pnotecite and \fnotecite for parenthetical and footnote citations, respectively. -- Joost Kremers Life has its moments
Question about citation processors [wip-cite branch]
Hi list, As the maintainer of Ebib, I have of course been following the threads on citation support for Org with some interest. I have not been able to follow every detail, however, in part probably due to my limited experience with CSL and citeproc. (I use biblatex myself.) Now I find myself with some specific questions that I cannot find an answer to. (Possibly because I'm just daft enough to overlook them in the e-mails Nicolas sent, but in that case feel free to point this out.) So, on the assumption that there are Org users out there that may want to use Ebib to manage their citations, what would Ebib need to do in order to be a good citizen? - A user should be able to insert citations into an Org document. IIUC nothing in org-cite provides any functionality for this, right? Is there a default list of styles a user would expect to be supported, or does this depend solely on the bibliography style one uses? - =:active= just means "font-lock", right? - Since I don't plan on writing an exporter, I assume that it is possible to mix and match processors? Say, have one for the =:follow= property, another for =:activate= and a third one for =:export-*=? - What kind of data structure do the =:follow= and =:activate= functions take? Should I just look at =oc-basic.el= or is this written down somewhere? - Is there a function or buffer-local variable that gives me a list of all the bibliography files of a buffer? Related to that: if a user has set =org-cite-global-bibliography= and also provides a =#+bibliography= keyword, are both sources used, or only the keyword? Thanks for any and all comments! -- Joost Kremers Life has its moments
Re: Notes about citations in Org (part 3)
On Tue, May 04 2021, Eric S Fraga wrote: > Question for the longer term: for LaTeX export, I will be wanting to > have the [cite:] constructs export to BiBTeX code. Will this be > possible in due course? For other targets (ODT, HTML), what has been > done in this branch is fantastic but, for LaTeX, publishers will expect > BiBTeX. Pedantic nit-pick: they *should* be expecting and using biblatex. (But perhaps that is what you meant already. :-) ) -- Joost Kremers Life has its moments
Input methods [was: Re: About multilingual documents]
On Tue, May 04 2021, Eric S Fraga wrote: > So, on this note, without hopefully hijacking the thread, maybe somebody > can tell me: what is the "default" input method, i.e. the one I get when > I start Emacs and haven't changed input methods at all? I see no way to > get back to it once I have switched to a different one. It's not really an input method, more like the lack of one. You're probably using =set-input-method= to change input methods? Check out =toggle-input-method=. :-) -- Joost Kremers Life has its moments
Re: About multilingual documents
[Not directly related to the OP, but might be useful to know.] On Mon, May 03 2021, Aleksandar Dimitrov wrote: > this sounds very interesting to me, as I, too, mostly write in Org > and, sometimes write documents in multiple languages, usually with > different varieties of either Latin or Cyrillic. [...] > Apart from the export, one of my biggest gripes is > flyspell. Specifically, the fact that you have to choose one language to > spell check the entire document with. That is insufficient in my case. flyspell is basically just ispell, and ispell can be configured with different backends. One possible backend is hunspell, which allows you to set multiple dictionaries. So if you regularly use different languages in a buffer, you should give hunspell a try. [...] > The drawback, and the clear disadvantage compared to your method is that > this works great only when the languages are separated by paragraph > breaks. If that is the case, you could also check out the =guess-language= package: <https://github.com/tmalsburg/guess-language.el>. It tries to detect the language of the current paragraph and sets the ispell (and hence flyspell) dictionary accordingly. I use it because I write in three different languages, but usually don't mix them in one buffer. -- Joost Kremers Life has its moments
Re: (Not so) Short note about citations in Org
On Mon, Apr 26 2021, Denis Maier wrote: > No, I was not talking about having multiple input files, but about having > multiple bibliographies in the output doc. > Perhaps each filtered in some way: > > #+print_bibliography: [style] [filter1] > #+print_bibliography: [style] [filter2] > > Obviously, filter1 and filter2 must be defined somewhere. The use case would > be > something along these lines: > - One bibliography with all the works by author X, a second bibliography with > everything else. > - One bibliography with books, the other with webpages Another use case would be a book in which each chapter has its own bibliography. A quick synopsis of the biblatex way: https://texblog.org/2012/10/22/multiple-bibliographies-with-biblatex/ -- Joost Kremers Life has its moments
Re: org-cite: make 'suppress-author' a citation 'style'
On Mon, Apr 26 2021, Denis Maier wrote:
> [...] Interestingly, I
> couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020)
> ... argues". You'd probably have to resort to lower level commands such
> as \citeauthor in combination with other commands.
> \citeauthor{doe} \parencites*[34]{doe}{smith}
Actually, that won't print the author name of =smith=. AFAIK If you want to
suppress the author in the first citation but not in the second, you need to be
even more low-level:
\citeauthor{Chomsky1995} (\cite*[34]{Chomsky1995}, \cite{Kayne1994})
At least that's the only way I've been able to find.
IOW it seems that in biblatex, suppress-author (obtained by the asterisk
following the command) is a property of the citation command, even if it
includes multiple citations. OTOH there are real cases (I have written
references such as the example here myself) where you want it to be a property
of the individual citation.
The thing about biblatex is that it offers low-level commands that allow you to
create unusual citations (my default LaTeX header contains three definitions of
citation commands that biblatex doesn't provide but which I use quite a lot). So
I would argue that it's better to keep the syntax =-@key=, just to keep the
system flexible in case the need arises.
--
Joost Kremers
Life has its moments
Re: Using backticks for the inline code delimeter?
On Sun, Apr 04 2021, Nicolas Goaziou wrote: > Joost Kremers writes: > >> On Sat, Apr 03 2021, Tom Gillespie wrote: >>> Is there any reason why folks couldn't just customize >>> org-emphasis-alist using a file local variable? > > [...] > >> If all exporters worked off an internal representation such as what is >> returned by `org-element-parse-buffer`, it should be easier to modify the >> front-end syntax. > > I think they do. So if I were so inclined, I could write a parser for Markdown that produces this internal format and get all the export targets that Org has? (Not that I'm so inclined... Just wondering. ;-) ) > Anyway, one of the goals of Org is to provide a universal document > format. It is not there yet, but allowing local modifications of the > syntax certainly goes against that goal. I tend to agree that allowing local modifications of Org's syntax is pretty much pointless, but then why is `org-emphasis-alist` a user option? I originally thought its purpose was to customise Org's syntax, until I found that the exporters didn't play ball. ;-) -- Joost Kremers Life has its moments
Re: Using backticks for the inline code delimeter?
On Sat, Apr 03 2021, Tom Gillespie wrote:
> Is there any reason why folks couldn't just customize
> org-emphasis-alist using a file local variable? Just add ("`" org-code
> verbatim) and see what happens. Knowing a bit about the codebase this
> will probably lead to trouble during export because the backends are
> likely unaware,
Yes, I tried this at one time because /.../ is used in linguistics to denote
phonological representations. So I removed the entry for `/` in
`org-emphasis-alist` and replaced it with something else. It worked up until the
point where you start exporting.
If all exporters worked off an internal representation such as what is
returned by `org-element-parse-buffer`, it should be easier to modify the
front-end syntax.
--
Joost Kremers
Life has its moments
Re: Using backticks for the inline code delimeter?
On Fri, Apr 02 2021, Tim Cross wrote: > Getting backticks to font-lock correctly is relatively easy. Getting the > exporters to understand the new syntax is more of a challenge Don't the exporters work off of some intermediate representation, like Pandoc does? I kinda thought that was what `org-element.el` was all about... And of course I meant to type ~org-element.el~ there... :D -- Joost Kremers Life has its moments
Re: About exporting
On Tue, Mar 30 2021, Eric S Fraga wrote: > On Tuesday, 30 Mar 2021 at 10:13, Detlef Steuer wrote: >> Btw. I had do deliver rtf recently. Is there any documented way to generate >> rtf from org? > > Two routes that I know of: > 1. org -> LaTeX -> rtf using latex2rtf > 2. org -> odt -> rtf by saving as that format in LibreOffice. > Pandoc may have similar, of course. Yes, Pandoc can write rtf files. Since it can also read Org files, you may be able to use it to go from Org to rtf directly. -- Joost Kremers Life has its moments
Re: How to jump from one spelling mistake to the next?
On Sat, Mar 20 2021, Dr. Arne Babenhauserheide wrote: > Kyle Meyer writes: > >> Sharon Kimble writes: >> >>> When I'm writing in org-mode I very often make spelling mistakes which I >>> can go back to later to correct. So how can I jump from one mistake to >>> the next please? >> >> If you have Flyspell mode enabled in the buffer, >> flyspell-goto-next-error (bound to `C-,' by default) will jump to the >> next marked word, cycling around once you've reached the last marked >> word in the buffer. Also, if you have flyspell-mode enabled, `C-;` is bound to `flyspell-auto-correct-previous-word`. It'll correct the last misspelled word preceding point (though there may be correctly spelled words between point and the misspelled word). Type `C-;` multiple times to cycle through different correction suggestions. Because you don't need to move back to the misspelled word to correct it, you can correct words while you type without interrupting the flow too much. YMMV, of course. -- Joost Kremers Life has its moments
Re: org-capture: question about function to create template
Hi Ihor & No Wayman, Thanks for your replies. On Tue, Mar 16 2021, Ihor Radchenko wrote: > Joost Kremers writes: > >> ... I was wondering if there's any >> way for this function to access the state of the ongoing capture process. >> Specifically, it would be useful for me if the function can find out the key >> of >> the template that the user selected. > > See org-capture-plist. Yes, I thought that might be it, but I wasn't sure. On Mon, Mar 15 2021, No Wayman wrote: >> From: Joost Kremers >> Specifically, it would be useful for me if the function can find out the key >> of the template that the user selected. > > This is stored on the above plist as :key. > > There are some corner cases to consider if you have overlapping > capture processes. > You'll want to look into `org-capture-get' and > `org-capture-current-plist' as well. Thanks for the pointers. I'll dive in a little and see what's best for my use case. -- Joost Kremers Life has its moments
org-capture: question about function to create template
Hi list, I've been looking at the =org-capture= mechanism a bit more closely recently and noticed that in =org-capture-templates=, the template can also be a function. This looks like a potentially useful feature, but I was wondering if there's any way for this function to access the state of the ongoing capture process. Specifically, it would be useful for me if the function can find out the key of the template that the user selected. Of course I could have a different function for each template that I want to create dynamically, or use a lambda that calls my function with an appropriate argument, but that wouldn't be as useful to me. TIA Joost -- Joost Kremers Life has its moments
Font lock in inner blocks [was: Re: Differentiate source blocks in export?]
On Wed, Nov 25 2020, Eric S Fraga wrote: > On Wednesday, 25 Nov 2020 at 09:37, Joost Kremers wrote: >> I like this solution for the "Org-ness" of the syntax, and yes, =C-c >> '= works, but font lock is gone... > > Yes, font lock is gone unfortunately but I am not sure why that > is. Something for somebody who understands the syntax highlighting code > to investigate? I guess font lock is based on the outer block, which in this case doesn't correspond to any major mode, so there is no font lock. Or at least no major-mode-based font lock. Org markup such as for =code= *is* font locked. One could argue that this isn't entirely consistent with the fact that =org-edit-special= *does* recognise the inner code block. It certainly would be nice if font lock did, as well. -- Joost Kremers Life has its moments
Re: ob-python: import local package into a session
On Tue, Nov 24 2020, Jack Kamm wrote: > If you install the package using either "python setup.py develop", or > "pip install -e", then Python will install your code via symlinks > instead of copying, so then you don't have to worry about reinstalling > every time you make an edit. Hey, that's good to know, thanks. > To switch between venv's in emacs, I use pyvenv: > https://github.com/jorgenschaefer/pyvenv Yes, that's what I use, as well. -- Joost Kremers Life has its moments
Re: Differentiate source blocks in export?
On Wed, Nov 25 2020, Eric S Fraga wrote: > On Tuesday, 24 Nov 2020 at 23:02, Joost Kremers wrote: >> That, unfortunately, seems to make it impossible to edit the source block as >> Octave (or in my case Python) code. Pressing =C-c '= in this source block >> gives >> me an Org buffer. > > Take away the begin...end org block itself which I only put to protect > the org code for the email. You should then be able to edit the src > block with no problem. Oh, sorry, I didn't realise that... > #+begin_myclass > #+begin_src octave > y = 3 * x + 5 > #+end_src > #+end_myclass > > If I have point within the octave src block, C-c ' works fine for me. I like this solution for the "Org-ness" of the syntax, and yes, =C-c '= works, but font lock is gone... -- Joost Kremers Life has its moments
Re: Differentiate source blocks in export?
On Tue, Nov 24 2020, Eric S Fraga wrote: > On Tuesday, 24 Nov 2020 at 17:22, Diego Zamboni wrote: >> And even (a bit) shorter: >> >> #+html: > > Or, if you want a more org-like feel to your special constructs, and > something that would in principle work to other export engines: > > #+begin_src org > ,#+begin_myclass > ,#+begin_src octave > y = 3 * x + 5 > ,#+end_src > ,#+end_myclass > #+end_src > > using special blocks which translate to divs on HTML export. That, unfortunately, seems to make it impossible to edit the source block as Octave (or in my case Python) code. Pressing =C-c '= in this source block gives me an Org buffer. -- Joost Kremers Life has its moments
Re: Differentiate source blocks in export?
On Tue, Nov 24 2020, Diego Zamboni wrote: > And even (a bit) shorter: > > #+html: > #+BEGIN_SRC python > print(5) > #+END_SRC > #+html: Thanks everyone for your suggestions. I tried this one and it works great. =myclass= of course ends up containing the =src= class, but as I just found out, that's not a problem. -- Joost Kremers Life has its moments
Re: ob-python: import local package into a session
On Tue, Nov 24 2020, Maxim Nikulin wrote: > 2. It seems that *recommended* and more flexible way is per-project > (per-version) virtual environments: venv in python3, similar thing were > called virtualenv in python2: > https://docs.python.org/3/tutorial/venv.html Maybe there is a convenient > way to choose and switch venv's directly from emacs. In simple cases > venv could be activated before starting emacs. Yes, I'm using virtual environments. Took me a while to get that figured out, though. Python-the-language is nice enough, but Python-the-ecosystem is quite a different thing... (Who said there should only be one way to do something?) I haven't really considered the option to install the utility functions as a package in the virtual environment, because I expect to change and develop those functions together with the rest of the project. If it were a separate package, I'd need to reinstall it every time I make changes to it, which will probably happen often. -- Joost Kremers Life has its moments
Differentiate source blocks in export?
Hi all, I was wondering if there's a way to distinguish between different kind of source code blocks when exporting to HTML. Specifically, I would like a way to mark certain code blocks in my Org file so that those code blocks get a specific class in the HTML export. I can then style them with some CSS to make them stand out visually. I know I can use special blocks to get divs with a custom class, but I don't want to lose all the benefits of code blocks... I tried Google and the Org manual but I haven't been able to find anything on this. TIA -- Joost Kremers Life has its moments
Re: ob-python: import local package into a session
Hi Jack, On Mon, Nov 23 2020, Jack Kamm wrote: > This shouldn't be ob-python or even Emacs specific. You can test whether > things work by typing "python" in the terminal and attempting to import > your module. It all seems to depend on the exact directories, though, and other than modifying =sys.path= there doesn't seem to be a way to make Org, Python and me happy at the same time. :-) I wanted to create a few small, related projects that would share the utility functions, so I thought I'd put them all in separate subpackages of a single package. That works with `M-x run-python` and with an LSP server, but when I then put an Org file in its own subdirectory inside the package, I couldn't import the utils subpackage. I guess putting a =:dir= header arg might resolve that, but the Org manual says that =:dir= should not be used with =:exports both=, which I was also using. Anyway, thanks to you and to John. I think I have a better idea now how it all works and what my options are. > By the way, are you using IPython or vanilla Python? I recently > encountered an issue trying to import modules through a symlink in > IPython, whereas it worked perfectly fine in a vanilla Python session. I'm using IPython in `M-x run-python`, but vanilla Python for Org. There are no symlinks involved, so I guess it shouldn't matter. -- Joost Kremers Life has its moments
ob-python: import local package into a session
Hi all, If I have an Org file with Python source blocks, I can run them in a session with the `:session` header arg. That way, I can include packages installed in `site-packages` and have them available in all code blocks. But is there a way to import my own packages into a session? In particular, packages I haven't installed system-wide? What I'm trying to do is to import a Python file with a bunch of utility functions into the ob-python session. I thought this might be possible if I'd structure my code as a regular Python package, because that works if I want to import my utility functions into another Python file. But it doesn't seem to work for the ob-python session. Is there a way to achieve this? I don't *have* to structure my utility functions as a Python package, so if there's another way of doing this, I'd be interested as well. TIA Joost -- Joost Kremers Life has its moments
Re: Use-case: simple nodes and todo-list
Hi, On Fri, Oct 09 2020, c.bu...@posteo.jp wrote: 1. Simple notes with keywords and endless time to life I have notes (most of them as post-its on the wall and monitor in my office) with information's I am not able or willing to remember. But I need this information's every few days. e.g. numbers for bank-account, projects, persons I find this information's by place (post-it glued to a specific place in my office). When they are digitized I would use keywords or in-text search. e.g. searching for the project name "my project" to find its number. Yes, Org can definitely do this, though in this particular case, I'm not sure Org really has any advantage over using just plain text files or say markdown files. (The advantage of Org would be in the integration that would be possible with other parts of your setup.) I personally have something similar: a bunch of files in which I keep notes of things I may need in the future. I keep them in Org format and I search them with Deft: <https://jblevins.org/projects/deft/>. (Though I do not follow the advice on that page of using Melpa Stable. I just use the Melpa version.) Of course, searching them can also be done with grep (or one of its alternatives, ripgrep, ag, etc.) and an Emacs frontend (ivy, helm, what have you). 2.ToDo List without time information's Yes, you can create todo-lists without time information. You can attach a deadline to a task, but you don't have to. You can also create multiple TODO-states (e.g., TODO, INPROGRESS, SUSPENDED, DONE, etc.) and set different priorities. -- Joost Kremers Life has its moments
Re: Anyone doing any fancy customizations of source blocks?
On Fri, Jun 19 2020, Norman Tovey-Walsh wrote: What’s the trick to get the background color to extend across the entire line? In Emacs 27, add an `:extend t` property to the face. In Emacs 26 and earlier, IIRC, you need to make sure that the newline at the end of the line is also fontified. (That may actually be necessary in Emacs 27 as well, in addition to the `:extend` property...) -- Joost Kremers Life has its moments
Re: Replace Org's C-TAB with C-M-TAB - objection?
On Sun, May 24 2020, stardiviner wrote: Bastien writes: C-TAB in Org is bound to `org-force-cycle-archived' to allow to cycle through archived subtrees. In the Emacs tab-bar mode, it is now bound to `tab-next', which needs to work globally. So Org's binding and tab-bar's one are in conflict, as reported here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325 I suggest binding `org-force-cycle-archived' to C-M-TAB: any objection? Thanks, I object this change. Emacs tab-bar is not enabled by default. When conflict, user can customize keybinding. I don't think it's very necessary to change. I would support the change, since both Org mode and tab-bar-mode are part of core Emacs and I doubt it'll be clear to new users coming to Emacs why these conflicting key bindings exist. Instead, they'll be annoyed that they cannot C-TAB out of the Org buffer and their impression of Emacs (not just Org mode or tab-bar-mode) will suffer. Ever more so because it's probably not immediately obvious to new users how C-TAB is different from just TAB: they both open the subtree at point. I've been using C-TAB for a long time to switch buffers (albeit not with tab-bar-mode), and it's always annoying when some mode usurps (from my perspective) this keybinding. Now, I'm familiar with Emacs and the relative independence and freedom that individual packages have, plus C-TAB is a personal keybinding, so I know this sort of thing may happen and I know how to resolve it. For a new user, that won't be so obvious. For them, this will simply look like a badly designed UI. So I think the general argument for habit-breaking UI changes applies: it creates a more consistent UI, which means it's easier on new users and more in line with what they expect. For existing users that want the old behaviour back, it's a simple configuration in their init.el. -- Joost Kremers Life has its moments
Re: wip-cite status question and feedback
On Sat, Apr 18 2020, Bruce D'Arcus wrote: The question, then: Is that what you're saying; we don't need suppress-author? I think I actually agree, though will add a topic that came up in the CSL implementation discussion for the author-in-text styles in the past few days. Here's a common way a citation might be integrated in a narrative text: Doe, by contrast, found negative results (2017). There are other constructions in with suppress-author is useful. For example, possessives: Doe's (2017) results... or Doe's (2017) ground braking paper... Such use is not uncommon in my field. Also, consider languages that require a case ending on the author name. And who knows what quirks other languages may have? So we have the author name in-text, than some text, then the year-only citation. The traditional way to do that in pandoc is to use the suppress-author command at the end. Doe, by contrast, found negative results [-@doe17]. So the piece of information I refer to above is that one of the CSL implementers (Frank Bennett) figured out how to make the above example an author-in-text variant, so that you don't need suppress-author, and the entire sentence is the citation. He did this by adding an optional "infix" variable to the citation. I doubt that would work in every case. Consider e.g., ; In her original (2017) study, Doe argues that... [...] This is arguably an edge case, but it does relate to the question of whether we need two (standard and author-in-text) or three commands (adding the suppress-author). I would definitely say that a way to suppress the author is necessary. In fact, I would argue that there should also be a way to cite just the author name, if only to make sure it's not misspelled or written inconsistently. (I'm a regular user of \citeauthor in BibLaTeX... ;-) But I admit that's less of a necessity. -- Joost Kremers Life has its moments
Fwd: Re: how to renumber footnotes?
Accidentally sent this message off-list. Trying again: On Fri, Apr 17 2020, Sharon Kimble wrote: org-footnote can't tell that footnote 1 ([fn:1]) at the beginning is in the right place when confronted with footnote 1 ([fn:1]) half-way through! No, obviously, so you'll have to renumber the footnotes in the second file before you merge the two files. Which is why I'm looking for some other solution, and I believe that it might be able to be achieved programmatically. Unfortunately my lisp skills are almost nil, hence my request for someone to help. I use the following function for renumbering stuff such as footnotes: #+begin_src emacs-lisp (defun jk-renumber-counters (start regexp) "Renumber counters. Renumbering starts at START. REGEXP describes the counters to be renumbered. The actual number must be enclosed in a group." (save-excursion (goto-char (point-min)) ;; because we incf the counter before using it, we need to adjust: (let ((counter (1- start)) (counters (make-hash-table :test 'equal)) fn) (while (re-search-forward regexp nil t) (setq fn (match-string 1)) (replace-match (or (gethash fn counters) (puthash fn (format "%s" (cl-incf counter)) counters)) nil nil nil 1) #+end_src In your case, you should be able to call this function with: M-: (jk-renumber-footnotes 355 "\\[fn:\\([0-9]+\\)\\]") RET Change «355» to the number you want to start the footnotes in the second file with. If you already merged the two files and don't want to separate them again, you could take out the line `(goto-char (point-min))`, put point at the position where you want to start renumbering footnotes and then call the function. But I'd play it safe and renumber the footnotes before merging the files. HTH -- Joost Kremers Life has its moments
Re: wip-cite status question and feedback
On Wed, Apr 15 2020, Richard Lawrence wrote: 62 combinations might sound like a lot, but if you want your cite commands to be mnemonic, you'll run out of options much more quickly. [...] So, I think the relevant question is: how many different basic citation types are needed *within a single document*, keeping in mind that these basic types will be formatted in different ways, depending on the choice of stylesheet? My experience is that it's typically just two (e.g. parenthetical and author-in-text), and my memory of the earlier conversation was that most people agreed. This is also borne out in the Pandoc syntax. As long as we have two basic types of citations, the finer points of formatting them can be achieved via other syntax, including the choice of stylesheet. Good points. I guess what this boils down to is whether Org wants to be like LaTeX, where simple things are doable and complicated things possible, or Pandoc, where simple things are simple indeed and complicated things essentially impossible. To clarify: in LaTeX (biblatex) you can mix footnote and in-text citations in a single document, Pandoc doesn't allow that. Pandoc's functionality is sufficient for a great majority of cases, but if you want or need to go beyond it, things get very difficult. My suggestion would still be not to hard-code a limit on possible citation commands. Org itself should probably just provide the basics, but users and add-on packages should be allowed to define more specific commands with readable names and there should be a well-defined interface for doing so (just like users and packages can add new link types, for example). Just my €0.02, of course. -- Joost Kremers Life has its moments
Re: wip-cite status question and feedback
On Mon, Apr 13 2020, Nicolas Goaziou wrote: denis.maier.li...@mailbox.org writes: What about allowing something more verbose? Perhaps "cite-intext:" or "cite:intext:"? [...] The simple syntax is great for most cases, but if you want to support some of those not so common biblatex commands, this might be better. Alphanumeric suffix provides 62 combinations, which should hopefully be enough for any citation back-end out there (I'm looking at you biblatex). It's not terribly readable, tho, as you point out. 62 combinations might sound like a lot, but if you want your cite commands to be mnemonic, you'll run out of options much more quickly. This is a conciseness versus readability problem, not a technical one, as long as we do not allow too much, from a parser point of view. I have no strong opinion on the topic. It would be more valuable to hear from actual citations users. What would they prefer? Not sure if my opinion counts, given that I mainly use LaTeX + biblatex to write my texts, but I would definitely allow more than one character. The more common commands (=citep=, =citet=) can still use a single character (and thus remain concise), but for less common commands, the ability to have more descriptive names is to be preferred. Imagine looking at a document you wrote a few years back and having to figure out what =citeQ= or =cite7= was meant for again, or finding that =citeF= was changed from =\fullcite= to =\footfullcite= because at some point the developers figured the latter would be used more often. I don't think it's necessary to use a dash (or any other character) in longer cite commands, though. =citeintext= isn't that much more difficult to read than =cite-intext=. (Biblatex does just fine without dashes, and there's always camelCase if you're so inclined.) 1. For the bibliography: #+bibliography: something.bib (Could this be a list containing multiple files?) Multiple keywords may be more appropriate, particularly if you need to spell out absolute file names. Org can provide a function listing all of them anyway. Yes, and please make it a public (one-dash) function. :-) 2. Placing the bibliography with: #+bibliography: here (Ideally, it would be possible to have this multiple times, perhaps with some filters, like printing only the works of a certain author, or with certain keywords, or so. But that's, of course something for later...) It is smart, but I'm not sure I like using the same keyword for two different things. OTOH, I don't have a better idea. As someone already suggested, using something like =#+printbibliography:= would work. And if that is too biblatex-like, you could instead opt for e.g. =#+list-of-references:=. (Output formats such as HTML or epub don't involve any printing anyway, so... ;-) -- Joost Kremers Life has its moments
Re: wip-cite status question and feedback
On Wed, Apr 08 2020, Bruce D'Arcus wrote: On Tue, Apr 7, 2020 at 5:13 PM Joost Kremers wrote: What would help, BTW, is if there's an easy way to find out what the bibliography file or files are that are associated with the current Org buffer. I guess the simplest and most flexible option would be to specify the bib file in the header? So if present use that; otherwise use the global bib file(s) specified in the init? That sounds like a good approach, yes. I don't know if Org would want to support having different bib files for different headers (i.e., be able to specify bib files in a :PROPERTIES: block). I believe that would be a bad idea, but who knows? For my purpose, the best thing would be to have a function that returns a list of bibliography files for the current buffer (or header, if you want to go that way). That way, I wouldn't have to come up with my own (bug-prone) way of figuring out what bib files a user expects a particular Org file to use. Since (presumably) such a function is going to be needed anyway for exporting, it would be a simple matter of making that function public (i.e., name it with one dash, not two). Thanks, -- Joost Kremers Life has its moments
Re: wip-cite status question and feedback
On Tue, Apr 07 2020, Bruce D'Arcus wrote: While I of course can't speak for John, I would hope and expect org ref to support the new syntax. I would hope and expect the same of other packages (like ebib) that use their own custom syntax. Ebib maintainer here. I would certainly include support in Ebib for any citation syntax that Org would adopt. What would help, BTW, is if there's an easy way to find out what the bibliography file or files are that are associated with the current Org buffer. -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
Hi Thomas, Thanks for that link. I really need to go over that document carefully. :-) Best, Joost On Tue, Mar 31 2020, Thomas S. Dye wrote: Aloha Joost, This link reflects my understanding of how properties accumulate, rather than overwrite: https://org-babel.readthedocs.io/en/latest/header-args/ hth, Tom -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Tue, Mar 31 2020, Berry, Charles via General discussions about Org-mode. wrote: `org-babel-view-src-block-info' (C-c C-v C-i with point in the src block below) reports I didn't know about that command, it's proven to be very helpful. Thanks! Joost -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Tue, Mar 31 2020, Ken Mankoff wrote: Yes I'm sure. From the link Thomas sent, Any property specification, unless it is postfixed with a `+`, will *reset* the value of that property to its current value. Yes, I realise now I was mistaken. For some reason, I though that `:results function` meant something, which it doesn't. C-c C-v (for me, Charles uses C-c C-v C-i) withitn a code block shows you the header args that are set for that block. Useful for debugging. Yes, that turned out to be very useful. Thanks. Joost -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Mon, Mar 30 2020, Ken Mankoff wrote: Header args overwrite. Change python to python+ to append header args. Are you sure? That's not documented anywhere I can find and it seems to be belied by the fact that if I put the headers in the order: ``` :PROPERTIES: :header-args:python: :tangle out1.py :header-args:python: :session py1 :results function :END: ``` everything works as I would expect (the code blocks are tangled to a file `out1.py` *and* they are evaluated in a python session `py1`), meaning that *all* header args are picked up. If I reverse the order and add a `+` sign, like so: ``` :PROPERTIES: :header-args:python+: :session py1 :results function :header-args:python+: :tangle out1.py :END: ``` the code does indeed get tangled, but the `:results` header arg isn't picked up, because the code block doesn't produce any output. For reference, this is my test file: ``` * Header 1 :PROPERTIES: :header-args:python+: :session py1 :results function :header-args:python+: :tangle out1.py :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: ``` -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Mon, Mar 30 2020, Joost Kremers wrote: Looks like a bug, right? And while I'm at it, this doesn't work as expected either: ``` #+PROPERTY: header-args :dir /home/joost/tmp/dlpy/ * Header 1 :PROPERTIES: :header-args:python: :tangle out1.py :header-args:python: :session py1 :results function :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src ``` I would expect that the file `out1.py` is created in the directory `/home/joost/tmp/dlpy`, but it's created in the same directory as the Org file. Are my expectations wrong or is this really a bug? -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. wrote: What we really need is an ECM rather than snippets of code. Yes, my apologies. It seems that having more than one `header-arg` line doesn't work properly. The following works: ``` * Header 1 :PROPERTIES: :header-args:python: :tangle out1.py :header-args:python: :session py1 :results function :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: : 3 ``` But if I swap the two `header-args` lines, tangling stops working and at the same time evaluating the code block doesn't give any output at all: ``` * Header 1 :PROPERTIES: :header-args:python: :session py1 :results function :header-args:python: :tangle out1.py :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: ``` With a `#+PROPERTY` line, I can't make it work at all: ``` #+PROPERTY: header-args:python :tangle out.py #+PROPERTY: header-args:python :results function * Header 1 #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: : 3 ``` Evaluating the code block works, but tangling doesn't. Reversing the order of the `#+PROPERTY` lines has no effect in this case. Looks like a bug, right? -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. wrote: On Mar 28, 2020, at 3:00 PM, Joost Kremers wrote: Is this expected behaviour? Am I doing something wrong? IIUC what you did, then yes and yes. This is the accepted idiom: #+PROPERTY: header-args :tangle yes I have tried: #+begin_example #+PROPERTY: header-args:python :tangle yes :dir /home/joost/tmp/dlpy #+end_example which AFAICT is the syntax shown in the info node you mentioned. I have also tried a file name instead of =yes=, both with and without quotes, but it doesn't work. What I really want is to have a property block with the =:tangle= arg under each top-level header, like so: #+begin_example :PROPERTIES: :header-args:python: :tangle out1.py :END: #+begin_example because I want the code below each top-level header to be tangled to a separate file. Again, AFAICT this is the syntax described in the info manual. Hmm, experimenting a bit more I find that if I leave out the =python= part, it works: #+begin_example :PROPERTIES: :header-args: :tangle out1.py :END: #+begin_example But the info manual gives this example: #+begin_example :PROPERTIES: :header-args:clojure::session *clojure-1* :END: #+begin_example The same is true for the #+PROPERTY block at the top of the file: leave out the =python=, it works. Isn't it possible to restrict tangling to source blocks of a particular language? (Or, more specifically what I want: to specify different tangling targets for different language? I wanted to have both python and bash code blocks under one header and have them tangled to different files...) Joost -- Joost Kremers Life has its moments
:tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
Hi list, I'm having trouble tangling an Org file. Basically, if I put a =:tangle= header argument in a =#+PROPERTY= line at the top of the file or in a =:PROPERTIES:= block under a header, it is not picked up and the code blocks to which (I think) it should apply are not tangled. Only when I put a =:tangle= argument at the top of the source block itself is the source block tangled. Is this expected behaviour? Am I doing something wrong? Emacs 26.3, Org 9.3.6. TIA Joost -- Joost Kremers Life has its moments
Re: Binding literal tab to C-Tab
On Fri, Mar 06 2020, Josh wrote: Hi all, I have a need to insert literal tab characters into my org-mode files frequently. I would like to bind a key to insert literal tabs (ASCII 9). I thought Control-TAB would be a good option. So I inserted the following lines into my .emacs file. It works when in normal emacs, but not in org-mode. Is there a way to get this to work in org-mode? If this is a bad key combination for org-mode, I'm ok switching to another key combo. Well, C-TAB is already bound in Org (to `org-force-cycle-archived`), but if you have no use for that command, you can of course rebind it. Since `global-set-key` creates global bindings, which are shadowed by local bindings, your binding has no effect in Org buffers. You need to bind C-TAB in `org-mode-map`: (define-key org-mode-map (kbd "C-") #'my-insert-tab-char) HTH -- Joost Kremers Life has its moments
Re: Survey: changing a few default settings for Org 9.4
On Wed, Feb 19 2020, Matthew Lundin wrote: - org-hide-emphasis-markers => t - org-hide-macro-markers => t [...] I have a few concerns about this. I believe that markup syntax, as a rule, should be visible. Most markdown editors do not hide markup by default. I realize that there are some exceptions in Org (e.g., links). But editing around the invisible boundaries of links can be in Org can be fussy (sometimes I have to do M-x visible-mode when editing near the edges of links). So I'd recommend not changing the default here, especially for emphasis markers. I was going to say the same thing. I set `org-hide-emphasis-markers` to t when I started out using Org, but at some point changed it to `nil` because editing at the beginning/end of words in emphasis markers was just too unpredictable. Same with links, BTW. What I'm wondering, though, is why Org doesn't make hidden markup visible when the cursor moves into it. `prettify-symbols-mode` can do this, and AUCTeX does it by default (IINM) in folded macros and preview snippets, so it's definitely doable. So my suggestion would be to keep it off unless/until such make-visible-at-point functionality is implemented. -- Joost Kremers Life has its moments
Re: Fixed vs variable pitch font [legibility 4/6]
On Tue, Feb 11 2020, Bastien wrote: Hi Texas, Texas Cyberthal writes: Why does there need to be an Org version of mixed-pitch-mode? It already works for Org. Yes, indeed. Besides, there's also `org-variable-pitch`, available on Melpa. -- Joost Kremers Life has its moments
Re: ob-scheme haunted source code block?
On Tue, Jan 21 2020, Neil Jerram wrote: OK, up to this point I am thinking: this is all quite curious, but presumably not really a big problem, as you surely don't need to use this rather strange workflow... Mind you, that's not my normal workflow. I normally just do =C-'= to edit a source block, =C-'= to finish the edit and return to the Org file, and then =C-c C-c= to evaluate the source block. The rest was just to try and find out where the problem lies. The weirdest thing about this is that the problem is persistent. I restarted Emacs and in my desperation even rebooted the computer, but to no avail. But this is indeed weird. Are you saying that you can reboot your computer, restart Emacs, open the relevant Org file, evaluate the source block (without any C-c ') and you still see the problem? Yes, that was what was happening. I suspected there might be some history being kept somewhere, that's why I grepped through my =~/.emacs.d/= directory. If so, I wonder if it's a real but intermittent problem in your code that was somehow made more likely by the original workflow, and now you're just being unlucky? The code was fairly straightforward (and not even mine... It came directly from SICP), so I doubt that had much to do with it. Anyway, I'm gonna have to put this down as a Heisenbug. The problem disappeared after a while and I can't reproduce it: Going through the steps that I thought triggered the bug doesn't recreate it. Weird. Thanks for reading and apologies for wasting everyone's time... Joost
ob-scheme haunted source code block?
Hi list, I've been learning some Scheme recently and decided to use Org mode and babel so I could document my progress, keep notes, etc. together with the code I write. I also installed the geiser package to work with Scheme source files directly. This all worked perfectly, until I made the (apparent) mistake of typing =C-c C-c= on an expression while editing a source code block. That is, I had pressed =C-c '= in an Org buffer on a source block and in the editing buffer that popped up, I hit =C-c C-c= (bound to =geiser-eval-definition=) on a particular function (well procedure...) definition. From that moment on, that particular procedure definition seems haunted. Whenever I evaluate a source block containing it from within an Org file, the associated REPL is doomed. It takes about 30 seconds for the evaluation to complete, during which time Emacs seems to hang (no CPU activity, just waiting). Any further interaction with the REPL from that point on, either from other source blocks in the same file (all source blocks in it use the same session) or in the REPL buffer directly, causes the same hang. I can `C-g` out of the hang, but this doesn't solve much because any further interaction causes the same hang. Putting the relevant procedure definition in a Scheme source file and evaluating that (within Emacs, through geiser) is unproblematic, so the code itself is not to blame. The weirdest thing about this is that the problem is persistent. I restarted Emacs and in my desperation even rebooted the computer, but to no avail. Does anyone have any idea what might be going on? I rgrepped through my =.emacs.d= directory to see if the relevant procedure name turns up anywhere but found nothing. I'm not really sure where to look beyond that. Versions: IELM> emacs-version "26.3" IELM> org-version "9.3.1" TIA Joost -- Joost Kremers Life has its moments
Re: very strange LaTeX error
On Fri, Dec 20, 2019, at 12:56 PM, Fraga, Eric wrote:
> #+begin_src latex
> \documentclass{scrartcl}
> \begin{document}
> % packages deleted, none of which is used anyway in the following
> \tableofcontents
>
> \section{some results}
> \label{sec:org4f5891c}
> \begin{table}[hbtp]
> \label{atable}
> \centering
> \begin{tabular}{lrrr}
> \hline
> x & z1 & z2 & g\\
> \hline
> [0.0005, 0.05, 0.5] & 9.0 & 0.05 & 0.0\\
> [0.000787451, 0.0575948, 0.5] & 11.0 & 0.05759476698672508 & 0.0\\
> \hline
> \end{tabular}
> \end{table}
> \end{document}
> #+end_src
>
> I get errors like this when compiling with pdflatex:
>
> #+begin_example
> ! Illegal unit of measure (pt inserted).
>
> ,
> l.18 [0.000787451, 0.0575948, 0.5]
> & 11.0 & 0.05759476698672508 & 0.0\\
> ! Missing = inserted for \ifdim.
>
> #+end_example
>
> What am I doing wrong?
You have `[...]` in the first cell of a table row that is not the first row.
Few people seem to realise that the double backslash `\\` in LaTeX is a macro
that can actually take an optional argument, a measure specifying the height of
the newline. So when a table row ends in `\\` (which is the normal case) and
the next row starts with an opening bracket, LaTeX assumes it is looking at an
optional argument and expects a measure, i.e., a number followed by one of the
supported units.
The solution I usually opt for is to enclose the brackets in an additional set
of braces: `{[...]}`. Whether Org export can and should automate that, I can't
say.
HTH
--
Joost Kremers
Life has its moments
[O] Get the text of a node
Hi all, I was wondering if there's a way to programmatically get the text of a node in an Org buffer. Basically, I have a buffer that looks something like this: #+BEGIN_SRC org * Top header ** Subheader :PROPERTIES: :Custom_ID: some_id :END: Text starts here, possibly with additional subheaders #+END_SRC What I would like to extract is the text below "Subheader", but without the :PROPERTIES: block. I've looked at the org-element library, but I haven't been able to figure out how to use it to extract just the plain text. I use the :Custom_ID: property to find the relevant subheading and I know I can use (org-back-to-heading) to get point to the Subheader containing the relevant :PROPERTIES: block. Obviously, I could then narrow the buffer to the subheader, use a text search to move point past the line containing :END: and then extract the text from there until (point-max). I'm just wondering if this may break in unexpected circumstances and whether there's a better way. TIA Joost -- Joost Kremers Life has its moments
Re: [O] lisp: scoping vars in repetitive defuns
On Wed, Sep 18 2019, Matt Price wrote: Is thre away to do that kind of destructuring bind -- which binds *everything* in the plist, without knowing the symbol names in advance? that would be really great. let-alist perhaps? -- Joost Kremers Life has its moments
Re: [O] Pandoc and Org-mode: list indention
On Mon, Aug 19 2019, Devin Prater wrote: I’ve taken it upon myself to clean all this up, and Org-mode does it all. The only problem is, when I convert from HTML to Org-mode using Pandoc, just doing: Pandoc -I lesson1.html -o lesson1.org <http://lesson1.org/> The lists are not made into indented ones, just a paragraph, which I manually have to indent, If you're using Pandoc to convert html to org, then you should probably ask on the Pandoc mailing list: https://pandoc.org/help.html HTH -- Joost Kremers Life has its moments
Re: [O] ivy-bibtex and orgmode inserts ebib: link
On Fri, Mar 22 2019, Eric S Fraga wrote: I am going down a rabbit hole here... Short question: how can I add a new link type to org? It used to be that we would use ~org-add-link-type~ but this is deprecated. Fine. The documentation points to ~org-link-set-parameters~ instead but this can only set the parameters for known links. Known links seem to be defined by a complex regex in ~org-link-types-re~. What is the replacement for ~org-add-link-type~ in the latest version of org, if any? Or do I have to both add to the regex and set link parameters separately? I'm pretty sure the regex is created automatically. I only needed to do this: (org-link-set-parameters "ebib" :follow #'org-ebib-open :store #'org-ebib-store-link) And then define the functions `org-ebib-open` and `org-ebib-store-link`. (Cf. <https://github.com/joostkremers/ebib/blob/master/org-ebib.el>). And yes, I apologize for the irony. ;-) -- Joost Kremers Life has its moments
Re: [O] New bug in org-agenda?
On Mon, Mar 04 2019, Roland Everaert wrote: I am facing the same issue with that version on emacs 25.2.2 (Ubuntu 18.04.2 LTS). When will it be available throu the Org Mode ELPA repo? I got the update this morning (finally...) -- Joost Kremers Life has its moments
Re: [O] Placement of \makeatletter with \beamer@frametextheight
On Thu, Nov 29 2018, Gustavo Barros wrote:
Louis,
a hunch, which might work.
It seems that, if you try to set the length in your preamble,
`\beamer@frametextheight` is not yet defined.
So, you might try the hook `\AtBeginDocument` to see if the
definition comes at
a better timing.
#+LATEX_HEADER:
\newlength\mytextheight\AtBeginDocument{\makeatletter\setlength\mytextheight{\beamer@frametextheight}\makeatother}
As I said, it's a hunch, for I haven't tested. But I think it
may be it.
Why not put the entire thing inside \AtBeginDocument?
To the OP: \paperheight does seem to be available in Beamer.
Couldn't you use that?
--
Joost Kremers
Life has its moments
Re: [O] malformed function
On Wed, Jul 11 2018, Joost Kremers wrote: On Mon, Jul 09 2018, hymie! wrote: Greetings. I know this is technically Technically and practically. ;-) Actually, I just now noticed your code is coming from worg, so that makes it not completely off-topic, I'd say. -- Joost Kremers Life has its moments
Re: [O] malformed function
On Mon, Jul 09 2018, hymie! wrote: Greetings. I know this is technically Technically and practically. ;-) an emacs problem and not an Orgmode problem, but maybe you guys will see the error that I can't find. A better place to ask would probably be the mailing list help-gnu-emacs, but: I have two different machines. One is a Linux machine running Orgmode 9.1.13 under Emacs 25.3.1 , and one is a Windows 10 machine running Orgmode 9.1.13 under Emacs 24.5.1 . Both have the same .emacs file as far as I can tell. Try diff or ediff to make sure. The Linux machine is getting this error: Warning (bytecomp): ‘(extract-window (line) (let ((start (get-text-property 1 (quote time-of-day) line)) (dur (get-text-property 1 (quote duration) line))) (cond ((and start dur) (cons start (org-time-from-minutes (+ dur (org-time-to-minutes start) (start start) (t nil’ is a malformed function That means that the entire s-expr (extract-window ... nil is being interpreted as a function, which is caused by the fact that it is the first element of the list ((extract-window ... nil) (note extra pair of parens). Since such an s-expr cannot be a function, you get an error. The fact that it is interpreted as a function indicates that the byte compiler doesn't know that `flet' is a macro, which in turn indicates that you haven't loaded the required library. Note that the documentation for `flet' says that it has been obsolete since Emacs 24.3 and that you should be using `cl-flet' instead (or `cl-letf', but that doesn't seem to be what you want). So best thing to do is to replace `flet' with `cl-flet' and then add `(require 'cl-lib)' somewhere at the top of your init file, and you should be good to go. Why you're only getting this error on one machine isn't entirely clear to me. It could be that something changed between Emacs 24 and 25 that causes this, it could be that you're loading a package on the Windows machine that loads cl or cl-lib and that you don't use on Emacs. HTH -- Joost Kremers Life has its moments
Re: [O] Org mode in combination with emacs follow-mode is terrible
On Wed, Jun 13 2018, Eric S Fraga wrote: On Wednesday, 13 Jun 2018 at 09:53, Gerald Wildgruber wrote: Switching to text-mode, with 5 windows and follow-mode still being active reduces lag significantly. So there must be an issue specifically with the combination of org-mode and follow-mode! I don't think there's an issue per se in the sense of bugs. Org does much more processing of the text than does text mode so if you have 60k worth of text to process each time you type something, it's probably not surprising that there is a lag. Actually, I would suspect it's more of a problem for follow-mode than org-mode, because follow-mode needs to keep the different windows in sync. For this, it adds a function to `post-command-hook', which means it's run after every key press. It's not inconceivable that `follow-mode' does something that is extra time-consuming in an Org buffer. To find out what that might be, you could try the Elisp profiler that comes with Emacs. See the section "Profiling" in the Elisp manual for details. Once you've found out which function(s) consume so much time, it might be possible to ask in here or on emacs-devel what exactly is causing the problem and whether there's a way around it. -- Joost Kremers Life has its moments
Re: [O] refile workflow -- move to same heading in different file?
On Fri, Aug 04 2017, Adam Porter wrote: "Raymond Zeitler" <zei...@yahoo.com> writes: Gosh, I was really hoping to be doing export to ODT or PDF by now! If you don't have time to fix it, you could export to HTML and convert it with Pandoc. Why convert to HTML first? Pandoc can read Org files pretty well. -- Joost Kremers Life has its moments
Re: [O] exporting markdown with tables
On Sat, Jun 03 2017, Peter Davis wrote: (FWIW, I tried using pandoc, but this just removed the table syntax altogether, so an entire table would just run together into a paragraph of gibberish.) You need a somewhat recent version of Pandoc for Org tables to be handled correctly (some distros still ship a very outdated version; latest is 1.19), and not all features are supported. So yeah, it's not necessarily the best option... -- Joost Kremers Life has its moments
Re: [O] Exporting PDF (new setup)
On Mon, May 01 2017, Peter Davis wrote: Nick Dokos <ndo...@gmail.com> writes: As a first step, switch to buffer *Org PDF LaTeX Output* and check for errors. Thanks, Nick. I found the same error I got running pdflatex in a command shell: ! LaTeX Error: File `wrapfig.sty' not found. I had installed basictex using Homebrew (one of several Mac package managers), but I think I'd be better off with TeXLive or MacTeX. I'm trying that now. IIUC BasicTeX is a subset of TeXLive. If it comes with the TeXLive Manager, it should be possible to add packages on a need-to-have basis, rather than installing all of TeXLive. Just do `tlmgr install wrapfig` in a shell, or (if installed) use the graphical TeXLive Manager. -- Joost Kremers Life has its moments
Re: [O] Exporting PDF (new setup)
On Mon, May 01 2017, Peter Davis wrote: I'm running Org 8.2.10 on a new MacBook with El Capitan as the OS. I can't seem to get PDF export working. I get these messages: Processing LaTeX file ./blahblahblah.tex... /bin/bash: pdflatex: command not found [3 times] org-latex-compile: PDF file ./blahblahblah.pdf wasn’t produced I did install basictex, and when I enter pdflatex on the command line, it works with no problems. Any clues why org export isn't finding the executable? This: https://github.com/purcell/exec-path-from-shell perhaps? -- Joost Kremers Life has its moments
Re: [O] Tables not converted to markdown format with markdown exporter
On Wed, Feb 08 2017, Sharon Kimble wrote: Roland Everaert <reveatw...@gmail.com> writes: Hi, Since a few weeks we use mattermost at work and I had recently to post a table to a team channel. I have created my table with org-mode, but when I export it to markdown format, the table is converted to html instead of markdown. Is there any reason to that, except the simple fact that table conversion is not implemented yet? As the markdown format is quite similar to the org-mode format regarding tables, I don't really see where could lie the difficulty. Example: - org format | column 1 | column 2 | column 3 | |---++-| | some text | some more text | event more text | | blah | 45 | fgf | - markdown format | column 1 | column 2 | column 3 | |---||-| | some text | some more text | event more text | | blah | 45 | fgf | This is obviously a very simple example, but usually, with mattermost, one doesn't post very complex messages. Regards. AFAIK markdown can't do tables. Any search of google won't show any ways of doing markdown-tables because its not available on markdown. There are certainly markdown variants that support tables, MultiMarkdown, PHP Markdown Extra and Pandoc markdown do, for example. Roland, if Org export won't work, you may want to take a look at Pandoc. It accepts Org files as input and can produce Markdown files as output, and it supports a number of different types of tables. The kinds of tables you're looking for are called pipe tables in Pandoc's documentation: http://pandoc.org/MANUAL.html#tables HTH -- Joost Kremers Life has its moments
Re: [O] Make wide tables more readable
On Thu, Dec 01 2016, John Kitchin wrote: I use: ;;;###autoload (defun tq-increase-text-size () "Increase text size." (interactive) (set-face-attribute 'default nil :height (truncate (* 1.1 (face-attribute 'default :height) ;;;###autoload (defun tq-decrease-text-size () "Decrease text size." (interactive) (set-face-attribute 'default nil :height (truncate (* 0.9 (face-attribute 'default :height) which I bind to C-- and C-= to shrink the font size down until it fits, then when I am done increase it. Why not use `text-scale-adjust`? This function has convenient bindings in the form `C-x C-+` to increase text size, `C-x C--` to decrease, and `C-x C-0` to reset to default size. Furthermore, once you press any of these, you can simply use `+`, `-` and `0` for increasing, decreasing and resetting until you've found your preferred text size. -- Joost Kremers Life has its moments
Re: [O] Track time on day-to-day basis
Hi Oliver,
On Fri, Nov 25 2016, ngre...@gmx.net wrote:
I do reports on a day-to-day basis using clocktables:
#+BEGIN: clocktable :maxlevel 4 :block 2016-11 :scope
("./Projekt01.org") :link t :step day :stepskip0
#+END:
Hope this helps.
Yes, that's exactly what I was looking for, thanks!
--
Joost Kremers
Life has its moments
Re: [O] How to find out in Elisp which .bib file is used for the current org buffer?
Hi, [Sorry for the late reply, I've been rather busy...] On Fri, Nov 18 2016, John Kitchin wrote: It depends on how you put citations in I guess. If you use org-ref, then there is a bibliography link or a latex_header with addbibresource. Otherwise, it is one of the files defined in org-ref-default-bibliography. I am not sure about the ox-bibtex setup. Ok, so there's no single method that will always work. Thanks for the info. It doesn't solve my problem but at least I know where to start looking. :-) -- Joost Kremers Life has its moments
[O] Track time on day-to-day basis
Hi all, I've come into the need to track the time I'm working on a particular project, which is great with Org, but I also need to report the tracked time on a day-to-day basis. This seems somewhat less straightforward to do. I realize I can generate a report limited to today by specifying `:block today`, but that only gives me the time clocked today. What do I do when I want to get a day-to-day overview of the time spent on a project? Do I need to maintain another table by hand, in which I copy the time calculated by `org-clock-report` at the end of each day? Or is there a better method? BTW, just looking at the LOGBOOK drawer doesn't work, because I may clock in and out of a project several times a day. Thanks for any hints and suggestions! -- Joost Kremers Life has its moments
[O] How to find out in Elisp which .bib file is used for the current org buffer?
Hi all, If you're writing a scientific document in Org, you'll normally have a .bib file that you use for your references. What I'd like to know is: is there a (robust) way to find out if a specific Org buffer has a .bib file associated with it? In a LaTeX file, you can usually find this out by looking for a \bibliography command or, if you use biblatex, for \addbibresource. I'm wondering what the canonical way is to specify this for an Org file. TIA Joost -- Joost Kremers Life has its moments
Re: [O] Obsolete org contrib package
[removed Grégoire Jadi <daim...@gmail.com> from the discussion.] On Thu, Nov 10 2016, Nicolas Goaziou wrote: Joost Kremers <joostkrem...@fastmail.fm> writes: Like I said, I'd be happy to take over maintainance. Just let me know how to go about making it available to org-contrib. (If there is a way to keep the file in the main Ebib repository, that would be my preference.) We don't need to make it available to Org contrib. Let me know when your version of org-ebib.el is available to Org users (e.g., through ELPA) and I'll remove it from contrib/ directory. In that case, I'll just make it part of the normal Ebib installation. No-one will be interested in org-ebib.el if they're not also using Ebib, so I believe this makes sense. Those that use Ebib but not Org will only have one small file added to their installation, which shouldn't be a problem. I won't `require' org-ebib.el in ebib.el, that will be up to the user. Unless there's some reason to make it available as a separate package? Thanks, Joost -- Joost Kremers Life has its moments
Re: [O] Obsolete org contrib package
On Tue, Nov 08 2016, Joost Kremers wrote: Hi, On Tue, Nov 08 2016, Nicolas Goaziou wrote: So you mean there is no equivalent to both (ebib-cur-entry-key) This one was what I was worried about, but on second thought, it should be possible to simply use: (ebib--get-key-at-point) and (ebib-db-get-field-value 'title key ebib-cur-db) That one's easier: (ebib-db-get-field-value "title" key ebib--cur-db) "org-ebib.el" is already compatible with Org 9.0. Ah, good, I didn't realise that. I'm Cc'ing the author. Ideally this library should be updated to new Ebib and moved to some ELPA. If Grégoire doesn't want to take care of it and no one volunteers to maintain that file, we can remove it. I was actually planning to add this functionality to Ebib itself. So if Grégoire isn't interested in it anymore, I could put it in the Ebib repo, or create a separate repo for it, either on Github or somewhere else, wherever you prefer. I received the following reply from Grégoire (which, although it was sent to the mailing list as well, apparently didn't show up there): == On 11/08/16 13:23, Nicolas Goaziou wrote: I'm Cc'ing the author. Ideally this library should be updated to new Ebib and moved to some ELPA. If Grégoire doesn't want to take care of it and no one volunteers to maintain that file, we can remove it. I don't use this package anymore. If anyone uses it, s/he take over it, otherwise we can just remove it from org-contrib. == Like I said, I'd be happy to take over maintainance. Just let me know how to go about making it available to org-contrib. (If there is a way to keep the file in the main Ebib repository, that would be my preference.) Best, Joost -- Joost Kremers Life has its moments
Re: [O] Obsolete org contrib package
Hi, On Tue, Nov 08 2016, Nicolas Goaziou wrote: So you mean there is no equivalent to both (ebib-cur-entry-key) This one was what I was worried about, but on second thought, it should be possible to simply use: (ebib--get-key-at-point) and (ebib-db-get-field-value 'title key ebib-cur-db) That one's easier: (ebib-db-get-field-value "title" key ebib--cur-db) "org-ebib.el" is already compatible with Org 9.0. Ah, good, I didn't realise that. I'm Cc'ing the author. Ideally this library should be updated to new Ebib and moved to some ELPA. If Grégoire doesn't want to take care of it and no one volunteers to maintain that file, we can remove it. I was actually planning to add this functionality to Ebib itself. So if Grégoire isn't interested in it anymore, I could put it in the Ebib repo, or create a separate repo for it, either on Github or somewhere else, wherever you prefer. -- Joost Kremers Life has its moments
[O] Obsolete org contrib package
Hi all, I just ran into org-ebib.el, a file that's part of org-contrib. I noticed that it uses functions from Ebib that were renamed pretty much exactly two years ago. (They're internal functions and thus got an extra dash.) This could in principle be fixed by changing the relevant function calls in org-ebib.el, but as it happens I'm about to push some changes to Ebib that will make it less straightorward to fix org-ebib.el. So perhaps it would be best to simply remove org-ebib.el from org-contrib? It doesn't seem to have been used by anyone the past two years and all it does is define a function to store an org link to an Ebib entry, which, IIUC, is done in a completely different way in Org 9.0. Joost -- Joost Kremers Life has its moments
Re: [O] Making DocBook xml books from org mode?
On Sun, Oct 02 2016, Peter Davis wrote: > Interesting. I just installed Pandoc on my Mac today with Homebrew, but > it claims to be 1.13.1. I'll try to find an update. Thanks. Check the "Installing" page on pandoc.org: there's a link to an OS X package on Pandoc's Github page: https://github.com/jgm/pandoc/releases/tag/1.17.2 Perhaps you can use that? -- Joost Kremers Life has its moments
Re: [O] Making DocBook xml books from org mode?
On Sun, Oct 02 2016, Peter Davis wrote: > When I try to export to docbook via pandoc (C-c C-e p d), I get > > Running pandoc with args: (-f org -t docbook5 -o > /Users/peterdavis/Dropbox/HMH/my_file.dbk --parse-raw --mathjax --standalone > /Users/peterdavis/Dropbox/HMH/my_file.tmp3362h9T.org) > Error occured. > pandoc: Unknown writer: docbook5 > > Any guesses? Is there something additional I need to install in pandoc? The `docbook5' writer was added to Pandoc fairly recently, in version 1.17.1, released in June of this year. There's also a `docbook' writer, which has been part of Pandoc much longer and which outputs to (I assume) DocBook v4. So I suspect you either need to upgrade your Pandoc or make sure ox-pandoc sets the output format to `docbook'. -- Joost Kremers Life has its moments
Re: [O] Making DocBook xml books from org mode?
On Thu, Sep 29 2016, Peter Davis wrote:
> I've started a new position in which I have to create and maintain a
> large set of documents in DocBook xml format. For new books, I'd really
> like to use org mode, since a) I'm already familiar with it, b) I love
> it, and c) I believe it does (or can be made to do) nearly everything I
> need.
>
> However, after Googling around the org-mode/DocBook space, I'm left with
> some questions.
>
> 1. I'm going to be creating books, as opposed to articles. My org-header
> looks like this:
>
> #+STARTUP: showeverything logdone
> #+OPTIONS: H:5 num:t \n:nil @:t ::t |:t ^:nil -:t f:t *:t <:t
> #+LaTeX_CLASS: koma-article
> #+LaTeX_HEADER: \usepackage{listings}
> #+LATEX_HEADER: \setlength{\parskip}{2ex plus 4pt minus 2pt}
> #+LATEX_HEADER: \setlength{\parindent}{0pt}
> #+LATEX_HEADER: \renewcommand{\baselinestretch}{1.0}
> #+LATEX_HEADER: \setlength{\topsep}{-10pt}
> #+LATEX_HEADER: \setlength{\partopsep}{0pt}
> #+LaTeX_HEADER: \usepackage{xcolor}
> #+LaTeX_HEADER: \lstset{
> #+LaTeX_HEADER: basicstyle=\ttfamily,
> #+LaTeX_HEADER: breaklines=true,
> #+LaTeX_HEADER:
> prebreak=\mbox{\ensuremath{\color{red}\hookleftarrow}},
> #+LaTeX_HEADER:
> postbreak=\raisebox{0ex}[0ex][0ex]{\ensuremath{\color{red}\hookrightarrow\space}},
> #+LaTeX_HEADER: columns=fullflexible,
> #+LaTeX_HEADER: keepspaces=true
> #+LaTeX_HEADER: }
> #+LaTeX_CLASS_OPTIONS:
> [book,letterpaper,times,12pt,listings-bw,microtype]
>
> but the PDFs I'm getting still look like articles. (I copied the
> above from some examples posted on this list a while ago. Thanks!)
Your LaTeX_CLASS is set to `koma-article', so that makes sense.
> 2. Are there any advantages to considering MarkDown or AsciiDoc as
> opposed to org markup? (Again, my familiarity with org is a strong
> incentive here, but I'm willing to consider other options.)
There is a (IMHO) excellent markdown-mode available on Melpa, and if you
use Pandoc[1] to convert your documents you have a lot of flexibility.
There's also `pandoc-mode' (of which I'm the author), a minor mode that
makes interacting with pandoc from within Emacs easier.
> 3. The direct route from org to DocBook xml seems to be missing. From
> what I gather, I can get there somehow via texi (but I don't even have
> that in org currently), or perhaps export to HTML and then convert that
> to db xml. Am I missing something? Is there some other route I should
> consider?
Pandoc can convert to Docbook, so that might be an option. Note that
Pandoc also converts *from* Org, (although it cannot handle all of Org's
capabilities), so depending on your needs, that might be a way to go
directly from Org to Docbook.
> 4. [LONGSHOT] Is there any way to /import/ docbook xml into org mode?
Pandoc also converts *from* Docbook, and can convert *to* Org, so again,
that might be of help.
Of course, whether Pandoc can be useful to you really depends on your
needs. Pandoc's internal document representation is based on Markdown,
and by its very nature Markdown is more limited in it capabilities than
Org. In essence, anything that cannot be handled by (Pandoc's version
of) Markdown, cannot be handled by Pandoc in other formats.
HTH
--
Joost Kremers
Life has its moments
Re: [O] Programmatically handling org files
On Mon, Sep 12 2016, John Kitchin wrote: >> I was wondering if there is some sort of (semi)official API for handling >> org files programmatically. That's to say, is there a documented way for >> non-org Emacs packages to manipulate (the contents of) org files? > > None that I know of. A non-elisp lib would have to be able to parse the > org-files. As you've already realised, I was asking about Elisp code that's not part of or intended to extend orgmode. >> Also, I was wondering if there's a way to hook into org-store-link. For >> a particular major mode, I would like to be able to define what kind of >> link is created when the user calls `org-store-link`. I looked at the >> source of `org-store-link` and it looks like the answer is no, but I >> thought I'd ask anyway. I could of course create the link myself and add >> it to `org-stored-links` but that feels rather hackish and I suspect >> will blow up in my face at some point in the future. > > You want to add a function to org-store-link-functions. The function > should check if it is responsible for creating this link (for example by > looking at the major mode). If not, it must exit and return nil. If yes, > it should return a non-nil value after a calling `org-store-link-props' > with a list of properties and values. Great, thanks! I looked at the source of `org-store-link', but this wasn't obvious to me. :-/ -- Joost Kremers Life has its moments
