[O] Org-drill doesn't work...
hi all, i'm trying to set up org-drill for learning some russian vocabulary, but i'm not very successful... i've created an org file that meets the requirements of a proper org-drill file. i have a bunch of entries that look like this: #+BEGIN_EXAMPLE ** Nomen :drill: :PROPERTIES: :DRILL_CARD_TYPE: twosided :ID: 9927d8c4-1692-4784-9afc-9e4a770a62c8 :END: *** Deutsch Herbst *** Russisch о́сень (f) *** Beispiele im *Herbst* о́сенью nächsten *Herbst* сле́дующей *о́сенью* letzten *Herbst* про́шлой о́сенью #+END_EXAMPLE of course, the ID was added by org-drill, not by me. after creating the file, the first run of org-drill seemed to be fine. i was prompted for a couple of items, maybe five or so, and after i had finished, emacs told me the results. however, trying to run org-drill the next day, i got the following message: #+BEGIN_EXAMPLE 0 items reviewed. Session duration 0:00:00. Recall of reviewed items: Excellent (5): 0% | Near miss (2):0% Good (4):0% | Failure (1): 0% Hard (3):0% | Abject failure (0): 0% You successfully recalled 0% of reviewed items (quality 2) 0/1 items still await review (0 failed, 0 overdue, 0 new, 0 young, 0 old). Tomorrow, 0 more items will become due for review. Session finished. Press a key to continue... #+END_EXAMPLE i wasn't prompted for any new items and the message tomorrow, 0 more items will become due for review worries me. also, running org-drill-again gives me the same message. i'm sure i'm doing something wrong, but i can't figure out what... would appriciate any help pointing me in the right direction. Org-mode version 7.8.02 (and org-drill included with it), GNU Emacs 23.3.1. TIA Joost btw, i noticed that some of the customize items in org-drill.el are incorrectly defined. for example, the :type declaration in org-drill-spaced-repetition-algorithm is: :type '(choice (const 'sm2) (const 'sm5) (const 'simple8)) but the symbols shouldn't be quoted: :type '(choice (const sm2) (const sm5) (const simple8)) there are one or two more cases like this. they're labelled in the customize buffer as MISMATCH. -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen
Re: [O] Org-drill doesn't work...
On Wed, Dec 28, 2011 at 10:21:30PM +0100, Milan Zamazal wrote: This is all right. You've just learned all the items and there is nothing to learn/repeat now. Nor tomorrow, there is minimum amount of 4 days by default before you are prompted for the same item again ah, i see. silly me, i should have read that in the docs... (I believe you can customize the interval with org-drill-sm5-initial-interval). In the meantime you can add and train new entries. :-) but org-drill isn't picking up the new entries. i've added a bunch of new entries to the file and they've all been given an :ID: property, but they are not being drilled. i'm sure i'm doing something wrong here, but i can't figure out what... -- Joost Kremers Life has its moments
Re: [O] Org-drill doesn't work...
On Fri, Jan 06, 2012 at 09:27:53PM +0100, Milan Zamazal wrote: It may happen if there is some problem with the contents of the entries (unrecognized items are silently skipped). I was hit by a similar problem but once I realized what's wrong, org-drill started to work perfectly for me. thanks for you reply. it prompted me to look a bit closer at the ignored items and i've now figured out what was wrong with them... it turns out that it is absolutely necessary that there is some text after the header of a drill item, before the first subheader. most of my items lacked this, however. my items looked like this: #+BEGIN_EXAMPLE ** Verb:drill: :PROPERTIES: :DRILL_CARD_TYPE: twosided :END: *** Deutsch some German verb *** Russisch Russian translation #+END_EXAMPLE however, they need to look like this: #+BEGIN_EXAMPLE ** Verb:drill: :PROPERTIES: :DRILL_CARD_TYPE: twosided :END: some text here = absolutely essential! *** Deutsch some German verb *** Russisch Russian translation #+END_EXAMPLE what is inconsistent about the way org-drill handles these is that even though it doesn't use these faulty entries for drilling, it *does* provide them with a unique :ID: property. so initially it doesn't look like there's anything wrong with them... i also didn't find an explicit mention of this in the docs, so perhaps i should send an email to paul sexton... but yes, now that i've figured out what i was doing wrong, org-drill works great! -- Joost Kremers Life has its moments
Re: [Orgmode] Context-sensitive word count in org mode (elisp)
On Wed, Feb 16, 2011 at 03:51:23AM +, Paul Sexton wrote: Improvements welcome. one remark about your naming convertions: (info (elisp) Coding Conventions) especially the second point. in short, you shouldn't use names such as in-comment-p or latex-macro-regexp for global variables and/or functions. use a prefix to distinguish them from other programs/packages. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Can I input multiline in a cell?
On Fri, Feb 18, 2011 at 10:09:07AM -0500, brian powell wrote: I haven't sent any HTMl that I know of--I fully embrace the plain text KISS methods. well, you're not sending plain text messages. look at your headers: Content-Type: multipart/mixed; boundary0485505407== the multipart part means that your messages contain different parts, encoded in different ways. more precisely in your case, your messages consist of a plain text part and an html part, both containing the same text. when i read your message in mutt, this is what it shows: [-- Autoview using elinks -dump -eval set document.codepage.assume = 'ISO-8859-1' '/home/joost/tmp/mutt2xkhQU' --] I haven't sent any HTMl that I know of--I fully embrace the plain text KISS methods. [...] the Autoview using elinks ... part means mutt is calling elinks to display the message. i.e., it's displaying the html part. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] Re: zotero (or mendeley) integration with org
On Wed, Mar 30, 2011 at 10:54:58AM +1000, Alan E. Davis wrote: I wonder if it would help to use orgmode for bibtex *.bib files. I think comments can be included in those files. yes. there is a @comment command, but bibtex ignores everything that's not inside an @entry, @string or @preamble command, so that you could create an org file that contains bibtex entries and use that as your bibliography file. however, i don't know if biblatex+biber is equally forgiving. Or does it also work the other way around, that any file can be used as a bibtex source database? in essence yes, as long as it's a text file and contains valid bibtex entries. (note that bibtex isn't unicode-aware; i have no idea how bibtex reacts to files containing unicode characters in text it's ignoring.) -- Joost Kremers Life has its moments
[O] MobileOrg: Org files already in Dropbox
Hi all, I got an iPad the other day and of course want to try out MobileOrg. The MobileOrg setup instructions say to create a folder MobileOrg in your Dropbox root dir, from where MobileOrg will read the org files. However, I'm already keeping my org files somewhere in my Dropbox folder (in order to keep them in sync between three computers) and if any way possible I'd rather not have two copies of them. So I have a few questions: 1) Can I set org-mobile-directory to something other than ~/Dropbox/MobileOrg (specifically, can I set the directory name to something other than MobileOrg?) 2) Can I set org-mobile-directory to the directory containing my org files, or will this lead to problems? 3) If so, is it possible to set org-mobile-inbox-for-pull to somewhere outside this directory, so that its contents isn't included in the agenda? (I have org-agenda-files set to ~/Dropbox/Work/Organiser.) 4) For the same reason, is it possible to make sure the files agenda.org and index.org that MobileOrg creates are placed somewhere outside the agenda directory? Thanks, Joost -- Joost Kremers Life has its moments
Re: [O] MobileOrg: Org files already in Dropbox
On Wed, May 11, 2011 at 07:59:06PM -0400, Greg Troxel wrote: 2) Can I set org-mobile-directory to the directory containing my org files, or will this lead to problems? I wouldn't. MobileOrg has a concept of the real org files, files converted for mobile use, and reintegrating changes from those back into the real org files. Also while real org can compute agendas, the ones you see in mobileorg are precomputed. Ok, well, if that's the case, then all the other questions are more or less moot. I'll just have to live with having two copies of my org files. :-) Not that it's really that bad, I just wanted to know if its possible to use the original org files as a source for MobileOrg. Thanks, Joost -- Joost Kremers Life has its moments
[O] Separate weeks visually in agenda month view
Hi all, I was wondering if there's a way to separate weeks in month view in the agenda. Either an empty line or a dashed line or something, anything that's more conspicuous than the Wxx that is displayed, because that doesn't really stand out. TIA Joost -- Joost Kremers Life has its moments
Re: [O] HTML5 presentations
On Wed, Jun 15, 2011 at 07:19:46PM +0100, Eric S Fraga wrote: What browser(s) are people using for this? Conkeror doesn't work well at all and iceweasel (aka firefox) 3.5.19 sort of works. since it's an html5 presentation, you'll need a browser with html5 support. i don't think firefox 3.6 has it, you'll need firefox 4. chrome and the latest internet explorer should also work. -- Joost Kremers Life has its moments
Re: [O] Release 7.6
On Thu, Jul 07, 2011 at 09:16:24AM +0200, Bastien wrote: I'm releasing Org 7.6. could it be that the new release hasn't been merged into maint yet? i've created a stable branch tracking origin/maint as per the instructions here: http://orgmode.org/worg/org-faq.html#using-stable-releases-only but doing a 'git pull' tells me already up-to-date and 'grep org-version' gives me a line with 7.5 in it. -- Joost Kremers Life has its moments
Re: [O] Release 7.6
Hi Bastien, Joost Kremers joostkrem...@fastmail.fm writes: On Thu, Jul 07, 2011 at 09:16:24AM +0200, Bastien wrote: I'm releasing Org 7.6. could it be that the new release hasn't been merged into maint yet? You're right -- it's done now, let me know if that's okay for you. Yes, I've just upgraded. Thanks! -- Joost Kremers Life has its moments
Re: [O] Tables in Plain Lists
On Wed, May 16, 2012 at 12:14:45PM -0400, Bernt Hansen wrote: SW sabrewo...@gmail.com writes: I was making notes today as follows: == * List of important items [0%] - [ ] Item 1 - This is an important item. - Remember to do the hokey-pokey. |---|---| | A | B | | C | D | - [ ] Item 2 - This is not as important. == Of course, the plain list terminates when the table starts, so TAB on Item 1 only collapses it to where the table starts. Also, the table can't be indented as part of the list. In the end, I moved the table elsewhere, but for future reference, is there a preferred way to do this? TAB won't indent it but you can use the rectable C-x r o to shift it right so it is part of the list. actually, IME, if you select the table and then hit tab, it does indent. -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen
Re: [O] Tables in Plain Lists
On Wed, May 16, 2012 at 07:13:36PM +, SW wrote: Emacs 23.2.1 with org 7.8.06. Tested with transient-mark-mode enabled and disabled. I selected the table and hit TAB. Point moved by one tab (if I selected from the top to the bottom of the table) or moved into the table (if I selected the other way round) and, in the one instance, the highlight on the region disappeared. But the table remained obstinately unindented. the trick is to move point to the line *below* the table. TAB will then do whatever it does on that line and if it happens to be an empty line or a line with ordinary text, it indents, taking the entire region (including the table) with it. in essence, TAB will do whatever TAB does, regardless of whether the region is active. so if point is still within the table, TAB moves to the next cell, possibly creating a new one. if the line after the table contains a headline and you move point to it, it (un)folds the headline. so you need to make sure TAB is on a line that it indents. -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen
Re: [O] Tables in Plain Lists
On Thu, May 17, 2012 at 12:24:22PM +0200, Gregor Zattler wrote: Really great. This works for me with Emacs 23.4.1 and it's org version 6.33x, while not with the same Emacs and org-version 7.8.10 (release_7.8.10-529-gc4cad9). I copied the version info from the info file since org-version shows no version any more. it works for me with: Elisp emacs-version 24.1.50.1 Elisp org-version 7.8.09 -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen
[Orgmode] Timestamp format questions
Hi all, Being a long-time Emacs user, I've finally decided to take the plunge and try org-mode. I'm still in the process of figuring out what the best way is for me to use it, (and I suspect I'll need a few more weeks to do so ;-) but I'm wondering about timestamps, especially about how to represent certain things that seem to me rather common but aren't discussed explicitly in the manual. Most pressing: how can I say that a certain event occurs every week on a certain day and time, but only for a limited period? E.g., for classes I teach I want to be able to say 'this class takes place from April 8 through July 8, every Thursday from 12.00 to 14.00. If I write: 2010-04-08 Thu 12:00-14.00 +1w I get the correct time and interval, but of course it doesn't stop at the correct date. However, if I write 2010-04-08 Thu 12:00-14.00 +1w--2010-07-08 Thu then it shows up *every day* in the agenda view, not just on Thursdays. (That actually looks like a bug to me, but perhaps I'm doing something wrong.) Also, is there a way to say that a certain event that occurs every week does not occur on one specific date? For example, I teach a class every Thursday, but the Thu. 13th of May was Ascension Day, so the class was cancelled. I would like the event to not show up on such days. BTW, I'm using Aquamacs 2.0, (org-version) says 6.33x, in case that's relevant. TIA Joost -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Timestamp format questions
On Tue, Jun 08, 2010 at 06:32:46PM +0200, Carsten Dominik wrote: On Jun 8, 2010, at 11:13 AM, Joost Kremers wrote: On Mon, Jun 07, 2010 at 02:40:30PM -0400, Matt Lundin wrote: The function org-diary-class nicely covers the scenario above: --8---cut here---start-8--- * 12:00-14:00 Weekly class %%(org-diary-class 4 8 2010 7 8 2010 4) --8---cut here---end---8--- http://orgmode.org/worg/org-faq.php#org-diary-class Is it still possible to schedule the time of the event as well? It is already there, 12-14! Oh, cool! I didn't know the time in the header is also added in the agenda view. Now that I've actually tried it, it works beautifully. :-) (I'm a bit surprised, though, that the format is `Month Day Year', when normally Org-mode uses `Year Day Month'... ;-) Year Month Day, of course... ;-) I hate this as well, but the decision was to be consistent within sexp commands. Calendar date format applied to all other sexp commands from the diary Sometimes you have to make difficult choices :-) Yup, life's that way. Thanks for your reply. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] cycle visibility from agenda view?
hi all, when i'm in an agenda buffer i can use follow mode (or the space bar) to view original location of an item. however, sometimes (usually?) the relevant tree isn't shown entirely, which is not always what i want. is there a way to cycle the visibility of the relevant item from within the agenda buffer? i haven't been able to find anything... tia joost -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] a bit offtopic, fonts in exported PDF documents - oops
On Mon, Aug 30, 2010 at 11:58:15AM -0400, Nick Dokos wrote: Erik Iverson er...@ccbr.umn.edu wrote: Both this system and MikTeX offer cm-super as a standalone package, so perhaps just recommending that package (cm-super) would suffice? I confirmed that cm-super is not one of the default MikTeX packages in a standard install, so Windows users may benefit from this advice, too. Do windows users use evince? I'd think they mostly go with Acrobat Reader, in which case they should have no problems with Type3 fonts. until they start sending their pdfs to other people, who might not be so lucky... ;-) Joost -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Texi2dvi: forcing a recompile?
On Sat, Dec 04, 2010 at 03:28:30PM -0500, Jeff Horn wrote: On Sat, Dec 4, 2010 at 3:22 PM, Jeff Horn jrhorn...@gmail.com wrote: On Sat, Dec 4, 2010 at 3:20 PM, Mike McLean mike.mcl...@pobox.com wrote: I solve this with a forced remove: (setq org-latex-to-pdf-process (quote (rm %b.pdf texi2dvi -p -b -c -V %f))) Nice! Very clever. Thanks for the tip! (CC-ing to the list, hope that's OK) Small problem: if the file doesn't exist, rm fails with error, which stops the process (the PDF file is not produced). This happens if I create a new source file in my project. change rm %b-pdf to rm -f %b.pdf, that should take care of it. -- Dr. Joost Kremers Georg-August-Universität Seminar für Deutsche Philologie Käte-Hamburger-Weg 3 D-37073 Göttingen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Export LaTeX file to different directory?
Hi all, If I export (part of) an org-mode file to LaTeX, the LaTeX file is created in the same directory as the org-mode file. Is there a way to specify the file should go somewhere else? Googling and looking through the manual didn't give me anything concrete. There is apparently a property EXPORT_FILE_NAME, but setting this doesn't seem to have any effect. (Though I may be using it wrong, there wasn't any description or example of it in the manual... Plus, I'd like to be able to specify just the export directory, not necessarily the file name as well.) TIA Joost -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Export LaTeX file to different directory?
On Mon, Dec 13, 2010 at 12:07:56PM +0100, suvayu ali wrote: [EXPORT_FILE_NAME] I think you have to set it as a property for the sub-tree you are trying to export. So whenever you export only that sub-tree, the file name will be taken from that property. I tried various incantations, including the one you mention, none of them seem to have any effect... For setting the directory you could try something like 'directory/filename.pdf' instead of just the usual file name. (untested) I am not aware of any directory only settings for export of sub-trees. Actually, I'm exporting a region, but that should pretty much work the same way. The thing is, I'm keeping lots of stuff in several org files and occasionally I want to export some of it (in this case it was a table) to latex/pdf in order to print it or send it to someone. I'm not actually interested in the .tex or .pdf file itself and I don't want to clutter up the directory containing my org files. So preferably the latex/pdf file should go into ~/tmp or /tmp, where it can sit until I clean it out. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Export LaTeX file to different directory?
On Mon, Dec 13, 2010 at 12:52:41PM +0100, suvayu ali wrote: I just tested this, it seems to work as expected. * Smearing :smear: :PROPERTIES: :EXPORT_FILE_NAME: tmp/smearing.html :END: ** Some sub-tree 1 ** Some sub-tree 2 Does this not work for you? it works if i export a subtree (C-c C-e 1 l), but not if i export a region (set mark, highlight region, then C-c C-e l). also, it doesn't expand a tilde ~ to my home directory, so writing :EXPORT_FILE_NAME: ~/tmp/temp.tex doesn't do what one would expect. (note that i can't write the full path because i switch between linux and OS X, which expand ~ differently: linux to /home/name, OS X to /Users/name.) also, i'd like to be able to specify an export directory for the entire org file, not just a subtree. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Export LaTeX file to different directory?
On Mon, Dec 13, 2010 at 10:57:45AM -0500, Nick Dokos wrote: Joost Kremers joostkrem...@fastmail.fm wrote: If I export (part of) an org-mode file to LaTeX, the LaTeX file is created in the same directory as the org-mode file. Is there a way to specify the file should go somewhere else? Googling and looking through the manual didn't give me anything concrete. There is apparently a property EXPORT_FILE_NAME, but setting this doesn't seem to have any effect. (Though I may be using it wrong, there wasn't any description or example of it in the manual... Plus, I'd like to be able to specify just the export directory, not necessarily the file name as well.) If the more refined methods don't work for you, here is a somewhat brute-force way: #+BIND: org-export-publishing-directory /tmp thanks, but this doesn't seem to work for me at all. :-( i'm using org version 7.4, if that's relevant at all. the variable org-export-publishing-directory is defined in org-exp.el (with defvar and a FIXME...), but it's not used anywhere in a meaningful way, AFAICT. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Export LaTeX file to different directory?
Thanks, everyone, at least now I know there's no easy and straightforward way to do this. May I suggest a feature addition? ;-) On Mon, Dec 13, 2010 at 08:14:11PM -0800, Richard Lawrence wrote: Yes, there is a Publish current file option in the export dispatcher, though I've never used it myself. Using this option with the right combination of :base-directory, :publishing-directory, and :exclude/:include in org-publish-project-alist might do the trick, depending on the OP's exact scenario. TBH it really sounds like too much configuration for the occasional export that I do... So the next time the need occurs, I'll have forgotten how I did it. But because WHEN I need to export stuff, it's usually more than a single region, it's annoying that the export to buffer, save to temp dir, run latex-sequence cannot be automated... J. -- Joost Kremers Life has its moments ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
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
[O] Programmatically handling org files
Hi all, 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? Specifically, I'm wondering about creating and deleting entries (by entries I mean headers with their contents), changing TODO state, moving entries, that sort of thing. 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. TIA -- Joost Kremers Life has its moments
Re: [O] Programmatically handling org files
On Mon, Sep 12 2016, Thorsten Jolitz wrote: > by "non-org Emacs packages" you mean Emacs packages written in Elisp, > but not part of Org-mode? Yes, exactly. My wording wasn't entirely clear, I admit. > The org-mode parser converts an Org document into a nested list and > provides many convenience functions to work on this parse tree. So > org-element.el (and maybe ox.el too) is the core library for converting > an Org text document into an Elisp data structure and working with that, So IIUC org-element.el is mainly for getting the contents of an org buffer in such a way that a program can work with it, but not really for modifying the contents of the buffer itself in such a way that it's still a valid org document, right? > If you feel you don't need the whole parse tree, but rather want to act > locally on the Org element at point, Yes. :-) > you might want to look at > org-dp.el Cool, I will do that! > with just two core functions (create and rewire an Org > element) and a mapping functions (plus quite a few utilities in > org-dp.el and org-dp-lib.el): [snip example] > Using this system, creating or rewiring an Org Element from Elisp > requires only to define the values of the interpreted parameters, all > the low level stuff (actually creating and inserting the new/modified > element in text form) is left to the interpreters (from org-element.el). > > You just declare what you want and don't worry anymore how it is done > (=> dp stands for declarative programming, in this context at least ;-) That sounds pretty cool, thanks! -- Joost Kremers Life has its moments
Re: [O] Programmatically handling org files
On Mon, Sep 12 2016, John Kitchin wrote: > indeed! Maybe I misunderstood the OP. > > You can find more on the API here: > > http://orgmode.org/worg/dev/org-element-api.html > > There are also a bunch of functions to do other things, e.g. > > (org-todo) (org-cut-subtree) (org-entry-put) and many others > > that let you change properties of headings, cut them, etc... > > These are documented in the org code. The best way to learn how to use them > is to reverse engineer how you would make the change you want manually, > e.g. which keys do you press, then use C-h k on those keys to see what > commands get run. Yes, I've been doing that and I've arrived at something that works, just wasn't sure it was the Right Way™. :-) -- 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
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] 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 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
[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] 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
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
[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
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
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
[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] 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] 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: 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] 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] 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] 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] 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] 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] 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] 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] 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
[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: 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
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: 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
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
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: 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
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 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: 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
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
: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: :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 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 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 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
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
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: 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: 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
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: 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
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
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: 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: 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: 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
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=
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: 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: [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: [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: 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: (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: 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: 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
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: 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
